PHP response time server meten

[Verwijderd]

Ik wil de belasting meten mijn server en op basis daarvan een draaiend script af te kappen als de server te druk is.
Is dit mogelijk in php?

Ik heb zelf al gekeken naar sockets alleen lijkt mij niet werken omdat je op dezelfde server draait en dus al gelijk een directe connectie hebt.
Ik heb op het moment niet de beschikking tot een complete test-omgeving en kan dit dus niet testen. Alleen de applicatie moet zo ver mogelijk zijn totdat ik over 2 week een test-omgeving heb.

Ik draai php via fastCGI op een windows server.

[ Voor 22% gewijzigd door Verwijderd op 19-06-2010 00:39 ]

[RobIII]

Verwijderd schreef op zaterdag 19 juni 2010 @ 00:31:
Ik wil graag de response time op de server meten waarop het php-script zelf uitvoert om zo te kijken of ik het script laat draaien, of dat de server het op dit moment te zwaar heeft en het script dus die(). Is dit mogelijk?

Ik moest vier keer lezen voor ik nou begreep wat je (denk ik) bedoelt. Je wil meten hoe hoog de belasting van de server is? Om dan een draaiend script af te kappen als de server te druk is?

Waarom zou je dit überhaupt willen? Kun je wat meer info geven over de situatie?

[ Voor 13% gewijzigd door RobIII op 19-06-2010 00:38 ]

[Verwijderd]

RobIII schreef op zaterdag 19 juni 2010 @ 00:33:
[...]

Ik moest vier keer lezen voor ik nou begreep wat je (denk ik) bedoelt. Je wil meten hoe hoog de belasting van de server is? Om dan een draaiend script af te kappen als de server te druk is?

Ja, dat is precies wat ik bedoel!

Sorry ik zal het even opnieuw formuleren, het zag er leesbaar uit toen ik het typte

[RobIII]

Verwijderd schreef op zaterdag 19 juni 2010 @ 00:38:
Sorry ik zal het even opnieuw formuleren, het zag er leesbaar uit toen ik het typte

Nogmaals: waarom wil je dat?
Je zou op een bepaalde interval natuurlijk ook in het draaiende script de belasting kunnen uitlezen en dan een sleep doen ofzo; dat is netter dan een script afkappen (een leraar zei vroeger tegen me: je steekt toch ook geen stok in de spaken van een fiets als je wil stoppen? ).
Je probleem is een beetje (denk ik) dat je onder windows draait. Anders lees je gewoon /proc/stat uit ofzo en doe je daar iets mee. Dat gaat denk ik niet (of niet goed) onder windows. Maar ik vermoed dat je sowieso in de verkeerde richting aan 't denken bent. Dus probeer de situatie eens wat beter te omschrijven?

[WouZz]

Doe eens gek:

1. Zet een account op bij pingdom.com en zet een Custom HTTP check op:

   HTTP Custom – A HTTP Custom check lets you monitor anything you want by letting Pingdom get status data from a web page provided by you in a special XML format. This check type in combination with your own local scripts allows you to monitor for example CPU load or do advanced database tests.

2. Mail je notification naar mailhooks.com en laat de contents posten naar je suspend.php script

[Verwijderd]

RobIII schreef op zaterdag 19 juni 2010 @ 00:51:
[...]

Nogmaals: waarom wil je dat?
Je zou op een bepaalde interval natuurlijk ook in het draaiende script de belasting kunnen uitlezen en dan een sleep doen ofzo; dat is netter dan een script afkappen (een leraar zei vroeger tegen me: je steekt toch ook geen stok in de spaken van een fiets als je wil stoppen? ).
Je probleem is een beetje (denk ik) dat je onder windows draait. Anders lees je gewoon /proc/stat uit ofzo en doe je daar iets mee. Dat gaat denk ik niet (of niet goed) onder windows. Maar ik vermoed dat je sowieso in de verkeerde richting aan 't denken bent. Dus probeer de situatie eens wat beter te omschrijven?

Ik heb een script draaiend waarmee clients kunnen connecten en deze kunnen informatie opvragen over producten, maar we hebben maar 1 server en deze krijgt het met veel clients te zwaar en dat zorgt voor gigantische response times.

@WouZz: Dat lijkt wel interessant, ga ik even lezen tnx

[FragFrog]

Verwijderd schreef op zaterdag 19 juni 2010 @ 01:40:
Ik heb een script draaiend waarmee clients kunnen connecten en deze kunnen informatie opvragen over producten, maar we hebben maar 1 server en deze krijgt het met veel clients te zwaar en dat zorgt voor gigantische response times.

