[olsserik]

Hoppas kunna få hjälp med ett problem jag har med att php har långa svarstider ibland på en sajt jag har. Ena sekunden kan det vara som bra, men svarstider på millisekunder, trycker F5 och då kan det vara svarstid på 5 - 10 sekunder! F5 igen och den kan vara nere på millisekunder igen. Även kollat hur servern mår parallellt med testerna ovan och den verkar ok med cpu användning på mellan 1 - 2% och minnesanvändningen på ca 30%. Även load_average verkar helt ok på cpu.

Det är en linux vps med php som apache instans och ca 2 - 2.500.000 sidvisningar i månaden.

Jag funderar om det är något felkonfigurerat eller om tunga script/sidor som laddas ibland gör att segar ner, men jag tycker jag borde fångat upp det på cpu användningen då...?

Tack på förhand!

[emilv]

Kolla i Apaches server-status om du har brist på lediga Apache-processer under den tid du har störst belastning.

Kolla även i databasen om det är ovanligt många, eller tunga, SQL-frågor som körs (i MySQL: SHOW PROCESSLIST;).

[pelmered]

Testa att höja gränserna för samtidiga anslutningar, antal processer osv i apache. Det låter som det är något sådant problem.

Skulle det vara tunga SQL-frågor som orsakade borde det ju synas i CPU-loaden och inte komma då och då om inte frågorna cachas.

[emilv]

Ursprungligen postat av ITisGood.se

Testa att höja gränserna för samtidiga anslutningar, antal processer osv i apache. Det låter som det är något sådant problem.

Skulle det vara tunga SQL-frågor som orsakade borde det ju synas i CPU-loaden och inte komma då och då om inte frågorna cachas.

Jag håller med. Men angående SQL-satser så har erfarenheten lärt mig att det inte är ovanligt att ha en fråga som till exempel låser en tabell ibland, vilket gör att alla andra måste ligga på kö. Det borde inte ge exakt dessa symptom en brukar inte skada att kolla. server-status är dock första steget för att ställa en diagnos i det här fallet. SQL-frågorna är bara intressant om det inte är webbservern som är problemet.

[olsserik]

Tack!
All sql ligger på annan server så det borde väl inte vara problemet då eller?

Vet inte riktigt hur man kollar apache status och antal processer, tips någon?
Det låter som om vi kan vara nåt på spåren där.

[Clarence]

Ursprungligen postat av olsserik

Tack!
All sql ligger på annan server så det borde väl inte vara problemet då eller?

Vet inte riktigt hur man kollar apache status och antal processer, tips någon?
Det låter som om vi kan vara nåt på spåren där.

Är det en låst tabell som skapar fördröjningen på SQL-servern spelar det ingen roll om det ligger på en extern server. SHOW PROCESSLIST på SQL:en när det segar är en tydlig indiktator. Ser du mycket "Locked" där vet du vad problemet är.

[pelmered]

Ah, table locks tänkte jag inte på.
Hur är loaden på databasservern?
Om loaden inte är hög där heller kan du börja med att kolla efter locks som beskrevs ovan. Ser du inte massa locks där är det förmodligen något med apache-konfigurationen.

Med mod_status kan du se status på worker-processerna för att felsöka.
http://httpd.apache.org/docs/2.0/mod/mod_status.html

[Anders Karlsson]

Ursprungligen postat av olsserik

Tack!
All sql ligger på annan server så det borde väl inte vara problemet då eller?

Vet inte riktigt hur man kollar apache status och antal processer, tips någon?
Det låter som om vi kan vara nåt på spåren där.

Kan det vara begränsningar på antal anslutningar till db-servern?

[olsserik]

Hej,
När jag kollar svarstider är de aldrig sega från sql servern, spiksnabbt, så det borde väl inte vara det då? Det är php svarstiderna som segar ibland.

Antal anslutningar till db har uppnått max några ggr vid hög belastning (många online), men då får jag felmeddelande om det, det får jag inte vid de långa svarstiderna.

[emilv]

Ursprungligen postat av olsserik

När jag kollar svarstider är de aldrig sega från sql servern, spiksnabbt, så det borde väl inte vara det då? Det är php svarstiderna som segar ibland.

Som sagt, börja med server-status (mod_status).