Webapplicatie monitoring

[Kalentum]

Ik beheer een webapplicatie die niet druk wordt gebruikt ( max. 1000 hits per uur). Omdat de performance nogal slecht is ben ik begonnen met het verzamelen van gegevens. Het blijkt echter dat onder bepaalde omstandigheden de gebruikers last hebben van het verzamelen van die gegevens. Ik heb daarom het verzamelen van die gegevens stop gezet. Ik wil daar wel weer mee verder gaan, omdat ik graag wil zien wat het effect is van toekomstige optimalisaties.

Het gaat om een PHP applicatie. Voor elk request leg ik een aantal gegevens vast:
- Datum/tijd
- Request ($_REQUEST geserialiseerd) (onnodig?)
- Queries (array met uitgevoerde queries, geserialiseerd) (onnodig?)
- aantal uitgevoerde queries
- run time van het request (dus de tijd die PHP nodig heeft om het request te verwerken)
- database tijd (optelsom van de tijd die elke query nodig heeft)
- maximale geheugenconsumptie

Deze gegevens worden weggeschreven naar een logtabel in de database. Maar echt handig blijkt dat niet te zijn. Dus nu ben ik op zoek naar andere methoden.

Ik vroeg mij af hoe anderen omgaan met dit soort informatie:

• Meet je überhaupt iets?
• Meet je elk request of een sample (bv 10% ofzo)
• Welke gegevens precies?
• Hoe leg je ze vast?

[fleppuhstein]

Monitoring is een vrij breed begrip, en kan verschillen van applicatie tot applicatie.

Ik zou zeggen begin met webalizer om je verkeer in beeld te brengen, hiermee kan je zie welke request met regelmaat worden aangeroepen. Deze zou je dan kunnen verder monitoren / debuggen.

Op je database server zou je de log slow query's aan kunnen zetten. En zou de langzame query's eruit pikken. Of als als je queries lansg een single point of code lopen (Database class, singleton instance), zou je een wrapper om PDO heen kunnen schrijven die query's logt, en de uitvoer tijd meelogt.

En loggen moet je niet naar DB doen, maar gewoon naar file, evt in een eigen te bepalen protocol/format, die je met een separate applicatie kan uitlezen. Disk ruimte is gratis terwijl CPU tijd optimaal benut moet worden. Dus het opslaan in database van een langzame query verergerd de situatie eigenlijk.

Als je gaat loggen zou ik wel voor alles loggen, en niet een deel van wat je logt, dit kan een verkeerd beeld geven. Denk aan gebruiks verschillen gedurende de tijd op een dag, of evt dag van de maand. Als voorbeeld: bepaalde rapportages worden vaak maandelijks gedraaid, hier onder vindt je dus hinder van op de eerste paar dagen in de maand.

[ Voor 27% gewijzigd door fleppuhstein op 13-01-2010 10:20 ]

[cariolive23]

Zend Studio heeft een profiler waarmee je dit soort zaken vooraf al kunt ontdekken. Daarnaast kun je langzame queries laten loggen en kun je jouw databaseserver (runtime) configureren t.b.v. een betere performance.

Loggen is noodzakelijk, maar liever niet op een productieomgeving waar dit e.e.a. kan vertragen. Gebruik een testomgeving die lijkt op jouw productieomgeving en zet hier hier een relevante belasting op (er zijn goede testtools voor load & stresstests).

[Compuhair]

Check ook of jouw app de enige is op de server. Anders zit je straks je eigen app te monitoren terwijl de vertraging ergens anders door wordt veroorzaakt.

Gebruik een logging framework. Voor C# is er log4net bijvoorbeeld, ik weet niet wat er voor PHP is, maar het is zonde van je tijd om een eigen logger te schrijven. Je wil ook niet dat je app crasht omdat je naar een logfile wil schrijven, terwijl dat bestandje net gelockt is door een andere logactie. Laat dat soort dingen dus door het logging framework afhandelen.

Label je logmessage: error, debug, info, warning

Een log-request zelf kost volgens mij maar een paar milliseconde. Met het aantal hits per uur dat jouw app heeft moet dat geen probleem opleveren, het verbaast me dan ook dat merkbaar is voor je gebruikers.
Desalniettemin, zorg ervoor dat je via een setting in je config-file de logging aan en uit kan zetten op de productieserver, zodat je je app of server niet hoeft te restarten.

