[PHP] Web-applicatie versnellen

[m33p]

Ik heb een webapplicatie welke een aantal server (zo'n 80) monitored. Op het moment werkt het maar het is nogal traag. De app haalt eens in de zoveel tijd (10 minuten) de nieuwe info op en cached deze. Ook kan men aangeven handmatig te refreshen naar dit duurt zo'n ruime 3 seconden per server (ruime 7 minuten in totaal).

Ik voer op elke server aan aantal acties uit, gewoon vanuit PHP. Ik heb van de server's alleen de IP's. Eeerst haal ik van deze IP's het DNS record op (reverse). Ook haal ik van al deze machines de NetBIOS namen op, en welke users er op dit moment ingelogd zijn (ook via NetBIOS). Ook check ik per server of deze online is door één of meer socket connecties te openen.

Het checken of een server online is doe ik op de volgende manier:

PHP:

fsockopen($ip, $port, $erno, $erst, 1);

Deze code looped maximaal 3 keer. Ik heb een 3 tal poorten. Als eerst check ik op algemene Windows poort (3389). Als hier reactie op is, dan is de server online. Zo niet, check dan poort 22 en 80. Als geen van deze poorten online is ga ik er maar van uit dat de server offline is.

Op deze manier heb ik naar mijn idee wat meer zekerheid dan een ping aangezien ik ook kan kijken of een bepaalde service draait, en maakt het qua tijd niets uit in vergelijking tot ping. Kan iemand dit bevestigen?

De reverse DNS name ophalen doe ik op de volgende manier:

PHP:

$GetDNSRecord = `nslookup -timeout=1 -retry=1 -querytype=A $ip`;

Dit scheen sneller te zijn dan het via de php functie 'gethostbyaddr' te doen, ik neem aan dat dit niet veel sneller kan?

Het NetBIOS gedeelte is wat ingewikkelder... Eerst check ik met het (Windows) commando 'sc' wat de status van de messenger service is. Als deze 'STOPPED' is, dan start ik deze. Wanneer de service eenmaal draait, haal ik met 'nbtstat' de nodige info op (NetBIOS name en actieve user(s)). Daarna zet ik de status van de messenger service weer terug naar hoe het was.

Mijn vraag: Zijn er manieren om dit process te versnellen? Ik kan voor PHP niet echt manieren vinden om relatief simpel de zooi multi-threaded te laten draaien (meerderen nslookup processen naast elkaar o.i.d) wat wel de mooiste oplossing zou zijn. Ook ben ik niet erg handig in andere talen waarmee ik een app zou kunnen maken die dit kan doen.

Op het moment draait dit alles op een Windows bak, wat ook zo moet blijven aangezien ik gebruik maak van Windows Management Instrumentation wat er niet is voor Linux.

Nogmaals, elke performance tip is welkom. Alvast bedankt!

[joopst]

op het eerste gezicht gaat veel tijd zitten in 'wachten'.

je kan dus snelheid opvoeren door meerdere 'scans' tegelijkertijd uit te voeren. Multithreaded dus, wat je zelf ook al zegt ...

om een proces in de achtergrond te starten kan je bijv gebruik maken van psexec

volgens mij kan je dan het beste een scriptje maken die 1 server scant .. en die flink veel tegelijkertijd opstarten

[ Voor 19% gewijzigd door joopst op 13-03-2006 15:27 ]

[m33p]

Dank je. Het multi-thread idee was ik ook al aan het uitdenken, maar volgens mij is het niet erg lekker realiseerbaar met alleen PHP. Wat jij zegt, een script maken welke alles in 1 keer scanned gaat nog niet werken, omdat je aan die wacht tijd vast blijft zitten (tenminste, als je het dus met alleen PHP blijft doen). PHP ondersteund niet echt multithreading, dus zal ik dat met een andere taal moeten doen, maar PHP is de enigste taal welke ik goed ken.

Wat beftreft psexec. Het op de achtergrond starten is het probleem niet, dat kan ook zonder psexec. Voordeel van psexec is dat je remote zooi kan starten, maar ik weet niet of dat in deze situatie nou een snelheidsverbetering is.... Het probleem waar ik (PHP?) mee zit is dat het wacht op de tijd de executable die de info op haalt (zoals je zegt), dus op de één of andere manier moet de app de info sneller ophalen. Ik denk dat dat de beste optie is... maar hoe..

Overigens praat ik hier ook over een 'optimaal' geval. Op het moment duurt het 13.24 seconden voor 4 servers welke online zijn (dus dan zit je nog niet eens aan de timeout dijden) en 1 simpele SQL query om de servers op te halen. Nou is er aardig wat info gecached ook nog, maar het mooiste zou zijn als het updaten onder de minuut kon komen. Ik weet niet of dit uberhaupt haalbaar is maar dit duurt wel extreem lang voor een paar simpele informatie aanvragen naar LAN servers....

[ Voor 21% gewijzigd door m33p op 13-03-2006 16:12 ]

[Verwijderd]

Ik zorgde dat het maximaal 1 keer per minuut kon controleren want er is geen eenvoudigere PHP functie
Zodra iemand de pagina opende liet ik het de MySQL database uitlezen wanneer de laatste update was, was deze binnen de minuut → las ik meteen de status uit de tabellen uit. Als dat niet het geval was dan liet ik ze fsocken binnen 1 of 2 sec. (max.) om het op te slaan naar een MySQL database en printte het ten slotte uit.

[m33p]

Dat is één socket connnectie naar elke bak (misschien nog paar keer voor andere poorten). Daar zit mijn probleem ook niet, het zit hem in de exec()'s. Deze voeren voor elke server een commando uit (nslookup, sc, nbtstat.. etc) waar PHP op gaat zitten wachten. Mijn vraag is min of meer of er andere manieren zijn dan 5 keer exec aanroepen per server en daar op gaan zitten wachten?

[xtra]

Wat wil je eigenlijk precies weten? Of de server online is?

Wat losse opmerkingen:
De Netbios namen en de hostname zullen misschien niet iedere 10 minuten wijzigen dus die zou je eventueel apart en minder vaak kunnen ophalen.
Is er geen 'Master Browser' waar je al je Netbios info in één keer vandaan kunt halen?
Als het kan in jouw situatie zou je de servers zelf hun informatie kunnen laten verzamelen en iedere 10 minuten naar jouw applicatie sturen. Als je na 10 minuten niets hebt is de server offline, toch? Op die manier maakt het ook niet veel meer uit of je 70 of 700 servers hebt.

[joopst]

je hebt 80 servers die je wilt scannen
3 sec per server

= 4 minuten scannen ... dat doe je elke 10 minuten ..
in beginsel is er dus geen performance probleem.

als je 80 threads tegelijk laat scannen .. , dan duurt het misschien 10 (of 20) seconden ..
en dan is je state in de database weer up2date .. pak je toch ff veel% performance winst...

klopt dit? of welk gedeelte van het probleem mis ik hier nu ?

[m33p]

@xtra:
Vanaf de servers informatie laten sturen naar de stats bak is een mooie oplossing waar ik ook aan gedacht heb, maar dan zit je weer met het probleem: Hoe ga je zoiets maken?

Ik kan een database best extern benaderbaar maken, maar dan moet ik gaan bedenken hoe ik vanaf een bak info kan gaan sturen (via PHP dan) naar de stats bak. Ik kan niet op elke server apache gaan installeren. Ook zitten er een paar linux servers bij, dus daar moet ik dan ook wat voor gaan maken. Nogmaals, dit systeem werk, maar naar mijn mening kan het beter. Niet qua opties, maar qua performance. 5 minuten moeten wachten op een update is niet geinig. Verder cache ik al zoveel mogelijk, maar online/offline status moet regelmatig gebeuren als het even kan, evenals ingelogde user (wat via NetBIOS gaat). Er van uit gaand dat er voor elke server een reverse dns record is, en netbios gecached is, dan nog duurt het te lang aangezien de nslookup amper tijd kost, en de netbios request toch moet gebeuren voor de ingelogde user (dit kan in 1 request).

Verder wil er ik er nog een aantal functies bij in gaan bouwen (meer uitbreiden van bestaande functies) waar ook weer een paar miliseconden in zitten. Al met al gaat het te lang duren als ik de uitvoer tijd niet omlaag breng van de apps die aangeroepen worden.

[m33p]

joopst schreef op maandag 13 maart 2006 @ 16:23:
je hebt 80 servers die je wilt scannen
3 sec per server

= 4 minuten scannen ... dat doe je elke 10 minuten ..
in beginsel is er dus geen performance probleem.

als je 80 threads tegelijk laat scannen .. , dan duurt het misschien 10 (of 20) seconden ..
en dan is je state in de database weer up2date .. pak je toch ff veel% performance winst...

klopt dit? of welk gedeelte van het probleem mis ik hier nu ?

Het deel waar je die 80 tegelijk laat scannen Mag jij mij uitleggen hoe je dat met PHP kunt oplossen... voor zover mijn PHP kennis rijkt (en dat is aardig ver) kan dat niet...

[joopst]

ik zit niet zo in de fsockopen .. maar kan je dan vanaf 1 server niet 2 fsockopens tegelijk doen vanuit twee script instanties ?

[stekkel]

Zie http://gathering.tweakers...message/19150550#19150550

[m33p]

Ok maar nogmaals, in het fsock gedeelte zit de tijd niet Het stuk waar je naar linkt staat wel een manier om onder linux asynchroon meerdere php instances te draaien, maar het betreft hier een Windows 2003 server Ik ben bang dat ik wat betreft de sockets er nog weinig snelheidswinst uit kan halen...

[SchizoDuckie]

wat je ook kan doen is het anders aanpakken:

• een batch file maken die andere batchfiles aanroept met call (asynchroon)
• die andere batchfiles laat je elk php aanroepen
• en voila, daar is je multithreaded script

spoiler:

*SchizoDuckie is uiteraard niet verantwoordelijk te houden als dit je hele stats bak plattrekt :-P maar volgens mij moet dit kunnen :-)

