Hello!
On Tue, Aug 12, 2014 at 11:27 PM, Ajay Bodhe wrote:
> My CPU bound code would be consuming 200-400 MS.
>
Let's say, it's 300ms CPU time per request, then each of your CPU
cores will only handle 3.3 requests/sec! If your machine has N cores,
then it's just a little above 3 * N req/sec in theory! Yes, no matter
what approach you use, because you cannot *invent* new CPU resources
from your software. You can only try to waste less.
> If I run this computation code inside nginx worker it will be blocked for
> further requests.
Because your current CPU core (bound by your current nginx worker
process) is already 100% on the current request, there is no point in
accepting new requests for this extremely busy nginx worker process,
because that'll only make the situation even worse :)
If I were you, I'll try to optimize this CPU hog thing to death. CPU
time a precious hardware resource anyway. Failing that, I'll just run
a machine farm of nginx servers, possibly before an nginx simply doing
reverse proxying. And in each "backend" nginx server, I'll configure
the standard ngx_limit_req module to limit the incoming request rate
to 3 * N req/sec (where N is the number of logical CPU cores available
in the current backend machine).
Please always keep in mind:
1. Trying to exceed the throughput limit of your server by launching
more OS threads or increase client concurrency level will never do you
any good but make the latency and throughput worse and worse.
2. Hardware resources like CPU time are constants. You cannot invent
new hardware resources from your software; you can only reduce
wasting.
3. Throughput limit is everything. See 1) above.
> I can write another processing stage(threadpool may be) to which I handle
> over this task along with Nginx-worker callback.
It's not really solving any problems here :)
> But then it will again cause more overhead in terms of switching, right?
>
Of course. This is a way of increasing the waste of hardware resources :)
> I was looking at solutions build around ASIO. It has the concept of
> IO_SERVICE which handle aync NW/IO calls & threadpool which handles such CPU
> tasks & gives a call to IO_SERVICE for any NW/IO thing.
>
You need to make a clear conceptual distinction between I/O-bound and
CPU-bound. Solutions to improve one thing will not really help the
other. Even use of nonblocking I/O is to reduce context switching
overhead (for CPU time!) involved with a lot of OS threads doing
blocking I/O. Again, to reduce wasting of hardware resources.
> Also in terms of Nginx what works better writing server logic as part of
> Nginx or moving it to another application layer which communicates with
> Nginx over FastCGI?
>
Another FastCGI layer involves more socket communication overhead
(including expensive system calls). Again, you may start wasting more
CPU time, i.e., more hardware resources :)
Best regards,
-agentzh