Cache to podstawa

4

Spędziłem ostatnią dobę albo i więcej na optymalizacji serwera i w nieco mniejszym stopniu – blogaska. Wszystko z powodu zauważonego krztuszenia się apache na.. 20 odwiedzinach w tym samym czasie (~30s) z powodu lekkiego napływu ludzi z wykopu – tak, znowu spamowałem!

Nigdy wcześniej nie przykładałem do tego takiej uwagi, na własnym serwerze siedzę ledwo kilka miesięcy i też nie przypuszczałem robić tutaj jakikolwiek wykop efekt itp. aby przygotowywać maszynę na sporo ludzi –  i tak serwer setki razy szybciej chodzi od byłego webd. No ale żeby nie dać sobie rady z ludźmi z durnych linków powiązanych?! Trzeba było coś z tym zrobić i wiochy nie prezentować ;-)

Z resztą odważniej postanowiłem korzystać z zasobów serwera, po za tym zupełnie wymieniłem konfigurację w związku z moją migracją do polski około tydzień temu – kto ogląda mojego blipa, ten wie, że na hetznera nieprawdopodobnie narzekałem.

Apacze co ja pacze

Niestety korzystam z jednego rdzenia tylko na moim koncie, więc nie przejdę na moduł workera w apache który wykazuje się większą wydajnością – pozostaje prefork, mozolny, ale stabilny. Serwer startuje z 4 procesami, do pomocy ma 6 wolnych pomocników maksymalnie do 16 (StartServers / MinSpareServers / MaxSpareServers). MaxClients, czyli limit procesów nie jest za duży (nie przyznam się ile, ale oscyluje między 30 – 80), MaxRequestsPerChild postanowiłem ustawić na 500 no i ServerLimit: ~256. Maszyna z 1GB Ram z Burst’em na 2GB: Na dzień dobry między 550-800MB pochłania (wiele usług, nie tylko serwer webowy), po kilku dniach uptime’u: ~1,2GB. Na usprawiedliwienie oszczędności zasobów: hostuje kilka kont, każde ma swoje procesy apacha, fcgi-php, dovecot… Wszystko od siebie odizolowane, liczę się z tworzeniem następnych.

Jeśli się wzorujesz ustawieniami… to przestań: ustawienia dobieraj według swoich przemyśleń, poczytać, testuj… każdy wykorzystuje serwer w innym celu, moje ustawienia niekoniecznie mogą pasować do Twoich upodobań.

Jak to jest, że nie miałem cache?

Jakoś tak się stało, że byłem święcie przekonany, że mam eAcceleratora wkompilowanego/dołączonego do php. Nie miałem go.

Przyszedł moment wyboru: XCache, eAccelerator albo APC… wybrałem ostatniego, bo wejdzie w jądro PHP6 – więc czemu już teraz go nie wypróbować? Wszystkie trzy rozwiązania zbliżone do siebie wydajnościowo, więc ence pence… Przy okazji przekonało mnie zwykłe proste apt-get install zamiast wypakowywanie, kompilowanie itd., które było wymagane np. przy eAcceleratorze.

Do tego dołączam php5-memcache i już możemy się zadowolić zależnościami w…

WordPress?

Wziąłem „highest rated and most complete WordPress performance plugin”, czyli W3 Total Cache a w nim już wykorzystanie APC, jeszcze popracuję nad CDN’ami i szablonem – kolejny rok czeka do poprawki – …efekty zagięły mi jaja.

Jak wyglądały testy?

Apache ma takie fajne narzędzie dołączone do siebie: ab a’ka Apache Benchmark – cudo do floodowania serwera requestami do tego podaje na koniec przyjemne statystyki i można już z tego czerpać inspirację.

Postanowiłem za bardzo nie przesadzać (na początku) w ogólnym testowaniu: 100 requestów, każdy z 5 lub 15 jednocześnie. Wszystko prowadzone na moim blogasku, więc pełen pakiet: php+mysql  – wszyscy wiemy, że WP jest dość wymagający. To wyniki jednego z testów:

Bardzo przed

Czas testów [s]: 315/198
Zesrane requesty: 2/53
Requestów na sekundę: 0,32/0,51 (o masakra)
Maks. czas requestu [s]: 15,78/29,65
Średni czas requestu [s]: 3,16/1,98
Transfer rzędu [KB/s]: 19,6/15,2

Po optymalizacji serwera

Czas testów [s]: 251/209
Zesrane requesty: 1/62
Requestów na sekundę: 0,40/0,48
Maks. czas requestu [s]: 12,55/31,34
Średni czas requestu [s]: 2,51/2,09
Transfer rzędu [KB/s]: 24,8/11,7

Czy ta optymalizacja dała więcej dobrego, niż złego ;-) ?

Dodałem cache

Czas testów [s]: 9/6,7
Zesrane requesty: 33/74 (mhmmmm)
Requestów na sekundę: 10,9/15
Maks. czas requestu [s]: 4,57/10
Średni czas requestu [s]: 0,91/0,67
Transfer rzędu [KB/s]: 591,2/809,9

Szczególnie ciekawa jest pozycja zesranych requestów – błąd przy dynamicznie generowanych stronach, na który wiele ludzi zwraca uwagę ;-). Równie ciekawe i ważne jest sprawdzenie postępu requestów w poszczególnych jego momentach: tych danych nie publikuję.

Po takim dość prostym teście od razu widać, jakie znaczenie pełni (tak niedoceniane przeze mnie) cache – nawet jeśli hostujesz prostą stronę (aw., te mordercze połączenia do bazy), warto optymalizację zastosować na przyjście reddit’a/wykop’u – nigdy nie wiesz co Cię dopadnie ;-)

Ale też postanowiłem raz bardzo przesadzić: 10000 requestów ze 30 żądaniami jednocześnie: bez cache serwer zesrałby się pewnie od razu – już sam drugi test pożerał bardzo pamięć i procesor, gdzie z pomocą cache nie odnotowałem większego obciążenia!

Nie wzoruj się!

Nie jestem pro administratorem – nie wzoruj się na moich testach, dobrałem je dlatego, bo tak uznałem za słuszne i z podobną sytuacją spotkałem się kilka dni temu. Raczkuję dopiero na polu administracji hostem, za rok pewnie będę mógł zaśmiać się z tego postu, bo wciąż się rozwijam i wszystko udoskonalam ;-)

Mimo wszystko: wczoraj (dzięki spamowaniu! / inne wczoraj niż na początku postu) z bardzo przyjemną wydajnością (nie jakieś ładowanie 5 sekund, lol!) obsługiwałem 30 osób jednocześnie na blogu (wcześniej był problem) – chyba, jesteś świadomy, że szybkość i dostępność usługi jest dzisiaj kluczowa w dotarciu do odbiorcy ;-) ? I tak oto dobiłem +500 UU w statystykach…

Tagi: , , , , , , ,

Komentarze 4 komentarze

A dlaczego nie nginx ?

Strach przed tym, co nieznane ;-)

„Wszystko jest szybsze od apache :)”

Skomentuj