If this were an SGI IRIX machine, I would use par on the processes. It would be useful to find out where the 7 seconds wait is happening.
On Solaris, I think the utility is called truss.
It is a big overhead on the system, but you can get it to show wall clock time for all system calls made.
You're not running into our old foe, the authentication process, are you? I'll QA this this afternoon and see whether I can chase down where the slowdown's occuring.
After workshopping this for a few minutes, I'm pretty sure you're running into the same overhead we run into when running blcli: the SRP authentication. I'm Not A Software Engineer, but it appears to be doing the same type of authentication. (I'm thinking this connection may be persistent after the initial connection, not requiring further authentication, but still need to test this)
I note that as of 6.2, there's also a "CLRMaxProxyThreads" setting to match SRPMaxProxyThreads, which implies that you might be able to use cleartext proxying, with all the security concerns that carries with it. However, the performance gain may justify it for your needs.
Apparently, there are some performance enhancements in 6.3 for nsh proxying.
to elaborate further...
there was a problem with SRP proxy where we were using a java method which is known to perform poorly. sun had a recommendation on a workaround which development implemented. in searching for the original problem, it was also discovered that there were memory leaks. both issues were adjusted accordingly and tested. SRP proxy for simple commands appears to be far closer to the realm of being reasonable now and, as a bonus, no more memory leak.