primS Telnet Client Performance
iftahb opened this issue · comments
Hi,
First, let me thank you for this very nice implementation.
I am working with the Telnet Client in a system with 5-10 threads - each connected to a different device.
Everything works nicely, except for low performance that I can also witness in the high CPU usage.
When comparing it with a similar SSH package (which is expected to be much heavier) I see that the Telnet implementation consumes almost three times the CPU doing similar things.
Digging in, I found out that you are reading from the socket char by char and only use minimal delay between reads.
Am I missing something? can this be somehow improved?
Kind regards,
I
Yes, of course it could be improved; can't everything? I'm glad it works; sorry about the high CPU usage. The sledgehammer that the existing implementation makes available you've already identified is the spinwait delay which in some places can be optionally passed in. If the entry points aren't sufficient for your needs you're welcome to branch, extend and submit a pull request and so long as you don't break anything incumbent I'll merge it in. Even if it does break something I'll consider it but it might take longer to complete the merge :)
Pros; simplicity and cross framework/platform reusability
Cons; it's all still pretty synchronous atm despite the half way house async spin stuff which was enough to facilitate keeping a simple UI responsive, per my use cases; but is going to come to it's knees before long if you start running multiple parallel threads per your use case... Delay and sleep are little better than each other; looking in to the event model and using callbacks to respond to activity is probably a good route to pursue; but that is likely to quickly break across the frameworks and certainly wouldn't be a trivial pursuit.
Thanks, but not sure I understand your first reply.
Is there a configurable "sleep/delay" setting I could use to lower the CPU load (and pay with responsiveness, as I am not using a UI and therefore less sensitive) without changing the code?
Sorry for misleading, you're right. I checked out the code while merging in the LineTerminator PR and seems like you would need a code change to alter the DefaultTimeoutMs (depending on framework version you're using). Wouldn't be too hard to add in an overload or two (or more for others with same problem :) and would definitely be a step in the right direction even if it would still be a bit of a sledgehammer...
In my latest Pull Request #35 I increased the delay between reads from 1ms to 16ms. I did this because most operating systems do not measure ticks below 10ms which can cause sleep times of 1ms to be treated as zero. That seems to help on receiving packets but the largest performance boost I was able to produce was from buffering writes and changing all internal write operations from .WriteByte to .WriteAsync. This vastly reduced TCP overhead.
Read about double buffered TCP writes here:
http://www.stuartcheshire.org/papers/nagledelayedack/
If you would like to beta test my new version you can get it here:
https://github.com/A9G-Data-Droid/Telnet/releases/tag/0.8.2
@iftahb @A9G-Data-Droid guys; sorry had to come on and reply that I likewise appreciate all done; but I've got a day job & life too and the amount of effort that's gone in to all the improvements suggested is going to take time to review, build and publish which I've not had in the last few days; sorry. Bear with me please... In the meantime feedback on the beta release would be most helpful to both of us :)
@iftahb I'm not sure. My code doesn't connect to more than one host at a time but I hope you see a performance boost from my improvements. Please let me know if it helps.