[PHP] Script laat server op hol slaan

[Anoniem: 255075]

Hallo,

Mijn webhoster nam laatst contact met me op om aan te geven dat een php script van mij te veel cpu load genereerde. Dit script wordt ongeveer 25x per 3 minuten aangeroepen. De mysql server waar verbinding mee wordt gemaakt is overigens een externe vps.

Ik ben gewoon een hobby coder en als het werkt vind ik het meestal prima (quick and dirty ). Van perfomance optimization heb ik dus weinig verstand. Ik hoop dat jullie me kunnen helpen

mysql_connect.php

Modbreak:

Zulke lappen code is niet de bedoeling

Iemand enig idee waar het mis zou kunnen gaan?

Alvast heel veel dank

[ Voor 81% gewijzigd door Woy op 02-11-2009 12:49 ]

[Anoniem: 308166]

Hoe groot is de tabel waaruit je die 10 resultaten select? En anders moet je misschien toch maar gaan cachen

[ACM]

Wat een boel tekst... je had iig dat html-stuk er wel uit mogen halen. Maar is het niet zo dat je steeds opnieuw het script aanroept als de seen-getparameter niet in de url staat?

[Keiichi]

xdebug gebruiken en de met een profiler achter de output daarvan aan.

Heb je je code nog ergens staan?

[Woy]

Het is hier niet de bedoeling dat we jouw code gaan debuggen. We kunnen best helpen met je probleem, echter verwachten we dan wel dat je zelf moeite hebt gedaan om je probleem te achterhalen.

Je zult dus eerst moeten profilen waar de bottleneck in je code zit. Je kan dit met een profiler doen, of gewoon wat simpele timings in je script toevoegen. Je kunt dan eenvoudig achterhalen waar het probleem ligt. Meestal kun je dan ook al achterhalen hoe je dat op kunt lossen.

Als je dus wat beter informatie hebt dan kunnen we er wat zinnigs over zeggen.

[ibmos2warp]

Gebruik http://php.net/mysql_real_escape_string
Sql injections zijn bij jouw mogelijk.

[ Voor 24% gewijzigd door ibmos2warp op 02-11-2009 12:52 ]

[Anoniem: 255075]

ibmos2warp schreef op maandag 02 november 2009 @ 12:52:
Gebruik http://php.net/mysql_real_escape_string
Sql injections zijn bij jouw mogelijk.

Het script is enkel toegankelijk voor bepaalde ipadressen van mij zelf. Dus vreemden kunnen het script niet benaderen.

Ik zal eens met profiler aan de slag gaan. Hopen dat het me lukt

Hier staat overigens het script voor de mensen die er nog naar willen kijken:
*weg* Lees Woy in "[PHP] Script laat server op hol slaan" nog eens

[ Voor 17% gewijzigd door RobIII op 02-11-2009 13:00 ]

[NMe]

Anoniem: 255075 schreef op maandag 02 november 2009 @ 12:59:
[...]

Het script is enkel toegankelijk voor bepaalde ipadressen van mij zelf. Dus vreemden kunnen het script niet benaderen.

Ja, totdat ik jouw IP-adres even achterhaal en mijn IP-adres ga spoofen.

Never trust user input.

[Anoniem: 255075]

Ik heb xdebug er op los gelaten en dit is het resultaat:


Dat ziet er op zich toch vrij normaal uit? Kan zoiets leiden tot een hoog cpu gebruik?

Dit gaf de hoster overigens als "bewijs" dat er toch echt iets mis is met het script (zegt mij weinig):

code:

