Cachowanie danych użytkownika Opcje

[rebuk]

Witam, potrzebuję rady odnośnie cachowania.
Przy ogólnodostępnych stronach serwisu stosuję cache do plików tekstowych, ale jaki cache należy stosować dla pojedynczego użytkownika po zalogowaniu się przez niego na swoje konto?
Użytkownicy na różnych zakładkach swoich kont mają wyświetlane wiele informacji (zarówno prostych jak adres avatara, data rejestracji ale i dane osobowe) - wszystko zapisane w bazie danych.
Szkoda, żeby każde odświeżenie lub przejcie na inna zakładkę/podstronę wiązało się z łączeniem z bazą.
Jak najlepiej (głównie pod względem bezpieczeństwa) cachować te dane? Na plikach, w sesji?

[nospor]

Akurat profilu uzytkownika ktory jest do edycji to ty nie cache'uj.

[Pyton_000]

Dla czego nie? Po zapisie tylko odbudować cache i tyle.
A gdzie? Gdziekolwiek. Może być sesja.

[nospor]

Ale po co? Po co cacheowac cos gdzie user zaglada raz do roku. Tylko zbedny proces.

[LowiczakPL]

User zagląda raz na rok ale inni zaglądają co sekundę

Dlatego nie keszuje się danych zmieniających się co chwilę ale stałe dane, które są edytowane powiedzmy raz dziennie.

Taki kesz jednodniowy to ogromne odciążenie bazy danych.

Ja keszuję dane do plików ale problemem jest ilość plików. W pewnym momencie LINUX się zawiesił bo było za dużo utworzonych plików w systemie.

Musisz pilnować ilości plików utworzonych w Linuxie i zwiększać limit co jakiś czas

Ten post edytował LowiczakPL 4.07.2016, 12:44:04

[daro0]

Ale da się w ogóle cokolwiek ugrać na wydajności?

[nospor]

Z tego co zrozumialem chodzi o dane dla zalogowanego usera i o jego wlasne dane a nie o dane dla wszystkich. No, ale ostatnio ciezko rozumuje wiec moge sie mylic

[LowiczakPL]

Masz rację, tylko kto keszuje swoje edytowalne dane, keszuje się dane dla kogoś bo to oni widzą niezmienne dane i to te dane zaciągane są tysiące razy z bazy, moje zaciągane są 1 raz.

Więc w tym przypadku cache to tylko dodatkowe obciążenie serwera

Ten post edytował LowiczakPL 4.07.2016, 12:48:10

[rebuk]

Dobrze rozumiesz nospor
Może obrazowo przedstawię:
- Użytkownik loguje się do serwisu i wchodzi do swojego panelu administracyjnego.
- Na głównej stronie swojego PA pobierane dane z bazy
- Użytkownik odwiedza kilka zakładek na swoim koncie: edytuje dane, sprawdza status zamówień, pobiera faktury, dodaje nowe rekordy do bazy itd.
Odwiedzenie każdej zakładki wiąże się z pobieraniem rekordów z bazy danych (w większości z tych samych tabel).
W przypadku np. forum faktycznie do panelu administracyjnego prawie się nie zagląda, ale już np. w serwisie gdzie użytkownik prowadzi sprzedaż to praktycznie przy każdym logowaniu się tam zagląda.
Pobieranie z bazy kilka(/naście) razy tych samych danych w ciągu kilku minut wydaje mi się rzeczą którą warto zoptymalizować (szczególnie przy większej ilości użytkowników)

[nospor]

Nom, to skorom dobrze rozumowal to podrzymuje swoje zdanie

[daro0]

@rebuk Ale optymalizacje to się robi jak jest co optymalizować a bez takich narzędzi jak profiler to sobie można. Każdy liczący się FW ma takie narzędzia, jeśli takiego nie masz to jedyne co możesz zrobić to dawać znaczniki czasu przed i po, przy użyciu funkcji microtime, to Ci da pewien obraz co i ile się wykonuje. Nie wiem czy używasz MySQL ale z tego co tu pisze to już sam silnik ma coś takiego:

http://dev.mysql.com/doc/refman/5.7/en/query-cache.html

Poza tym w jakiej postaci masz to zrealizowane? Serializujesz dane i zapisujesz cokolwiek na czym robisz cache do jednego tylko katalogu? Frameworki mają w File Store nazwy plików cache jako SHA1 albo md5 z tego co się zapisuje (po nazwach kluczowych), do tego jeszcze tworzone są podkatalogi o nazwach z dwóch pierwszych znaków z tych nazw plików czyli 00..ff, masz więc pliki cache rozmieszczone w 256 podkatalogach, o ile będą utworzone. Laravel dzieli jeszcze te podkatalogi na kolejne podkatalogi z 2 kolejnych znaków z nazw plików, więc zapisuje cache np tak:

app/storage/cache/a1/91/a1918afa3f5dd7f8369287c0f18ad874

i jak widzisz masz podkatalogi a1 a potem 91 które są od nazwy pliku tego cache które jest tak naprawdę md5 z klucza.

Dodatkowo na file store robi się garbage collector, więc wygasłe cache usuwa się probabilistycznie przy użyciu mt_rand albo rand, więc usuwane są wygasłe już pliki cache a podkatalogi raczej zostawiane, tak żeby zwolnić miejsce na dysku.

Ale oczywiście masz rację, bo robiłem cache np. na generowaniu danych do PDF, tutaj nie ma sensu czegoś takiego robić za każdym razem na tych samych danych, tak samo jak używałem cache przy pobieraniu nie zmieniających się danych z zewnętrznych JSON-owych API ale to też dobrze widać jak to działa i ile się da ugrać przy użyciu profilera. No ale jak dane zmieniają się zbyt często to zastanawiam się gdzie tu jest sens?

[rebuk]

Nie wiem czy używasz MySQL ale z tego co tu pisze to już sam silnik ma coś takiego:
http://dev.mysql.com/doc/refman/5.7/en/query-cache.html

Cenna informacja o której nie wiedziałem, dzięki!