Is het dan niet practischer de time-out op je scripts of connecties te verlagen? Zie ook de connection handling quick guide. Eventueel zou je met register_shutdown_function vrij simpel kunnen bijhouden wanneer veel requests een (execution) time-out opleveren (even op GC volgorde letten zodat je er nog wel bij kan - iets als APC is waarschijnlijk nuttig hier of handmatig zorgen dat je DB connectie nog niet verbroken is). Als je vervolgens bij een nieuw request ziet dat er een dozijn afgebroken requests waren in de laatste paar seconden kun je direct het request droppen.

Als het je echt alleen maar gaat om scripts die langer dan X seconden duren af te kappen kun je natuurlijk veel simpeler domweg max-execution-time aanpassen, al blijf ik het hoe dan ook een erg vreemde situatie vinden. Een normaal PHP script hoort nooit langer dan een fractie van een seconde te duren. Je bent toch niet een socket server in PHP aan het schrijven he?

[MueR]

Is het niet veel praktischer om, indien je werkelijk zo veel verkeer trekt dat je server gaat zweten, een nieuwe server bij te plaatsen?

Disclaimer:
Ik weet dat je nooit zomaar extra servers ergens tegenaan moet smijten, er kan vaak genoeg verbeterd worden in code, maar het lijkt me in dit geval stukken praktischer

[ Voor 41% gewijzigd door MueR op 19-06-2010 02:50 ]

[martin149]

iets als

code:

<?php
$time = time()
 //wat php
if($time+5 >= time()) die('<h1>server is te druk</h1>')
?>

alleen gaat deze van de tijd die de server er over doet uit...
Ik heb ook op mijn site wet eens van die meldingen "server too busy" maar ik weet niet hoe ze dat doen

[ Voor 22% gewijzigd door martin149 op 19-06-2010 07:50 ]

[Mexel]

PHP:

if (function_exists('sys_getloadavg')) {
    $load = sys_getloadavg();
    if ($load[0] > 80) {
       header('HTTP/1.1 503 Too busy, try again later');
       die('Server too busy. Please try again later.');
    }
}

Zoiets, deze werkt alleen op een linux bakje, aangezien je een windows bak hebt kun je er helaas niets mee, maar als je eventueel een linux bak neemt kun je deze gebruiken, deze draait ook op de zoek functie van thepiratebay.

[ Voor 29% gewijzigd door Mexel op 19-06-2010 08:04 ]

[Verwijderd]

@FragFrog: Het is een webservice die informatie over producten terug geeft. Het script moet dus eigenlijk volledig draaien. Dus wanneer een server te druk wordt moet de volgende klant er niet bij kunnen. Time-out kan ik helaas niet gebruiken bij dit probleem.

@MueR: An sich wel alleen ik wilde eerst kijken of dit ook anders op te lossen was. Het is niet een probleem dat de clients een uur niet kunnen synchroniseren. Alleen wanneer het te druk is moet de melding komen. Een nieuwe server is bij ons ook niet echt een probleem, maar een beetje hetzelfde idee als wat jij in de disclaimer hebt staan

@martin149: Dat zou bij mij ook niet werken omdat ik het real-time wil, en sommige scripts kunnen 10 minuten draaien en anderen weer 4 minuten, dan krijg je dus een beetje een vertekend beeld.

@Mexel: Das een beetje blij maken met een dooie mus he

Bedankt voor de reacties, ik zal even kijken of er monitor software beschikbaar is die naar een bestand kan schrijven, dat ik die dan uitlees.

[Rob]

Verwijderd schreef op zaterdag 19 juni 2010 @ 11:02:

@Mexel: Das een beetje blij maken met een dooie mus he

Bedankt voor de reacties, ik zal even kijken of er monitor software beschikbaar is die naar een bestand kan schrijven, dat ik die dan uitlees.

Monitor software is extra software die je al op een drukke server gaat draaien... lijkt mij niet verstandig.

Je kunt beter kijken of er een script is zoals die van Mexel die wel werkt op Windows

[RobIII]

Verwijderd schreef op zaterdag 19 juni 2010 @ 11:02:
@FragFrog: Het is een webservice die informatie over producten terug geeft

Explain more.

Met alle respect maar het stinkt hier een uur in de wind naar een ontzettend ranzige "oplosing" voor een probleem dat er nooit had moeten zijn.

[ Voor 26% gewijzigd door RobIII op 19-06-2010 12:35 ]

[Verwijderd]

RobIII schreef op zaterdag 19 juni 2010 @ 12:34:
[...]

Explain more.

Met alle respect maar het stinkt hier een uur in de wind naar een ontzettend ranzige "oplosing" voor een probleem dat er nooit had moeten zijn.

Er worden via een soap-service functies aangeboden die arrays terug geven met product informatie( dit wordt uit een database gehaald). Het probleem dat voorkomt is dat met veel clients die tegelijk connecten er een error naar voren komt: 'error fetching http soap headers'.

[RobIII]

