Discussions

Performance and scalability: how to reduce I/O activities with JBoss

  1. how to reduce I/O activities with JBoss (2 messages)

    Hi All Jboss/EJB guru

    It is highly appreciated somebody can advice me on how to configure JBoss to reduce I/O activities. Below is the info of my ejb app.

    JBOSS 2.4.4 + Tomcat 3.2.3 + Win 2000 server + Apache 1.3.

    When there are multiple concurrent users(~5-10) accessing my ejb app, l find that the I/O activities of the JVM surge and the response of my EJB app is very slow. And in general, my app follow quite closely the ejb design patterns suggested by sun's petstore.

    It is very thankful if someone can suggest to me
    1) how to configure jboss to reduce I/O activities
    2) advice me on some effective approaches to identify which part of my ejb app bring to the fierce I/O activities. For,e.g how can l monitor the I/O activites of stateful / stateless / entity bean in JBoss (use print statement or what ???).
    3) Share with me, in general, what bad practice can cause high I/O activites in EJB app

    thanks a ton !
    dso
  2. 1) Minimize remote calls

    2) Do not do new InitialContext() from a client app every time you want a reference to an EJB; get the EJBHome you need and create EJB instances from it when necessary.

    3) Use STATELESS session beans; make all the efforts you can for this to be possible. If you need to keep state, try using some kind of session identifier object that you transmit at every method call.

    4) Transfer logic on the client-side; do not give your clients direct access to the session beans. To do so, wrap your session beans in local, client-side objects and put some business logic in these objects - rather than delegating everything to the remote.

    5) Make sure all caching/pooling config params are properly set-up.

    And what else...??? That's a start anyway...
  3. 4) Transfer logic on the client-side; do not give your

    > clients direct access to the session beans. To do so,
    > wrap your session beans in local, client-side objects and
    > put some business logic in these objects - rather than
    > delegating everything to the remote.

    Actually, I don't think this will reduce in less network traffic, as all business logic wants to operate on some business data (querying, manipulating, persisting it).

    If I get it right, the whole idea of app servers is that the most of the data stays on the middle tier. (Unless being displayed, but usually you wouldn't want to display all the data, would you?)

    In my book, session beans are designed for business operations, as all data is local for them, and we want a client as thin as possible.

    Disagree?

    I got some more ideas:

    6) Use fine grained DTOs.

    7) Be sure to give your VM enough memory allowance with the -Xms and -Xmx switches. The defaults used are very conservative to say the least.

    8) Be sure to have enough RAM in your box for 7 :o) to avoid endless swapping, especially if you...

    9) Think of disabling passivation. That's done by using the org.jboss.ejb.plugins.NoPassivationCachePolicy instead of any LRU*ContextCachePolicy classes.

    10) Disable all logging.

    11) Look at your SQL, if using BMP. If not, use your DB vendors tool to look at the SQL queries reaching the database. Maybe you find some beans where JAWS generates stupid SQL, which can be implemented better using BMP.

    Hope this helps,
    Lars :o)