public service message- caching with zlib handler and SMF

[drewactual]

it sure seems counter intuitive to me that the httpd.cong file asks you what output, what handler, how many byte chunks, and what level of compression to use (1-6) making a person believe this happens to work... 'cause it's the precise opposite. 

after many a go 'round with caching considerations and SMF as the primary purpose of my page, and on a dedicated server running apache2.4, mpm_worker/FPM and FastCGI with php.7.1 w/mod_memcached and while also operating OPCache, i finally realized SMF (even with caching off) was still crunching output...... which played less than nicely with the server and caused some goofy collisions that may or may not be readily apparent (things such as js below the fold being ignore, and some inherit functions such as quoting/ajax being broken)....

so- to cut this short into a BLUF (bottom line up front) :

set the before mentioned httpd.conf selections 0 (zero) or Off.  you can chunk- that isn't a problem and is encouraged, 4096bytes seems to work in my instance.. and you can set the compression level to whatever you want (I rec -1 which allows the server to decide case-by-case), but insofar as handler and output? OFF, yo, and if your server reacts like mine the clouds are gone!!!! SMF is now set to compression level 3 and she flies...

make sure you've got your cache expires set up in either your virtualhost or your htaccess- set them reasonable to your needs.   at last look, there are only like six items on my page that aren't pulled out of a users private cache on load, making the site pretty fast for returning visitors (the one's i really care about), but also new visitors get the fully loaded page in around 2.5seconds using chrome (.5~1 second DOM loads).  not a bad gig, huh?

I wish somebody would have explained this to me long ago.... and to be honest, maybe they tried but i didn't have a clue what they were talking about.   

[GigaWatt]

Found this out the hard way. SMF doesn't seem to play well when output compression is enabled on your server (hosting account, whatever). Configured SMF to handle the compression and turned off compression server side, bam, no problems .

I don't use the caching option in SMF, so I can't confirm if it also causes problems when caching is on/off.

[drewactual]

SMF compresses all on it's own- no need for server directives to do it... when server does it's basically compressing the already compressed data again, and bound to cause weird things to happen.

the thing i guess that was so hard for me to wrap my brain around, is I was thinking SMF needed the mod available and running on the server for even it to use it... but... nope.  it has to be there yes, but SMF activates it itself- no need to have it capture 'in between' SMF and the server via php or apache_mod to do it again, as in twice, and causing issues.

here, though, is the underlying issue: getting SMF to STOP compressing is virtually impossible w/o digging in deep into source.  setting deflate directives in your htaccess and it's going to compress because SMF turned it on... the only way to KEEP it from compressing is to turn all compression off and have zero deflate directives, and i bet even then some are going to be compressed... so... why fight it?  I have all the apache mods and php apps needed to compress whatever and however, but NONE of them, on their own, do as well as the embedded compression and using the deflate directives in either httpd.config, php.ini, htaccess, or at a directory specific level, the .user.ini, to enhance them. 

[Arantor]

So when did the option to turn it off stop working? Also please be sure you're not confusing the output buffering gzhandler with the other output buffering SMF does.

[drewactual]

that's exactly what I'm doing, Arantor, is lubbing the gzhandler in with zlib (which can be chosen between in httpd) and throwing it in the conversation with SMF's crunching...

[Arantor]

You know there's literally an option in the admin panel to turn off gzhandler, right? Then the other output buffer must be left alone (but on its own it does not gzip anything)

[drewactual]

i am aware... i'm also aware that the server can handle output compression without regard to what SMF is outputting... what i'm suggesting is that using SMF to manage it is a lot easier than setting up your server to do so- not only in simplicity but also for performance.  the point of my OP, which i have a hard time articulating obviously, is that zlib or gzhandler ought NOT be configured on the server level httpd in order for SMF to output efficiently.  it just has to 'be there', staged and ready for SMF's use, but not configured- SMF will handle that.

[Arantor]

Your message came across as though you hadn't found that setting and that you were running into issues with it as a result.

I firmly believe that an application should where possible not try to influence its environment, let the webserfer layer take care of the compression rather than SMF. Other PHP apps don't try to use this, precisely because they hand it off to the underlying system to deal with as they should.

[drewactual]

when i totally turned off SMF compression, and relied in whole on the server to do so- some functions ceased.  AJAX functions failed and possibly due to js being ignored or rendered useless due to compression (or twice compressed?) ... SMF handing it and there were no such issues.  < This is what i can tell you with certainty.  is it because of a mod or because of SMF still compressing with that switch off is a great big unknown.. i would guess it to be a mod, but it was absolutely still happening.