Detta är väll en ganska svår/omöjlig fråga att svara på egentligen men jag undrar om någon
kan ge mig en hint om vad en vettig loadtime för ett script (i detta fallet php) är.

Jag håller på med att optimerar koden på en site som kräver lite väl mycket CPU tid för att webbhotellet ska vara nöjt.

Min första sida som inhåller en hel del material tex medlemstoplista, bilder och lite info om femton slumpade medlemmar, vilka som är online samt en vanlig toplista.

Laddtiden på denna sida hamnar på mellan 0,2-0,3 sekunder. Låter det som en rimlig tid eller är det mycket?

Hoppas någon kan ge mig en hint...

Jag tycker det låter lite mycket, men beror på.. Hur många databasfrågor har du? Hur mycket tid spenderas i php vs. mysql?

Jag har tagit bort det mesta av mySQl anropen och så mycket php som möjligt och gjort cash filer som bara inkluderas med php. Tyvärr är det ett köpt script då jag tänkte att jag skulle spara tid... Skaparen av detta verkar inte ha vetat ett dugg om optimering. Jag har nu kapat ca 0,1 s på startsidan genoma att göra om det som återstod av den den ursprungliga koden.

Bara för att få gnälla av mig lite....

I den ursprungliga koden så skulle en slumpmässig medlem plockas ut.
Skaparen hade då hämtat alla medlemmars id från databasen och stoppat in dom i en array och sen gjort ett random på detta och då fått ut ett id, sen anropar han databasen igen med detta id för att hämta medlemsinfon :blink:

Så slutsatsen av detta är nog att man får gå igenom allt och se vad mer roligt man kan finna....

0.2 sekunder är sannerligen inte speciellt mycket. Optimeringar skall man dock alltid försöka göra, med jämna mellanrum.

Testa att köra lite profiling på koden för att hitta eventuella flaskhalsar, google är din vän samt kolla:

http://www.sitepoint.com/blogs/2007/...de-with-xdebug

Annars är ju memcached ett hett val när det gäller att cacha mysql frågor.

Precis som coredev sa så är 0,2s inte så speciellt mycket om det är mycket information som skall visas, men att det kan bli bättre med optimering är inte fel.

Har testat att köra lite frågor och mätt responstiderna mot diverse olika sajter i Sverige samt mina egna och 200ms verkar vara rätt mycket:

www.webmasternetwork.se: 84ms
www.dn.se: 37 ms
www.idg.se: 75 ms
min sajt1: 373 ms
min sajt2: 48 ms

Har kört ApacheBenchmark som följer med webbservern Apache med följande argument:

ab -n 10 -v 2 http://acme.se/

0,2 sekunder skulle inte vara så farligt om det är hög belastning, men.. Är belastningen mer eller mindre obefintlig så kommer det bli riktigt otrevligt när det drar på lite sen :/

Kan ha gjort detta för MySQLs RAND är notorisk långsam med större dataset.

Jag har ca 4000 unika besökare per dygn så lite trafik har den ju...

Men det måste väl ändå vara snabbare än att plocka in 43 000 rader i en array och plocka ur en??

Jag har inte tänkt så himla mycket på optimering förut utan mest kodat med sunt förnuft och det har funkat bra hittills
Men nu när jag grävt lite mer i det så är det ju uppenbarligen så att CPUn i servern idlar medans den väntar på sql anropet ska returnera resultatet (vilket ju är helt logiskt och rimligt) så det jag optimerat i sql anropen verkar inte ha påverkat CPU användningen alls, snarare verkar det ha haft omvänt resultat.

Tex verkar MySql ha stora problem med group by
Följande fråga tog ca 10 sekunder att exekvera:
select
$tb_comments.id as id,
$tb_comments.user_id as user_id,
$tb_comments.subject as subject,
$tb_comments.comment as comment,
$tb_comments.author_id as author_id,
count($tb_comment_views.comment_id) as comment_views,
$tb_users.username as author_name,
$tb_users.image_status as image_status
from
$tb_comments
left join
$tb_comment_threads
on
$tb_comments.id = $tb_comment_threads.comment_id
left join
$tb_comment_views
on
$tb_comments.id = $tb_comment_views.comment_id
left join
$tb_users
on
$tb_comments.author_id = $tb_users.id
where
$tb_comments.pid = 0 ";

