JMJ CLOUD
  • Home
  • Projects
  • Blog
  • About Us
  • Contact Us

Our Blog

Tomcat Vs GlassFish (Which is faster for APEX and ORDS)

11/3/2016

7 Comments

 

Introduction

Picture
Running ORDS in standalone mode is not supported for production environments. This means you need to run ORDS in a J2EE Web Server. At time of writing, the three supported J2EE web servers are Weblogic, Tomcat and GlassFish. Of these, only Tomcat and GlassFish are Open Source (read free). Oracle's view on support is that it supports running ORDS on these web servers but does not support the web servers themselves. This means that if you have issues with ORDS on these servers you will have to prove ORDS is causing the issue and not the web server.

Picture
Having said that, both Tomcat and GlassFish are capable web servers and I have a number of customers that have been running ORDS on them in production for many years, without any issues.
When choosing between these web servers, I typically recommend GlassFish unless the client has a preference for Tomcat. This is based on my personal preference and ease of use as opposed empirical evidence. I decided it was time to run a performance test to see if one performed significantly better than the other.

Tests Performed

The goal of the speed comparison is to compare the two web servers under moderate loads. In view of this the tests are not overly complex or load intensive. The load will be generated from number of simultaneous 'users' and repetitions. The idea being to compare them not break them.

​APEX Page Render
A basic APEX public page with three regions. A region with a classic report, a region with 5 form fields and a static text region. This test is aimed squarely at how the web server handles APEX page requests. The test is run 25 concurrent threads and repeated 10 times for a total of 250 transactions. The siege (see below for details on siege)  command run was:
siege -c 25 -r 10 -d 0.1 -m "ApexDynamicPage" -f /home/ec2-user/siege/ApexDynamicPageURL.txt
Picture
APEX Page Used in Tests
ORDS REST Get Service
A basic GET service with the following SELECT (no OAUTH security enabled):

select owner,object_name
from   all_objects
where  object_type = 'SEQUENCE'
and    owner  = 'MDSYS'


This is the same SQL used in the APEX page. Under ORDS 3.X calling a REST service does not rely on APEX at all. This test is focused purely on throughput from a REST perspective. The test is run using 25 concurrent threads and repeated 10 times for a total of 250 transactions. The siege command run was:
siege -c 25 -r 10 -d 0.1 -m "ORDSRESTGet" -f /home/ec2-user/siege/ORDSRESTGet.txt

Minified CSS File
I used the minified version of the apex ui css 'apex_ui.min.css'. The file is located in the Apex images folder and referenced in the ORDS i.war file as: i/css/apex_ui.min.css. The file is 108,694 bytes. The test runs in 100 concurrent threads and is repeated 5 times for a total of 500 transactions. The siege command run was:
siege -c 100 -r 5 -d 0 -m "ApexStaticCSS" -f /home/ec2-user/siege/ApexStaticCSSURL.txt

​Static HTML File

I created a small static HTML file and placed it in the root of the respective web server. The file is 3,711 bytes. The goal of this file is raw throughput of the web server as APEX and ORDS are not involved in serving this page at all. The test is run 100 concurrent threads and repeated 5 times for a total of 500 transactions. The siege command run was:
siege -c 100 -r 5 -d 0 -m "StaticHTML" -f /home/ec2-user/siege/StaticHTMLURL.txt

Test Conditions

Servers
All of the servers used were running on the us-west availability zone on AWS. They were all running the AWS flavor of Linux except the DB Server which was running OEL.
  • DB Server - t2.large (2 cpu, 8gb Ram)
  • App Server - t2.small (1 cpu, 2gb Ram)
  • Test Server - t2.small (1 cpu, 2gb Ram)

​Software

I used the latest stable versions (at time of writing) of all the software involved (except the DB):
  • Database 12c (12.1.0.2.0)
  • ORDS 3.0.8
  • APEX 5.0.4
  • JDK8 (1.8.0_111)
  • GlassFish Server (Web Profile) V 4.1.1
  • Tomcat 8.56

Key Configurations

ORDS
  • jdbc.InitialLimit = 25
  • jdbc.MinLimit = 25
  • jdbc.MaxLimit = 25

GlassFish
  • Set logging level to WARNING
  • JVM Xms and Xmx = 1024MB
  • JVM -server option
  • Caching Off
  • Compression Off
  • Thread Pool Size = 100
  • max-connections = 100

Tomcat
  • Set logging level to WARNING
  • JVM Xms and Xmx = 1024MB
  • JVM -server option
  • Caching Off
  • Compression Off
  • Thread Pool Size = 100

Load Test Software

