[PHP/Shell] Execution time verminderen

[Weppel]

Hey,

Op dit moment hebben we enkele nogal "heavy" php scripts draaien op een dedicated database machine.
In die database bevinden zich 10.000+ url's, die we iedere nacht met een php script laten checken ofdat ze nog bestaan e.d.
Op dit moment doen we dat met een crontabje op de machine, die lynxt naar localhost en het php bestand aanroept. Dit duurt ongeveer 1,5 uur voordat dit script klaar is (in php.ini hebben we de max execution time een "klein" beetje omhoog gezet om dit ook daadwerkelijk mogelijk te maken).

Nu las ik ergens op internet dat je php ook rechtstreeks via de shell kon aanroepen

eg.

code:

weppel@database dbcheck]$ php phpfile.php

ipv.

code:

weppel@database dbcheck]$ lynx -dump http://localhost/phpfile.php

Ik vraag me dus af of de bovenste manier (buiten de webserver om het php document aanroepen en laten uitvoeren) sneller zou zijn, immers, je slaat een factor over (apache)).

Iemand ervaring met deze materie alvorens ik zelf wat ga testen? Ik wil graag eerst wat meningen horen voordat ik een productieserver (die afhankelijk is van php en bijbehorende scripts) overhoop ga halen, met het risico dat het niet goed meer werkt..

[Verwijderd]

Commandline en 'normale' aanroep heeft geen merkbaar verschil in de uitvoer tijd.
Wat wel zo is, als je de normale manier gebruikt kan iedereen dat dus aanroepen (als die kan connecten naar de betreffende server).

Als je het sneller wil maken kan je beter wat code posten, of wat uitleg van de manier waarop je het nu doet...

[Weppel]

Code posten lijkt me niet nodig, ik was alleen benieuwt of dit merkbare verschillen zou gaan maken.. Opzich hebben we er nu geen last van (wat maakt ons het uit dat er om 2 uur 's nachts een script start op de achtergrond, en om half 4 's nachts is afgelopen).

Het is niet zo dat we er echt verlegen om zitten om die tijd te verkorten, het zou alleen mooi zijn meegenomen als het wat korter zou gaan

Wat ik dus wil zeggen is dat we geen tijd / behoefte hebben om het script sneller te gaan. 10.000+ url's opvragen, html downloaden, analyseren, en de links die erachter zitten ook nog eens checken lijkt me niet iets wat je minder snel kunt doen
We doen dit overigens niet met 50 urls tegelijk, maar met 1 url per keer.
Misschien dat dit een puntje van verbetering zou zijn, maar nogmaals, zolang het script niet boven de 5 uur execution time uitkomt, ga ik me geen zorgen maken

[ Voor 39% gewijzigd door Weppel op 31-10-2003 16:29 ]

[gvdh81]

Je kunt php alszijnde shell scripts executen maar daarvoor moet je hem wel als perl module hebben gecompileerd. Zoek op google doet wederom wonderen

[Weppel]

Xces: ik weet dat het kan, ik vroeg me alleen af of het sneller was... beter de OP lezen

[Verwijderd]

gvdh81 schreef op 31 oktober 2003 @ 16:28:
Je kunt php alszijnde shell scripts executen maar daarvoor moet je hem wel als perl module hebben gecompileerd. Zoek op google doet wederom wonderen

Php is gewoon beschikbaar als executable hoor.

[ixi]

Dit heeft weer niet te maken met je oorspronkelijke vraag, maar je zou eens kunnen benchmarken waar de tijd vooral in gaat zitten. Als de analyse code traag is dan zou je kunnen overwegen om php te schrappen en een andere prog-taal te gebruiken.

[OkkE]

Volgens mij was de vraag alleen of iemand er ervaring mee had, aangezien het de productie server is, en hij dus liever eerst ervaringen / meningen wil horen voor hij op die server gaat testen.

Helaas heb ik er zelf geen verstand van, en kan ik dan ook niet verder helpen ...

[ecageman]

Zend optimizer wellicht een optie?

http://www.zend.com/store/products/zend-optimizer.php

[Weppel]

