WebPagetest Forums
Webshop: TTFB and Compression issues - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: Web Performance (/forumdisplay.php?fid=3)
+--- Forum: Discuss Test Results (/forumdisplay.php?fid=4)
+--- Thread: Webshop: TTFB and Compression issues (/showthread.php?tid=13938)



Webshop: TTFB and Compression issues - koenig - 09-21-2015 06:30 PM

Hello, i'm looking for an issue slowing down my site speed.
Im spending around 300€ for my managed server host and optimized a lot on the content side, but still get bad results.


Results: http://www.webpagetest.org/result/150921_DS_BKD/1/details/

Im looking for two particular issues:

1. Time to first byte: F, 1169ms incl. download
This time is unacceptable high. >500ms would be the target.
If i run the test targeting a "Hello World" php-script, im getting a TTFB of 247 ms (including a redirect), which gives me a solid B.
So, is this only the heavy shopsoftware producing that latency, or is there anything else that could be done? No idea how to fix.

2. Compress Transfer: D, 75/100
I've got an issue with the gzip/deflate compression, which i enable via .htaccess.

I'm redirecting all requests to domain.tld to http://www.domain.tld to avoid dublicate content and domain unity.

So i can see in the headers that the webserver compresses the first awnser for the redirect, but the html of http://www.domain.tld is always chunked and not compressed. Everything else works: The server is compressing .js or .css just as intended, but there are a few documents/files where compression always fails.
I do not understand why the server is doing this. How do i look deeper into that issue?

If you see any other issues that could speed up my site, let me know Smile


RE: Webshop: TTFB and Compression issues - AlephBeth - 09-22-2015 01:00 AM

Hi koenig,

> So, is this only the heavy shopsoftware producing that latency

Yes, this is most likely due to slow PHP code or unoptimised database calls. Consider getting a PHP developer who is familiar with the PHP framework that is being used, or add a caching plugin to your framework if possible, or consider getting your web host to set something like Varnish up to do entire web page caching.

I'm not familiar with Apache's compression directives - could you post a copy of the .htaccess file in your document root and we can see if we can find anything?


RE: Webshop: TTFB and Compression issues - dfavor - 09-25-2015 08:39 AM

Focus on tuning PHP (install Opcache vi pecl/pear) + MariaDB/MySQL.

If your hello world php script executes fast, then PHP + Database are likely the culprit.

Best guess is Database.

Use mysqltuner or MySQL Tuning Primer Script (which seems to give more accurate data).

Also, consider converting your png images to jpg + compressing + progressifying all jpgs.

TTFB though is likely due to your Database.


RE: Webshop: TTFB and Compression issues - GreenGecko - 09-29-2015 05:08 AM

dfavor has hit it on the head... you may be paying for a managed server platform, but that doesn't guarantee they know how to tune it!

In addition to the tuning of database resource and installing an opcode cacher, look at ensuring PHP is run in FPM mode ( then APC is the best opcode cacher... still good for PHP 5.4 ), and enable compression to keep the content volume down.

Finally, there are good built-in caching plugins for WordPress, which can help a lot too: preprocessing the output to reduce stress on the server. They won't necessarily lower the TTFB, but will help in delivering the web page in the most timely manner.

( I always +1 for nginx over apache, but there are minimal gains to be had if the above are addressed ).


RE: Webshop: TTFB and Compression issues - dfavor - 10-01-2015 12:28 AM

+1 to most of what GreenGecko said.

Tuning determines site speed. As I do this every day for clients, I see clients with expensive hosting with slow site speed. Highest has been $2000/month.

Moving to $100/month hosting, stripping out all CDNs + proxies (NGINX/Varnish) + tuning machine, provides support for 100,000+ uniques/hour at 5% - 10% machine load.

LAMP (Linux + Apache + MariaDB + PHP) is very fast, if the entire LAMP stack is tuned well.

As for NGINX, there was a significant performance difference comparing NGINX to Apache-2.2.x + all the testing I've done shows Apache-2.4.10+ is roughly 20% faster than NGINX.