[ Voor 3% gewijzigd door SchizoDuckie op 13-03-2006 18:08 ]

[SIMPY.be]

simplystisch idee:
een for-luske met 80 iframes. Zodoende kan je in een weinig tijd toch 80 threads starten?!

[Guldan]

Kun je ook niet via bat/C/C# whatever een bestandje maken dat deze gegevens uitleest en deze in een textbestandje heenzet wat je via php gaat uitlezen. Dan zet je de exe in de scheduling service en heb je bijna geen lange responsetijd meer. Maar ik weet niet of je fysieke toegang tot alle servers hebt.

[m33p]

Ja ik heb fysieke toegang tot alle servers, maar ik kan geen C scripten. Bat wl, en het idee wat SchizoDuckie ga ik morgen eens proberen, ik test alles in een virtual PC omgeving op mn werkstation dus als de boel keer plat gaat is geen probleem.

Opzich is het idee ranzig maar dat is niet echt een punt. Het is toch een intern project waar alleen ik aan werk, puur om een groot aantal servers makkelijk te kunnen monitoren vanaf elke welkplek. Dat zulke pakketten wel bestaan weet ik maar dat is ook niets aan.

Alvast bedankt, morgen update(s).

[m33p]

Ik heb het idee van SchizoDuckie geprobeerd, maar call is volgens mij niet asynchroon. Het 'include' gewoon het bestand (de andere batch) in de huidige batch en gaat hem daar ook uitvoeren. Het probleem met het wachten bestaat dan alsnog. Ook heb ik geprobeerd met call gewoon meerdere keren de PHP CLI aan te roepen, maar geeft (uiteraard) het zelfde effect.

