One of the problems when running through inetd is that it's going to introduce overhead in the performance. If performance is a concern, which it is, do not use inetd and use a standalone daemon.
The best way to improve performance would be to take inetd out of the picture. But if you really, really have to use inetd, here are some ideas:
Another possibility is that your service is processing one request or a small number of requests, and then shutting down. If that's the case, then under load inetd will consume a lot of time relaunching your service. So you want to avoid that scenario.
A final possibility is that problem you are seeing is caused by server processes not terminating correctly, and hanging around using up kernel resources. In the worst case, they may be even spinning. It would be worth using your system's monitoring tools to see what is actually happening when your system is running slowly.
Can you give us some idea of the difference between "very very slowly" and "very fast"? It could be that inetd is doing something like doing a reverse lookup of IP addresses on each connection (I don't know for sure, this is just a guess) and maybe you don't have a DNS server set up to answer, so it's getting a 1 or 2 minute timeout on each connection.
If the difference is "10 per second" vs. "12 per second", then you will have different issues than if the difference is "takes 90 seconds to respond" vs. "responds right away".
It sounds like your TCP service is being started for each request incoming to inetd, then shutting down immediately.
Forking a new process like this for every request is pretty slow, so I think the best place to look is changing your TCP service to stay alive to handle x number of requests before shutting down.
