Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re: Slow performance of non-blocking select?

by flexvault (Monsignor)
on Nov 05, 2012 at 16:31 UTC ( #1002355=note: print w/replies, xml ) Need Help??

in reply to Slow performance of non-blocking select?

Welcome PMCarl,

You don't mention what operating system you're using, but a few things differ greatly with the operating systems I have testing with.

When using 'can_read', I pass 3.025 seconds as:

my @ready = $select->can_read(3.025);
Your comments in your code says it waits the full time so you use 'sleep' with a small time-out. If the above did that, then I would only be able to process 19 transactions per minute. If fact on different *nix systems I process between 8,000 and 38,000 transactions per second per core. So it may be a problem with your platform. Why '3.025' because I started with '.025' and found that using a larger number got better performance than using a smaller number. So I put a '3' in and got better performance. Could be platform related. YMMV.

You mention a 'default' of 64K. I have systems with different read/write buffered ranging from 8K to 512K. You should use 'getsockopt' to find your limits, and then I've found that the best performance is to ask the client for their sizes, and return a 'good' value to the client for all communication. Keep in mind that you can use a hash to keep track of the different 'MAXRD/MAXWR' for each client.

I haven't looked at all of your code, but these items jumped out at me, and since you're trying to improve and generalize the code, maybe this will help.

Update:I changed '19 transactions per second' to '19 transactions per minute' which would be correct ( 60 seconds / 3.025 seconds ).

Good Luck!

"Well done is better than well said." - Benjamin Franklin

Replies are listed 'Best First'.
Re^2: Slow performance of non-blocking select?
by PMCarl (Initiate) on Nov 05, 2012 at 22:09 UTC
    Thanks flexvault!

    My first thought was: "I'm using non-blocking IO::Select objects, so the time-out shouldn't matter"

    ...but that seems to have been the problem. 'can_read' and IO::Select::select both seem to be blocking even though I'm calling $obj->blocking(0);

    By using a very small time-out, I'm able to get very close to the performance of the original version of that package. Some runs actually show the new version out-performing the old one.

    The way the code is structured, it misses time that it could be doing other things while it is being blocked on can_read, so I don't get the advantage that you may be getting.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1002355]
[Discipulus]: good first day of Spring nuns and monks
[LanX]: yeah let's break the ice!

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2018-03-21 07:57 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (264 votes). Check out past polls.