lighty's life

So the fastcgi code would basically create a tempfile, write stuff into it, send the headers (HTTP, Content-Type, X-LIGHTTPD-send-tempfile) to the usual fastcgi stdout stream, and lighty would do the rest?

It sounds brilliantly crazy!

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

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.

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?

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.

I like it. Simply avoids an extra memcpy?

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

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

Very neat idea! Are you going to implement it?

Very neat idea! Are you going to implement it?

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.

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.

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

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

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/

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.

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

valentin, use mod_magnet in do it there directly.

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

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...

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.

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.

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.

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?

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?