RMI is slow, hence the creation of asynchronous interfaces such as JMS.
There may be certain instances you can cache, so subsequent calls can be done using the same objects.
Are you accessing the server using direct IP address?
If so, try assuring that there is a dns mapping for the ip address.
Yes, direct IP. I found that caching everything to do with the bean lookup helped - got it down to 250ms so that was an improvement.
I have all the reference data cached with infrequent checks. Activity data I just check if it has changed. I was able to get the application reasonable over the internet. If I could batch a number of calls together that would certainly help in some cases though there are not that many opportunities.
Managing caches to prevent stale data is tough but I think I can do it.
It still doesnt make sense to me that there is that much overhead on a single RMI call over the internet. Does one Boolean call with no parameters pass a lot of additional content? But regardless if I can ftp at 100's of KB per second...
There must be something still to be tuned there, doesn't quite add up.
Bandwidth is not the same as latency. Run "tcpdump" or turn on server.log debugging to see what's actually taking time. I'm guessing there's a lot of ping-ponging going on.