In order to eliminate network as much as possible, I did not want to install the load test software on my laptop. This ruled out desktop tools such as JMeter. In view of this I installed Siege on an AWS EC2 server in the same region as my App Server and DB Server. For a command line tool, Siege comes with a number of features included with a number of the more sophisticated tools. I used version 3.1.4 of Siege in my tests.

Test Method

  • Start GlassFish
  • Run each of the four tests (throw away results, server warmup)
  • Wait 1 Minute
  • Run the four tests twice, average the two results (document results)
  • Stop GlassFish
  • Start Tomcat
  • Run each of the four tests (throw away results, server warmup)
  • Wait 1 Minute
  • Run the four tests twice, average the two results (document results)

The Results

Thanks for sticking with me this far! I do believe, however, it is important to lay out the method I used so you can understand what was and what was not tested. This allows you to more easily apply the results to your situation. First of all, let's look at the raw results (winning metrics are highlighted in green):
Picture
Picture
Picture
Picture
Picture

Summary

As you can see, generally it was a pretty close race. This is not totally unexpected. For ORDS, these web servers are acting as a J2EE container and they are both using the exact same version of the Java JDK.

Apex Page
Generally Tomcat seems to be about 3% faster than GlassFish except for in the area of concurrency where the difference was only 1.45%.

REST Service
Again Tomcat is the victor, this time by a larger margin of around 7% for response time, elapsed time and transaction rate. The two are almost exactly matched for throughput (mb) and concurrency.

Compressed CSS
GlassFish fights back here with a significant win over Tomcat of between 12% and 15%. I believe this shows that GlassFish is much better at serving larger files (the css file is about 100k).

HTML File
Once again Tomcat wins by around 3% except for the area of concurrency where they are again almost exactly matched.

Overall
One deduction from the above (and I am sure you have your own) is that the two are very well matched except that Tomcat seems to be better at thread handling. What I mean by this is that it is getting through the volume of transactions and switching between them faster. But, when there is more work to do (in the case of the larger css file) GlassFish is performing better.

Conclusion

So which web server should you choose? Based on the results of my testing, while Tomcat seems to be generally slightly faster, there is really not much in it.

While not having a clear winner seems like a bit of a let down (it was for me), all is not lost. It does mean that I can now provide my 'client preference' advice with some empirical evidence to back it up. 
7 Comments
M link
11/16/2016 12:46:48 am

We have used Glassfish for two years, then we switched to TomCat mainly cuz TomCat enables us to do URL rewriting easily.
Check it here : <a href="https://famproperties.com/" target="_blank"> famproperties.com </a>. <br>
Also, unlike TomCat, Glassfish takes long time to deploy ORDS

Reply
Jon link
11/16/2016 07:15:34 am

Agreed, Tomcat is speedier in startup and loading ORDS. Also, good to know Tomcat is better at URL re-writes. I have often used Apache as a reverse proxy so have generally done URL re-writing there.

Reply
Shaun
12/5/2016 04:52:48 am

Is it possible to see the same test with tomcat behind Apache2 server? This could significatnly reduce the CSS timings as the caching will be handled by Apache??

Reply
Jonathan Dixon link
12/5/2016 06:21:38 am

Hi Shaun. I agree, I think Apache would improve the static file caching. Unfortunately I no longer have the test setup I had for this test to re-test with Apache. Good thought though.

Reply
YOUB AYOUB link
2/4/2017 09:38:53 pm

Thank you it's a very good and helpful testing.
Merci Mr.
Have a good luck in your next test :D between weblogic and tomcat why not ^^ i think weblogic it's the faster ;)

Reply
M
2/5/2017 07:48:07 am

I've tried web logic before. It is remarkably faster, but expensive.

Reply
Joddy Ed link
11/13/2019 07:30:51 am

We have used Glassfish for two years, then we switched to TomCat mainly because TomCat enables us to do URL rewriting easily.

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    RSS Feed

    Popular Posts

    - APEX Dog Food
    - Cloud ERP & APEX Mashup
    - Modernizing EBS with APEX
    - Easy APEX_WEB_SERVICE
    - Running APEX in RDS
    - ORDS What & Why?

    Categories

    All
    APEX
    AWS
    Fusion Cloud ERP
    INTEGRATION
    OCI
    ORDS
    PaaS
    RAD
    REST
    SOAP

    Archives

    January 2021
    October 2020
    September 2020
    June 2020
    May 2020
    April 2020
    February 2020
    January 2020
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    September 2017
    August 2017
    July 2017
    June 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016

Company

About
Contact
Blog
  • Home
  • Projects
  • Blog
  • About Us
  • Contact Us