Hi

   I am architecting a J2EE application which will going to use JSP/Servlets or may be possible EJB's, On that application there will be many registered users and many many of them will be remain online at any given time, So the main issue/problem will arise of Handling Concurent Users, So If any body would like to advice me on Clustring/Scalabilty issues of J2EE Application servers PLUS scalability of databases servers with reference to Vendor specific tools, It will be appericiated.
I need Vendor Servers specific information... e.g JBoss supports 2000Maximum concurant users online. etc etc

Regards

Khurram M. Khokhar

The answer is impossible to provide. I like to say "your mileae will vary". Too much depends on your application, what it does, how it works, how it was designed, how it is used, etc. IMHO all the application servers are about the same in terms of performance. I say that because so much of your performance of the app server depends on the code running inside of it.

You're better spending your time working with senior developers or consultants with real world experience in building scalable web applications.

Invest in an app server with wide spread adoption, lots of available consultants, and good technical support.

Dave Wolf
Cynergy Systems

i would go for oracle app server as i think it has a good report on the db market and the performance given by oracle is fairly good. j2ee is good for testing
weblogic and websphere have a good technical support on hand. spend some time with the appservers and u will get to know which is the best for which appication
i would prefer weblogic for ejb and for servlets webspere.
for jsp i would prefer oracle. oracle has a good performance tuning capability which i think is good for huge applications
thanks
Pradyut

Oracle DB Clustering is very expensive, so I do not think you want to scale out on that layer.

Interestingly enough MySQL AB is offering clustered DB solution now - so you may want to look into that.

Also a good idea is to explore caching opportunities. We had good results using Hibernate + JBossCache integrated into it. JBossCache is a solid clustered cache and very handy in providing horizontal growth for your application.

Although, when considering caching opportunities, be very careful not to overuse it. 32bit JVMs have a memory limit of ~1.6GB. If you have 64bit processor, the memory limit is not present there but, because of garbage-collection overhead, using a lot of memory may still hurt.

Hi Irakli

Also a good idea is to explore caching opportunities. We had good results using Hibernate + JBossCache integrated into it. JBossCache is a solid clustered cache and very handy in providing horizontal growth for your application.

Although, when considering caching opportunities, be very careful not to overuse it. 32bit JVMs have a memory limit of ~1.6GB. If you have 64bit processor, the memory limit is not present there but, because of garbage-collection overhead, using a lot of memory may still hurt.

I think an important thing to note here is that to provide room for the horizontal growth of your application in a clustered environment, you also need to have the data grow horizontally.

This is the exact reason we developed Coherence's Partitioned Cache. The Partitioned Cache automatically partitions the cached dataset across all nodes participating in the cluster (while providing fault-tolerance of the data). You no longer have to deal with the ~1.6GB limit on memory or the garbage collection pains.

Later,
Rob Misek
Tangosol, Inc.
Coherence: It just works.

Hey Rob,

Yes, I agree with you. And you do know I am among the admirers of what you guys do with Coherence.

However, I just wanted to give an example of an OSS solution. Coherence, alas, is commercial :)

Also, as purely a fact - the memory limitation is gone on 64bit machines. It is possible to use much more RAM than 1.6G.

At the same time, I am not so sure if using a lot of memory for in-process caching is a good idea, even if one can. Garbage collector will have to deal with too much data, complete replication may become a headache in a cluster - lots of other reasons to consider.

It would be nice to see a comparision test-results. Maybe you have done something like that? Comparing a 64bit machin using, say, 4GB in-process and Coherence that clusters the same 4GB of memory in a network.

Hi Irakli,

Yes, I agree with you. And you do know I am among the admirers of what you guys do with Coherence.

Thanks for the kind words!

However, I just wanted to give an example of an OSS solution. Coherence, alas, is commercial :)

Yes, "alas" ;-)

Also, as purely a fact - the memory limitation is gone on 64bit machines. It is possible to use much more RAM than 1.6G.

At the same time, I am not so sure if using a lot of memory for in-process caching is a good idea, even if one can. Garbage collector will have to deal with too much data, complete replication may become a headache in a cluster - lots of other reasons to consider.

Exactly, the garbage collection issues will not go away. In fact, they will get worse (or at least even more complex).

It would be nice to see a comparision test-results. Maybe you have done something like that? Comparing a 64bit machin using, say, 4GB in-process and Coherence that clusters the same 4GB of memory in a network.

How about a combination (or best-of-both-worlds)? For instance, Coherence's Near Cache. A Near Cache is composed of two parts a "front cache" and a "back cache"; the "front" typically being a size-limited/auto-expiry cache that stores the MRU/MFU objects in the local JVMs heap and the "back" typically being a Partitioned Cache. When you say cache.get(X) the "front" is checked first, if X does not exist (in the front), we fetch it from the "back" and place it in the "front" for future use. The result being limitless storage of cached data in-memory in the application tier (Partitioned Cache) with a good percentage chance that the "get" will be a local call provided there is repetitive access to the data (Near Cache).

Taking it one step further, you can even configure "storage" on a JVM by JVM basis, so you application server JVMs do not necessarily need to be responsible for an equal partition of the cached dataset, just the Near Cache (of which you control the size).

Later,
Rob Misek
Tangosol, Inc.
Coherence: It just works.

Thanx 2 all !!!!

It will be appericiated.I need Vendor Servers specific information... e.g JBoss supports 2000Maximum concurant users online. etc etcRegardsKhurram M. Khokhar

Ok, if you only need references, these are the numbers of the application that we are developing:

- WebSphere 4.0.7 deployed on top of Solaris (two machines, all of them with four processors and 4 gigas of RAM.)
- Databases: Oracle (on UNIX) and ADABAS (in mainframe, of course)
- Number of pages served by minute: 1320.
- Number of concurrent users: 1000.


Jose Ramon Huerga
http://www.terra.es/personal/jrhuerga