ecageman schreef op 31 oktober 2003 @ 16:38:
Zend optimizer wellicht een optie?

http://www.zend.com/store/products/zend-optimizer.php

Draait al standaard met php mee...

[Verwijderd]

ixi schreef op 31 oktober 2003 @ 16:34:
Dit heeft weer niet te maken met je oorspronkelijke vraag, maar je zou eens kunnen benchmarken waar de tijd vooral in gaat zitten. Als de analyse code traag is dan zou je kunnen overwegen om php te schrappen en een andere prog-taal te gebruiken.

Ik vermoed dat de ts een techniek gebruikt die wellicht verbeterd kan worden, maar dat blijkt niet nodig te zijn.

[Verwijderd]

Wij gebruiken deze manier van werken voor het cachen van pagina's op de tvgids.nl. Grote voordeel van het command line uitvoeren van php t.o.v. het uitvoeren via lynx is dat de maximum execution time niet geld voor de command line variant. Je kan je maximum execution time dus gewoon op 30 seconden laten staan en toch een 'langlopend' script commandline uitvoeren. Hoe het verder met performance zit weet ik niet. Zal het eens proberen te testen.

[Soultaker]

Als ik het goed begrijp ga je dus voor elk van de 50k URLs in je database een HTTP request uitvoeren. Ik kan me voorstellen dat het probleem dan niet de CPU-belasting is, maar het netwerkverkeer en (misschien nog belangrijker) de vertraging. Klopt het dat als je je script draait, PHP nauwelijks van de CPU gebruik maakt? (Op UNIX-servers kun je dat zien met 'top'.)

Als dat het geval is, heeft het geen zin om je script lokaal te gaan optimaliseren (met dingen als Zend optimizer enzo). Wel kun je dan de intesiteit van je operaties opvoeren door meerdere URLs parallel te controleren, zodat je je tijd beter benut (en je hopelijk sneller klaar bent). Tevens kun je proberen de benodigde hoeveelheid netwerkverkeer te verlagen, door je HTTP requests te versimpelen (alleen HEAD requests in plaats van volledige GET requests, bijvoorbeeld). Welke code gebruik je nu voor de requests?

[ecageman]

Weppel schreef op 31 oktober 2003 @ 16:40:
[...]


Draait al standaard met php mee...

Dat denk ik niet. Wat jij bedoelt is dat standaard in php gebruik wordt gemaakt van de "Zend Scripting Language Engine". Dat is wat anders dan de Zend Optimizer. Het zou ook vreemd zijn dat ze de optimizer nu nog steeds maken voor de nieuwste versies van PHP als het er al standaard in zou zitten.

Why use the Zend Optimizer; isn't PHP 4 supposed to be quite fast already?

The standard Zend run-time compiler used by PHP 4 is indeed extremely fast, generating code that is usually 2 to 10 times faster than the equivalent code in PHP 3. But an application that uses the Zend Optimizer typically executes another 40% to 100% faster.

[djc]

Verwijderd schreef op 31 oktober 2003 @ 16:42:
Wij gebruiken deze manier van werken voor het cachen van pagina's op de tvgids.nl. Grote voordeel van het command line uitvoeren van php t.o.v. het uitvoeren via lynx is dat de maximum execution time niet geld voor de command line variant. Je kan je maximum execution time dus gewoon op 30 seconden laten staan en toch een 'langlopend' script commandline uitvoeren. Hoe het verder met performance zit weet ik niet. Zal het eens proberen te testen.

OF je zet gewoon de timeout op nul (dus oneindig) met de daarvoor bestemde functie. Beetje een bogus argument.

[Weppel]

Soultaker schreef op 31 oktober 2003 @ 16:44:
Als ik het goed begrijp ga je dus voor elk van de 50k URLs in je database een HTTP request uitvoeren. Ik kan me voorstellen dat het probleem dan niet de CPU-belasting is, maar het netwerkverkeer en (misschien nog belangrijker) de vertraging. Klopt het dat als je je script draait, PHP nauwelijks van de CPU gebruik maakt? (Op UNIX-servers kun je dat zien met 'top'.)

