Re: [Fastcgipp-users] Fastcgipp-users Digest, Vol 18, Issue 1

[Eddie Carle]

On Tue, 2012-03-06 at 21:06 +0800, lxs567890 wrote:
> Thanks, I understand what you mean. But I am still confuse about the
> multi-request for Fastcgipp. When many request come to the Fastcgipp,
> if I use one process to handle it. It means I should use multi-thread
> to handle it(e.g boost::asio to support)? Can you give me other
> multi-thread examples to handle it (except the website).

Multiple threads are not necessary to handle concurrent requests. This
is a misunderstanding of how computing systems work that is very
prevalent in the field. It has lead to all these server applications
that scale horribly because a new thread is spawned every time a new
request is made. Ultimately, assuming a single core, your processor can
only do one thing at a time. If you have multiple threads, time slices
are assigned to each thread and every time it switches between threads,
the registers are dumped to and loaded from the stack. This is very
inefficient for large amounts of threads and exactly what fastcgi++
intends to avoid. The illusion of concurrency that multiple threads
provides is just that, an illusion. You're better off deciding yourself
which request gets computing time based on when they actually need it.
As long as a request has work to be done, let it work. It will be faster
that way. If it doesn't have work to be done, return false from
response() and the manager will let another request do work. If the
request is done everything it needs to do, return true. It is that
simple. If a request wants to go to sleep and be awaken by something
else (maybe it is waiting for a database query or another request to
complete), then you call the requests callback function to have it woken
up by the manager so it can resume execution.

If you start using boost::asio and multiple threads, you wreck the
efficiency gains you get from using fastcgi++. You might as well use
something that is intended as a request per thread model. It will work
better.
-- 
        Eddie Carle