Het idee van SIMPY.be is ook realiseerbaar, maar nogal ranzig al zeg ik het zelf. In dit geval gaat de client (of vanaf waar je de pagina bekijkt) een aantal threads starten wat opzich niet direct een probleem is, maar wel ranzig is. Het lieft fix ik het op de server. Tot nu toe al veel goede ideeën maar niet allen (door mij) realiseerbaar. Mogelijk heeft iemand nog een idee?

UPDATE
Ik heb het zojuist opgelost door 'start' te gebruiken. Dit werkt wel gewoon voor zover ik zo gauw kan zien. Ik ga hier nog even verder meer prutsen.

[ Voor 13% gewijzigd door m33p op 14-03-2006 11:16 ]

[oogapp0ltje]

best wel minder dat php geen multi-threading heeft en alleen on-call word uitgevoerd, ben net begonnen met servlets in Java. Ik beschouw het toch wel als een groot voordeel dat je gewoon threads kunt gebruiken en dat alles stateless is. Afhankelijk van de eisen die je stelt, lijkt het me voor complexe en grote projecten sneller en efficienter om J2EE te gebruiken ipv. PHP. Maar dat is natuurlijk een losstaande discussie opzich.

[m33p]

Klopt, in dit geval is het echt een minpunt. PHP is ook niet echt geschreven voor zoiets maar het is de enige mogelijkheid die ik heb, en het kan met wat truckjes, en als het werkt is het nog snel ook dus waarom niet