Als dat het geval is, heeft het geen zin om je script lokaal te gaan optimaliseren (met dingen als Zend optimizer enzo). Wel kun je dan de intesiteit van je operaties opvoeren door meerdere URLs parallel te controleren, zodat je je tijd beter benut (en je hopelijk sneller klaar bent). Tevens kun je proberen de benodigde hoeveelheid netwerkverkeer te verlagen, door je HTTP requests te versimpelen (alleen HEAD requests in plaats van volledige GET requests, bijvoorbeeld). Welke code gebruik je nu voor de requests?

Dat doen we inderdaad, en nog eigenlijk iets anderser
De urls die we opvragen zijn altijd movie links, we halen daarvan de eerst 1024 bits binnen, en kijken of in dat stukje code een mpeg / avi / videocode staat (dit staat altijd in het begin van een file, vandaar de eerste 1024 bits).

Het script gebruikt nauwelijks cpu, maar duurt gewoon erg lang. Het dataverkeer is ook te verwaarlozen (30/40k/s schat ik zo, iig geen 100k/s+).
Inderdaad zou het mogelijk zijn meerdere files per keer te checken, maar bij mijn weten is het niet mogelijk om in php verschillende dingen parralel te laten lopen.. of toch wel?

De ZEND optimizer ga ik zeker even naar kijken, als dat 50 tot 100% scheelt, is dat toch weer minimaal een uur minder!

Mocht iemand anders nog tips hebben, of andere input, laat maar komen!

[PanMan]

Aangezien je een groot aantal netwerkconnecties opent, zal je je script nauwlijks kunnen versnellen met Zend of andere trucs. Het duurt gewoon een aantal (m)s voor je connected betn met die andere site.
Als je dit echt wilt versnellen, moet je OF met meerdere sites tegelijk connecten. Of je site verhuizen. Wat ik me b.v. best kan voorstellen is dat het grootste deel van die video's in de USofA worden gehost: Wellicht is het dan efficient om je server ook daar te hosten (of een andere server, alleen voor het checking deel, oid). Want nu connect je dan 50.000 keer de oceaan over.
Maar, nogmaals: Als je zoveel connect zal dat zeeer w.s. de grootste vertraging zijn, en daar is niet tegen op te automaliseren.

[Weppel]

Ik ga eerst eens kijken wat het script nu doet met ZEND, maar ik verwacht inderdaad geen wonderen..

Misschien toch eens 1 of 2 servers in amerika kopen dan maar.. Gaat weer geld kosten

Het is dus niet mogelijk om een script te maken dat verschillende connecties maakt tegelijkertijd? Dus ipv steeds 1 link af te werken, er 5 tegelijk af te werken?
Bij mijn weten is dat dus niet mogelijk in php..

[ Voor 37% gewijzigd door Weppel op 02-11-2003 14:38 ]

[gorgi_19]

Ik ken PHP wat dat betreft niet zo heel erg goed. Wel kwam ik laatst een vergelijkbare techniek tegen met ASP.Net. Misschien dat er wat nuttigs staat in het artikel en je de gebruikte methodiek kan toepassen op PHP.

http://www.wwwcoder.com/m...07&site=1883&parentid=177

[Verwijderd]

Zend Optimizer gaat weinig helpen als je een I/O bottleneck hebt zoals jullie lijken te hebben. Zend Optimizer optimaliseert het uitvoeren van de daadwerkelijke PHP code in de "Zend Executor"

Door van elke URL het IP op te vragen kun je wellicht veel virtual hosts grouperen. Vervolgens kun je misschien wel meerdere HTTP requests op die server doen zonder iedere keer een nieuwe HTTP connectie te hoeven leggen.

LinuxJournal.com had laatst een item over de profiler in APD. Als je nu verwacht dat je code het probleem is, dan kun je die eens installeren en kijken wat je code nu allemaal aan het doen is en waar de trage delen zitten.

[ Voor 23% gewijzigd door Verwijderd op 02-11-2003 14:54 ]

[Soultaker]

Weppel schreef op 02 november 2003 @ 13:42:
Dat doen we inderdaad, en nog eigenlijk iets anderser De urls die we opvragen zijn altijd movie links, we halen daarvan de eerst 1024 bits binnen, en kijken of in dat stukje code een mpeg / avi / videocode staat (dit staat altijd in het begin van een file, vandaar de eerste 1024 bits).