13-1    9177    0/72/72 W       3.40    36556   0       0.0     0.17    0.17    123.123.123.189
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.189 HTTP/1.1
14-1    12767   0/72/3573       W       3.22    18528   0       0.0     0.13    11.42   123.123.123.203
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.203 HTTP/1.1
15-1    13745   0/49/1615       W       4.03    26897   0       0.0     0.14    5.67    123.123.123.249
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.249 HTTP/1.1
16-1    13485   0/36/2490       W       4.09    17170   0       0.0     0.13    9.53    123.123.123.248
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.248 HTTP/1.1
18-1    9178    0/44/1421       W       2.62    27142   0       0.0     0.15    5.67    123.123.123.247
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.247 HTTP/1.1
19-1    11388   0/67/4532       W       2.32    16161   0       0.0     0.04    16.49   123.123.123.247
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.247 HTTP/1.1
20-1    14609   0/7/12  W       0.01    37311   0       0.0     0.02    0.02    123.123.123.227
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.227 HTTP/1.1
21-1    3952    0/30/4138       W       3.02    13428   0       0.0     0.04    17.38   123.123.123.227
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.227 HTTP/1.1
22-1    9280    0/33/1958       W       2.59    18602   0       0.0     0.28    6.04    123.123.123.231
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.231 HTTP/1.1
23-1    27470   0/17/117        W       1.88    35661   0       0.0     0.08    0.29    123.123.123.173
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.173 HTTP/1.1
25-1    16104   0/72/4895       W       3.72    959     0       0.0     0.19    19.39   123.123.123.249
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.249 HTTP/1.1
26-1    6231    0/29/2242       W       3.41    13408   0       0.0     0.19    9.78    123.123.123.203
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.203 HTTP/1.1
27-1    8772    0/27/1947       W       3.97    17161   0       0.0     0.21    7.14    123.123.123.183
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.183 HTTP/1.1
28-1    13747   0/84/978        W       3.96    28300   0       0.0     0.19    3.47    123.123.123.230
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.230 HTTP/1.1
29-1    18549   0/95/395        W       5.16    31239   0       0.0     0.25    0.92    123.123.123.203
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.203 HTTP/1.1
30-1    4232    0/58/4022       W       5.69    2521    0       0.0     0.18    18.98   123.123.123.173
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.173 HTTP/1.1
31-1    22323   0/23/1934       W       3.11    12743   0       0.0     0.10    7.85    123.123.123.248
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.248 HTTP/1.1
32-1    12237   0/17/117        W       0.02    32046   0       0.0     0.02    0.19    123.123.123.189
www.freerollmaniac.nl   GET /ipscript/transactions.php?ip=123.123.123.189 HTTP/1.1

[ Voor 168% gewijzigd door Anoniem: 255075 op 02-11-2009 16:48 ]

[Keiichi]

Wat je hoster als bewijs geeft, kan ik weinig uit opmaken dat jouw script voor een DoS van de server van hun zorgt.

Wel dat er veel php script tergelijk aan het draaien zijn, maar dat kan net zo goed gebeuren als je in je script een timer hebt zitten oid.

De cummulatieven voor CPU tijd in het overzicht van de hoster zeggen ook niets, omdat dat per child fork van apache is en daarop elke willekeurige vhosts van hun gedraaid kan hebben.

[Manuel]

Heb dan eerder het gevoel dat het script een leuke loop bevat. Heb het script nog niet gezien omdat het een te grote lap code zou zijn

Ik zou zeggen, begin eens met debuggen, hier en daar een echo en functies uitzetten, zo kom je er sneller achter dan vertrouwen op een profiler. Zo werkt het namelijk ook altijd voor mij

[Anoniem: 255075]

Lokaal loopt het script gewoon goed en naar mijn weten wat ik aan de clientzijde kan zien bij de hoster ook.

Als er een loop in zou zitten wordt het script toch na 30 sec. automatisch gestopt? Bovendien zijn de condities bij het aanroepen van het script altijd het zelfde. Dan kan het script toch niet ineens andere dingen doen? Of denk ik nu verkeerd?

[NMe]

Anoniem: 255075 schreef op maandag 02 november 2009 @ 21:15:
Lokaal loopt het script gewoon goed en naar mijn weten wat ik aan de clientzijde kan zien bij de hoster ook.

Als er een loop in zou zitten wordt het script toch na 30 sec. automatisch gestopt? Bovendien zijn de condities bij het aanroepen van het script altijd het zelfde. Dan kan het script toch niet ineens andere dingen doen? Of denk ik nu verkeerd?

Dat hangt van je instellingen af.

