Vad göra åt segheten i trådvisningssidan i mitt forum?

Om du kör lokalt med samma datamängd i databasen, upplever du samma sak då? Om det skett "av sig självt" låter ju som att någon datamängd någonstans har nått en kritisk gräns (typ, som plötsligt en dag började överskrida någon cachestorlek eller nåt) och som genom det får någon/några av din/a SQL-frågor att gå segt, gissningsvis då en fråga som bara körs för användare som är inloggade.

Om du inte upplever samma sak lokalt med samma databas kanske det har med trafiken att göra (den råkade inte öka i smaband med att problem uppenbarade sig?). Sånt är lite klurigare att felsöka men det finns lastsimuleringsverktyg (t.ex. ab för Apache).

Om det nu är din kod eller något den anropar som går slött kan jag rekommendera att du tar och tittar lite på den optimerande programmerarens bästa vän, profileraren, som låter dig se vilka funktioner det är som tar tid på sig:
http://www.google.se/search?q=php profiling&hl=sv&meta=

lillebror skrev:

Sedan fick jag rapport om att det även skiljer i hastighet när en tråd skall visas beroende på om man är inloggad eller ej.

ja, för när jag klickade runt där på forumet så small det bara till så hade sidorna laddats färdigt...

Märkligt Jag surfade runt och läste ett par trådar. Gick jättebra.
Så loggade jag in och testade med en annan tråd. Då tog det tid innan sidan laddades!
Typ över 10 sekunder alltså.

Jag har läst era kommentarer med stort intresse!

spango skrev:

Om du kör lokalt med samma datamängd i databasen, upplever du samma sak då?

För ett halvår sedan körde jag med en databas lokalt på min bärbara och vad jag kan minnas så gick det inte långsamt då. Nu har jag inte haft någon lokal databas installerad på ett bra tag och trafiken (antal inlägg i forumet) och medlemmar har stigit en hel del bara de senaste månaderna. Det kanske är läge att ta en dagsfärsk kopia på databasen och slänge in på min bärbara och göra ett test?

spango skrev:

Om det skett "av sig självt" låter ju som att någon datamängd någonstans har nått en kritisk gräns (typ, som plötsligt en dag började överskrida någon cachestorlek eller nåt) och som genom det får någon/några av din/a SQL-frågor att gå segt, gissningsvis då en fråga som bara körs för användare som är inloggade.

Här är lite statistik för databasen:

Tabeller: 56
Rader: 118 248
Data: 19,9 MB
Index: 1,0 MB
Totalt: 20,9 MB

spango skrev:

Om du inte upplever samma sak lokalt med samma databas kanske det har med trafiken att göra (den råkade inte öka i smaband med att problem uppenbarade sig

Nu när du säger det så kan jag nog tycka att det här problemet har kommit i samband med ökad aktivitet på sidan.

Fredde Mannen skrev:

lillebror skrev:

Sedan fick jag rapport om att det även skiljer i hastighet när en tråd skall visas beroende på om man är inloggad eller ej.

ja, för när jag klickade runt där på forumet så small det bara till så hade sidorna laddats färdigt...

När man inte är inloggad på sidan så är min uppfattning att det alltid går fort att visa en tråd.

Lasp skrev:

Märkligt Jag surfade runt och läste ett par trådar. Gick jättebra.
Så loggade jag in och testade med en annan tråd. Då tog det tid innan sidan laddades!
Typ över 10 sekunder alltså.

Det är just detta som är prioblemet.

Det som skiljer mellan att vara och inte vara inloggad i showthread.php är att det ställs ytterligare några databasfrågor för att exempelvis kolla om användaren har bevakat en tråd eller ej. Så mycket tycker jag inte det borde inverka på prestandan.

Har du provat att köra de frågorna som bara körs för inloggade genom något admingränssnitt för att se hur lång tid de tar, och kanske även köra en EXPLAIN (se manualen) för de frågorna? Du skulle kunna ha en ful join någonstans som genererar för många rader.

spango skrev:

Har du provat att köra de frågorna som bara körs för inloggade genom något admingränssnitt för att se hur lång tid de tar, och kanske även köra en EXPLAIN (se manualen) för de frågorna? Du skulle kunna ha en ful join någonstans som genererar för många rader.

Jag ska göra det! Återkommer med resultat!

En sak som är värd att tänka på är att om det bara drabbar inloggade medlemmar kan problemet bara till viss del bestå i hög trafik. Annars skulle prestandaproblemen drabba alla någorlunda jämnt, och bara bli lite värre för inloggade (eftersom det körs fler frågor).

Efter att på ett metodiskt sätt gått igenom alla SQL-satser som körs i inloggat läge (till skillnad från utloggat då sidan laddas snabbt) har jag hittat nålen i höstacken! :)

För varje inlägg som skrivs ut i tråden så finns det en "lägg till som kompis"-funktion som scannar igenom tblmyfriends för att matcha tblmyfriends.posterID med $RSobjTreadrepy['posterID']. Om det går att sätta ett likhetstecken mellan dessa två så visas symbolen "tar bort kompis" eftersom kompisen redan finns i tabellen tblmyfriends.

I samband med att jag hämtar information i tblmyfriends så körs följande SQL-fråga. Här kommer ett utdrag ur slutet av SQL-satsen och PHP-funktionen som tar emot ett userID som argument:

function listMyContactsForum($ID) {
...(SELECT
memberID
FROM
tblonline AS t5
WHERE
t5.memberID = t1.friendID) AS online,

(SELECT
activity
FROM
tblonline AS t6
WHERE
t6.memberID = t1.friendID) AS activity

FROM
tblmyfriends AS t1
WHERE
t1.memberID";
}

Det som är fel i koden ovan är att WHERE-satsen inte jämförs med något värde. Nu står det enbart WHERE t1.memberID, ja - med vadå kan man ju fråga sig!? :) Nu har jag gjort om SQL-satsen och lagt till $ID (argumentet som funktionen matas med) så att satsen ser ut på följande sätt:

WHERE
t1.memberID = ".$ID."";

Det konstiga är att koden exekverades utan någon anmärkning tidigare, bara det att det tog lite längre tid. Innan hade jag svarstider från databasen på ca 5.4279 sek. Nu har jag svarstider på 0.0114 sek.

Jag är så himla nöjd! :birp Nu rasslar det bara till så visas tråden!

Tack för hjälpen allesammans! (y)

Förnodligen evaluerade den bara värdet av t1.memberID som ett boolskt värde, och om jag inte missminner mig är alla numeriska värden förutom noll sant i MySQL (precis som på så många andra ställen), vilket borde betyda att den kört de två subselecterna för varje medlem i hela databasen, och då låter det inte så konstigt att det tagit lite tid :)