Also Apache-2.6 will ship with mod_h2 (native HTTP/2 support).

Couple this with PHP-7 (benchmarks show it's faster than HHVM) + you have the makings of a blazing fast site.

If + only if, you LAMP stack is tuned.

"Managed Servers" (especially RackSpace) are usually a waste of money, as these machines are never tuned + so far I've found HostGator tech support far superior (expertise wise) than RackSpace.

Better to find a sharp admin person + pay them to tune your server machine or run your site in an LXC container running on a tuned machine, which is what I do now.

Better a sharp admin then wasted dollars on "Managed Servers".


RE: Webshop: TTFB and Compression issues - GreenGecko - 10-07-2015 03:03 PM

Personally, I use Percona MySQL, but seeing as Mariadb use their replacement InnoDB engine that will make no difference.

The reason that i use nginx is pretty simple... (massive oversimpleifcation alert!) it just acts as a switch, and either delivers a file or hands over to php-fpm, which is waiting for something to do. This makes monitoring and finding bottlenecks much simpler, as you're basically looking at either the database or php: db needs memory, and php needs raw cpu power. nginx itself requires little in the way of feeding, and tweaking is relatively painless. It also provides no mechanism akin to .htaccess, which does keep the configuration sensible.

The problem with using late versions of PHP ( and before you whinge at me my own site is running drupal 6 on HHVM via nginx 1.9.5/HTTP 2/pagespeed - I eat my own dogfood! ) is that I can't in all honesty set that up for a customer unless whichever CMS I'm using supports it. That's in the realms of negligence!

+1 for the rackspace comment. I have a list of incompetents I'll never recommend.


RE: Webshop: TTFB and Compression issues - koenig - 10-07-2015 06:45 PM

Hey, thank you so far for all your helpful comments.

I've done a lot of phone calls the last few weeks - The website devs told me, its a hoster-problem, the hosting-team told me its a web dev problem ...

Now, im totally done with both of them.

Turned out that rendering one websiteview took like 15% of the managed servers quad core (!!!). Webdevs say they will update that issue "soon™".
The hoster cant install anything on my server, no varnish, no apc, its against their "server management practices".
But they recommended upgrading my package to a better CPU (8-core) for 500€/month.

Code:
$ time php5.4 -f index.php > /dev/null
real    0m0.679s
user    0m0.548s
sys     0m0.080s

Turned also out, that a lot of the managed servers backend options (like switching php-engine between CGI mode or apache_mod) are just fake. They give you php in CGI and a useless interface, thats it - i was shocked.

I strapped away all CDNs, disabled plugins, optimized the template code myself as good as i could, was able to activate compression for all website assets now, changed hostnames for IP-Adresses (127.0.0.1 instead of localhost), ect..

This is what ive done all by myself...im really proud of it.
http://www.webpagetest.org/result/151007_MB_FBR/1/details/
Saved 1 sec in "Start Render" and 2,5 Secs in total load.

The hosting-team tested the server with a phpinfo()-file, which had a TTFB of 270ms. They say thats "good". Really? Is that true?

I want the get rid of these hosting-guys asap.

Can anybody recommend a good europe-based root server hoster with 1 GBit Link, nice and friendly customer support for a good price?

Thank you so far,
koenig.


RE: Webshop: TTFB and Compression issues - GreenGecko - 10-09-2015 11:59 AM

270ms is good for CGI based PHP... extremely good if you're using mod SuPHP! However, I use php-fpm and that's not so good, especially if you're testing at LAN speeds and latency which I expect that they are!

I wouldn't have changed hostnames for IP addresses... or is this in config files ( if it's for DB access for example, using a named socket removes all necessity to build up and tear down a TCP stack at all! )???

I've no experience with JTLshop, but as it's a MySQL / PHP based product, I expect most of my Magento experience will count. I have servers running on linode in London, and Amazon in Dublin. I can set them up ready for you, but I do my own support. I have one customer who uses linode tech support but doesn't rate it. In either case, you shouldn't be paying anything near 500 euro!