Verder zou ik alles loggen, niet slechts een bepaald percentage.

Probeer te achterhalen of een specifieke query traag is, of dat op een gegeven moment het hele systeem traag wordt. Of ligt het juist aan een bepaald stuk code dat je hebt gebouwd?


Nog even over wat je nu logt:
- Datum/tijd noodzakelijk
- Request ($_REQUEST geserialiseerd) (onnodig?) zegt me niet zoveel
- Queries (array met uitgevoerde queries, geserialiseerd) (onnodig?) ga je hiervoor een lijstje bijhouden ofzo? ik zou gewoon voor iedere actie die je naar de DB gooit naar de log schrijven. En nadat je antwoord hebt gekregen ook weer naar de log schrijven.
- aantal uitgevoerde queries Niet doen, dat kan je wel uit je logfile halen. Geen lijstjes bijhouden, geen tellers bijhouden. Ik wil alleen loggen dat er iets wordt uitgevoerd, wat dat is, en wanneer. Dan kan ik vervolgens zelf wel uitrekenen hoevaak en hoelang dat was
- run time van het request als je naar een DB logt, dan is dat makkelijk uit te rekenen in de DB, met een tekstbestand als log is dat lastiger. Lijkt me niks op tegen op tijdsduur bij te houden
- database tijd (optelsom van de tijd die elke query nodig heeft) Ik zou elke afzonderlijke query timen. Het totaal zegt te weinig. Ik wil niet weten dat 10 queries samen langzaam zijn, ik wil weten dat 9 queries supersnel zijn, maar de laatste in de rij duurde erg lang.
- maximale geheugenconsumptie heb je hier geen server app voor? scheelt je een hoop moeite, dan hoef je voor dit soort stats geen logging te bouwen

Ik vroeg mij af hoe anderen omgaan met dit soort informatie:
Meet je überhaupt iets?
[/b]Als er echt ergens een bottleneck zit, dan wil ik eigenlijk de hele flow loggen. Dan log ik als volgt:
12:24:03:371 - buttonX_click - Start
12:24:03:372 - buttonX_click - call Method1
12:24:03:373 - Method1 - start
12:24:03:379 - Method1 - execute GetProducts - start
12:24:03:479 - Method1 - execute GetProducts - end
12:24:03:480 - Method1 - execute GetSales - start
12:24:04:480 - Method1 - execute GetSales - end
12:24:04:490 - Method1 - end
12:24:04:491 - buttonX_click - return from Method1
12:24:04:492 - buttonX_click - DoeNogIets
12:24:07:259 - buttonX_click - end

[Kalentum]

De applicatie heeft een slechte performance. Dit komt doordat de meeste queries meerdere tabellen nodig hebben en veel van de indexen verkeerd staan of niet aanwezig zijn. Toen de applicatie werd ontwikkeld in een grijs verleden is er onvoldoende rekening gehouden met het gebruik van nu.

Om toch gegevens te krijgen op basis van productie ga ik ga eens kijken naar een logging framework. Er zijn er verschillende voor PHP. Ik denk dat ik dan naar file ga loggen en dan gegevens ga aggreren in de database.

Het bijhouden van queries doe ik maar niet meer. De kandidaten voor verbetering komen in de slow query log en kan ik dus daar vandaan halen.

[MueR]

rutgerw schreef op woensdag 13 januari 2010 @ 09:36:
- Request ($_REQUEST geserialiseerd) (onnodig?)

Die is inderdaad niet nodig. Wat wel nodig is, zijn de $_GET en $_POST arrays. Het is beter om $_REQUEST helemaal links te laten liggen in je applicatie.

[Anoniem: 187577]

Zie het volgende: http://devzone.zend.com/a...-Applications-With-xdebug
Met CacheGrind kan je de zooi weer inlezen. Profiling 1 uur aanzetten, daarna een paar bestanden uitpikken om te onderzoeken in cachegrind.

[Juup]

rutgerw schreef op woensdag 13 januari 2010 @ 16:28:
De applicatie heeft een slechte performance.
Dit komt doordat de meeste queries meerdere tabellen nodig hebben en veel van de indexen verkeerd staan of niet aanwezig zijn.

Dus je weet al een oorzaak?
Tijd voor wat alter table's of CREATE INDEX

