Hi all, I haven’t posted here much in the past couple of years. I pretty much lost the game dev itch and started working on some mISV projects and also switched jobs a while back. Now I’m doing J2EE development. Turns out that EJB 3 and JPA make J2EE a lot easier than I ever expected. Well, deceptively easy I guesss, as there seem to be a lot of ‘gotchas’. I think there are some experienced J2EE people posting here so I thought I’d bother you all with some questions. Hopefully this can turn into a general tips and tricks thread.
How do you write/execute tests J2EE applications running in the application server?
How do you perform load testing on your applications?
Do you use stateful beans? If so why or why not?
How do you monitor system performance?
Do you use continuous integration to auto run tests?
(note here I’m referring to mainly the backend: ejbs and entities) At this company I’m with we don’t do any of these; no tests because it’s too hard to manually build complicated business entities for the tests, and where to run them? Externally connecting to the app makes it impossible to test code internal to the application.
No load testing because the ui change pretty constantly so they’re difficult to automate.
One stateful bean but it’s a heavy weight and the source of a lot of performance issues.
Performance monitoring is watching the jboss console and ‘omg data source connections are maxed out!!!’
No continuous integration because Eclipse builds everything.
The result is there are a lot of phantom performance issues that no one know how to fix so they end up throwing servers at it. How does this all jive with your experiences?
[quote]How do you write/execute tests J2EE applications running in the application server?
[/quote]
I write them using Eclipse+Maven2.
Testing can be done via junit tests (though only as a simple test) and then inside the containers:
using a client to interface with it and run the tests
using mbeans as web interfaces
[quote]How do you perform load testing on your applications?
[/quote]
… just create load, like by starting the test client multiple times.
[quote]Do you use stateful beans? If so why or why not?
[/quote]
Depends on if you need the statefulness or not.
For a webapp, yes, I do.
[quote]How do you monitor system performance?
[/quote]
JBoss has some built in info you can use to monitor.
[quote]Do you use continuous integration to auto run tests?
[/quote]
Maven has Junit tests but they can only do the ‘light’ tests as noted above.
Well you can do light tests as noted above. F.i. just testing the basic signature and failproof parts of the code because the injected parts are not injected.
For everything else, you can just automate it externally:
create a script that will provide a clean AppServer, deploy your components in, start the server and then run the tests.
[quote]No load testing because the ui change pretty constantly so they’re difficult to automate.
[/quote]
Huh? The stateful/less Beans can also be accessed from the ‘outside’ via remote interfaces.
Just write up a remote interface, write up a client that does the correct calls and letter rip!
[quote]One stateful bean but it’s a heavy weight and the source of a lot of performance issues.
[/quote]
Then ask yourself, why is your SSB so heavy weight?
How can you trim it down?
[quote]Performance monitoring is watching the jboss console and ‘omg data source connections are maxed out!!!’
[/quote]
[quote]No continuous integration because Eclipse builds everything.
[/quote]
Never depend on the IDE to do your building for you.
I suggest using Maven (with plugin for Eclipse) + Hudson for CI and other features.
[quote]The result is there are a lot of phantom performance issues that no one know how to fix so they end up throwing servers at it. How does this all jive with your experiences?
[/quote]
Yep, people do not know what is going on, so they do something to make it look like they know WTF they are doing.
The place I work at is doing the same, though my efforts against it is slowly penetrating the fog.
I’d take a step back and re-evaluate your set-up and design.
Often stuff is presumed in the beginning and then reality strikes.
Not to mention the architects/designers/developers should at least know something about what they are working with.
If I were you, I’d start out by adding in testing interfaces on each layer to determine where the issues are coming from.
Something simple I do is to add remote interfaces for all local ones (though remote does cost performance, though it is negligible).
Also you can add MBeans that provide web interfaces via the jmx-console to do simple http based tests.
Put all these in a 2nd ear you deploy after the first, so that they can be added and removed on demand.
We use “The Grinder”. Bit annoying to get going, but pretty simple after that. It runs processes on multiple machines and plays back recorded Jython scripts. There is a proxy so you can just click around your website with the browser pointed at the proxy and it records a script that when played back makes the same HTTP requests, including pauses between them. We also use Grinder on the machines being tested, but there the Jython script logs a timestamp, CPU, memory, etc. We use Pnuts script to parse the resulting data into a format suitable for gnuplot, which makes pretty charts.
This boring ass shit is why I make games in my free time.
Great responses, thanks! I spent a lot of time trying to do ‘out of container’ testing. The problem with testing ejbs is that the container wraps the beans and with EJB 3, performs dependency injection based on annotations. One thing I tried was to set up OpenEJB to run in a JUnit test. It worked great for simple ejbs, although start up time was a little slow. There were some problems: the jndi lookup name generated by OpenEJB differed from JBoss, so I would have had to change all of the @Mapped annotations to @EJB. For production code this wasn’t desirable at the time. Another option was EJB3Unit, but I ran into problems with it too (that don’t remember now).
I stumbled across Arquillian the other day to do in-container tests for JBoss: http://community.jboss.org/docs/DOC-14376
I haven’t had the opportunity yet to give it a full test drive but it looks pretty promising.
The thing that impacts performance for our application the most is by far the database: some poorly written queries, joined views, slapping indexes on just about everything, bad caching, etc. really slows stuff down.
We have a manager here who thinks that when you just throw an index on every column of a table, stuff speeds up. But unfortunatly, the more indices you have, more work needs to be done when you insert, update and delete records, slowing that process down.
@Tunedbeats:
Oh, that is what you mean. I thought adding indexes to tables.
I honestly have to fight with developers who are against adding ids to tables and instead do reference-by-name. Naturally it is the REAL name of the object like ‘My Little Pony’ and if you change the name, guess what …
Sadly I fear they have not yet figured out why this is bad.
