Apache/PHP compression not working

Question

1.00/5 (1 vote)

See more:

Hi
Apologies, I'm figuring this out as I go along, so I might state the obvious, or not state something that I should. This probably isn't even the right place to ask, but I suspect there are other devs here who've had to figure this out in their spare time.

We've deployed an application to a hosted linux server running CentOS v7.9.2009 standard kvm, I have full access to this via whm, cpanel, putty, and ftp.

The application's front end is coded in php, the back end in java, both accessing a set of mysql databases. I'm java, I don't know php at all.

I'm trying to enable Apache deflate. I'm using the following as a guide:

https://copyprogramming.com/howto/compressing-content-with-php-ob-start-vs-apache-deflate-gzip

This is actually critical, we're trying to target Zimbabwe, and have only now figured out how slow, expensive, and nasty their internet actually is.

What I have tried:

If I go into WHM and look at EasyApache, I can see that we're using Apache 2.4, and the mod_deflate package is enabled.

I launch filezilla and navigate to .htaccess. I pull it to my machine, edit it to include all of the AddOutputFilterByType DEFLATE lines, the important one being text/html. I upload it back.

I initially tested using the pingdom site linked to on that guide, but later I just used wget from a powershell, and looked for a line saying Content-Encoding:gzip.

I also logged into the system using chrome, and looked at the developer tools view. I then started wireshark, then navigated to a particularly heavy form. I stopped wireshark, and looked at the stats. I also ftped into the server and looked at the html file that the php had generated. The generated file was 5.56Mb in size, but if I compressed it using 7Zip it reduced to 116kb, or 200kb with winzip. The wireshark traffic looked to be 6474 packets of 1514 bytes each over 5 seconds sent from the server, while my machine replied with 6460 packets of 54 bytes each. This totals around 9.3Mb down and 340kb returned. So not compressed.

It occurs to me that the html generated by php may not sit in the file structure under the .htaccess file, so is excluded from it's scope? Is that a thing? Can you move where php generates html?

Posted 24-Jan-24 4:10am

ThePotty1

Updated 25-Jan-24 20:38pm

v4

Add a Solution

2 solutions

Solution 1

Looking at your link given, you are going about this the wrong way, PHP is supposed to be your backend and javascript/jquery you front end looking at your post... You are adding multiple loads to your requests on you server which responds in slow times. Either use PHP fully for your server requests and Javascript to "css" your pages. To use Javascript/css in PHP is going to slow down enormously because you have requests running back and forth between user and server, total loss of time and resources.

The above is based on assumption, if you show some sample code, we might make sense of what you are trying to describe.

Posted 24-Jan-24 8:24am

Andre Oosthuizen

Comments

ThePotty1 25-Jan-24 1:09am

Hey neighbour :D
I agree that there are probably several poor architectural choices, which we will address, but right now I'd like a quick fix to reduce the size of the traffic required to run this monster which I had no part of building. My code performs like nothing they've ever seen, but they aren't even looking at it because the php is too bloated to run.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

ThePotty1 · Accepted Answer · 2024-01-25T20:37:00

Morning. I'm going to post my findings as a solution, because I feel it helps to keep the initial symptoms I experienced separate from my final analysis.

So. Navigate to your web page using your browser, and turn developer tools on. Click the network tab, select your main page, and scroll down to Response headers. Find the Server item. Mine says nginx. Yours might say apache or iis. The thing is though, I'm definitely using apache. It's a LAMP stack.

We bought a basic lamp from an isp, and didn't really tweak it in any way. The isp themselves set it up in the following way. When the server receives a web request, it is handled by nginx. nginx is better at handling malicious attacks than apache, so it filters the incoming requests. Any valid requests are then passed to apache, in my case php then generates some html and apache passes this html back to nginx. nginx then serves it to the client browser. All good, and I think it's just apache.

The following is conjecture. I set up apache compression, and I assume I did it correctly. The compressed html was sent to nginx, which presumably uncompressed it. Then, because I had no compression set in nginx, the uncompressed html was then served to the client browser. So I added extra overhead with no benefit whatsoever.

Eventually I noticed that my webserver logging was occurring under /var/log/nginx rather than /var/log/apache2. I set up nginx compression as follows:

Create a text file called /etc/nginx/conf.d/compress.conf (any file named *.conf is ok).
My file contained the following, but I really don't know if these are the optimum settings:

##
# `gzip` Settings
#
#
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types
  application/atom+xml
  application/geo+json
  application/javascript
  application/x-javascript
  application/json
  application/ld+json
  application/manifest+json
  application/rdf+xml
  application/rss+xml
  application/xhtml+xml
  application/xml
  font/eot
  font/otf
  font/ttf
  image/svg+xml
  text/css
  text/javascript
  text/plain
  text/xml;

Using the same test as before, the server now sent 432 packets of 1514 bytes each over 2.5 seconds, while my machine replied to each with a packet of 54 bytes. This totals around 639kb down and 23kb returned. Not as fast as I'd hoped, but I think my clients might see a more significant improvement.