Current time: 12-11-2019, 05:24 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Time to first bite toooooo loooongggg
06-20-2010, 03:49 AM
Post: #1
Time to first bite toooooo loooongggg
Hi,

this is my test page http://www.webpagetest.org/result/100619_7XS/1/details/

Why the time to first bite is so long??

I have my site hosted with

Hosting: godaddy linux shared server.
CMS : Joomla 1.5.18

The first BIG question is if that is a server problem or something that can be solved.

If It can be solved by me what I must to do or check first?

In other words if I optimize the red marks ( combine css and JS, Gzip all files, resolve ETags) will decrease the firs bite connection???

Thank in advance those who respond to me.

My site name is : www.investx.net
Find all posts by this user
Quote this message in a reply
06-20-2010, 04:42 AM
Post: #2
RE: Time to first bite toooooo loooongggg
you need to do some server side caching of the generated html. I have not used Joomla for years, but im sure there are plugins for that.

It could also be that you are on a slow server....

Also... another issue could be if you are loading the data for the 2 boxes on the right side from external sites every time.... What id do is cache that locally..

You should also reduce the number of requests... so many requests for a single page load will cause excess server load when you get high traffic....

cdnplanet.com: We help you select the right CDN
Visit this user's website Find all posts by this user
Quote this message in a reply
06-20-2010, 07:49 AM
Post: #3
RE: Time to first bite toooooo loooongggg
Yeah, what he said. None of the recommendations will help your first byte times - you need to enable page caching on your joomla install (not sure if it is natively supported or you need a plugin). That first byte time is the joomla code making dozens of database requests on the back-end to generate the page.

Faster hosting would help but the real solution is to tune joomla in which case it will perform reasonably well even on crappy hosting (not saying that the godaddy hosting is crappy, just that server-side cached pages are trivial to serve).
Visit this user's website Find all posts by this user
Quote this message in a reply
06-20-2010, 10:01 AM
Post: #4
RE: Time to first bite toooooo loooongggg
I'd say it would be an accurate guess that the majority of that time is due to the database. Not sure how much experience you have, but it would be best to log the queries (or if whatever dbms you're using can log the slow queries) used by the app, then try to optimize the tables and fields used within the "where" clause. Usually this means proper indexing (can help performance quite a bit), but you can even go further and change the table types for improved performance. For example in mysql the MyISAM only offers full table locking for any update operations, which if you're writing to the database all the time can cause a major bottleneck, so you can change it to another table type like InnoDB which offers row level locking. Or if you table contents is temporary in nature you may get away with a memory table type...etc.
In my opinion, while caching is most definitely a good thing, it is like putting a band aid over a gaping wound in a case like this.
Find all posts by this user
Quote this message in a reply
06-20-2010, 10:12 AM
Post: #5
RE: Time to first bite toooooo loooongggg
Yep, unfortunately it is a problem with all of the common CMS platforms (drupal, wordpress and joomla are the big players). They have started to pay more attention but it hasn't been a huge focus by the teams themselves with caching being the common work-around (that even the platforms usually implement).

They do tune and log the queries (well, I know the drupal team does) but fundamentally they just make way too many to generate a page.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-24-2010, 06:30 AM
Post: #6
RE: Time to first bite toooooo loooongggg
Hey Patrick,

I understand that database queries can cause longer first byte times on php, cfm, and asp pages.

However, why are there sometimes long first byte times on images? For example, the following image first byte time was 3 seconds in this result:

http://images8.green-watch.org/img/biz_l...s/logo.jpg
http://www.webpagetest.org/result/100623_DZ0/2/details/

While we are looking at that test result, how come there is a huge connection time for:

http://images8.green-watch.org/img/biz_l...ganicb.jpg

images9.green-watch.org and cdn.green-watch.org are on the same original server and using the same cdn service.

It seems like one long initial connection or one long first byte time can really delay that document complete event.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-25-2010, 03:20 AM
Post: #7
RE: Time to first bite toooooo loooongggg
A 3 second delay on a socket connect is usually the result of a dropped (or filtered) packet somewhere in the path (2 seconds for DNS usually indicated a dropped request). Run the test several times and for a couple of different sites to make sure it's not a problem near the test agent but you can see that when there are networking problems (sometimes at the provider).

In the raw page details (CSV) there is a column that keeps track of TCP retransmits during the test. If it is non-zero there was a networking problem somewhere in the path (dropped packets are not unusual - sometimes as high as 1% on the net but sometimes they are because of a real problem).
Visit this user's website Find all posts by this user
Quote this message in a reply
06-25-2010, 04:03 AM
Post: #8
RE: Time to first bite toooooo loooongggg
Hey there,

Do you have any recommendations for minimizing the number of dropped packets?

I suppose server location would come into play. When you look for a server hosting location, do you have a preference to minimize dropped data?

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-25-2010, 04:26 AM
Post: #9
RE: Time to first bite toooooo loooongggg
Honestly you shouldn't see it happen regularly - if you do then it's not really a location problem it is a network problem that generally needs to be fixed (anything from dirty fiber connections to failing routers to too much traffic). It's just part of how the net works. Usually it can go by mostly unnoticed but if it happens during a dns lookup or socket connect the impact can be significant.

That's largely why I recommend always running several tests at a time to make sure you don't accidentally get an "outlier" run. Focus on the page itself and just accept that it happens intermittently (unless it is happening a lot and then ping someone to take a look).

Thanks,

-Pat
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)