Op het moment ben ik bezig het zo op te lossen:
- Script genereerd een batch file met daarin de lines in de vorm: start /B X:\pad\naar\php.exe -f X:\pad\naar\script.php var var var

Start zorgt er voor dat het extern aangeroepen zal worden, en de /B zorgt er voor dat het in de background gebeurd. De var's zijn in mijn geval ID's van servers welke ik groepeer. Stel ik wil 4 threads en ik heb 8 ID's, dan heb ik 4 php instances welke allemaal 2 keer draaien. Deze data pleur ik in een MySQL database, waar de index pagina de boel weer uit haalt. Ik moet hiervoor wel heel veel omgooien, maar het lijkt mij op het moment de enige snelle oplossing.

[ Voor 4% gewijzigd door m33p op 14-03-2006 13:44 ]

[joopst]

joopst schreef op maandag 13 maart 2006 @ 15:25:
volgens mij kan je dan het beste een scriptje maken die 1 server scant .. en die flink veel tegelijkertijd opstarten

zoiets had al iemand ooit gezegd .. iig bedoeld

ik zal de volgende keer proberen het wat duidelijker op te schrijven

[sariel]

Als je wil kijken naar threads/forks en zo, kijk dan hier ff: http://nl2.php.net/manual/en/ref.pcntl.php

[m33p]

sariel schreef op dinsdag 14 maart 2006 @ 14:25:
Als je wil kijken naar threads/forks en zo, kijk dan hier ff: http://nl2.php.net/manual/en/ref.pcntl.php

Ik zat er al naar te kijken maar ik quote:

Note: Currently, this module will not function on non-Unix platforms (Windows).

En aangezien ik wel een Windows bak moet gebruiken voor een onderdeel dat WMI gebruikt kan ik er niet veel mee, maar bedankt.

@joopst:
Je zei het ja Ik heb het ook bedacht, het ging meer om de uitvoering er van, wat achteraf ook relatief simpel blijkt te zijn, het moet alleen ff bedacht worden. Bedankt in ieder geval.

[Wim Leers]

Ik zou ook iedere server bv. éénmaal per minuut zijn status (en de laatste status-update-tijdstip) laten loggen naar een .txt/.xml/.html/.whatever en dit vervolgens uitlezen op de 'master server'. Dit is het snelst en het effectiefst!

[m33p]

Mogelijk maar nogmaals, PHP is de enigste scripting taal die ik goed ken. Nou kan ik de CLI versie van PHP gebruiken, maar het nadeel is dat nogal 'zwaar' is om alleen wat simpele stats op te halen. Ook moet ik dan op elke server het client pakket installeren wat ook een nogal tijdrovende klus is Aangezien de helft developer servers zijn, en we elke week wel een nieuwe server installeren is dat niet echt lekker te doen.

