There is a very nice overview of exactly what Glassfish (and indeed what an application server in general) is here: https://glassfish.dev.java.net/faq/v2/GlassFishOverview.pdf
If you are new to Glassfish, or just wondering what it can do, this is a good place to start.
Sunday, June 24, 2007
Sunday, June 10, 2007
Glassfish...Summing it Up
I've been using Glassfish for about a year now and its cousin the Sun Java System Application Server for several years prior to that and have noticed a steady improvement in the product. Some of the nice things about Glassfish include:
1) Support for leading edge technology like EJB 3
2) Nice GUI for administration
3) Price :)
4) Good user community (see link to the right for home page)
5) Support for clustered environments
6) Relative ease of use (due in part to the GUI)
7) Very nice logger...it even has some graphic capability in Log Statistics :)
8) Stability of the actual application server (not necessariliy the admin console...read on) is very good with the later versions like the one tested. In fact, I cannot remember having any problems with and vesion of Glassfish after build 33 with respect to up time during my load tests.
All things considered, Glassfish proves to be a very capable Java application server. There are some things that can be done to make it even better though. First, as with all software of this magnitude, there are a few bugs to be ironed out here and there. The Glassfish community does a good job with this, but a couple items I noticed for this latest build include:
1) Problem with Help Search. Typing in JDBC then clicking Search for example yielded no results.
2) As mentioned in a prior blog post, there are some instances where drop down boxes were not populated...having them deactivated may make more sense.
3) Missing System Properties icon (no biggy obviously)
4) Clicking on Admin Service under Configuration logged me out. This only happened once (the first time) but I am certain it was not due to a time out as I had just clicked on Connector Service before that and received a response. This also happened the first time I clicked on Security->Realms and Connectors.
There are also some things that I would like to see added/changed to Glassfish. Those include:
1) Snap points in logs. What I mean by this is to give the admin the ability to click a button and have the log insert some sort of marker. This is useful when changing setting or running tests. You might give them the ability to add text to the marker. For example: <<<<<<< MARKER: Test new connection Pool >>>>>>>
2) Snap point in configuration with comparison utility. This would allow administrators the ability to roll back changes much more easily and to see what was changed and when it was done. It would also be nice to be able to see performance characteristics tied to these changes. In other words, have the configuration changes add markers that can be seen in the monitors.
3) When running on Windows, there are some Unix specific items that should be greyed out or not displayed. Example: Logging->Write to System Log to use Unix syslog service.
4) The ability to configure email alerting based on application and log level.
5) The ability to tune the application server based on anticipated usage. For example, I noticed in my performance testing that this version of Glassfish produced better results for smaller sized data packets than build 36, but that build produced better results for larger sized packets. That made me wonder if it might be possible to allow tuning at least at the install level. If it could be done at the application level, all the better!
6) Although the help system (aside from the bug I mentioned) is very good, a printed manual that gave detailed information and good real world examples would go a long way in helping the adoption of Glassfish IMHO.
Aside from these wants and minor bugs, when it comes down to the ability of Glassfish to do what it needs to do easily, efficiently, and reliably, I think Duke says it best:
1) Support for leading edge technology like EJB 3
2) Nice GUI for administration
3) Price :)
4) Good user community (see link to the right for home page)
5) Support for clustered environments
6) Relative ease of use (due in part to the GUI)
7) Very nice logger...it even has some graphic capability in Log Statistics :)
8) Stability of the actual application server (not necessariliy the admin console...read on) is very good with the later versions like the one tested. In fact, I cannot remember having any problems with and vesion of Glassfish after build 33 with respect to up time during my load tests.
All things considered, Glassfish proves to be a very capable Java application server. There are some things that can be done to make it even better though. First, as with all software of this magnitude, there are a few bugs to be ironed out here and there. The Glassfish community does a good job with this, but a couple items I noticed for this latest build include:
1) Problem with Help Search. Typing in JDBC then clicking Search for example yielded no results.
2) As mentioned in a prior blog post, there are some instances where drop down boxes were not populated...having them deactivated may make more sense.
3) Missing System Properties icon (no biggy obviously)
4) Clicking on Admin Service under Configuration logged me out. This only happened once (the first time) but I am certain it was not due to a time out as I had just clicked on Connector Service before that and received a response. This also happened the first time I clicked on Security->Realms and Connectors.
There are also some things that I would like to see added/changed to Glassfish. Those include:
1) Snap points in logs. What I mean by this is to give the admin the ability to click a button and have the log insert some sort of marker. This is useful when changing setting or running tests. You might give them the ability to add text to the marker. For example: <<<<<<< MARKER: Test new connection Pool >>>>>>>
2) Snap point in configuration with comparison utility. This would allow administrators the ability to roll back changes much more easily and to see what was changed and when it was done. It would also be nice to be able to see performance characteristics tied to these changes. In other words, have the configuration changes add markers that can be seen in the monitors.
3) When running on Windows, there are some Unix specific items that should be greyed out or not displayed. Example: Logging->Write to System Log to use Unix syslog service.
4) The ability to configure email alerting based on application and log level.
5) The ability to tune the application server based on anticipated usage. For example, I noticed in my performance testing that this version of Glassfish produced better results for smaller sized data packets than build 36, but that build produced better results for larger sized packets. That made me wonder if it might be possible to allow tuning at least at the install level. If it could be done at the application level, all the better!
6) Although the help system (aside from the bug I mentioned) is very good, a printed manual that gave detailed information and good real world examples would go a long way in helping the adoption of Glassfish IMHO.
Aside from these wants and minor bugs, when it comes down to the ability of Glassfish to do what it needs to do easily, efficiently, and reliably, I think Duke says it best:
Saturday, June 09, 2007
Glassfish Performance
A while back I wrote a test application that pits CORBA (using Java's ORB), EJB 3.0 (using Glassfish), and sockets against one another. For the EJB 3.0 test, this involves accessing stateless session beans on the server.
The client is a fairly simple application that spawns a given number of threads where each one requests data of varying size from the server. The client threads each do this as many times as they can in a given interval and then the results are tallied. The interval is broken down into two parts. A warm up period and a actual period. EJB in particular seems to show better results after a nice warmup period. I've run this test several times since early this year and have noted some steady improvement in the performance of Glassfish (the CORBA and the sockets test remained flat as their server side implementations did not change).
Here are the results for a relatively short test. Only the EJB results are provided as those are the ones we are interested in here. The sizes of data packets are dived into five categories:
TINY = 1000 bytes
SMALL = 5000 bytes
MEDIUM = 10000 bytes
LARGE = 20000 bytes
XLARGE = 50000 bytes
As a side note, Glassfish builds prior to 36 had a timeout problem (Exceeded 1,800,000 milliseconds) so you cannot run extended period tests on older versions.
On Glassfish 36
Thread_1 found 22159 warmup and 35631 actual Tiny datapoints
On Glassfish Build 41
Thread_2 found 23514 warmup and 38000 actual Tiny datapoints
Although many test runs need to be conducted to weed out anomalies, from this set of data we can see that the newer build clearly had an improvement in performance in Tiny, Small, and Medium packets. By the time we got to the large packets the old version was about as fast and even showed an edge in the XLarge performance criteria. Here it is graphically:
Hmmm...have the Glassfish folks done some tuning as of late? Might it be possible to someday set an option that allows you to tune your installation? For example, some applications deal primarily with returning small data packets of text based data while others deal in larger binary files (big images for example). If you knew the size of the data your app server dealt with, then perhaps there might be a way to tune this on an install by install basis.
When some more app servers suport EJB 3 (note that Oracle's does now as well), I'll run these tests again and pit Glassfish against them. From what I've seen with it so far though, my thought is that Glassfish will do more than hold its own...in fact, Glassfish may just have a little piranha in it and eat their lunch! We'll see.
Next time I'll go over some of the things I'd like to see added/changed to/about Glassfish.
The client is a fairly simple application that spawns a given number of threads where each one requests data of varying size from the server. The client threads each do this as many times as they can in a given interval and then the results are tallied. The interval is broken down into two parts. A warm up period and a actual period. EJB in particular seems to show better results after a nice warmup period. I've run this test several times since early this year and have noted some steady improvement in the performance of Glassfish (the CORBA and the sockets test remained flat as their server side implementations did not change).
Here are the results for a relatively short test. Only the EJB results are provided as those are the ones we are interested in here. The sizes of data packets are dived into five categories:
TINY = 1000 bytes
SMALL = 5000 bytes
MEDIUM = 10000 bytes
LARGE = 20000 bytes
XLARGE = 50000 bytes
As a side note, Glassfish builds prior to 36 had a timeout problem (Exceeded 1,800,000 milliseconds) so you cannot run extended period tests on older versions.
On Glassfish 36
Thread_1 found 22159 warmup and 35631 actual Tiny datapoints
Thread_4 found 19889 warmup and 31647 actual Tiny datapoints
Thread_0 found 20032 warmup and 31655 actual Tiny datapoints
Thread_3 found 22300 warmup and 35617 actual Tiny datapoints
Thread_2 found 20031 warmup and 31575 actual Tiny datapoints
Thread_0 found 11822 warmup and 18273 actual Small datapoints
Thread_1 found 12950 warmup and 19549 actual Small datapoints
Thread_4 found 11787 warmup and 18100 actual Small datapoints
Thread_3 found 13011 warmup and 19518 actual Small datapoints
Thread_2 found 11815 warmup and 18168 actual Small datapoints
Thread_3 found 6069 warmup and 9687 actual Medium datapoints
Thread_2 found 5692 warmup and 9080 actual Medium datapoints
Thread_4 found 5693 warmup and 9039 actual Medium datapoints
Thread_0 found 5699 warmup and 9084 actual Medium datapoints
Thread_1 found 6081 warmup and 9609 actual Medium datapoints
Thread_4 found 3268 warmup and 5399 actual Large datapoints
Thread_3 found 3300 warmup and 5507 actual Large datapoints
Thread_0 found 3222 warmup and 5392 actual Large datapoints
Thread_1 found 3329 warmup and 5460 actual Large datapoints
Thread_2 found 3263 warmup and 5361 actual Large datapoints
Thread_4 found 1377 warmup and 2233 actual XLarge datapoints
Thread_0 found 1370 warmup and 2227 actual XLarge datapoints
Thread_1 found 1373 warmup and 2225 actual XLarge datapoints
Thread_3 found 1382 warmup and 2219 actual XLarge datapoints
Thread_2 found 1358 warmup and 2226 actual XLarge datapoints
On Glassfish Build 41
Thread_2 found 23514 warmup and 38000 actual Tiny datapoints
Thread_4 found 23581 warmup and 37653 actual Tiny datapoints
Thread_1 found 24727 warmup and 39992 actual Tiny datapoints
Thread_3 found 24543 warmup and 40005 actual Tiny datapoints
Thread_0 found 23553 warmup and 38002 actual Tiny datapoints
Thread_1 found 12854 warmup and 19917 actual Small datapoints
Thread_2 found 12385 warmup and 19169 actual Small datapoints
Thread_3 found 12968 warmup and 19798 actual Small datapoints
Thread_0 found 12497 warmup and 19201 actual Small datapoints
Thread_4 found 12498 warmup and 19215 actual Small datapoints
Thread_2 found 6024 warmup and 9630 actual Medium datapoints
Thread_1 found 6256 warmup and 10028 actual Medium datapoints
Thread_3 found 6229 warmup and 10038 actual Medium datapoints
Thread_0 found 6101 warmup and 9615 actual Medium datapoints
Thread_4 found 6045 warmup and 9636 actual Medium datapoints
Thread_2 found 3238 warmup and 5392 actual Large datapoints
Thread_3 found 3369 warmup and 5678 actual Large datapoints
Thread_0 found 3224 warmup and 5395 actual Large datapoints
Thread_4 found 3237 warmup and 5372 actual Large datapoints
Thread_1 found 3353 warmup and 5622 actual Large datapoints
Thread_2 found 1288 warmup and 2114 actual XLarge datapoints
Thread_3 found 1333 warmup and 2154 actual XLarge datapoints
Thread_0 found 1293 warmup and 2123 actual XLarge datapoints
Thread_4 found 1289 warmup and 2128 actual XLarge datapoints
Thread_1 found 1324 warmup and 2170 actual XLarge datapoints
Although many test runs need to be conducted to weed out anomalies, from this set of data we can see that the newer build clearly had an improvement in performance in Tiny, Small, and Medium packets. By the time we got to the large packets the old version was about as fast and even showed an edge in the XLarge performance criteria. Here it is graphically:
Hmmm...have the Glassfish folks done some tuning as of late? Might it be possible to someday set an option that allows you to tune your installation? For example, some applications deal primarily with returning small data packets of text based data while others deal in larger binary files (big images for example). If you knew the size of the data your app server dealt with, then perhaps there might be a way to tune this on an install by install basis.
When some more app servers suport EJB 3 (note that Oracle's does now as well), I'll run these tests again and pit Glassfish against them. From what I've seen with it so far though, my thought is that Glassfish will do more than hold its own...in fact, Glassfish may just have a little piranha in it and eat their lunch! We'll see.
Next time I'll go over some of the things I'd like to see added/changed to/about Glassfish.
Sunday, June 03, 2007
Another helping of Glassfish...mmmm good stuff!
Today I'd like to work with some old things and some new...let's start out by configuring a database for use with Glassfish. In specific, I'll be adding a connection pool for SQL Server using a third party (jTDS) driver.
Here is the procedure
1) Unzip the driver.
2) Copy the jTDS.jar file to the Glassfish's lib directory.
3) If you haven't done so, add a database using in Enterprise Manager...for this test I called
it glassfishdb
4) Add logins as needed to have access to us the glassfishdb
5) Start Application Server as described in a prior blog entry. Note that if Glassfish is
already running then you will want to restart it so it will find the JDBC driver.
6) Open up the Sun Admin Console and log in.
7) Add a connection pool by clicking on Create New JDBC Connection Pool under Other Tasks then
follow this list:
a) Name = sqlserverproxy (or some name of your choice)
b) Resource Type = XADataSource (depends of course...)
c) Database Vendor = Microsoft SQL Server
Click Next (upper right)
d) Datasource Classname = net.sourceforge.jtds.jdbcx.JtdsDataSource
e) Description = Enter some description (SQL Server for Glassfish Test for example)
f) Check connection validation required
g) Servername = localHost
h) port = 1433 (SQL SErver default unless you have changed it)
i) Databasename = glassfishdb
j) User = the user you set up
k) Password = the password you gave the user
After that, click Save then click Ping to verify all is OK.
Note that if you have a question about any of the parameters mentioned here or those I did not specify (pool size for example), simply click Help (upper right hand corner) and Glassfish you tell you all you need to know about this page.
Once that part is complete, you'll want to add a JDBC resource. On the left hand pane, expand Resources, then expand JDBC Resources. On the right hand pane, click New. Give it some name (glassfishResoucePool for example) and select the connection pool name you set up in the prior step, add a description of your choice, then make sure the enabled box is checked.
That's all there is to it! The GUI steps you throught the process and provides assistance should you need it, and even allows you to verify connectivity (via the ping).
So good for the tried and true (this functionality is has been in Glassfish more or less unchanged for as long as I can remember), let's try something a bit newer next. I recall back in an earlier build of Glasssifh (circa b27-30) there was a problem getting web services generated through Netbeans to work due to a problem with Glassfish...let's see if this is still the case.
Following instructions at http://www.netbeans.org/kb/55/websvc-jax-ws.html I built and deployed a test web service (CalculatorWS). I then went into the Classfish Admin Console to see if it was successfully deployed and, hopefully as this did not work the last time I checked, test it out.
To do that, click on Web Services in the left hand pane and verify that ClaculateWS is there.
Click on the name to bring up more options. Here you will see a button labeled Test. This is the part that was missing/broken when I last tried but now it works great.
Click on Test and you will see that Glassfish brings up a little tester web page for you.
It even shows you the soap request and response (click add). Very nice!
Next week I'll try to test some of the performance improvements over prior versions. In build 33 I saw a substantial improvement for simple stateless session EJBs transporting data in packet sizes from 2 to 20K over build 27. Will the improvments continue?
Until next time then...
Here is the procedure
1) Unzip the driver.
2) Copy the jTDS.jar file to the Glassfish's lib directory.
3) If you haven't done so, add a database using in Enterprise Manager...for this test I called
it glassfishdb
4) Add logins as needed to have access to us the glassfishdb
5) Start Application Server as described in a prior blog entry. Note that if Glassfish is
already running then you will want to restart it so it will find the JDBC driver.
6) Open up the Sun Admin Console and log in.
7) Add a connection pool by clicking on Create New JDBC Connection Pool under Other Tasks then
follow this list:
a) Name = sqlserverproxy (or some name of your choice)
b) Resource Type = XADataSource (depends of course...)
c) Database Vendor = Microsoft SQL Server
Click Next (upper right)
d) Datasource Classname = net.sourceforge.jtds.jdbcx.JtdsDataSource
e) Description = Enter some description (SQL Server for Glassfish Test for example)
f) Check connection validation required
g) Servername = localHost
h) port = 1433 (SQL SErver default unless you have changed it)
i) Databasename = glassfishdb
j) User = the user you set up
k) Password = the password you gave the user
After that, click Save then click Ping to verify all is OK.
Note that if you have a question about any of the parameters mentioned here or those I did not specify (pool size for example), simply click Help (upper right hand corner) and Glassfish you tell you all you need to know about this page.
Once that part is complete, you'll want to add a JDBC resource. On the left hand pane, expand Resources, then expand JDBC Resources. On the right hand pane, click New. Give it some name (glassfishResoucePool for example) and select the connection pool name you set up in the prior step, add a description of your choice, then make sure the enabled box is checked.
That's all there is to it! The GUI steps you throught the process and provides assistance should you need it, and even allows you to verify connectivity (via the ping).
So good for the tried and true (this functionality is has been in Glassfish more or less unchanged for as long as I can remember), let's try something a bit newer next. I recall back in an earlier build of Glasssifh (circa b27-30) there was a problem getting web services generated through Netbeans to work due to a problem with Glassfish...let's see if this is still the case.
Following instructions at http://www.netbeans.org/kb/55/websvc-jax-ws.html I built and deployed a test web service (CalculatorWS). I then went into the Classfish Admin Console to see if it was successfully deployed and, hopefully as this did not work the last time I checked, test it out.
To do that, click on Web Services in the left hand pane and verify that ClaculateWS is there.
Click on the name to bring up more options. Here you will see a button labeled Test. This is the part that was missing/broken when I last tried but now it works great.
Click on Test and you will see that Glassfish brings up a little tester web page for you.
It even shows you the soap request and response (click add). Very nice!
Next week I'll try to test some of the performance improvements over prior versions. In build 33 I saw a substantial improvement for simple stateless session EJBs transporting data in packet sizes from 2 to 20K over build 27. Will the improvments continue?
Until next time then...
Subscribe to:
Posts (Atom)
