This depends entirely on your aplication. I worked with a customer where we were trying to get an OOME when running web services. We got the heap down to 16MB before we could force the OOME - with 20MB we could still run 50 simulated users for about 20 minutes and noticed the ehap usage was not increasing.

The best thing to do is set up a load test using a commercial tool such as LoadRunner (if you have lots of money that you don't know what to do with) or an open source tool such as JMeter or Grinder. Set up the tests to simulate typical customer activity. Monitor the heap usage an GC and various OS and database metrics during the test. That should give you a good idea.

My basic rule is this: On a 32-bit system, you should have at least 3GB or RAM, 4 GB would be better (yes some will be wasted, but the extra 600MB or so that is usable does come in handy. Set the ehap to about 1.5GB with a 500MB young generation. Set permgen to about 256MB (usually way more than enough unless you are constantly hot deploying or redeploying applications). That should let you handle a fairly decent load. Of course, it could be overkill, but the load test will tell you that. (My guess is that unlessy our code does an awful lot of processing that it will be overkill for 20 simultaneous users, perhaps something 1/2 the size will work. But like I said, it really depends on what you code is doing.)

When you say "20 users", do you mean that the server will always be busy handling 20 requests, or do you mean just 20 people currently connected with open sessions? There is a huge difference. With 20 connected usesrs I would expect only about 1 or 2 requests to be handle simultaneously. If you are handling 20 simultaneous requests, then you are actually supporting about 100-200 connected users.

One more hint: don't start load testing with 20 simultaneous users, Instead, do 1 first, then up it to 5, then 10, then 15, then 20. Each time, gather all of the performance data and analyze it. That will give you a better feeling for how many users your system could handle.

You might want to look over a few of the perfomance papers I wrote for CMG:

http://www.cmg.org/cgi-bin/search.cgi?q=peter+johnson&x=36&y=13