WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Normal "loadtime" (https://www.wn.se/forum/showthread.php?t=25874)

nakna 2007-12-27 11:23

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...

Onkelborg 2007-12-27 13:38

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?

nakna 2007-12-27 14:20

Citat:

Originally posted by Onkelborg@Dec 27 2007, 14:38
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....

coredev 2007-12-27 16:16

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

JLE 2007-12-27 16:17

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.

Samben 2007-12-27 17:08

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.

JLE 2007-12-28 00:07

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/

Onkelborg 2007-12-28 00:11

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 :/

Weaver 2007-12-28 11:03

Citat:

Originally posted by nakna@Dec 27 2007, 15:20

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

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

nakna 2007-12-28 12:56

Citat:

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 :/
Jag har ca 4000 unika besökare per dygn så lite trafik har den ju...

Citat:

Kan ha gjort detta för MySQLs RAND är notorisk långsam med större dataset.
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?


Alla tider är GMT +2. Klockan är nu 22:19.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson