Van valakinek tippje, hogyan lehetne egy lamp teljesítményét rendesen feltuningolni?
Mondjuk egy ab-bal mért (-c 5 -n 1000) eredményt drupalnál (vagy any PHP) valahogy 100 request/sec fölé tornászni? :)
APC, reverse proxy nem segített igazán. A legjobb teljesítmény valahol 10(drupal) és 40(wordpress) req/sec között mozog. Statikusnál ~2700 r/s.
Meglátásom szerint nem csak maga a php/apache használata problémás. A Mysql is igazán lerohasztja az erőforrásokat. :S
- 1154 megtekintés
Hozzászólások
statikus fajloknal ugye az apache kvazi memoriabol dobalja vissza a valaszt, ezert nincs io, cpu bound.
1 gepes kornyezetben imho nem fogsz oldal szintu cacheeles nelkul egy ilyen osszetetsegu php alkalmazasbol(drupal/wordpress) 100 request/sec-t csinalni.
40req/sec-nel 1 orara 144k lapletoltes jut.
ha mondjuk csak a peak idoben van ekkora forgalmad(~8 ora), az 1152000, azaz tobb mint 1 millio lapletoltes.
a prohardver.hu lapcsaladja bonyolit kb. napi 1 millio lapletoltest.
http://prohardver.hu/hir/megujult_a_prohardver.html
persze, attol fuggoen, hogy mint csinal az alkalmazas, lehet rajta optimalizalni, csak probaltam erzekeltetni, hogy hova keves a 40 request/sec.
Tyrael
- A hozzászóláshoz be kell jelentkezni
5 percen belül beírja mondjuk 1000 TV reklám nézője a webcímet és lehal a szerver, nem kell hozzá 1 millió lapletöltés.
Ahol ilyesmire számítani kell, ott egy script generálja a dinamikus tartalmat html-be, ami már statikus fájlként megy ki. Ilyen pl a www.valasztas.hu is.
- A hozzászóláshoz be kell jelentkezni
Szerintem a reverse proxy jobb ötlet.
- A hozzászóláshoz be kell jelentkezni
5 perc, az 300 sec, 300 sec alatt 1000 lapletoltes az masodpercenkent 3.3, ettol csak nem fog felborulni a szerver.
Persze, ha mind az ezer ugyanabban a masodpercben nezi az oldalt, az mas teszte.
statikus fajl generalas jo lehet, ha megoldhato, de inkabb kevert megoldas a divat reverse proxy pagecache megfelelo szuressel es invalidalassal, illetve az alkalmazasban is amit lehet cachelni, amilyen magas szinten csak lehet.
de ahol ekkora forgalom van, ott nem 1 gepes felallas a diva.
szerintem.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Most szenvedek én is egy Magento-val. Sokat javított az egész sebességén, miután a statikus fájlokat nem az apache, hanem egy nginx szolgálta ki.
Aztán a mysql tuningolása után 1s/főoldal letöltődése 700ms-re változott. A következő lépés a var könyvtár RAM partícióra rakása, mert egy halom xml-t dolgoz fel a magento futásidőben és a cache-t is oda teszi. Több ötletem nincs sajnos. A probléma az, hogy a megrendelő ezt a php4-es überprimitív oldalt hasonlítja hozzá: http://dvdfutar.hu/ (itt mértem már 100ms alatt is a főoldalra). Vettem már részt egy másik Magento projektben, ott az apache indítása után 2GB RAM-ot megeszik a Magento. Ez az a webáruház, amit jobb lett volna Java-ban írni, mert a gépigénye ugyanott van viszont nem skálázható.
Drupalnál szintén a sites/all/themes mehetne nginx-en vagy lighttpd-n keresztül és meg lehetne nézni, hogy mik azok a fájlok, amikhez sokat nyúl, azok szintén mehetnek ramfs-be.
Drupal cache nálam még soha nem működött úgy, ahogy kellene, soha sem kapcsolom be.
- A hozzászóláshoz be kell jelentkezni
Drupalnál a sites/*/files-t érdemes nginx-szel kiszolgálni, oda generálódik mindenféle cachelt css és js.
ramfs-nek nem sok értelmét látom, ha van elég ram, akkor úgyis a file cache-ben fog az egész Drupal ülni. Ha meg kevés a ram, és valaminek kell, akkor a file cache kivágása mindig kisebb fájdalom, mintha elkezd swappelni a webszerver. ramfs helyett érdemes lehet az APC opcode cache méretét növelni.
- A hozzászóláshoz be kell jelentkezni
"Aztán a mysql tuningolása után 1s/főoldal letöltődése 700ms-re változott."
ha en lennek a megrendelo, en is reklamalnek, ez sok. plane a fooldalra.
a talalgatasos optimalizalas helyett lehet hogy erdemesebb lenne megmerni, hogy mivel tolti az alkalmazas a futasidot, es ott optimalizalni a lehetosegekhez merten.
nem ertem mire gondolsz amikor azt irod, hogy 2G-t eszik indulas utan az apache alatt a magento a masik projectben.
nem gondolom hogy 1 lapletoltes generalasahoz 2G ramot hasznalna az alkalmazas, gondolom inkabb az osszes inditott apache worker altal allokalt memoria volt 2G, de arrol meg nem az app hanem a php, illetve a moduljai tehetnek, kiveve ha maga az alkalmazas leakel esetleg memoriat.
na mind1, elleptem aludni. :)
Tyrael
- A hozzászóláshoz be kell jelentkezni