Hoe beperk je die gegevens tot 1024 bits? Is daar een HTTP header voor, of sluit je gewoon de verbinding na de response headers en 128 bytes (==1024 bits) van de response body?

Op de verbinding zou je nog kunnen besparen, afhankelijk van hoe je database in elkaar zit. Als je in je database kunt zien wanneer links nog geldig waren (bijvoorbeeld omdat je ze automatisch wist of markeert als ze ongeldig geworden zijn) dan kun je je met een If-Modified-Since header in 99% van de gevallen de response besparen en krijg je misschien minder gegevens terug en sneller antwoord.

Het script gebruikt nauwelijks cpu, maar duurt gewoon erg lang. Het dataverkeer is ook te verwaarlozen (30/40k/s schat ik zo, iig geen 100k/s+).
Inderdaad zou het mogelijk zijn meerdere files per keer te checken, maar bij mijn weten is het niet mogelijk om in php verschillende dingen parralel te laten lopen.. of toch wel?

Als je die PHP scripts op de command line start, dan is het geen probleem om een aantal instanties tegelijk te starten, bijvoorbeeld zo:

C:

#!/bin/sh
# (NB. Dit is geen C code, maar anders verneukt React de boel)
php -r '$pid=0; include("scriptje.php");' &
php -r '$pid=1; include("scriptje.php");' &
php -r '$pid=2; include("scriptje.php");' &
php -r '$pid=3; include("scriptje.php");' &
php -r '$pid=4; include("scriptje.php");' &
php -r '$pid=5; include("scriptje.php");' &
php -r '$pid=6; include("scriptje.php");' &
php -r '$pid=7; include("scriptje.php");' &
php -r '$pid=8; include("scriptje.php");' &
php -r '$pid=9; include("scriptje.php");' &
wait

Zo start je 10 processen tegelijk, zodat je je processorkracht en netwerk bandbreedte beter kan benutten. In theorie kan het dan 10 keer zo snel gaan, tenzij je nu een andere bottleneck tegenkomt (CPU, database of netwerkverbinding). Uiteraard moet elk scriptje wel andere links checken, maar dat kan bijvoorbeeld door elk script alle links uit de database te laten checken waarvoor geldt (row_id % 10) == $pid.

De ZEND optimizer ga ik zeker even naar kijken, als dat 50 tot 100% scheelt, is dat toch weer minimaal een uur minder!

Geloof PanMan maar: dat gaat je hier niets helpen. De Zend Optimizer optimaliseert de code die lokaal uitgevoerd wordt, maar in dit geval wordt de vertraging niet veroorzaakt doordat je CPU teveel werk uitvoert, maar omdat je script continue zit te wachten op reacties over het netwerk.

[Grijze Vos]

Ik zou dat via lynx eruit gooien, dat is onnodig ranzig. Das net zoiets als een scriptje dat elke 5 minuten moet worden uitgevoerd niet via je cron te runnen, maar i.c.m. een browser en een meta refresh tag uit te voeren.

Verder, qua optimalisatie, kun je aan threading denken. Wijzig je scriptje zo, dat ie aan de hand van argumenten een deel van de database checkt. Bijvoorbeeld, de eerste 1000. Zo laat je 50 scriptjes runnen, met elk hun eigen 1000 dingetjes.

Denk dat dat het beste is, qua snelheidsoptimalisatie. Verder, is het evt nuttig na te denken over een roulatiesysteem van wanneer je wat moet checken. Bijv, elke 2 of 3 dagen, ipv elke dag alles. Ik denk niet dat je linkjes zo snel verdwijnen, dat je elke dag moet checken. Verder is het handig te onderzoeken of het sowieso erg is om 1 of 2 dagen een paar dooie linkjes te hebben...

[PanMan]

