Is it possible for you to explain a little more detail about these two 
undocumented functions? is there a reason why they remain undocumented?

process._getActiveHandles()
process._getActiveRequests()

cheers

Tj



On Tuesday, June 18, 2013 12:54:04 AM UTC+4, Forrest L Norvell wrote:
>
> There are a few things you can do, but this is a simple question with a 
> surprisingly complex answer. The short answer is that knowing the length of 
> a notional "event loop queue" doesn't really do a very good job of telling 
> you how *busy* your application is. The different kinds of tasks that 
> libuv manages (I/O, deferred execution via setTimeout / setInterval, 
> "asynchronizers" like process.nextTick() and setImmediate(), signal 
> handlers) are handled at different stages and with different priorities.
>
> The first thing is to remember that there are a number of different 
> sources of work feeding into the event queue:
>
>    - there's the process.nextTick() queue, which is processed at a 
>    variety of points through each turn of the event loop
>    - as Jorge said, there's are tasks set to execute via setImmediate()
>    - libuv handles the list of I/O requests with available input and 
>    hands those off to turns of the event loop
>
> See this handy graphic for an only somewhat out-of-date (but *very* useful 
> -- it should probably be part of the docs) visualization of how all that 
> happens: 
> https://a248.e.akamai.net/camo.github.com/e0b4108147b3fa603ef6badd805a2f01d73460fc/687474703a2f2f68746d6c352e6f687473752e6f72672f6e65775f736574496d6d6564696174655f73656d616e746963732e706e67
>
> The problem is that turnings of the event loop aren't homogenous, and the 
> event loop queues on their own don't really tell you the most important 
> thing, which is whether your application is getting bogged down (for 
> whatever definition of "bogged down" works well for you). There are modules 
> like node-toobusy <https://github.com/lloyd/node-toobusy> that try to 
> monitor the latency of the event loop and tell you if it's taking too long 
> (which can actually be helpful if you're doing a lot with 
> process.nextTick(), or are trying to do something CPU-intensive in single 
> turns of the event loop), but by and large, this kind of information is 
> hard to gather from inside Node and turns out to be of limited use.
>
> There's also DTrace, which can give you much finer-grained (or 
> coarser-grained!) statistics about what's going on with the event loop.
>
> Most of the time, the only time you'll encounter performance problems tied 
> to event loop processing is when you're trying to do too much computation 
> during a single turn of the event loop. I'd generally look pretty much 
> everywhere else first when trying to do performance tuning.
>
> F
>
>
>
> On Mon, Jun 17, 2013 at 1:21 PM, Jorge <jo...@jorgechamorro.com<javascript:>
> > wrote:
>
>> On 17/06/2013, at 17:20, Chaoran Yang wrote:
>>
>> > Dear all,
>> >
>> > Is there any way in node.js I can query the length of event loop queue?
>>
>> No.
>>
>> > I assume the event loop has a queue of callbacks.
>>
>> No there's no queue. An event happens -> its handler (if any) is called: 
>> it doesn't go through any queue.
>>
>> > Checking the queue length can be useful to know whether a server is 
>> busy or not at a certain time.
>>
>> The only queue there is is the nextTick queue. Well now it's the 
>> setImmediate queue, I think. But IIRC neither the nextTicked functions' [] 
>> nor its .length was visible from user code.
>>
>> --
>> ( Jorge )();
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines: 
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nod...@googlegroups.com<javascript:>
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to nodejs+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to