The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: ry <ry.d...@googlemail.com>
Date: Tue, 1 Apr 2008 10:45:50 -0700 (PDT)
Local: Tues, Apr 1 2008 1:45 pm
Subject: Re: upload handling
Hi Adam,
> It seems that EBB_BUFFERSIZE controls the behavior of two unrelated things:
That's correct. The initial continuous block of memory that the
request header is stored on. ebb sends pointers to each header field and value which reference the buffer. Only the header needs to be on a continuous block of memory, the body could be broken up. However Ebb does not have support (yet) for growing this buffer - instead it writes to file if the request is too big for it. > a) the buffer size for reads. This buffer must be set large enough that it
No. Ebb tries to get the header onto the buffer. Once the header is
> can't be filled before the next time libev calls on_client_readable, > correct? If the buffer gets filled all the way (client->read == > EBB_BUFFERSIZE) you throw an error, because we've probably lost some data > that didn't fit in the buffer. on, it checks the content-length - if there is enough room it puts the rest of the request onto the buffer, otherwise spawns a thread and writes the whole request to file. It will error out if the header is larger than EBB_BUFFERSIZE. However, the buffer is sufficiently large that this shouldn't happen for any normal request. > b) Cut-off for mem versus disk. Once the request is finished, EBB_BUFFERSIZE
Once the header is read, and Ebb determines the content-length +
> controls which requests get saved to disk. In this case, anything larger > than 40KB gets tossed in a thread which saves it to disk. header_size > EBB_BUFFERSIZE it 1) spawns a thread 2) opens a tempfile 3) writes the part of the request body that was already in client- >request_buffer to the file
4) reads blocks from the socket and writes them to the tempfile.
> Please correct me on any errors, but it seems like even large uploads aren't
No, that wouldn't be good. Large requests are written as they come in.
> written to disk until they've been completely stored into memory(or swap?). > I say this because read_body_into_file is only called after
the parser only handles the header, not the body.
> client_finished_parsing==true and after we have a total_request_size. Is > that assessment correct, or am I mis-reading your code? The obvious improvement that can be done is allowing larger memory
ry You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||