Als je minder vaak gaat checken lever je wel gebruiksgemak van users van je site (dooie links), in voor jou server performance, die hier nog geen probleem was.
Bovendien vermoed ik dat de branche waar de TS w.s. in zit nogal veel video-links heeft die na een dag al lang weer verdwenen zijn. (Zo, dat is politiek gezegd )
Ik zou als TS idd zeker gaan kijken naar 10 scripts tegelijk, en dan wel scripts zo aanpassen dat ze idd allemaal 1/10e van de links doen. Wellicht dat dat idd (vrijwel) 10x zo snel gaat. zal iig. meer schelen dan elke andere methode. (ook bij meerdere connecties naar 1 IP via 1 connection doen, houd je elke keer de x ms tijd die het duurt om een opdracht naar de US of A te sturen. Die vertraging is denk ik minimaal 75% van de runtijd van het script, en die kan je eigenlijk niet verlagen (beh. dus door de server te verhuizen). Maar, w.s. kan je het totaal ERG verminderen door meerdere tegelijk te doen. Dus, probeer dat, en vertel ons de resultaten, ben erg benieuwd .

[Soultaker]

Grijze Vos schreef op 02 november 2003 @ 15:03:
Ik zou dat via lynx eruit gooien, dat is onnodig ranzig. Das net zoiets als een scriptje dat elke 5 minuten moet worden uitgevoerd niet via je cron te runnen, maar i.c.m. een browser en een meta refresh tag uit te voeren.

Helemaal mee eens!

Verder, qua optimalisatie, kun je aan threading denken.

PHP en threading?

[stekkel]

Soultaker schreef op 02 november 2003 @ 15:30:

PHP en threading?

Nou, je zou wel threading kunnen faken.

Als ik de post goed begrijp dan wordt er dus een socket connectie geopend om te checken of een link werkt. Wanneer je eens meerdere connecties tegelijk opent in non blocking mode dan zou je in een while lusje 1 voor 1 die connecties kunnen afgaan met als voordeel dat wanneer er nog geen data is, de volgende connectie gechecked kan worden.
Dit is mogelijk omdat fgets/fread in non blocking mode niet blijft wachten op een response.
Je zou elke connectie als een aparte thread kunnen zien. Wanneer 1 connectie niet werkt, traag is of whatever dan heeft dat geen invloed op de snelheid van afhandelen van de andere openstaande connecties.
Maar goed, als het opzetten van de connectie de bottleneck is dan schiet je hier nog niet veel mee op.

[ Voor 8% gewijzigd door stekkel op 02-11-2003 16:02 ]

[Soultaker]

stekkel schreef op 02 november 2003 @ 15:59:
Nou, je zou wel threading kunnen faken.

Ah, multiplexing met behulp van non-blocking I/O en select. Dat is inderdaad goed mogelijk.

Maar goed, als het opzetten van de connectie de bottleneck is dan schiet je hier nog niet veel mee op.

Jawel hoor; ook het maken van de verbinding kan non-blocking!

[Weppel]

PanMan schreef op 02 november 2003 @ 15:21:
Als je minder vaak gaat checken lever je wel gebruiksgemak van users van je site (dooie links), in voor jou server performance, die hier nog geen probleem was.
Bovendien vermoed ik dat de branche waar de TS w.s. in zit nogal veel video-links heeft die na een dag al lang weer verdwenen zijn. (Zo, dat is politiek gezegd )
Ik zou als TS idd zeker gaan kijken naar 10 scripts tegelijk, en dan wel scripts zo aanpassen dat ze idd allemaal 1/10e van de links doen. Wellicht dat dat idd (vrijwel) 10x zo snel gaat. zal iig. meer schelen dan elke andere methode. (ook bij meerdere connecties naar 1 IP via 1 connection doen, houd je elke keer de x ms tijd die het duurt om een opdracht naar de US of A te sturen. Die vertraging is denk ik minimaal 75% van de runtijd van het script, en die kan je eigenlijk niet verlagen (beh. dus door de server te verhuizen). Maar, w.s. kan je het totaal ERG verminderen door meerdere tegelijk te doen. Dus, probeer dat, en vertel ons de resultaten, ben erg benieuwd .

Ik wilde toch even snel hier op reageren. Morgen komt de rest aan bod, als ik weer op mn werk ben

Ten eerste, ik vermoed dat je wel weet in welke branche ik zit ja en daar heb je dus ook gelijk in.

Ten tweede, je kent die branche blijkbaar ook nog niet echt Het is een regel dat links die online gezet worden, niet, of pas na maanden verwijderd worden.
In de database zitten nu 13000 links, waarvan er iedere dag ongeveer 5 uitgefilterd worden. Om te voorkomen wat jij zegt (links die na 1 dag dood zijn) hebben we een apart script draaien dat iedere 4 uur draait om de laatste 300 links die zijn toegevoegd te checken. Dit script loopt uiteraard een stuk sneller.
Het complete database script loopt 1x per nacht omdat we toch bijna zeker weten dat alle links werken, maar dit toch even willen vaststellen (voor die 5 links die niet werken).

Ik ga eens kijken naar het multi-threaded verhaal, lijkt me inderdaad wel interresant. Ik wil als het even mogelijk is de databaseserver niet verhuizen naar amerika, gaat teveel werk in zitten, plus ik heb dat ding graag een beetje in de buurt

[PanMan]

Ok, valt me idd erg mee.
* PanMan zit totaal niet in die branche .
Laat je even weten wat de resultaten zijn van meerdere threads tegelijkertijd? Ben er wel benieuwd naar!

[Weppel]

We hebben besloten om het huidige checkscript niet meer aan te passen, maar een compleet nieuwe te schrijven, die op een andere manier checkt.

Ik zal even een kleine uitleg geven over de situatie

We hebben een database met inmiddels 14000 links naar html pagina's, met op die pagina's weer links naar kleine filmpjes.

Oorspronkelijk ging het ons om de links naar die filmpjes, en hebben we de html pagina er extra bij geindexeerd. Gaanderweg zijn we ons meer gaan interreseren in de html pagina als in de filmpjes die er achter zitten (de html pagina moet werken, of de filmpjes werken die erop staan maakt ons wat minder veel uit).

Op dit moment halen we steeds 1kb binnen van het filmpje, en kijken of het daadwerkelijk een movie file is (door de header te analyseren die we binnen hebben gehaalt met die 1kb).

Dit is natuurlijk toch al gauw weer 14000 http requests per keer, inclusief het downloaden van 14000x1kb files.

De opzet voor nu is dat we steeds de html pagina opvragen, en kijken wat de error code is die we terug krijgen.
Als we bijvoorbeeld een "code 200" terugkrijgen als we de pagina ophalen, betekent dit dat de pagina bestaat, en we nemen dus aan ook alle filmpjes op die pagina.

Ik denk dat de nieuwe methode sneller zal zijn als iedere keer het ophalen van 1kb van de film file. Ik hou jullie op de hoogte, en ideeen / input is altijd welkom!

[Verwijderd]

PHP en treading? mjah...
pcntl (Process Control)..
pcntl_fork(), pcntl_signal(),pcntl_waitpid().. woei

Natuurlijk wel ff php recompilen als je pcntl er nog niet in heb zitten (--enable-pcntl)

En ipv. in je config time limit hoger te zetten, kan je dat beter bovenaan in je scriptje doen: set_time_limit()

[Weppel]

Hmm, mag je me wel iets meer over uitleggen DrArcHeH

Ziet er interresant uit iig

[Verwijderd]

Ik ga er vanuit dat er gebruik word gemaakt van (p)fsockopen(), wat dan ook heel erg helpt is om verbinding te maken met een ip-adres i.p.v. een url. Dit heeft als voordeel dat er niet telkens een ip opgevraagt hoeft te worden bij de dns-server, enkel eenmalig bij het opslaan van de site in de db. Wel moet je dan opletten dat de http header Host wel de echte url moet zijn.

Bij mijn script scheelde het enorm, en het zal in ieder geval wel een aantal ms per site schelen!

[NMe]

Hoi arnoldxp, en welkom op GoT.

Zou je in het vervolg misschien even kunnen kijken wat de datum van het laatste bericht in een topic is? Ik neem aan dat de topicstarter van dit topic na twee jaar zijn probleem wel heeft opgelost, of er op zijn minst in elk geval niet meer mee bezig is.