[Advanced-java] architectural guidelines for j2ee/java systems software

[Joel Thompson]

Hello,

I'd like to find (or create) a set of architectural guidelines to right 
size J2EE systems. 

Inputs would be items like # of users, # concurrent users, estimated 
trans/second, database size, OLTP or OLAP type systems, and more.  Then 
based on these come up with a architecture to meet these requirements.

IE, based on the inputs we might generalize, that the system would fall 
into one of these categories:
1) Small
2) Medium
3) Large
4) X-Large

Then each category would have it's own recommended base configuration of 
hardware/software. Example "Small" might be less than 100 users, and 
less than 10 concurrent users, data base size of 100 MB. In this case, 
we could get away with one server, running Application Server, Database 
Server, HTTP Server sofware.

And on the other extreme, considering #4, we might have 100's of 
grid-clustered computers, each running appropriate software to meet 
these need with Load balancers, and clustered database servers in the 
backend.

I'd like to know some real-life #'s (like supported request per second 
(RPS), db transactions per second (TPS), with different 
hardware/software configurations that people have actual expereience with. 

In otherwords, if folks could help me with info like I have 2 clustered 
JBOSS servers, running on Sun XYZ Hardware/Software, with squid caching 
servers, and 3 load balancers, and it currently handles 100 RPS with an 
Oracle backend.

I'd be interested in the sales pitches too, ei. Weblogic claims they can 
handle 1000 RPS on XYZ platform, or Some databaes like Oracle 10g or 
Sybase can handle 100's of SQL TPS for single server, or in a 2 way 
cluster handle 1,000-10,000 SQL TPS (just estimating here).


I realize that there are literally 1000's of software/considerations, 
but I am trying to get a "ball-park" sense of this.

Please help, if you can, and if you'd like to see the results of this 
inquiry, email me at joel at rhinosystemsinc dot com.

Thanks,
Joel