[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Javier de la Dehesa
Subject: Re: [Fastcgipp-users] how does fastcgi++ support multiple concurrent requests ?
Date: Tue, 04 Dec 2012 14:40:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

El 03/12/12 18:49, Eddie Carle escribió:
> 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.

I am using FastCGI++ too and needed the ability to process several
concurrent requests. As Eddie states, creating a new thread for each
request do not scale well. My approach is to use some kind of simple
thread pool, so I can process a number of simultaneous requests without
needing to create new threads. I am attaching some sample code - not
that is really good or anything, but it may be useful as a guide (I've
just made it up from my real code, so there could be some flaws here and

There is a generic BlockingQueue class used to enqueue the requests -
class ThreadedRequest, which implements deferred response enqueuing
request in the queue. RequestDispatcher implements a singleton thread
pool that process requests and send responses.

Constant NUM_WORKERS define the amount of threads in the pool, and in
line 208 you should put the code to process your request. If you have
any question about it please ask.

Javier de la Dehesa

Attachment: threadedRequest.cpp
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]