[FASTCGI] mod_fastcgi buffersize
Rasmus Andersson
rasmus at flajm.com
Sun May 3 07:03:39 EDT 2009
Totally depends on the implementation. FastCGI is merely a protocol
and a C library implementation of that protocol. How you handle the
kind of I/O you're talking about is outside of the scope of this list.
But there are basically three models:
1. blocking I/O, single thread
This model handles one request in sequential order. That means if
request 1 takes 4 seconds to process, request 2 will have to wait for
up to 4 seconds.
2. non-blocking/asynchronous I/O, single thread
This popular model builds on the idea that I/O is the bottle neck, not
the CPU. Handles multiple requests at once but code will never execute
concurrently.
3. blocking or non-blocking I/O in multiple threads of control
Consumes more memory, context switches and CPU than model 2 but is
much easier to implement and provides the same features, except from
that in a well-designed application, code can execute concurrently.
If your model is 1. you have a problem (unless there are multiple
processes running, which is probably the case if you are running PHP).
If your model is 2. and you use blocking I/O (for instance from other
libraries, like database clients) you have a problem (unless multiple
processes, but then you would probably want to use model 1.).
On Sat, May 2, 2009 at 23:13, double <ninive at gmx.at> wrote:
> Hello,
>
> A FastCGI application creates a website, and the content
> size is below e.g. 100k.
> Let's image, the client has a slow dialup-connection. Will,
> in this case, the FastCGI application be blocked until the
> website is entirely transfered to the client? Or is this website
> buffered by the webserver and the FastCGI application can
> process a different request?
>
> Thanks
> Marcus
>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers at mailman.fastcgi.com
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
--
Rasmus Andersson
More information about the FastCGI-developers
mailing list