Doe eens wat Woy zei: profilen en kijken waar de meeste tijd in gaat zitten. Druk gewoon op bepaalde plaatsen in de code even een identificatie af van waar je zit met daarbij de bijbehorende verstreken tijd sinds de pagina begon met laden. Je bent er dan al vrij gauw uit waar je moet gaan optimaliseren.

[Anoniem: 255075]

Volgens profiler doet het script 6.5ms over het uitvoeren van het script (zoals je kunt zien in de screen). De tijd gaat um vooral zitten in het connecten naar de externe mysql host. Zoals ik het al zei is het een vrij eenvoudig script en draait het 25x per 3 minuten.

Heeft het profilen dan wel zin. Zal het probleem niet ergens anders liggen?

[crisp]

Wat me nog wel opviel in je originele code was dat je in de branch waarin je een aanroep met de 'seen'-parameter afhandelde je na het outputten van de redirect-code geen exit deed, dus effectief de rest van de code voor niets uitvoerde.

[Anoniem: 255075]

crisp schreef op maandag 02 november 2009 @ 21:59:
Wat me nog wel opviel in je originele code was dat je in de branch waarin je een aanroep met de 'seen'-parameter afhandelde je na het outputten van de redirect-code geen exit deed, dus effectief de rest van de code voor niets uitvoerde.

Daar heb je gelijk in. Echter wordt die branch echter 1-10x per dag uitgevoerd. Dat kan niet HET probleem zijn waar de server op vast loopt.

[JordyOnrust]

Is er nog een plek waar de code staat? Pastbin ofzo?

[Gomez12]

Simpele vraag, maar wat zijn je time-outs/error-afhandeling?

Kan het niet gewoon gebeuren dat het script in perfecte omstandigheden goed werkt maar dat bijv je mysql server 1 minuut geen antwoord gaf en dat er daarom 10 script-requests in de wacht stonden, van 10 requests raakte je server weer over de zeik waardoor er geen antwoord was voor de 11e request, etc. etc.

Heel simpel gesteld, wat gebeurt er als er 1 script request niet op tijd klaar is, wordt er dan wel / niet een 2e script request opgestart?

[Anoniem: 255075]

@Bright010957: Ja, maar die zijn weggeedit. Volgens mij mag het niet

@Gomex12: Zou zoiets in mijn php script moeten staan of is dat een serverinstelling? Als het eerste het geval is dan verwacht ik dat het er niet in staat.

[JordyOnrust]

Het is niet handig hier hele lappen code neer te zitten, maar begreep dat er ook veel HTML etc in zat, dat is natuurlijk niet interessant. Misschien dat je relevante code kan plaatsen? Desnoods via http://pastebin.com/ oid.

[Gomez12]

@Mr_Zoidberg : Als je niet weet waar het zou moeten staan dan kan je rustig vanuit gaan dat het er niet in staat, oftewel bij een storing ( / tijdelijke overbelasting ) van je vps gooi jij er blind nog even 25 requests per 3 minuten overheen. Zijn deze niet snel genoeg verwerkt dan kom jij in de volgende 3 minuten wederom met 25 nieuwe requests... Ik begin in te zien wat er fout kan zijn.

Ik zou gewoon een extreem simpel locking mechanisme gebruiken in het script
eerste regels kijk je of bestand x op schijf aanwezig is, zoja dan exit script, zonee maak bestand x aan.
Laatste regels haal je bestand x weer weg

Desnoods nog te verfraaien met dat je een check erin gooit dat als bestand x een bepaalde tijd oud is dat je als extra check alle processen naloopt om te zien of er wel echt een script draait ( of dat er eentje geknald is voordat hij het bestandje weghaalde ) zoja, dan wederom exit, zonee dan verwijder bestandje en ga verder met uitvoer.

[Anoniem: 255075]

Ik ga eens aan de slag met het locking meganism. Als er een probleem zou zijn, dan zou dat het inderdaad kunnen voorkomen. Thx.

@Bright: Ik had linkjes naar .phps geplaatst, maar dat mag blijkbaar niet.

[NMe]

Anoniem: 255075 schreef op maandag 02 november 2009 @ 23:31:
@Bright: Ik had linkjes naar .phps geplaatst, maar dat mag blijkbaar niet.

