FAQ |
Kalender |
![]() |
#1 | ||
|
|||
Nykomling
|
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... |
||
![]() |
![]() |
![]() |
#2 | ||
|
|||
Flitig postare
|
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?
|
||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Nykomling
|
Citat:
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.... |
||
![]() |
![]() |
![]() |
#4 | |||
|
||||
Bara ett inlägg till!
|
0.2 sekunder är sannerligen inte speciellt mycket. Optimeringar skall man dock alltid försöka göra, med jämna mellanrum.
|
|||
![]() |
![]() |
![]() |
#5 | |||
|
||||
Flitig postare
|
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. |
|||
![]() |
![]() |
![]() |
#6 | ||
|
|||
Mycket flitig postare
|
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.
|
||
![]() |
![]() |
![]() |
#7 | |||
|
||||
Flitig postare
|
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/ |
|||
![]() |
![]() |
![]() |
#8 | ||
|
|||
Flitig postare
|
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 :/
|
||
![]() |
![]() |
![]() |
#9 | ||
|
|||
Flitig postare
|
Citat:
|
||
![]() |
![]() |
![]() |
#10 | ||
|
|||
Nykomling
|
Citat:
Citat:
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? |
||
![]() |
![]() |
Svara |
|
|