Jump to content

Recommended Posts

All of my php pages load pretty fast. Most are around 5kB in size. However whenever my index.php is inclived to display data, my site takes alot of time to load. My index.php is 51,3kB in size. Maybe the size doesn't matter, but what work the server has to do to find stuff in the database is what demands a longer load time. I honestly don't know. Does somebody know?

Link to comment
https://forums.phpfreaks.com/topic/86301-website-speed-indexphp/
Share on other sites

I see. Well my database is 234 MB in size. And there are quite alot of queries to get the content for. Indeed. Do you have any suggestions on how to optimize it?

 

What puzzles me is that I know a website with a much (much!) larger database who ask about the same amount of queries in the index.php - I just don't know how it can maintain resonable speed while growing tremendously each day.

 

Any advice is welcome. Thanks.

Well the quality of your servers (particularly your sql server) is also an issue - your physically geological location will affect speeds (you get slower connections to servers across the country/world for example). Also, if your web hosting shares the servers with others (instead of you having a dedicated server) will affect the speed.

 

Are you using your own server or do you have a website hosted somewhere?

adam

http://EzineArticles.com/

Check below for my website.

What content? I depends on what page has to load. the index.php has to load the main page, or an articles category, or an authors bio, or an authors's articles portal. So it has to fetch different content depending on what variable is in the url.

 

nikefido

It's not a dedicated. Not yet. It's a shared host. Though server speed is ok - at first glance.

Run both sites through this speed tester.

http://EzineArticles.com/
http://SmallArticles.com/

http://www.selfseo.com/website_speed_test.php

 

The page loaded pretty quick on my machine. You might need to consider reducing the approved articles bit to show a selection. Then have a section for all aproved articles. On that page use pagination to cut down the amount of records a query has to return.

 

 

Nice suggestion. I could yes. :)

Can you post the speed results you get. I'm curious. (server hosting is in Belgium, Europe)

 

I've reduced recently approved articles to 30, instead of 50, but it shows the same speed. I think it's due to article count # displayed next to subcategories ~ subcategory [#]

you shouldn't even have 30 article. Its the home page. If people have to scroll down load on a page they wont bother. They will just navigate away.

 

Speed test

 

Server platform: lighttpd/1.4.18

Page size (total): 120.129 Bytes

Number of elements considered: 29

Expected loading time for Modem / ISDN (56-64 kbs): 16,02 s

Expected loading time for DSL1000 (1024 kbs): 0,94 s

Expected loading time for DSL2000 (2048 kbs): 0,47 s

Expected loading time for DSL3000 (3064 kbs): 0,31 s

Expected loading time for DSL6000 (6128 kbs): 0,16 s

Overall evaluation (1 highest, 6 lowest) 7  (good)

 

 

The biggest file to load is the page itself with all that html code from the articles. I suggest limiting it to 10. You can randomise the 10.

 

 

I've limited it to 10. What do you mean exactly with "The biggest file to load is the page itself with all that html code from the articles."? Can you elaborate on that a bit? Imo, article pages load pretty fast. It's just the index.php without any varialble (homepage) asking alot.

Ok, I think that's the most important thing. I'll focus on optimising the size.

 

You think I should look into optimizing queries or php code blocks? Does smarter php code (more advance ways of how to fetch content from the database) reduce load time too?

if you can limit the number of queries the quicker the load time, as less searchs are done on the database and less records are being returned. At the mo 6seconds is not bad.

 

I read somewhere that anything over 8secods then users will navigate away. So 6is good

Ok, that's reassuring! I'll put myself to work and hopefully make it 5.5sec... who knows?

Thanks for all the help you offered here. You've made quite a difference for imagine how many people...  right? ;D

 

I"m hoping to add a revenue sharing program on my site, as soon as it becomes a hit. Meaning people will earn a percentage from all Google AdSense revenue gathered on the site, for writing articles. So it has got to be top notch! You've certainly helped me closer to my goal by helping me on an important aspect, imo.

 

So, cheers!

 

Yves

You might also consider looking into a caching system.  Let the front page cache out to a flat file for X minutes. (or hours).

 

Puts a delay in updates showing, but most big sites do this anyway (even partial caching at least). This reduces the strain on your SQL Service(s).

 

My own site uses a full-cache that writes the results out to a flatfile and replaces it once every hour.

 

For pages that are unlikely to change (specific article pages), i set to cache to rewrite the page once every month.

 

Other things to consider: Make sure your DB tables use indexes properly.

Should i contact my host to get caching system running or is it something I can manage myself? Any good resources are allways welcome.

 

I never heard about DB tables using 'indexes' before. How can I check if they do? A link to a resource is again welcome.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.