![]() ![]() |
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%)
|
Ostatnio zacząłem się interesować systemem cachowania, gdyż niektóre elementy na mojej stronie długo się generują.
Ja wymyśliłem coś takiego:
I do testów użyłem:
Proste, funkcjonalne. Tylko czy szybkie? Na pewno wykonuje się szybciej niż generują się dane. Jak wygląda sprawa z kompresją? (Czy dobrym pomysłem jest jej zastosowanie) Myślałem, aby dane wrzucić do wielowymiarowej tablicy i potraktować serialize" title="Zobacz w manualu PHP" target="_manual a przy odczycie z powrotem do tablicy unserialize" title="Zobacz w manualu PHP" target="_manual Jak Wy to widzicie? P.S. Jak najlepiej mierzyć czas wykonywania skryptu? (Pomysły na to, które widziałem to zapisanie czasu na początku i na końcu odejmowanie + wyświetlenie) |
|
|
|
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%)
|
ja poprostu zapisuje w pliku $value = ................. wystarczy include i mamy w skrypcie $value ktory posiada to co nam potrzeba... chyba najbardziej trywialne rozwiazanie... Tak, ale mi chodzi aby zaoszczędzić miejsce na dysku. (IMG:http://forum.php.pl/style_emoticons/default/haha.gif) Zrobiłem taki test: Plik testowy bez kompresji bzip2: 116KB Po kompresji bzip2: 2KB Różnica jest i to spora. Czas z konca - czas z poczatku jest IMHO the best (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Tak, ale do czasu doliczone są również te operacje. (IMG:http://forum.php.pl/style_emoticons/default/haha.gif) Chyba będę musiał przy tym zostać... ;d Kolejny test: Strona na której pobieram dane z mysql (około 100 wyników) Czas wykonania skryptu: 0.01926 sekund(y) Te same dane z cache: 0.00145 sekund(y) Pomimo kompresji, znacznie szybciej odczytuje z cache. Kolejny test: Dane z mysql: 0.67112 sekund(y) Dane z cache: 0.02267 sekund(y) (Troszkę większa ilość danych i jakie różnice na korzyść cache) Ten post edytował fifi209 11.06.2009, 09:22:58 |
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%)
|
Wiec po co ten watek? Pytasz czy szybkie? Robisz testy i....... roznice widac golym okiem.... wiec w czym tu problem? Cache dziala tak jak powinien... masz zaoszczedzony czas i miejsce na dysku o co jeszcze chodzi? Mozesz pomyslec nad stopniem kompresji... lepsza kompresja - wolniej, gorsza - szybciej... znajdziesz jakis kompromis... poza tym cache ma jakis TTL... wiec nie kompresujesz tego co wywolanie strony... a dekompresja jak widzisz przebiega kilkukrotnie szybciej.... Głównie chodziło mi o to jak Wy to robicie. I czy zastosowanie kompresji jest dobrym pomysłem (jeżeli chodzi o szybkość) Czy dane lepiej zapisywać jako tekst czy jako zserializowaną tablicę? Ten post edytował fifi209 11.06.2009, 10:00:18 |
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%)
|
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 444 Pomógł: 79 Dołączył: 26.05.2009 Ostrzeżenie: (0%)
|
zapisuj pliki w postaci
i masz serializacje z glowy (tylko pamietaj o addslashes() lub czyms podobnym) co do kompresji - skoro celem jest przyspieszenie ladowania strony to jest ona zbedna - przeciez przestrzen dyskowa nie jest towarem ekskluzywnym (a przynajmniej w takich ilosciach) |
|
|
|
Post
#6
|
|
|
Grupa: Moderatorzy Postów: 15 467 Pomógł: 1451 Dołączył: 25.04.2005 Skąd: Szczebrzeszyn/Rzeszów |
Cytat Głównie chodziło mi o to jak Wy to robicie. serialize" title="Zobacz w manualu PHP" target="_manual jest najszybsze w parsowaniu, jeśli chodzi o pliki (co ciekawe, szybsze niż var_export" title="Zobacz w manualu PHP" target="_manual). Chyba o tym, że kompresja cache'u jest fatalnym pomysłem, nie muszę wspominać. Masz odciążyć serwer, a nie go jeszcze dobijać. Jeśli potrzebny jest wyższy kaliber - cache z akceleratora (eAccelerator coś takiego umożliwia), APC, potem shm, memcached, jest tego nawet sporo. ;] |
|
|
|
![]() ![]() |
|
Aktualny czas: 24.12.2025 - 20:22 |