Dat klopt, want wij gaan niet je volledige code voor je debuggen. Sowieso: als het script op zichzelf prima draait dan zou het inderdaad best eens aan de load van meerdere instanties tegelijk kunnen liggen. Je zou een PHP file kunnen maken die dit script 25 includet en dat script kunnen profilen om dat te simuleren. Als dat het ook niet is, dan is het voor jou verder lastig om te traceren en ga je er zonder hulp van je hoster met wat meer info verder ook niet uit komen.

[pedorus]

Gomez12 schreef op maandag 02 november 2009 @ 23:13:
@Mr_Zoidberg : Als je niet weet waar het zou moeten staan dan kan je rustig vanuit gaan dat het er niet in staat, oftewel bij een storing ( / tijdelijke overbelasting ) van je vps gooi jij er blind nog even 25 requests per 3 minuten overheen. Zijn deze niet snel genoeg verwerkt dan kom jij in de volgende 3 minuten wederom met 25 nieuwe requests... Ik begin in te zien wat er fout kan zijn.

Ehm, het ging met meta-refresh vanaf 25 hosts met 180 seconden, dus als er niks meer komt stop het vanzelf... En zoveel is 1 per 7.2 seconden die ook nog eens normaal over de tijd zijn verdeelt nou ook weer niet.

Waar zijn de log-bestanden van de hostingprovider van en/of wat betekenen de verschillende kolommen? Draait de hostingprovider met php onder verschillende usernamen, zodat ze dit ook eenvoudig met dingen als top hebben gezien? Ik kan me zo voorstellen dat er gewoon verkeerd gemeten wordt. Een ander script zorgt bijvoorbeeld voor hoge load of een lockconditie in MySQL, en jij krijgt de schuld omdat er altijd wel requests van jou aanwezig zijn.

[Anoniem: 255075]

Heb het lockfile systeempje nu gemaakt. Iedere client die het script om de 3 min aanroept (zijn er in totaal 25) heeft een eigen lockfile.

Ik heb momenteel 4 clients die het script om de 3 min aanroepen en nu zaten er al 2 bij waar de lockfile op het eind niet verwijderd is. Hmm... er is dus inderdaad iets mis met mijn script. Heb nu wat debug info (line nummers) in de lockfile toegevoegd. Ik ben benieuwd wat er morgen in staat...

[Gomez12]

pedorus schreef op dinsdag 03 november 2009 @ 00:23:
[...]

Ehm, het ging met meta-refresh vanaf 25 hosts met 180 seconden, dus als er niks meer komt stop het vanzelf... En zoveel is 1 per 7.2 seconden die ook nog eens normaal over de tijd zijn verdeelt nou ook weer niet.

Ach, dat krijg je als je het script zelf niet kan zien...

Ik ging ervanuit dat hij dit op de server zelf regelde en niet met meta-refreshes. Met meta-refreshes stopt het idd als er 1x iets fout gaat.

Enkel ( ik heb het script zelf niet gezien ) zie ik even niet in hoe jij kan zeggen dat de aanroepen normaal over de tijd zijn verdeeld, ik heb in ieder geval geen idee hoe dit met meta-refreshes te regelen, afaik zijn die redelijk static na aanroepen pagina, en de aanroeptijd van de pagina heb je over het algemeen geen controle over.

En 1 per 7.2 seconden is idd niet veel, maar het zal niet de 1e x zijn dat ik servers tot een stilstand heb zien komen omdat er vanwege reden x/y/z extra overhead bijkwam die ervoor zorgde dat 1 script bleef hangen waardoor alles een overhead kreeg waardoor elk request boven de 7.2 seconden uitkwam ( myisam is hier lekker in met zijn table locking, lock een hele tabel met 1 update actie en je volgende request heeft al x overhead )

[NMe]

Anoniem: 255075 schreef op dinsdag 03 november 2009 @ 00:38:
Heb het lockfile systeempje nu gemaakt. Iedere client die het script om de 3 min aanroept (zijn er in totaal 25) heeft een eigen lockfile.

Ho even, dat zei je er in het begin niet bij. Je hebt dus niet zomaar 25 keer per 3 minuten een script draaien, je hebt 25 clients die één keer per drie minuten je script aanroepen. Wat als die alle 25 tegelijk komen? Wat denk je dan dat er gebeurt met je profile?

