Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to tune a high message traffic system running on Solaris. The architecture is a large number (600) of clients which connect via TCP to a big Solaris server and then send/receive relatively small messages (.5 to 1K payload) at high rates. The goal is to minimize the latency of each message processed. I suspect that the TCP stack of the server is getting overwhelmed by all the traffic. What are some commands/metrics that I can use to confirm this, and in case this is true, what is the best way to alleviate this bottleneck?

share|improve this question

migrated from stackoverflow.com Feb 25 '10 at 1:04

This question came from our site for professional and enthusiast programmers.

2 Answers 2

snoop(1m) and dtrace(1m) will probably be your best friends. First one for watching and timing the traffic, second one for measuring server's internal latency.

share|improve this answer
    
+1 for dtrace, it's amazing. You need to be careful though, since asking for too much data could hog resources and cause problems. Any dtrace work should be done on a non-production system first so you don't inadvertently bring down your production server. Not that I'm speaking from experience or anything.... –  Milner Jul 8 '10 at 11:40

If your total message size is <1k, you may significantly ease your network load by using UDP instead of TCP. Sending a short message via TCP entails overhead at each end setting up the session/connection information, the three-way handshake to start and connectin close to end on the network.

With UDP, you'll send a single packet with your message, and rely on the network "best effort". You'll probably want to code the client with some timeout and retransmit should the packet be lost, but if your transaction and response are both under the MTU, you can get by with less than a quarter of the actual packets.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.