Autor Zpráva
ntdrt
Profil *
Zdravím,
narazil jsem na zvláštní chování PHP (konkrétně verze 5.5, nicméně se tak chovali i starší verze), kdy je PHP na Windows pomalejší, než na Linuxu.

Mám nějaký počítač (SSD, i5, 16GB RAM). Na tom běží Windows, kde běží nginx a přes php-fpm si tam spouštím aplikaci (větší projekt v Nette). Běh scriptu PHP zabere nějakých 500ms a více. Na stejném stroji mám virtuál, kde běží Debian, tam nginx a zase přes php-fpm si tam spouštím tu stejnou aplikaci s totožnou databází, s totožným kódem. Běh PHP zabere kolem 100ms. Konfigurace PHP je výchozí, extension stejné, extra navíc tam je pouze xdebug.

Takže otázka je jednoduchá: proč je PHP na Windows tak pomalé a hlavně jak může být virtuál rychlejší než jeho host?
Jan Tvrdík
Profil
ntdrt:
Následující 3 věci obecně velmi významně ovlivňují rychlost provádění Nette aplikací:
1) Xdebug
2) Opcode cache
3) Produkční resp. vývojový mód v Nette

Jinak PHP mi taky na Windows běhá vždycky pomaleji než na Linuxu. Předpokládám, že je to proto, že je primárně optimalizované pro Linux.
ntdrt
Profil *
xdebug je jak na windows, tak na linuxu (profilování a debug je vypnutý)
nette debug mod je zapnutý, jak na windows, tak linuxu
opcache je vypnutá, zase jak na windows, tak linuxu

Já doufal v nějakou kouzelnou direktivu, která tohle opraví. Menší rozdíl bych chápal ale tohle je moc a až tak mě to otravovalo, že teď vyvíjím na virtualu, ač je značně nepohodlné (neustálé kopírování souborů mezi hostem a virtualem). No nic, budu muset pokračovat v tom jak to mám, každopádně díky za reakci.
Jan Tvrdík
Profil
ntdrt:
xdebug je jak na windows, tak na linuxu
Tak ho zkus vypnout.

opcache je vypnutá, zase jak na windows, tak linuxu
Tak ji zkus zapnout.

Já doufal v nějakou kouzelnou direktivu
Máš ji mít, ale nečekej zázraky.
realpath_cache_size = 16M
realpath_cache_ttl = 3600
ntdrt
Profil *
Takže se to ještě zhoršilo :D, je to 1000ms (5.5.7, xdebug on, opcache off, realpath default)... Zkusil jsem upgrade na 5.5.20 x64 (xdebug on, opcache off, realpath default), z toho mám zpátky 500ms. Bez xdebugu 330ms, s opcache 150ms, upravená realpath cache 70ms. Samá konfigurace na linuxu s PHP 5.5.20 32bit vyjde na 50ms, což je v podstatě to samé.

Takže teoreticky problém vyřešen, na Windows jsou keše očividně hodně potřeba. Jen teda nevím, zda je na vývoj opcache či velká realpath keš vhodná, nerad bych docílil toho, že budu muset něco invalidovat či restartovávat PHP. Proto jsem taky měl tu opcache vypnutou.

Bez xdebugu se klidně obejdu, na profilování/debugování tak i tak zasahuju do configu... Předpokládám, že celkově xdebug ztrácí s použitím tracy smysl, protože jeho vylepšený hlášky stejně nevidím...
Amunak
Profil
ntdrt:
vyvíjím na virtualu, ač je [to] značně nepohodlné (neustálé kopírování souborů mezi hostem a virtualem).
Netuším, jaký máš setup, ale třeba virtualbox umí poskytnout disk nebo složky hosta jako připojitelné zařízení (dokonce i s automountem). Hodně to usnadní život při vývoji ve virtuálu.
Jan Tvrdík
Profil
ntdrt:
Zkusil jsem upgrade na 5.5.20 x64
Vida, to jsi před tím nenapsal, že máš na Windows 64-bitovou verzi. Ta je (obecně) vždy pomalejší než 32-bitová. Navíc pokud ji nemáš staženou z oficiálního webu, ale stáhl jsi ji z apachelounge, tak ještě výrazněji pomalejší, protože není zkompilovaná s PGO. Další rozdíl v rychlosti může být způsoben použitím TS verze místo NTS.
ntdrt
Profil *
Amunak:
Zkoušel jsem si sdílet disk přes NFS i SMB, oboje má šílený overhead a nevyplatí se to. Takže ve finále jsem skončil se synchronizací pomocí FTP. IDE mě to synchronizuje sám po uložení (samozřejmě jen změněný soubory), což je otázka pár milisekund a následně není žádnej overhead, protože host i virtual má kód u sebe a všechny náročný operace jsou prováděný lokálně.

Jan Tvrdík:
Ono jsem měl původně 32bit a upgradem na novější 64bit se to zrychlilo, možná to je díky verzi (5.5.7 => 5.5.20), to mě osobně už moc netrápí. Stahuju z php.net (a PGO v phpinfu vidím), konkrétně jde o VC11 NTS.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0