2 Replies Latest reply on Jan 7, 2009 7:55 PM by dknox

    Isolating web applications performance in JBoss Web Server

    xcenogar

      Hi all

      I am searching for the best way to isolate the performance of different web applications (contexts) running on the same JBoss Web Server. The objective is to avoid that multiple and heavy requests performed against one web application provoke the server to get overloaded, and therefore, the rest of the applications to perform poorly.

      In IIS6.0 (we are migrating from IIS6.0 to JBoss Web Server) there is a concept called Application Pool. Each Application Pool defined in the IIS runs in its own worker process, so errors in one Application Pool will not affect the applications running in other Application Pools. For example, the amount of CPU usage is configurable separately for each Application Pool. And web applications that belong to different Application Pools can run on the same TCP port.
      We have not found an equivalent concept in Tomcat/JBoss Web Server.

      We will appreciate any kind of suggestion.
      Thanks in advance

        • 1. Re: Isolating web applications performance in JBoss Web Serv
          peterj

          There is no such concept in Tomcat/JBoss Web. All web apps run in the same JVM (hence in the same process) and there is no mechanism to provide priority or throttling of requests on a web app basis.

          • 2. Re: Isolating web applications performance in JBoss Web Serv
            dknox

            Request handling starts in the Connector and is configurable in server.xml. The Connector has properties e.g., port and thread pool metrics. If one webapp supports long-lived requests starving other requests from obtaining a thread, you can adjust the thread pool metrics to avoid starvation.

            If you want to isolate the applications to avoid thread contention the best way is to deploy two distinct instances of JBossWeb. These days that's fairly easy to do using virtualization.

            Another possibility - configure an additional HTTP Connector to listen on a unique port. The additional connector as its own thread pool by definition.