Verwijderd schreef op zaterdag 19 juni 2010 @ 13:28:
[...]


Er worden via een soap-service functies aangeboden die arrays terug geven met product informatie( dit wordt uit een database gehaald). Het probleem dat voorkomt is dat met veel clients die tegelijk connecten er een error naar voren komt: 'error fetching http soap headers'.

En waarom zou een soap-service een langlopend proces zijn? Je probleem zit in het feit dat een request te veel tijd nodig heeft om afgehandeld te worden, daar moet je wat aan doen. Ga eens kijken of je queries niet optimaler kunnen etc.

[ACM]

RobIII schreef op zaterdag 19 juni 2010 @ 13:52:
Ga eens kijken of je queries niet optimaler kunnen etc.

Of wellicht nog beter, (deel)resultaten cachen. Dat kan op allerlei manieren en het voorkomen dat werk gedaan wordt is toch wel een van de betere manieren om op dat werk te besparen. Je hoeft dus niet per se direct memcached te installeren, maar wellicht is een reverse proxy juist zinvol of kan je al een hoop winst halen door resultaten van zware queries in je database in een eenvoudigere tabel weg te schrijven. Zeker als het druk is zou zo'n beetje elke bruikbare oplossing je goede cache-hitratio's moeten kunnen opleveren.

Afgezien daarvan zou je kunnen kijken of je een deel van de zware processing kunt offloaden naar een process buiten de SOAP-request om. Hier kan je bijvoorbeeld een queue-omgeving voor gebruiken (in een java-wereld zou je dan bijv JMS gebruiken) die snel aan te vullen is en dan rustig op de achtergrond in een of enkele threads het werk te verwerken.
Hier bij tweakers.net hebben we bijvoorbeeld een paar 'queue-consumers' die naar gelang de load van de databaseserver stijgt, het aantal berichten dat ze per seconde afnemen terugschalen om zo een wat dempend effect op de load te hebben. Als dan even later de load weer daalt, neemt het aantal verwerkte berichten weer toe en wordt de achterstallige data in queue dus weer opgeruimd.

[Voutloos]

Dat zijn een aantal heel interessante mogelijkheden, maar ts moet vooral eerst uberhaupt de bottleneck vaststellen, en misschien zie je dan wel wat laag hangend fruit.

[Verwijderd]

ACM schreef op zaterdag 19 juni 2010 @ 17:06:
[...]

Of wellicht nog beter, (deel)resultaten cachen. Dat kan op allerlei manieren en het voorkomen dat werk gedaan wordt is toch wel een van de betere manieren om op dat werk te besparen. Je hoeft dus niet per se direct memcached te installeren, maar wellicht is een reverse proxy juist zinvol of kan je al een hoop winst halen door resultaten van zware queries in je database in een eenvoudigere tabel weg te schrijven. Zeker als het druk is zou zo'n beetje elke bruikbare oplossing je goede cache-hitratio's moeten kunnen opleveren.

Afgezien daarvan zou je kunnen kijken of je een deel van de zware processing kunt offloaden naar een process buiten de SOAP-request om. Hier kan je bijvoorbeeld een queue-omgeving voor gebruiken (in een java-wereld zou je dan bijv JMS gebruiken) die snel aan te vullen is en dan rustig op de achtergrond in een of enkele threads het werk te verwerken.
Hier bij tweakers.net hebben we bijvoorbeeld een paar 'queue-consumers' die naar gelang de load van de databaseserver stijgt, het aantal berichten dat ze per seconde afnemen terugschalen om zo een wat dempend effect op de load te hebben. Als dan even later de load weer daalt, neemt het aantal verwerkte berichten weer toe en wordt de achterstallige data in queue dus weer opgeruimd.

Ik ben nu bezig een cache uit te voeren, om zo het dubbel werk te besparen.

[FragFrog]

RobIII schreef op zaterdag 19 juni 2010 @ 13:52:
En waarom zou een soap-service een langlopend proces zijn?

Erm, omdat dat is hoe een SOAP server werkt?

Having said that, ik heb geen ervaring met de SOAP serverclass van PHP, maar als die net zo geweldig in elkaar zit als de client of sowieso als je server onder te hoge load komt is het wellicht een idee om helemaal van PHP af te stappen? Last I checked was multithreading in PHP verre van optimaal (danwel nonexistent), als de SOAP server persistent is (en die indruk krijg ik) zou die daar ook wel eens last van kunnen hebben - dat zou ook gelijk verklaren waarom requests op elkaar zitten te wachten, toch de meest voorkomende reden voor algemene traagheid. Mits de bottleneck daadwerkelijk in je PHP script zit (en dus niet in je databaseserver bijvoorbeeld - daar zijn andere oplossingen voor) zou ik hard overwegen over te stappen op een ander platform.

Of er domweg een extra server bij plaatsen natuurlijk