How to test a TCP server implementation?
I have written a TCP server implementation using which I created an application which works as TCP echo service.
Now I want to test this echo server in terms of
- How many connections it can handle
- What is the response time
- How much memory and CPU it uses
Please can you suggest any standard method/tools to test this echo server. I understand that both TCP and echo server implementation is fairly standard practice so I hope to find established tools to test it.
P.S.: I can write my own test application but I don't want to do it because if I see some problem, I need to be sure that it is my server that is doing it wrong. I don't want to end up testing my test client first.
I wrote this implementation using C# and .NET 3.5 though I believe it doesn't matter with reference to the question.
Answer
I have a free tool that might help you. I use it for testing servers that are built with my C++ server framework. The tool is available here: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html. It allows you to create a configurable number of connections to your target server at a configurable rate and then send data on each connection (again at a configurable rate).
If find that the best way to use it is to run it on a different machine to the server (fairly obvious I know, but...) and possibly to run multiple copies on multiple different machines. Note that if you find you can't make more than around 4000 connections then it's quite likely that you need to tweak your MAX_USER_PORT registry setting on the machine that's running the client.
Once you've tested your TCP code you may find you need to test the protocol that your server supports. I wrote a test tool for this kind of situation in C# which is available on CodeProject (http://www.codeproject.com/KB/IP/testingsocketservers.aspx). This allows you to write a "plugin" to support your protocol and handles the protocol agnostic stuff (lots of connections, breaking messages up so that you get fragmented reads, etc) for you. The design is a rather nasty thread-per-connection design and for higher numbers of connections you'd be better off reimplementing something using an async design but I have my C++ tools for that so I never got around to changing this test program...