gZip compression

#1
Does anyone have gZip compression working? According to the default settings it looks like it should just work for text/html files. All the settings are set to yes at server level and also VH level. When I tried looking at the response headers for a html file it is not gzipped. Is there anything I may be missing?
 
#2
Okay, I got it to work by adding "zlib.output_compression = On" to my php.ini
There was no default php.ini so I guess it's missing a lot of other stuff too.

However, I only managed to get it to work for text/html. I tried text/css (and text/*) and application/x-javascript, but they didn't work for css and js respectively. Any ideas?
 

Slavik

Administrator
#3
Theres no default php.ini used, but you can find them in

Code:
/usr/local/lsws/phpbuild/*phpversion*/
folder to copy over to
Code:
/usr/local/lsws/lsphp5/lib/php.ini
 
#4
Yea, I need to do that, I just started a blank php.ini there. Still not sure why gzip is not working for css and js files though.
 

lsmichael

Active Member
#5
Howdy. Really, really sorry I haven't been paying attention to this forum. I'm a basshole.

Y'all are right about moving the php.ini files. I'm really confused, though, as to why your php.ini is affecting your compression of static files. Maybe I'm missing something (I often am)...

I thought about this for a while and the only thing I can think of is this: When you set something up to be compressed, the first time you serve it it won't be compressed. It gets compressed while it is getting served the first time. This means that it is only compressed from the second time you serve it. Is it possible that you tested html once, it wasn't compressed, then you tested it again (after changing php.ini) and it was. Then you tested the text/css and text/* settings each once?

That's what I have for now... If you can tell me the exact settings, maybe the error is there...
 
#6
No problem... :)

I actually tend to over test things rather than under test, so I did try viewing the headers many times before changing php.ini.

While the html files are being compressed now, I still wasn't able to get css or js to work. The last settings I tried were:
Code:
Enable Compression    Yes
Enable Dynamic Compression    Yes
Compression Level (Dynamic Content)    6
Compressible Types    text/html, text/css, application/x-javascript
Auto Update Static File    Yes
Static GZIP Cache Directory    Not Set
Compression Level (Static File)    6
Max Static File Size (bytes)    1M
Min Static File Size (bytes)    300
 

lsmichael

Active Member
#7
Oh well. I thought I was so smart.

We've been having trouble reproducing this. (It shows up on one machine, but not on another...) Can you tell us more about the environment? What system are you using? What kind of site are using this with? (I assume it's dynamic content, since editing php.ini changes things.) It's OpenLiteSpeed 1.0.2, right?

m
 
#9
I'm on Centos 6.4 final (minimal 64-bit), and yea it's dynamic content, a php/mysql site. Although for standard css and js files should it matter (mine are not generated by php or anything)? When I first made this thread, it was 1.0.1, but I've upgraded to 1.0.2 last week and it was the same.
 
#10
So googling around I found this:

The disadvantage of enabling GZIP compression via PHP is that only web pages generated by PHP scripts will be compressed by GZIP encoding. All external CSS or JavaScript files will not be compressed. For the ability to enable GZIP compression on all file types, uses mod_deflate or mod_gzip on HTTPD web server instead.
Maybe that is the reason I wasn't able to get my css and js gzipped. Meaning that I shouldn't be setting this flag through php.ini and gzipping should just work with litespeed, but it's not... I guess that is what I need to figure out now, why the gzip isn't working by default, but I think I will have to skip this for now as I already wasted too much time on it...
 

lsmichael

Active Member
#11
Yo! Real sorry to fade away on this one. I went to HostingCon in Austin and, well, everything fell by the wayside. (Speaking of which, I highly recommend both HostingCon and Austin. Or at least Austin, if you're not in the hosting business. I went to school there and that was great — and, by "great", I mean blastaculously awesome with five beers on the side — but Austin has gotten way cooler since I left.)

It turns out that this gzip problem was a bug. (I have no idea why my coworkers had trouble reproducing it at first...) After some prodding, they fixed it. We're releasing 1.0.4 in a moment...
 
Top