[ Voor 3% gewijzigd door Juup op 13-01-2010 16:40 ]

[Kalentum]

Juup schreef op woensdag 13 januari 2010 @ 16:40:
[...]


Dus je weet al een oorzaak?
Tijd voor wat alter table's of CREATE INDEX

Ja ik weet de oorzaak. Het gaat mij om het meten van de performance zodat het effect van verbeteringen meetbaar wordt.

[cariolive23]

Wanneer je weet dat jouw queries en database het probleem zijn, dan hoef je toch alleen maar de queries te loggen en te explainen? Je ziet dan snel genoeg welke queries voor problemen zorgen en je kunt dan zowel de queries als de (beschikbare) indexen gaan optimaliseren. Vervolgens ga je de query nogmaals explainen (zonder cache te gebruiken!!!) en je ziet per query het verschil in performance.

Uiteraard begin je met de queries die voor de grootste problemen zorgen.

[mithras]

Je kan met XDebug een hele hoop profilen wat betreftje php code. Als je dat inleest bij verschillende requests kan je de daadwerkelijke prestaties vergelijken. Met behulp van php (tijd/geheugen etc) meten is bij lange na niet nauwkeurig en zal je dus ook niet de correcte informatie geven.

Mocht je liever db queries in php debuggen, kan je kijken of je Firephp kan gebruiken. Met Firephp kan je middels php heel eenvoudig berichten in de console van Firebug stoppen. Met mijn Zend Framework applicatie is de Db adapter gekoppeld aan een Firephp logger. Hierdoor worden alle queries, inclusief uitvoertijd, beschikbaar via je Firebug console.

[Shagura]

mithras schreef op woensdag 13 januari 2010 @ 19:37:
Je kan met XDebug een hele hoop profilen wat betreftje php code. Als je dat inleest bij verschillende requests kan je de daadwerkelijke prestaties vergelijken. Met behulp van php (tijd/geheugen etc) meten is bij lange na niet nauwkeurig en zal je dus ook niet de correcte informatie geven.

Hoezo zou dit onnauwkeuriger zijn? XDebug doet toch precies hetzelfde alleen dan met hooks in de parser oid.? (geen idee tbh)

[mboy]

Of kijk eens naar xhprof (http://pecl.php.net/package/xhprof). Hebben ze ooit bij Facebook gemaakt om bottlenecks in die app te fixen. xhprof kan mooie grafische call trees genereren die precies laten zien welke onderdelen van je applicatie traag zijn.

Overigens is het altijd van belang je MySQL server (ik ga er maar even vanuit dat je dat gebruikt) zo te finetunen dat het optimaal gebruik maakt van je hardware. Een makkelijke manier om dat snel te doen is mysqltuner te downloaden (wget mysqltuner.pl) en dat te draaien.

[Koelkasten]

rutgerw schreef op woensdag 13 januari 2010 @ 16:28:
De applicatie heeft een slechte performance. Dit komt doordat de meeste queries meerdere tabellen nodig hebben en veel van de indexen verkeerd staan of niet aanwezig zijn.

Wel, je bent op de goede weg volgens mij maar volgens mij zet je hier in deze post precies wat het probleem is.

Nu probeer je door middel van logging en ik denk daarmee een redelijke omweg tot de kern van het probleem te komen. volgens mij wil je je query's en database optimaliseren. ik zie nergens staan welke database je gebruikt maar bij heel veel databases (bijv MySQL) kun je gewoon query logging aanzetten. zo worden alle langzame query's in een log bijgehouden en kun je die stuk voor stuk gaan optimaliseren ook kun je met een grep dan nog wel terugvinden uit welk script (deel) ze komen.

Scheelt je een heel logging systeem implementeren.

[Anoniem: 53868]

Haal de applicatie en database eens naar een lokale machine. Zet daar query logging aan inclusief log-queries-not-using-indexes. Ga eens een beetje rond klikken en kijk wat er in de log staat. Als je dit op de server zelf aan kunt zetten voor een paar uur ofzo is nog beter aangezien je dan real life data hebt van wat gebruikers doen,

Daarna EXPLAIN gebruiken en je kunt vrij snel zien wat er eventueel mis is. Let er op dat het niet gaat om hoeveel indices maar om de juiste indices.