[Anoniem: 255075]

25 requests (wat puur theoretisch kan) tegelijk kan een server toch wel aan?? ( het is een meta refresh ja )

Maar anyway, ik denk dat ik het euvel heb gevonden. De hele lockfile heb ik vol gestopt met debugging info (erg handig, ik kende de techniek voorheen nog niet). De volgende regel was denk ik het probleem waarop het script soms vast liep:

PHP:

echo "<strong>" . $remote_ip . ": " . gethostbyaddr($_SERVER['REMOTE_ADDR']) . "</strong>";

Niet cruciaal voor het script dus die heb ik maar even gecomment.

Hopen dat nu alles blijft draaien. Thx voor jullie hulp!

[NMe]

Anoniem: 255075 schreef op dinsdag 03 november 2009 @ 15:07:
25 requests (wat puur theoretisch kan) tegelijk kan een server toch wel aan?? ( het is een meta refresh ja )

De requests wel, maar de verschillende functies die je aanroept gaan misschien wel eens locken of op een andere manier moeilijk doen. In dit geval dus gethostbyaddr waarvan nota bene in een van de bovenste comments op de manualpage het volgende staat:

Just wanted to let everyone know that gethostbyaddr() takes more than 20 seconds to respond if the IP address is not listed in DNS.

So be careful if you are going to use this function in the production environment. You or your users may not be able to get the response from the server before the timeout occurs. Slow website only makes people very frustrated.

You shouldn't use this function at all unless you have a very good reason to do so (taking logs? then save ip addresses instead and resolve them later by running a batch or something.)

Ja, dat gaat je problemen opleveren ja.

[Anoniem: 255075]

Vandaar dat ik ook graag het script wilde posten. Omdat er waarschijnlijk iets in zat wat een ervaren phper er zo uit kan halen...

Anyway, ik heb nu wel veel van debuggen geleerd, maar heb er ook veel kostbare tijd mee verloren.

Thx voor alle hulp

[NMe]

Anoniem: 255075 schreef op dinsdag 03 november 2009 @ 16:10:
Vandaar dat ik ook graag het script wilde posten. Omdat er waarschijnlijk iets in zat wat een ervaren phper er zo uit kan halen...

Ja, maar zo kun je net zo goed meteen stoppen met programmeren en gewoon ieder probleem dat je hebt hier als topic posten. We zijn er niet om jouw problemen voor je te identificeren, dat kun je zelf doen. Je had best een stukje code kunnen posten zolang je eerst zelf eens de bottleneck omschreven had. Sowieso, als je in je eerste post had uitgelegd dat 25 keer per 3 minuten niet betekent dat je het eens per 7 seconden doet, maar dat er 25 requests op een willekeurig interval gedurende die 3 minuten zijn dan had je niet eens code nodig gehad.

Anyway, ik heb nu wel veel van debuggen geleerd, maar heb er ook veel kostbare tijd mee verloren.

...en een volgende keer weet je precies wat je moet doen en ben je die tijd tegen die tijd niet meer kwijt.

[Woy]

Anoniem: 255075 schreef op dinsdag 03 november 2009 @ 16:10:
Vandaar dat ik ook graag het script wilde posten. Omdat er waarschijnlijk iets in zat wat een ervaren phper er zo uit kan halen...

Maar het punt is juist dat we hier niet willen dat mensen op die manier te werk gaan. Anders gaat iedereen hier straks complete scripts plaatsen, om zo andere hun probleem te laten zoeken. Het word dan ook ondoenlijk om laten met de search nog iets terug te vinden over een specifiek probleem.

Als je een simpele test-case had gemaakt van een klein aantal regels, en daar nog steeds onverklaarbare problemen mee had, dan was het geen probleem geweest als je die had geplaatst.

Anyway, ik heb nu wel veel van debuggen geleerd, maar heb er ook veel kostbare tijd mee verloren.

Het is anders een van de belangrijke vaardigheden die een ontwikkelaar moet hebben, dus het lijkt me erg goed geïnvesteerde tijd.