|Keep It Simple, Stupid|
Re: Slow performance of non-blocking select?by flexvault (Monsignor)
|on Nov 05, 2012 at 16:31 UTC||Need Help??|
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:
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 ).
"Well done is better than well said." - Benjamin Franklin