if ( $poster_id )
{
$sql .= " and $tb_comments.author_id = $poster_id ";
}

$sql .= " and
$tb_comments.status = 'approved'
group by
$tb_comments.id
order by
$tb_comment_threads.updated desc
limit
$csr, $comments_per_page

när jag ändrade den till:
select
$tb_comments.id as id,
$tb_comments.user_id as user_id,
$tb_comments.subject as subject,
$tb_comments.comment as comment,
$tb_comments.author_id as author_id,
$tb_users.username as author_name,
$tb_users.image_status as image_status
from
$tb_comments
left join
$tb_comment_threads
on
$tb_comments.id = $tb_comment_threads.comment_id
left join
$tb_users
on
$tb_comments.author_id = $tb_users.id
where
$tb_comments.pid = 0 ";

if ( $poster_id )
{
$sql .= " and $tb_comments.author_id = $poster_id ";
}

$sql .= " and
$tb_comments.status = 'approved'
group by
$tb_comments.id
order by
$tb_comment_threads.updated desc
limit
$csr, $comments_per_page

så tar den ca 1 sekund att exekvera.

Efter ändringen fick jag köra count() separat så det blev ju ett anrop till samt hantering av detta vilket ju ökar belastningen på CPUn litegrann. Laddtiden på sidan blev dock ca 10 sekunder snabbare vilket ju är bra för besökaren men inte för sänkningen av CPU använningen.

Nu kanske man sväljer kameler och silar mygg men, hur krävande är det egentligen och hålla på att ersätt alla dess fördefinerade variablerna tex $tb_comments, det borde ju ta ett par klockcykler för varje, eller?

Kan testa att använda SQL_CALC_FOUND_ROWS. Blir ioförsig 2 anrop fast det är bara ena anropet som egentligen gör något.

Jag skulle nog se det såhär: Det är bättre om du sänker användningen av din databasserver än din webbserver då du vid en ev. utökning av serverparken lätt kan slänga dit en till webbserver, men en till databasserver är betydligt svårare.. Lättare att skala om det är webbservern som får jobba lite extra med andra ord.

Intressant råd Onkelborg, frågar du en DBA kommer han säga motsatsen i 9 fall av 10. Desto mer logik du lägger i databasen desto bättre kommer din sida att flyta på i regel.

Nja, det tror jag inte på.. Alltså: Vad man vill minimera är att man plockar ett värde från databasen till webbservern, låter sedan webbservern skicka tillbaka det värdet för att plocka ytterligare ett värde. Dvs. få ner _antalet_ anrop. Men..

I det här fallet tvingar man databasen att jobba i 10 sekunder med någonting under ett anrop istället för 1 sekund under två anrop. Vad är bäst för prestandan?

Vidare, du vill aldrig göra några väldigt beräkningsintensiva saker i databasen om du likaväl kan göra beräkningarna på någon annan server (troligtvis webbservern) om du har några som helst planer på att skala någon gång i framtiden. Dock, finns undantag; om det är stora mängder data som det ska beräknas på så måste man ta hänsyn till att det är stora mängder data som ska transporteras, beräknas på något sätt, och sedan kastas. Det är också dyrt.

Anledningen till att man inte vill belasta databasen så mycket är att när man väl vill skala ut så är det väldigt enkelt att slänga dit en till webbserver; båda jobbar fortfarande mot samma databas. Det enda man måste fixa är sessions-hanteringen då.

Om vi å andra sidan har alla stora beräkningar i databasen så att den tar stryk först så är det en till databasserver vi behöver, och då börjar allting bli problematiskt..

Hmm njae..detta är ju bra för CPU oxå . Då används ju cpu tid i 10 sekunder mindre, oavsett om DB kör på separat sever eller inte är det mycket bättre..

Hur vet du vilken sida som orsakar cpu problem? Kan ju vara en viss sida eller query eller oändlig loop eller något so orsaker det..