3 Replies Latest reply on Oct 5, 2010 6:39 AM by lvdberg

    an we rely on JBoss Seam to support heavy load calls ?

    walidkarray
      Hi,
      We want to test the scalability of JBoss Seam by sending successively HTTP GET requests to the same URL.

      Test case 1:
      We have created a simple Seam application and we have added test.xhtml that return a blank page.

      Target URL: http://serverhost:8080/SeamLoad/test.seam
      Threads: 1
      Invocation count: 10000

      Result:

      Test duration: ~ 8 minutes
      Throughput: 19.8/seconds

      => As you can see this test has took about 8 minutes to finish with a throughput average of 19.8/seconds.

      Test case 2:
      We just renamed "test.xhtml" to test.html of the last project to bypass Seam framework, it's now a JSF project

      Target URL: http://serverhost:8080/SeamLoad/test.html
      Threads: 1
      Invocation count: 10000

      => Result:

      Test duration: ~ 46 seconds
      Throughput: 217/seconds

      => As you can see this test has took about 46 seconds to finish with a throughput average of 217/seconds.


      How can you explain that the first test is 11 times slower than the second test ? Can we rely on JBoss Seam to support heavy load calls ?

      Note: For the stress test simulation tool we have used the latest version of Apache JMeter.

      * Software environment:
      --------------------------
      - Operating system: Redhat Enterprise Edition 5 (64 Bits)
      - JVM: OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
      - JBoss EAP 5.0.0 (Intgrate JBoss ESB 4.8)
      - JBoss Seam 2.2
      - IDE: JBoss developer sutdio 3.0

      * Hardware environment:
      --------------------------
      - Server HP ProLiant DL320 G6,
      - CPU: Intel(R) Xeon(R) CPU 5520 @ 2.27GHz x 8 (8 Core) [64 Bits],
      - Memory: 12 GB,
      - 500 GiB HDD.
        • 1. Re: an we rely on JBoss Seam to support heavy load calls ?
          lvdberg

          Hi,


          I think that in the secons case it is a simple static page, so it is not even processed by JSF (because it's a blank page). I think you need some content to process and than compare Seam with JSF.


          Leo

          • 2. Re: an we rely on JBoss Seam to support heavy load calls ?
            walidkarray

            Thanks Leo four your fast reply,


            This is the content of test.htm :
            ------------------------------------



            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
            <html xmlns="http://www.w3.org/1999/xhtml" 
                  xmlns:ui="http://java.sun.com/jsf/facelets" 
                  xmlns:h="http://java.sun.com/jsf/html" 
                  xmlns:f="http://java.sun.com/jsf/core">
            
            </html>
            





            This is the content of test.xhtm :
            ------------------------------------




            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
            <html xmlns="http://www.w3.org/1999/xhtml"
                  xmlns:h="http://java.sun.com/jsf/html"
                  xmlns:f="http://java.sun.com/jsf/core"
                  xmlns:ui="http://java.sun.com/jsf/facelets">
            
             
            </html>






            Regards.

            • 3. Re: an we rely on JBoss Seam to support heavy load calls ?
              lvdberg

              Hi,


              I am sure both files are the same, the thing you should check is what happens when you request the page. In the first case the whole Seam process is triggered because your rquest (ending in .seam) implies that. In the second case, you just ask an empt html-page, so I wonder if the JSF processing is triggered, because you just ask for a resource and, because there is nothing to process it is just returning at lightning speed an empty page.


              That's my remark. Give both something to do and try again.



              Leo