Re: [Fastcgipp-users] how does fastcgi++ support multiple concurrent requests ?

[Eddie Carle]

On Sun, 2012-12-02 at 01:48 -0500, Chang-Jian Sun wrote:
> I tested several examples in fastcgi++ (very nice API !), but didn't
> find any examples to show how it can process multiple concurrent
> requests.
> 
> It seems that fastcgi process handle one request at a time. In the
> echo.cpp example, if I added sleep(10) in Echo::response(), and
> started multiple connection in browser, the requests are processed
> sequentially.
> 
> I thought the fastcgi++ main() should support something like this:
> 
> while (true)
> {
>     accept new request
>     spawn new thread (or assign to worker thread) to process this
> request
> }
> 
> This will allow processing concurrent requests. Am I conceptually
> wrong ? Thanks a lot!

Well, just because something is running in a separate thread doesn't
necessarily mean that it is actually running concurrently. Not to
mention that the cost of setting up and managing many threads is quite
high. It is fairly well established that the thread per request model
does not scale very well.

The idea with fastcgi++ is that requests are given control over
execution and then when they are idle, they return it. One would never
call sleep(10) in a request as it would block. One would start a timer
and immediately return from response(). Then when the timer is complete,
response() would be called again to complete the request. If you peruse
through the examples you'll notice a timer example that shows how it
works.

Do some apache benchmarking with tradition libfcgi calling a thread per
request and compare it to fastcgi++ doing things "sequentially" and the
results may surprise you.
-- 
        Eddie Carle