lighty's life: Faster FastCGI

Faster FastCGI

jan — Wed, 29 Nov 2006 13:02:00 +0000

While I was throwing away from bogus data-copy operations from the mod-proxy-core code I stumbled over a simple question:

Why do we copy the HTTP response data from the backends at all ?

We are just forwarding them in most cases without touching them.

How about:

HTTP/1.1 200 OK
Content-Type: text/html
X-LIGHTTPD-send-tempfile: /dev/shm/fcgi-output/j37f467d

... and lighty removing the file when it has sent it.

/dev/shm is memory and the application is writing to it and only passes a reference to the webserver where it can take the content from.

Especially for large content which is generated on the fly this might help alot.

Crazy or Cool

Now it takes someone to implement and benchmark it. Adding it as easy: just add the header filter to mod_fastcgi and set is_temp on the file-chunk.

"Faster FastCGI" by Matt

Fri, 22 Dec 2006 13:10:37 +0000

Would it be neat to see a way to serve content directly from a memcached, using a header like "X-LIGHTTPD-send-file: memcache:10.0.0.1:11111:thekey" ? Haven't really figured out where it could/would make a big difference, but maybe? Difficult to implement? Shouldn't be, right?

"Faster FastCGI" by Matt

Fri, 22 Dec 2006 13:09:20 +0000

"Faster FastCGI" by Jan Kneschke

Fri, 22 Dec 2006 07:00:37 +0000

Valentin, back in the mod_cml days it was handled like this: If the cached files are you of date, ask the backend to generated the content and update the files and only let mod-magnet handle the cache-hit case. Usually you can move the logic about freshness of the cache into mod-magnet and use timestamps, hashes in memcache, ... as source for deciding about the request and cache-hit/-miss.

"Faster FastCGI" by Jan Kneschke

Fri, 22 Dec 2006 06:57:54 +0000

Romuald, the connection the FastCGI is persistent in 1.5.0. See http://blog.lighttpd.net/articles/2006/10/08/reducing-requests-setup-costs for some numbers.

"Faster FastCGI" by Valentin

Thu, 21 Dec 2006 17:27:44 +0000

I mean rather X-LIGHTTPD-send-file Header for multiple puzzle pieces. FastCGI is synchron, but Lighttp - asynchron. In addition are the pieces often reusable.

"Faster FastCGI" by Romuald

Thu, 21 Dec 2006 17:15:48 +0000

Wouldn't be even faster if persistent FastCGI and multiplexing were implemented ? Cause with current implementation, you would open/close a fast CGI connection for as few as a X-LIGHTTPD-send-tempfile header...

"Faster FastCGI" by Valentin

Thu, 21 Dec 2006 16:23:31 +0000

I want to return file-set AFTER the cache update, but its impossible with mod_magnet

"Faster FastCGI" by Jan Kneschke

Fri, 15 Dec 2006 22:25:54 +0000

valentin, use mod_magnet in do it there directly.

"Faster FastCGI" by Valentin

Fri, 15 Dec 2006 16:08:35 +0000

Ich wünsche mir, man kann mehrere Dateien zurücksenden: HTTP/1.1 200 OK Content-Type: text/html X-LIGHTTPD-send-tempfile: /dev/shm/fcgi-output/header,body,footer

"Faster FastCGI" by Jakabosky

Thu, 07 Dec 2006 04:37:15 +0000

I did some more testing a noticed that lighttpd 1.4.0 was using
more cpu then lighttpd 1.5.0 during the test.

I am going to rerun the apache bench from another computer,
so lighttpd and php will have the whole cpu.

"Faster FastCGI" by Jakabosky

Thu, 07 Dec 2006 03:33:34 +0000

This feature will only be faster when the response content is atleast
16Kbytes. Each 16Kbytes of content will need atleast one
read() by lighttpd from the fastcgi connection. When the response
content is returned in the tempfile, lighttpd only needs to do
one read() for the response headers.

Here is a test with a php script that generate 512k of content

