Caching

Caching

[@ 2013-04-18 20:03 UTC (permalink / raw)]

Hi all,

serving huge files through cgit does not really play well with lighttpd
-- lighty's RAM consumption skyrockets, because it seems to have to load
the file into memory and is not freeing it thereafter, especially with
multiple concurrent requests.

Fortunately a couple of servers implement the X-Sendfile extension (or
synonyms thereof) that allow to pass a path to the webserver which then
serves it directly like every other static file.

Lighty even implements an X-Sendfile2 extension that enables us to pass
a _range_ of a file to serve, which is ideal to serve cgit cache files
directly. So quite some time ago I wrote a patch for cgit that uses
X-Sendfile2. As the patch was clumsy and hard to understand, I tried to
rewrite it, but then noticed that I was doing a wrong thing all along:
If I understood the caching code correctly (which I most likely haven't)
this might fail, as the cache file to serve might be replaced by some
new content (read: might even be some complete other page) inbetween
sending the path to the server and the server sending the file.

So my questions are:

a) Is it possible to use X-Sendfile2 with the current cache implementation?
b) If not: Is it worthwhile to figure out a new scheme to do so, i.e.
where it can be guaranteed that a cache file is not altered between
sending the response and the server serving it?
c) If yes: Should one remove the cache-key from the file, s.t. one can
use "normal" X-Sendfile to serve the file as-is?

My current view is pessimistic, because from my understanding the
answers are:

a) no, there is no lock on simple serving
b) no, because if there were a lock, there would be no possibility to
remove it, as a CGI application does not get feedback from the server (a
'request-handled' message)

I'd be very glad if anyone could tell me I'm wrong :)

Regards,
Ren?

Caching

[@ 2013-04-18 20:24 UTC (permalink / raw)]

Am 18.04.2013 22:03, schrieb Ren? Neumann:
> Hi all,
> 
> serving huge files through cgit does not really play well with lighttpd
> -- lighty's RAM consumption skyrockets, because it seems to have to load
> the file into memory and is not freeing it thereafter, especially with
> multiple concurrent requests.

Or perhaps I should switch webservers ... just noted that this is known
and simply stated as "your fault, don't serve huge files via (Fast)CGI" :-/

- Ren?

Caching

[dpmcgee]

On Apr 18, 2013, at 3:24 PM, Ren? Neumann <lists at necoro.eu> wrote:

> Am 18.04.2013 22:03, schrieb Ren? Neumann:
>> Hi all,
>> 
>> serving huge files through cgit does not really play well with lighttpd
>> -- lighty's RAM consumption skyrockets, because it seems to have to load
>> the file into memory and is not freeing it thereafter, especially with
>> multiple concurrent requests.
> 
> Or perhaps I should switch webservers ... just noted that this is known
> and simply stated as "your fault, don't serve huge files via (Fast)CGI" :-/
> 
I switched to Nginx on my web server for this exact reason and haven't looked back.

Caching

[Jason]

On Thu, Apr 18, 2013 at 10:03 PM, Ren? Neumann <lists at necoro.eu> wrote:
>
> Fortunately a couple of servers implement the X-Sendfile extension (or
> synonyms thereof) that allow to pass a path to the webserver which then
> serves it directly like every other static file.


I would be potentially interested in implementing this as we move
closer to having FastCGI/SCGI support (which is a bit of a ways away
due to memory management strategies). Personally, I'm more interested
in nginx's X-Accel-Redirect than X-Sendfile, but supporting either
isn't too difficult. Remind me of this in a few months.

Caching

[@ 2013-04-26 14:39 UTC (permalink / raw)]

Am 26.04.2013 15:47, schrieb Jason A. Donenfeld:
> On Thu, Apr 18, 2013 at 10:03 PM, Ren? Neumann <lists at necoro.eu> wrote:
>>
>> Fortunately a couple of servers implement the X-Sendfile extension (or
>> synonyms thereof) that allow to pass a path to the webserver which then
>> serves it directly like every other static file.
> 
> 
> I would be potentially interested in implementing this as we move
> closer to having FastCGI/SCGI support (which is a bit of a ways away
> due to memory management strategies). Personally, I'm more interested
> in nginx's X-Accel-Redirect than X-Sendfile, but supporting either
> isn't too difficult. Remind me of this in a few months.
> 
I'm still not sure this is possible at all w/o having a complete new
caching algorithm, as you can't know whether the URI/path you've sent to
the webserver to serve still contains the content you wanted to send the
moment the web server processes it. There is also the chance that the
server only sees a partial written file.

Main problem is the missing ack in the protocols. Though perhaps a
reasonable time period where writes are not allowed (5 mins?) could be
sufficient.

- Ren?

P.S.: While writing this email, I had an idea for an approach using this
timeout method:

1.) On request, copy the content part of the file to an extra
xsendfile-file (with 'sendfile()' the overhead should be reasonable).
2.) Send back the path to this new file.

*.) On each request check each file in the xsendfile-dir and remove it
if older than 5? minutes.

The part of "*" could also be taken by a cronscript or sth alike.

Also one should take care to not create the same content trillions of
times, so a check should be added, that does not create the
sendfile-file again if the cache did not change in the meantime.

If noone objects I'll see if I can give it a try during the weekend... :)