Designing for scalability availability & performace

Discussions

Performance and scalability: Designing for scalability availability & performace

  1. For a recent requirement of supporting a small web application with 20 JSP pages with 3 Million users over a 1 week period (with 23000 concerrent users at a peak)

    What in your opinions is the most scalable approach towards calling a data access object for simple updates, using a servlet calling the data access object or a servlet calling stateless session beans which inturn calls the data access object?

    My money is on using (local) stateless beans given it's better lifecycle mangement (such as object pooling, possibility for transactions) and it's thread safety.

    To me the option of running of each instance of a servlet on a different thread is defintely is the less scalable of the architectures.

    Any opinions?
  2. For a recent requirement of supporting a small web application with 20 JSP pages with 3 Million users over a 1 week period (with 23000 concerrent users at a peak)What in your opinions is the most scalable approach towards calling a data access object for simple updates, using a servlet calling the data access object or a servlet calling stateless session beans which inturn calls the data access object? My money is on using (local) stateless beans given it's better lifecycle mangement (such as object pooling, possibility for transactions) and it's thread safety. To me the option of running of each instance of a servlet on a different thread is defintely is the less scalable of the architectures. Any opinions?
    You may have to cluster if you want to support 23,000 concerrent users at a peak. So I would build the system with a JSP front end. A controller that communicates to a Session Facade, even though it is a small simple application. The Session Facade wraps a POJO backend such as Hibernate.
  3. Hi Karthik,

    [adding to Matthew's comments]

    If you go with a clustered environment with Hibernate check out the Coherence/Hibernate plugin to cluster the second level Hibernate cache. This will add clustered reliability and fault tolerance to your implementation.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  4. Spring is an excellent alternative to local SLSBs in such an application. You get declarative transaction management, and instance pooling if you need it. (Often you're better with a threadsafe service object, as this is often how things fall out naturally if that object is stateless.)

    As Rob pointed out, whether you need clustering is probably the key to scalability. Do you need to hold session state? Do you need to replicate cached data?
    To me the option of running of each instance of a servlet on a different thread is defintely is the less scalable of the architectures.
    I'm not quite sure what you're getting at here. If you mean single thread model, I don't recommend it, and it's deprecated in Servlet 2.4.

    Rod Johnson
    Spring Framework
    Author, J2EE without EJB
  5. guys,

    this is an interesting thread - somewhat similar to another one I've got open on TSS.

    I'm toying with the idea of using Hibernate (specifically the Coherence/Hibernate engine) with large web based application. It doesn't pose as many concurrent users as the original poster (more like 7500-10000). Current paradigm is that the app is using native JDBC via Websphere connection managers, and we implement DAO's for persistance interface. Our transaction rate to the DB (and Oracle 9i RAC cluster) will be around the 80-120 sql statements per second and a fairly complex data model. Whilst trying hard to avoid the open ended question (and resulting answer of "how long is a piece of string"), in your experience with Hibernate and or Coherence/Hibernate, how does it scale for high query rate and fairly complex data schema based J2ee apps?

    Thanks in advance,

    a.
  6. Spring and Instance Pooling[ Go to top ]

    Spring is an excellent alternative to local SLSBs in such an application. You get declarative transaction management, and instance pooling if you need it. (Often you're better with a threadsafe service object, as this is often how things fall out naturally if that object is stateless.)As Rob pointed out, whether you need clustering is probably the key to scalability. Do you need to hold session state? Do you need to replicate cached data?
    To me the option of running of each instance of a servlet on a different thread is defintely is the less scalable of the architectures.
    I'm not quite sure what you're getting at here. If you mean single thread model, I don't recommend it, and it's deprecated in Servlet 2.4.Rod JohnsonSpring FrameworkAuthor, J2EE without EJB
    Hello Rod

    I was examining Spring if I can use it in a WebSphere AppServer in back end application (B2B) where we have to process messages from multiple sources and peform several business actions (work with multiple databases) based on the messages. The application has to scale upto double the volume every year in the next 3 years. We will use JMS based messaging as enterprise bus to perform updates to a legacy system too. We want to achieve scalability with clustering. How can I use Instance pooling of Spring framework in clustered environment?