Optimalizace vykonu PHP aplikace rubrika: Programování: PHP

5 kacerr
položil/-a 1.12.2013

Zajimaly by mne zkusenosti s optimalizaci vykonu serveru s PHP. Mam na mysli zejmena PHP cast, vyuziti nejaky opcode cache? Zend opcache / XCache / APC. Momentalne se mi jedna o PHP 5.4 (upgrade na PHP 5.5 momentalne asi neklapne) - nicmene to, ze zend opcache nebo co presne tam je jiz soucasti PHP asi naznacuje ze to je spravna cesta. A co hiphop/hvvm?

Druha cast je spis k analyze aplikace? Xdebug profiling + nejaky cachegrind k analyze. Pouzivate? Jaky jsou s tim zkusenosti? Nejaky "materialy" kde se dozvim vic jak s tim zachazet spravne?

Hraju si s tim chvili, na par zajimavych veci jsem prisel, nicmene nakpnuti spravnym smerem, nebo varovani pred spatnym smerem by mi mohlo dost pomoci. O to co jsem zatim vyzkoumal se rad podelim bude-li mit nekdo zajem.

Komentáře

  • kacerr : presne to co ted zminujete jsem udelal, xdebug -> enable profiling -> analyze cachegrind (qcachegrind na macu). To pomuze hezky, ukaze to kde aplikace stravi nejvic casu, takze diky tomu jsem z aplikace odstranil nejaky hnusy (ma-li nekdo nejaky odkazy na to jak to pouzivat - i kdyz to je v podstate jednoduchy, nicmene potvrzeni toho, ze to co vidim ctu spravne z nejakejch zdroju od zkusenejsich by nebylo od veci). Nicmene dostavam se k tomu, ze ta aplikace kterou potrebuju potunit je postavena na CMS, ktery asi neni zrovna genialni optimalizovany pro rychlost (MODx), takze pak prichazi na radu optimalizace vykonu serveru = vymlatit z toho co to jde, protoze aplikace ted stravi vetsinu casu procesovanim vlastnich widgetu a sablon — 1.12.2013
  • kacerr : Takze ve smeru hrube optimalizace vykonu to vypada, ze mame moznosti APC/XCache/Opcache, ktery zjevne zvysi vykon a odlehci procesoru, no a vcera jsem si zkusil trosku zjistit co teda ten HipHop (https://github.com/facebook/hhvm/) a pusobi to na mne tak, ze uz je to ve stadiu, kdy instalace/pouziti je pomerne snadna, pokryva to znacnou cast PHP a v mojem pripade to vypada, ze vykon je cca 3x lepsi nez PHP 5.4 + Xcache. Problem je, ze to stale jeste asi neni "tak duveryhodne", takze abych se do toho mohl pustit, tak by bylo pekny, kdyby ta nase aplikace byla pokryta testy, aby se zjistilo co se rozsype, kdyz zacneme experimentovat a to bohuzel NENI :-( — 1.12.2013
  • Anonym : @kacerr: To je ako by Ti dolámali nohy a povedali, že musíš zabehnúť stovku pod 9 sekúnd. Pomalý oničom framework, pomalý server, to nezrýchliš nejakým zázrakom. Osobne mám dobré skúsenosti, ako tu už bolo spomenuté xhprof + cachegrind = optimalizovaná app + rýchly server + xcache = celkom slušné response time ms (používam ZF2). — 1.12.2013
  • kacerr : No v podstate to tak je. Byl jsem tam prijatej jako "radovej" programator, no a pak to z myho pohledu vypadalo tak, ze to bud vezmu do svejch rukou, nebo se to zhrouti. Ono to asi takhle presne nebude, protoze nejak by to bezelo i beze mne, ale kdybych se furt s nekym nedohadoval, nekomu neodporoval a furt se v necem nerejpal tak by se bud stalo to, ze by zjistili, ze to je hrozny a museli najmout nekoho, kdo je dostatecne dobrej na to aby to dal do kupy (a nestihl by to vcas), nebo by to nejak bezelo, asi s dost ruznejma chybama, ktery by se objevovaly vsude mozne a svadelo by se to na to, ze PHPcka jsou pomaly, a ze ten CMS/Framework co se zvolil je proste spatnej atd ...... byly by kecy, kecy ... ale mozna by ta firma zila vlastne uplne stejne jako ted, kdyz se heroickym vykonem snazim zalatat to co mel vedet ten co tu aplikaci a infrastrukturu navrhoval. No a to s tim, ze virtualizovanej server od Rackspace (kterej o sobe tvrdi neco jako 2xcore opteron blablabla) je takova sunka to jsem zjistil uplne nahodou. Navic tim, ze za tim stoji medialne znama osoba, tak provoz na serveru vypada tak, ze dlouho nic moc (1-10 uzivatelu), takze ono i kdyz je to vlastne vsechno spatne se to nejak ustoji no a pak post na facebook a najednou 300 uzivatelu a response time leti do nebe ...... reseni tech problemu mne bavi, ale uz se to dostava do takyovyho stavy, ze abych se nekam pohnul, tak tam strilim zmeny na vlastni zodpovednost a navrhy typu, tak tu infrastrukturu tochu rozsirime ... loadbalancer + n workeru + databaze zatim taky nebyly vysleyseny — 2.12.2013
odkaz
9 Martin Mystik Jonáš
odpověděl/-a 2.12.2013
 
upravil/-a 2.12.2013

První co bys měl optimalizovat je samotná aplikace - zjisti, kde trácí čas a dodej cache, změň algoritmy apod. Tady určitě doporučuju kombinaci xdebug + cachegrid.

Pokud ti jde opravdu čistě o optimalizaci serveru jako takového tak pár tipů:

  • pokud to je možná přejít na PHP 5.4 a výše - je tam fakt znatelný výkonnostní skok (na našich aplikacích máme změřeno že šlo o 20-30%)
  • určitě použít opcode cache (my používáme Zend Optimizer+ v rámci Zend serveru)
  • sessions neukládat do souborů ale do memcached
  • v php.ini zvednout realpath_cache_size (tohle má vliv celkem malý, ale přece)
  • zkus na server nasadit NewRelic (https://newrelic.com/) a monitorovat, kde máš úzká místa (disk I/O, paměť, procesor)
  • pokud máš vysoké čekání na disk I/O zkus se podívat co všechno server loguje a jestli tam nejsou nějaké zbytečnosti (častý případ je, že se během každého requestu několikrát zaloguje PHP notice, že není nastavená timezone)

Pokud aplikace používá databázi (MySQL) tak bych potunil i tu:

Komentáře

  • jkbnerad : session do memcached mi neprijdu uplne vhodne. Kdyz ji flushnu tak se mi vsichni odhlasi? A jak resis, aby se ti to neprepisovalo napr. pri dvou XHR pozadavcich odeslanych soucasne? — 3.12.2013
  • Honza Břešťan : A proc bys ji flushoval? — 3.12.2013
  • jkbnerad : Ok, neni to uplne denodenni operace, ale restart serveru neni neobvykla situace. A hlavne memcached (a vsechny cache obecne) uz ze sve podstaty neni persistentni uloziste (nemate zaruceno ze to tam bude) a session patri nekam kde ty data zustanou a muzete se na to spolehnout. Radeji tedy ukladat kdyz uz ne disk, tak do DB (mysql, redis, nosql). — 3.12.2013
  • Honza Břešťan : Restart neni neobvykla situace? Jakou mate dostupnost? Jinak na cachovani se da samozrejme pouzit i uloziste s persistenci - kdyz uz tak neco, co umi jak data drzet v pameti, tak je odnekud znova nacist v pripade restartu. Treba Couchbase. — 3.12.2013
  • jkbnerad : I kdyby ten restart byl jednou za rok, tak jednou za tok ztratite vsechny session. Jde mi o to, ze radit nekomu pouzit k ukladani session nepersistentni uloziste je proste spatne. Couchbase je treba vhodna volba, i kdyz nevim jestli v ni jde zamykat zaznamy, coz je pro session take dulezite. — 4.12.2013
  • Martin Mystik Jonáš : Asi záleží na účelu k čemu session používáte. U nás máme v session více méně jen informaci o přihlášení a aplikace sama o sobě má automatické odhlášení při delší nečinnosti. To že se jednou za rok při nějakém nočním restartu serveru stane, že aplikace někoho odhlásí nevidím jako zásadní problém. Samozřejmě to ale není vhodné řešení pro všechny situace - pokud je náhlé odhlášení uživatelů problém tak to není nejlepší řešení. Konflikty při více požadavcích současně řeší přímo memcached modul v PHP (zamykáním stejně jako v případě session v souborech). — 4.12.2013
  • jkbnerad : O Session-locking v memchaced jsem nevedel. Diky. — 5.12.2013

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Programování: PHP

Otázky uživatele kacerr