Hej,
niedawno byłem ofiarą wykop-efektu i stwierdziłem, że czas najwyższy wziąć się za temat cachowania.
Po kilku godzinach zawziętego klepania i testowania wyszło mi takie oto coś:
http://files.ognisco.com/kickasscache/kickasscache-20110608/KickAssCacheApc.php
aby tego użyc trzeba:
Hmmm... sam się miałem zabrać za tworzenie jakiegoś małego cache. Tylko coś zabrać się nie mogę tym bardziej że sądzę że mam bardziej "elementarne" rzeczy do dopracowania. Ale w testach wygląda fajnie. Ciekawi mnie jak spisuje się w porównaniu do tej metody: http://blog.wilgucki.pl/2010/10/statyczny-cache-w-zend-framework.html (Niestety nigdy mi się do tego nie udało skonfigurować apache a szkoda bo wygląda obiecująco :) ). No niby można tu część ustawień papugować z WP Super Cache ale i tak było to dla mnie za trudne na dzień dzisiejszy :/
Jak będę miał chwile to zobaczę jak u mnie testy wypadną :)
statyczny cache jest najszybszy bo mozesz uzywac samego lekkiego serwera www bez uruchamiania modulu php, problem raczej jest z uzywaniem tego ze wzgledu na dynamicznosc kontentu i separacje serwera danych od serwera logiki.
a ten moj kickass to goly php + apc i odziwo daje rade ;D
2krps? To ma być coś nadzwyczajnego (przy cache'owaniu pełnej strony)? W szczególności, że nie podałeś ile było bez tego mechanizmu. Ja bym wolał postawić varnisha przed tym wszystkim, dać mu agresywny cache i nie martwić się w ogóle o ruch rzędu dziesiątek/setek krps (widziałem jak obsługuje 300krps, przy ruchu z kilku maszyn, nie localhost <-> localhost).
bez tego mechanizmu bylo miedzy 5...8 req/s :) oczywiscie ze sa inne metody cachowania, ale to jest goly php ktory mozna uzyc w 3 linijki kodu i ktory jako tako daje rade, cala magia to nie sam cache tylko mutexy :P
5-8 normalnego ruchu, czy podczas benchmarkowania z tymi samymi parametrami?
podczas benchmarkowania, zrobilem ten cache pod cycki,
bez apc: 5req/sec
z apc: 8req/sec
z apc i kickass cache ale bez mutexow: 500req/sec ale zwieszalo przy odswierzaniu cache
z apc, kickach i mutexem: do +- 2000 req/sec
zalozenie jest takie ze jesli nagle wzrosnie liczba polaczen (wykop efekt) to wtedy wiekszosc odpowiedzi bedzie serwowana z cache, natomiast przy odswierzaniu jest wyscig polaczen ktore pierwsze zrobi locka wiec nawet jezeli wiecej niz jeden request uruchomi reszte aplikacji to nic sie nie dzieje bo naraz bedzie tego znikoma ilosc (testowane przy konkurencyjnosci = 200)
kumpel zrobil test na swojej apce
i z 137 wskoczyl na ponad 4.5k requestow / sec :D
zreszta podejzewam ze gdybyscie to wstawili na 4p to zysk bylby widoczny,
ttl = 5 i randomfactor = 7...10
jedynie trzeba by chyba dorzucic sesje do generowania cache id
4p jest na tyle dynamiczne, że nie da się cache'ować całej strony jak w tym przypadku. Poza tym każdy user ma inaczej zaznaczone wątki na forum. Do cache nadawałyby się raczej tylko artykuły, które IMO generują jakieś 10-20% ruchu, więc zysk byłby marginalny. Cacheowanie fragmentami może by przyniosła większy zysk, ale może być to trudne.
Do forum trzeba zastosować zupełnie inne rozwiązanie (przeniesienie części logiki na stronę klienta), a jako że mamy dedyka to nie ma sensu pakować warstwy cache do php'a, skoro dokładnie to samo (a nawet więcej) może zrobić jakieś dedykowane narzędzie do cacheowania.