Re: mod_fastcgi buffersize

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 <[email protected]> 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-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>



-- 
Rasmus Andersson