Original website: http://www.networkcomms.net/forums/topic/throughput-and-performance/
An article on the forum is recorded for future reference
Hi, I develop an application where a central server was connected to many clients (mobile devices via Wifi).
The central server on the he part routes the received messages to a further application that usually resides on the same PC, So it ' s localhost communication.
Basically it works, but I worry that the throughput of Networkcomms are not sufficient.
Even with both test clients, that is, each send approxmimately small messages per second, and the central server have a total CPU Load up to 50% for a single CPU core (Intel i7-4702mq).
One hotspot for CPU usage seems to is the Streamtools.write method.
I Don ' t fully understand why it's realized this, but it seems to introduce a considerable amout of overhead.
I tried different settings of sendbuffersizebytes and initial/max-receivebuffersizebytes, but without any satisfactory res Ults.
Is there a-to-reduce CPU load?
Apart from that it ' s really a great library!
-------------------
I replaced the Streamtool.write implementation with a simple synchronous version:
Public Static DoubleWrite (Stream InputStream,LongInputstart,LongInputlength, Stream Destinationstream,intWritebuffersize,DoubleTimeoutmsperkbwrite,intMintimeoutms) { if(InputStream = =NULL)Throw NewArgumentNullException ("Source"); if(Destinationstream = =NULL)Throw NewArgumentNullException ("Destination"); //Make sure we startInputstream.seek (Inputstart, Seekorigin.begin); intBytesRemaining = (int) Inputlength; intBufSize = Math.min ((int) inputlength, writebuffersize); byte[] buf =New byte[BufSize]; while(BytesRemaining >0) { intcount; if(BytesRemaining <buf. Length) Count= (int) bytesremaining; ElseCount=buf. Length; Inputstream.read (BUF,0, Count); Destinationstream.write (BUF,0, Count); BytesRemaining-=count; } return 0; }
Now the performance is fine!
First I thought the allocation of the various buffers and objects in your implmenentation are the reason, but now I suppose It ' s due to the overhead of thread/context switching from the asynchronous stream begin/end methods.
Tested it with a slightly modified version of your Examplesconsole Advandedsend example which runs now five times faster.
Send calls per second increased from the 25000 on localhost and the CPU load dropped to one third.
------------------------------------
Interesting, thanks for the update. The reason we use a async write is this we noticed on some platforms, I think it's mono and Android, streams would some Times freeze and the write would crash the application.
I would not having expected to see such a significant performance difference. Could give us some more information about the platform is running this on?
Kind Regards,
Marc
---------------------------------------
Hi Marc, I ' m running it on a Windows 8.1 Pro Notebook with a i7-5702mq CPU (2,2 GHz). The effect is the same at least for. Net Framework 3.5 and 4.0.
-----------------------------------------
Correction:i7-4702mq
Hi Marc, can reproduce this observations and be there a chance that a faster Streamtool.write implementation finds it ' S-to-a coming release?
---------------------------------------------
I have added the roadmap.
Regards,
Marc
Throughput and performance