lighttpd 1.4.11
ab -n4000 http://localhost:1080/send-tempfile.php?use_temp=0
lighttpd 1.4.11
Concurrency Level: 1
Time taken for tests: 18.691657 seconds
Complete requests: 4000
HTML transferred: 2097152000 bytes
Requests per second: 214.00 [#/sec] (mean)
Time per request: 4.673 [ms] (mean)
Time per request: 4.673 [ms] (mean, across all concurrent requests)
Transfer rate: 109593.93 [Kbytes/sec] received

lighttpd 1.5.0(patched)
ab -n4000 http://localhost:1080/send-tempfile.php?use_temp=1
Concurrency Level: 1
Time taken for tests: 17.239221 seconds
Complete requests: 4000
HTML transferred: 2097152000 bytes
Requests per second: 232.03 [#/sec] (mean)
Time per request: 4.310 [ms] (mean)
Time per request: 4.310 [ms] (mean, across all concurrent requests)
Transfer rate: 118831.00 [Kbytes/sec] received

1.5.0 with send-tempfile is only 18 requests per second faster
So the difference is still not that greate.
See ticket #922 for patch and send-tempfile.php

I would only use the send-tempfile feature for large responses.
If you have a server with alot of ram and it needs to send large
responses to many clients then this feature might help.
just make sure you allocate enought space to /dev/shm/

"Faster FastCGI" by boom@bamex.ru

Sun, 03 Dec 2006 15:57:17 +0000

I tested lighttpd 1.4.11 vs lighttpd 1.5.0-svn (faster fast_cgi on) with php 5.2.0
1.4.11 slower that 1.5.0

# ab2 -n100 http://test.com

1.4.11
Requests per second: 4.34 [#/sec] (mean)
Time per request: 230.197 [ms] (mean)
Time per request: 230.197 [ms] (mean, across all concurrent requests)
Transfer rate: 87.45 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 209 229 74.9 219 960
Waiting: 200 218 74.1 204 939
Total: 209 229 75.0 219 961

1.5.0
Requests per second: 4.55 [#/sec] (mean)
Time per request: 219.888 [ms] (mean)
Time per request: 219.888 [ms] (mean, across all concurrent requests)
Transfer rate: 91.55 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 206 219 16.5 212 297
Waiting: 194 207 15.2 201 278
Total: 206 219 16.5 212 297

but in some cases 1.4.11 faster that 1.5.0 on large php scripts

"Faster FastCGI" by Marty

Sat, 02 Dec 2006 14:05:17 +0000

Isn't it better (faster?) to let PHP do the compression anyway?

"Faster FastCGI" by Jakabosky

Sat, 02 Dec 2006 07:24:42 +0000

I have implemented this feature for lighttpd-1.5.0
Find the patch attached to ticket #922
There is also an example php script.

This feature can be made to work with mod_deflate.
Currently mod_deflate has not been ported to 1.5.0.

"Faster FastCGI" by Russ

Fri, 01 Dec 2006 13:03:50 +0000

I just had a thought - this would presumably not work with the compression mod, as the output would go straight to the socket, where usually it would go fast-cgi - lighty - compress - user? You could get around this by having PHP (etc) doing the compression. Or have I missed something.

"Faster FastCGI" by Russ

Thu, 30 Nov 2006 16:59:29 +0000

Very neat idea! Are you going to implement it?

"Faster FastCGI" by Russ

Thu, 30 Nov 2006 16:58:45 +0000

Very neat idea! Are you going to implement it?

"Faster FastCGI" by Ben Harper

Thu, 30 Nov 2006 15:15:57 +0000

Rr- You would still avoid a memcpy on the backend machines, as spawnfcgi pumps data back to the server.

"Faster FastCGI" by Rr

Thu, 30 Nov 2006 12:17:29 +0000

And how would it work in more than one fastcgi backend environment (remote boxes)?

"Faster FastCGI" by Ben Harper

Thu, 30 Nov 2006 06:30:08 +0000

I like it. Simply avoids an extra memcpy?

"Faster FastCGI" by Jakabosky

Thu, 30 Nov 2006 02:15:08 +0000

The FastCGI app may not be able to cache the full content.
Parts of the content may still need to be generated dynamically.
I have worked on a website that pulls cached data from
different data sources. Caching the full page wouldn't work
since each data source has different refresh intervals and
might be used on multiple pages.

"Faster FastCGI" by Scott Yang

Thu, 30 Nov 2006 00:29:59 +0000

And what's the difference with the current X-LIGHTTPD-sendfile implementation beside the sent filename reference will be removed at the end of the request? I thought for sending large content, it would be wiser to let FastCGI apps to intelligently cache the generated result, instead of having delete/re-generate/delete/re-generate cycle even if the intermediate content is stored in fast shared memory?

"Faster FastCGI" by Jakabosky

Wed, 29 Nov 2006 23:21:55 +0000

I like this idea. It can be used with
mod_cgi/mod_fastcgi/mod_proxy/mod_proxy_core

Elliptical: who said it has to be HTTP/1.1 compatible, as long as the
header is unique and lighttpd removes it from the response to
the client it will not cause any compatiblity problems.

"Faster FastCGI" by Elliptical Workouts

Wed, 29 Nov 2006 20:52:01 +0000

I'm afraid it's a crazy idea to make it. It's not HTTP/1.1 compartible.

"Faster FastCGI" by Fernando Silva

Wed, 29 Nov 2006 20:40:38 +0000

It sounds brilliantly crazy!