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