First Byte Time F and Cache static content F

Hello there,

I have a website running on a dedicated server ( It is a core i7 with 8gb ddr3 ram hosted by (germany). The DNS part is managed at

Here are the results of the Webpagetest:

The server is running an updated Debian with apache2, mysql, php5, apc (accelerator) and it is running a joomla website.

I tried a lot of things to improve the time it takes to load the website. Installed apc, tried cloudflare, changed settings in apache2 config and database config but it is still pretty slow.

I spend hours now googling but nothing seems to work.

Any ideas?

With that level of server access you should take a look at New Relic. You get a 14-day trial of their pro-level diagnostics when you activate and it should be able to tell you pretty quickly which database queries are slow (which is what I expect the problem is with the first byte time).

You should also take a look at this image which is a 500KB PNG that could be a LOT smaller as a jpeg:

I changed the Client.png.

new test = so still a F.

I installed New Relic (thanks for the tip) and it is running now for 1 day. If I check the database page I see:

And that is not that slow I think (Of course I could be wrong, that’s why I’m posting the screenshots).

The Slow Queries page at Diagnostics it says: “If there are no SQL statements in your time window, then you’ll see this page, even if everything is set up.”.

The Main page is saying:

                    Apdex score ? 	Resp. time 	Throughput 	CPU usage 	Memory

16 instances 0.720.5 857 ms 53 rpm 27 % 1.07 GB

So I personally don’t think it is the database.

Nope, you are right, those times look great - 2ms response times for the database queries is great (assuming there aren’t a few thousand queries going into each response). What does your App Server overview look like? That will give you an overall time and split it across PHP, Database and external services. From the summary it looks like it is averaging 857ms.

If the app server time looks good from New Relic’s perspective then my next bet would be on an apache configuration that is running out of clients (not uncommon when persistent connections are enabled). Could be a combination of items as well.

this is my apache configuration:

But it takes the same time to load when I restart the apache2 daemon.

Sorry, you are looking at the “end user” display which is the full page performance for your users in the field.

Click on the “end user” dropdown and select “overview” from the “app server” group:


You should also be able to upload images directly here if you want.

Whoops, sorry. this should be the correct page.

Very cool, looks like there is room for optimization across a bunch of different areas with the raw PHP itself taking up a fair bit of time.

If you click on the graph you will be able to drill into the individual components and see where the time is going. Clicking on php for example should take you to a list of entry points arranged by the order in overall server time. If you then click on one of those you will get a multi-tab chart on the right where you can then click on “performance breakdown” to see for a specific page what the breakdown looks like.

I can hop on a Google+ hangout and show you what it looks like on the WebPagetest dashboard if that would help.

Sorry for the late reaction:

I Installed php5-memcache and a few other optimization tools. I installed jotcache (component for joomla that caches everything) and i transferred from registrar.

New results are:

The First Byte time is now A so that is a good thing. Also the Load time is lower now so that is a good thing.I think this helped a lot: (I will remove the php file later) but it looks like it is all working. Want to test this for a least a day to see if the load time stays stable.

Very cool. Yeah, the size of the APC cache probably made a big difference. I think the default is around 32MB and it looks like you blew right through that. Do you know if jotcache will let you cache directly to APC (if it isn’t already)?

I’d keep an eye on that fragmentation to see if it becomes a problem. Here is WPT’s APC info for comparison: (really different use cases though).

Sorry for the late reaction. Was away for a few days.

What I noticed is that when i’m not logged in the site is a lot faster. When I login it takes a lot more time before it starts rendering the site.

The Cache and Session are all in APC so that should be fast enough. Maybe you have an idea what it could be?

One thing that is loaded when you are logged in is the Envolve chat. I disabled that but it did not helped. There are as far as I know no other modules/plugins/components that are loaded extra when you are logged in.

Most caching modules will bypass the cache for logged-in users (the html page cache anyway).

I changed the webserver from apache2 to nginx and enabled system cache. Site is at least for me really fast now (also doesn’t matter anymore if you are logged in or not).

Very nice. With the back-end under control are you starting to look at the front-end now?