Op het moment doen we wel wat jij zegt op de workstations. We hebben hier een app runnen welke info verstuurd naar een master server (waar deze app ook op moet komen) welke dit netjes weergeeft in een lijst. Deze zouden we ook op de servers kunnen gebruiken, maar dat is niet echt een oplossing vanwege bovenstaand en dat de app dan omgegooid moet worden aangezien deze nu véél info ophaald wat we voor de servers niet nodig hebben.

Ik ga nog wat verder experimenteren met de 'threads' in PHP. Gister kwam het er niet echt van, kijken of het vandaag wat beter gaat. Nogmaals bedankt

[Thekk]

SIMPY.be schreef op maandag 13 maart 2006 @ 18:12:
simplystisch idee:
een for-luske met 80 iframes. Zodoende kan je in een weinig tijd toch 80 threads starten?!

Dit lijkt me nieteens zo'n slecht idee, iedere server een id geven en die meegeven aan het query-scriptje dat je in een iframe laad.
Vervolgens de hoofdpagina een refresh van x seconden meegeven, waarna je zeker weet dat je alle gegevens weet.

[CH4OS]

Heb je ZendOptimizer geinstalleerd staan? Zo niet, dan kan je dat ook nog proberen, dat kan namelijk ook een performance boost geven...

[SIMPY.be]

ahaaa, ben blij dat er toch iemand mijn post opmerkt en wat commentaar geeft.

[m33p]

offtopic:
ik heb ook mijn mening gegeven over je post...

Overigens denk ik dat de ZendOptimizer hier geen boost geeft. Ik heb de ZendOptimizer al er in gebakken en die draait ook, maar nogmaals, de tijd zit in het uitvoeren van de scriptjes. De scriptjes zelf kunnen makkelijk naast elkaar draaien (waardoor het sneller gaat) waar ik nu mee bezig ben, maar eerst moet ik een flinke update doen aan het script wat hier even los van staat, wat op het moment even wat prioriteit heeft.

Uiteraard bedankt voor het meedenken

[ Voor 2% gewijzigd door m33p op 15-03-2006 13:28 . Reden: 2 maand Duitsland is niet bevorderlijk voor Nederlandse zinsopbouw ;) ]

[killercow]

php heeft gewoon multithreading hoor,

alleen niet op windows.

kijk hier maar eens naar:
http://nl2.php.net/pcntl_fork

Opcode cashes etc werken natuurlijk maar marginaal, de tijd zit het echt niet in het "compilen" van de code.

[ Voor 32% gewijzigd door killercow op 16-03-2006 10:54 ]

[m33p]

Met scriptjes bedoel ik de externe apps die aangeroepen worden zoals ook in de TS start

Overigens is je link al gegeven, en zoals ik ook vermeld heb draai ik Windows en kan ik daar ook niet vanaf aangezien ik WMI nodig heb, wat niet op Linux werkt

[mr_obb]

Via wat googlen en lezen van Franse artikelen heb ik het volgende stukje voor je gevonden. Dit artikel beschrijft precies wat jij wilt doen:

http://netevil.org/node.php?nid=280

Zijn manier: Op fsockopen moet ik wachten, dus gebruik ik dat niet. Best slim eigenlijk.

Succes ermee!

[ Voor 24% gewijzigd door mr_obb op 16-03-2006 12:01 ]

[orf]

Via wat googlen en lezen van Franse artikelen heb ik het volgende stukje voor je gevonden. Dit artikel beschrijft precies wat jij wilt doen:

Mooi stukje, ik kan het in ieder geval gebruiken, misschien de TS ook.

[m33p]

