On Tuesday, January 7, 2014 9:08:10 PM UTC+5:30, Saúl Ibarra Corretgé wrote:
>
> Hi, 
>
> > 
> > Hi Sa�l, 
> > 
> > Thanks really for your looking into this. 
> > 
> > If we call uv_queue_work unconditionally it goes on creating thousands 
> > of threads (I did see it through Windows task manager). It was becoming 
> > tough to manage resources in that case. To avoid that, I call 
> > uv_work_queue only for predefined number of times, and next call(s) will 
> > occur only after I got callback(s) to previous call(s). 
> > 
>
> I see. 
>
> > My event loop puts incoming data (requests) in a queue and routine 
> > passed to uv_work_queue (thread) processes those requests in queue 
> > sequentially. Thus, event loops job is only to dump incoming requests to 
> > queue through on_read callback, and to attend other callbacks 
> > (after_work_cb, tty callback etc) 
> > 
> > Currently it is simple echo server. So nothing much I am doing in 
> > threads except copy the request (for sake of doing something), so that 
> > after_work_cb can send it back to client. 
> > 
> > It all works fine. But when I simulate thousands of connections those 
> > bombards my server with continuous asynchronous requests, event loop 
> > keeps invoking only on_read callback. Thus, after_work_cb never gets 
> > called and my request queue goes on increasing forever to system memory 
> > limits. (TTY callback also never gets called but I guess underlying 
> > reason might be the same for both) 
> > 
> > What I observed additionally is, once I stop simulator, event loop 
> > immediately resumes calling back these other callback. 
> > 
>
> Since what you are implementing is an echo server, thus i/o bound, lets 
> try to create a simpler test case: don't use uv_queue_work at all. Just 
> do the uv_write on the read callback to send the reply back. 
>
> Then hammer your server with those thousands of connections and lets see 
> how that goes. 
>
>
> Regards, 
>
> -- 
> Sa�l Ibarra Corretg� 
> bettercallsaghul.com 
>


Hi  Saúl,

I tried as you suggested by not using uv_work_queue and doing just uv_write 
on the read callback and then hammering with thousand connections and 
requests.
It works absolutely perfect and I also get other callbacks (after_write, 
TTY callback)

( However, the echo server is just for test purpose. In production scenario 
I have to have worker threads to do CPU bound processing on all incoming 
requests before I send results to client(s) )

Now I still didn't get any clue,   with massive incoming requests from 
thousands of clients, after doing uv_work_queue calls why only read 
callback works and other are inactive?

Many Thanks,
Ashish

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to