First Byte Time + GZIP Compression + Speed

[db2012]

http://www.webpagetest.org/result/120618_7Z_BCX/

I have a couple of questions regarding Litespeed for an online store application (Magento). The server is running the latest Litespeed version through a WHM configuration coupled with varnish as a cache solution (unfortunately Litespeed VPS license does not include cache). Overall, the page speed speed is equivalent to that of Apache and the first byte time is extremely long. Before Varnish was added, the first byte time was about twice as long. Also, Litespeed GZIP compression is installed, but it's not working. It's on, enabled, and the headers will read as the site is being compressed - but no compression is actually occurring. Lastly, the overall speed of the site isn't really different than the Apache configuration we had. Please let me know if something went wrong during the application of Litespeed or if there are any settings to configure.

Edit: also if you test gzip here, http://www.whatsmyip.org/http-compression-test/compression_test.php, it says 0 percent compression.


More information: One of the javascript sends headers which indicate GZIP encoding but the other one indicates that is not encoded. The MIME types are the same.

 

[webizen]

you need to run 'top -c' on server to see what process occupies the most cpu cycle. For magento, it usually should be php and/or db. you need opcode cache to offload php and improve first byte time. varnish is for content/static cache, which will not help much here.

for gzip compression, pls provide specific example showing the problem.

 

[db2012]

you need to run 'top -c' on server to see what process occupies the most cpu cycle. For magento, it usually should be php and/or db. you need opcode cache to offload php and improve first byte time. varnish is for content/static cache, which will not help much here.

for gzip compression, pls provide specific example showing the problem.

I'm currently running memcached to offload op-cache. Also, for a concrete example refer to www.discobath.com . There, you can see that one javascript is being compressed, while the other is left uncompressed.

 

[db2012]

Update:

For some reason, the GZIP now works, but there are 10 instances of lswsphp5 index.php running and taking up ridiculous CPU usage