Kijk dit is handig. Ik denk dat ik hier een heel eind mee moet komen. Het enigste waar ik mee zit het is wachten op 3 batch files per server (checken of een service draait, netbios info ophalen, service restoren naar oorspronkelijke staat) maar ik denk dat ik dat maar ga aanpassen naar alleen de netbiosnaam te cachen (sql) en de login user niet op te halen... In princiepe hoef ik dan alleen een scheduled task te laten draaien, en het checken of de boel online is is met bovenstaand artikel wel rap genoeg ga ik van uit, hoogstens een seconde of 5 denk ik zo.

[Verwijderd]

http://nl3.php.net/bcompiler
daar kun je eens naar kijken, schijnt echt retesnel te zijn.

[m33p]

Weer een zeer goede tip. Ze praten er over 30% snelheidswinst. Op een flink script kan dat toch weer een paar seconden schelen. Ik dev nu op een devbak (de logica...) maar wanneer het script klaar is voor gebruik komt het op een dual xeon bak, en een aparte MySQL server. Ruimte is er zat (300 gig SCSI) dus ik kan zonder problemen bcompiler gebruiken (bytecode is groter dan orginele source). Thnx

\Overigens zit ik nu op 40 seconden voor 45 servers (incl. caching, excl threads ). Binnenkort threading inbouwen en bytecompiling testen. Daarna / daarvoor nog tunen en tweaken en dan moet het wel wat zijn denk ik

[ Voor 22% gewijzigd door m33p op 16-03-2006 18:02 ]

[maartenba]

Met compileren denk ik eigenlijk niet dat je veel snelheidswinst gaat maken. Uiteindelijk zit de vertraging vooral in het feit dat je moet wachten op externe factoren, je scriptje lijkt me niet eens zo zwaar te zijn.

[m33p]

Al met al denk ik dat ik flink nog wat snelheidswinst kan halen. Het is niet 'een scriptje' wat het misschien zo lijkt op het eerste gezicht. Het is ondertussen al een flinke app aan het worden en ik ben nog niet op de helft denk ik. Ook zijn er stukken code waar veel berekeningen uitgevoerd worden en veel geparsed moet worden. Maargoed ik vermeld ook dat ik het eerst ga testen. En ook al is het maar 10 of 20 procent van de tijd, op een pagina die bijv 10 of 20 seconden nodig heeft om te parsen tikt dat al aardig aan. Uiteraard moet het wel in verhouding zijn tot de tijd die je kwijt met met compilen enzo maar daarom ook testen

[frankivo]

en als je het andersom gaat bekijken?

elke server gaat de mysql server om de zoveel tijd vertellen dat ie er nog is
op het moment dat jij de status opvraagt en de laatste update van een server is langer dan bijvoorbeeld 10 minuten dan is ie stuk

nadeel is dat je op elke server een scriptje en een crobjob hebt, maar dat scriptje kan wel via cvs oid geupdate worden


--- edit ---
cron gaat niet werken
maar windows heeft ook zo'n scheduler

[ Voor 11% gewijzigd door frankivo op 17-03-2006 15:17 ]

[SinergyX]

Mischien doormiddel van een <img tag naar een php script te verwijzen die obv de status een jpg/png terugparsed? Zo heb ik het zelf voor een 16 servers gedaan, de pagina laad meteen in en langzaam komen alle status-images te voorschijn.

of ik begreep het verkeerd

[m33p]

@FrankTM
Gaat niet werken Het is eerder vermeld maar er zijn hier servers zat en wekelijks, soms dagelijks komen ze er bij en gaan ze weg. Dan moet ik elke keer die app installen wat eigenlijk niet een optie is.

@SinergyX
Dat heb ik eerder gedaan maar nog niet aan gedacht. Dat is wel een makkelijke manier van 'threading' opzich, maar ik denk dat ik het alleen kan gebruiken bij het online/offline checken. Overigens hebben we nu gewoon via een policy messenger service overal aangezet, en haal ik de ingelogde user via WMI op i.p.v. netbios. Zit nu op 44 seconden voor 51 servers. Dit is nog steeds zonder threading aangezien ik daar nog geen tijd voor gehad heb. Al met al moet het nog wel flink omlaag kunnen door die netbios request d.m.v threads te doen.