lighty's life: Compression of dynamic content

Compression of dynamic content

jan — Thu, 28 Dec 2006 23:49:00 +0000

It looks like a few changes won’t make it into trunk/ before I leave for vacation. But you should know what is in the pipeline and what you want to wait for:

HTTP Response filtering is implemented
HTTP/1.1 chunking becomes a module
compression of dynamic content

This will add compression not only for mod_proxy_core and its backends (FastCGI, SCGI, HTTP, AJP13) but also to internally generated content like the directory listings.

With these changes we will become more and more stream based. Or like JDD called it: The Web is a Pipe

"Compression of dynamic content" by QHY

Fri, 19 Jan 2007 08:08:05 +0000

I have found several bugs of mod_deflate and patch at http://blog.quehy.com/doc/lighttpd-1.5.trunk.mod_deflate.patch , detail at http://blog.quehy.com/archives/184.html

"Compression of dynamic content" by refactored.net

Wed, 10 Jan 2007 13:40:28 +0000

Also, might be useful if there is some indication that you've submitted a comment. Maybe disable submit until the comment is show/timeout?

"Compression of dynamic content" by refactored.net

Wed, 10 Jan 2007 13:39:33 +0000

Could we also set a header from (f)cgi scripts (maybe X-LIGHTTPD-compress-response: on|off or something) to turn it on|off on a response basis? I think this would be useful.

"Compression of dynamic content" by servertweak.com

Tue, 09 Jan 2007 22:33:26 +0000

I've tried the patch of mod_deflate, there are a few problems such as seeing half of the page load now and then. I can see mod_deflate beneficial when there are a X load balancing servers and 1 frontend server proxying all of the requests. the load balancers may be overloaded so by not doing the compression on the load balancers it will lower it's load and increase load in the frontend which will do the compression there. I've seen minimal performance increases or drops in serverload if PHP and mod_deflate run on the same server. Afterall, all of the compression is done via the library.

"Compression of dynamic content" by FreeDude

Mon, 08 Jan 2007 22:27:08 +0000

OK, so with work-block-size set to something small (512 bytes, I assume the manual is incorrect to talk about _kilo_ bytes?) the latency increase should be minimal. But when you have a multi processor server, it just seems to me that the other CPU's are still a better place to do the compression. That is assuming that the OS is smart enough to distribute the load... Does anybody have any real world numbers on this?

"Compression of dynamic content" by Jakabosky

Mon, 08 Jan 2007 20:56:58 +0000

mod_deflate doesn't compress the whole response all at once. There is an option "deflate.work-block-size" to tune how much of the response gets compressed at one time. That allows I/O and compression work to be mixed.

For some websites the backend has to do a lot of work. So moving some of the cpu work to the frontend will help balance the work load.

Also mod_deflate can be turned on/off for any mime type, url or user agent.

"Compression of dynamic content" by FreeDude

Mon, 08 Jan 2007 17:38:27 +0000

Yeah, but while the data is compressed lighttpd will block. When the compression is done in the backend, lighttpd can still accept and process other connections.

"Compression of dynamic content" by QHY

Mon, 08 Jan 2007 03:59:00 +0000

php's gzip compress performance is far lower than mod_deflate. mod_deflate eats 10% CPU at most from my usage experiences

"Compression of dynamic content" by FreeDude

Sat, 06 Jan 2007 10:24:18 +0000

Won't dynamic compression (mod_deflate) hurt lighttpd performance (i.e. block)? I thought that dynamic compression should be handled by the backend (i.e. PHP) and not by the single threaded lighttpd server.

"Compression of dynamic content" by Jakabosky

Sat, 06 Jan 2007 07:22:33 +0000

I have committed to trunk:

new filter chain API
mod_chunked (HTTP/1.1 chunked encoding)
mod_deflate (dynamic compression)

New response filtering modules can be made easily now.

mod_ssi (server side includes) should be converted to a filter, that way any dynamic content can include static headers/footers.

"Compression of dynamic content" by Mike

Fri, 29 Dec 2006 03:05:22 +0000

Hi all, This reply is related to a previous thread called "Faster FastCGI", I was unable to submit it there.

Im sorry, there seems to be a problem leaving comments on firefox =(

Just to say, someone mentioned caching of dynamic pages. My opinion is its prolly not best to do any sort of caching on dynamic text.. Its normally better practise to make faster code than cache sections of it.

However, What i do thing would be a good idea is to determine what is dynamic PHP and static PHP, for example I use PHP files for all my pages, not just dynamic ones. So we could cache anything that does not use a function except echo and print.
Simple =)

e.g.

(a PHP file with no code sections)
<?php $c = 0; $c++; echo $c; ?>
<?php echo "testing..."; ?> can all be cached.
<?php echo rand(); ?> can't.

This gets alittle more complex when you start to think about includes and if statements involving external arguments. but im sure there are solutions for them too.

That is the only case of caching I can think of. I dont know how caching is handled, but i presume that if the cachefile exists it will send it, if the cache file doesnt its tested and cached if pos, so this could easily be implimented.

Anyway, This original thread is about using temp files to send large amounts of data to the core from swarm-fcgi. I believe that the current IPC is via Unix Sockets, which are handled by the kernel and should be the fastest method available. I have a little understanding on the current method used, but what i think would be the fastest would be to

Create a triangle pipe/IPC system, something like

1. Fork() "forwarder"
2. pair TCP/Unix socket with a Pipe[out]
3. Pipe[in] send request to fcgi
4. fcgi send output to "forwarder" on Pipe[out]
5. The "forwarder" thread passes on the information recieved to the TCP/Unix socket.

I had a quick read on mod_fastcgi.c but its a pretty big file. From what i could understand is that this module forks off anyway, and runs the CGI scripts. If so, you could just forward two fd handles to the fork(), 1 for the TCP output, and 1 for the PIPE errors/cmds. This would mean that the "core" would get the page request, forward the fd handle to the cgi module, the cgi module would do its stuff in its own thread, once complete it would send the result down the TCP connection and either close it, itself or hand it back over to the core to close.

Mike

P.s, Give vfork() a go instead of fork(). This should save some memory on each cgi thread as it shares memory and thread's until execve(). It will require removing the code that clears the fd handles etc.

http://www.hmug.org/man/2/vfork.php