Code using PreparedStatement.executeUpdate failing in stress test

Question

Hello,
I've just recently learned how to use J-Meter and have been performing tests on my programs. One of which performs the following:
1. Read user data using a simple SELECT password FROM users where userid = 'xxx'
2. When authenticated, runs an immediate update using value binding via PreparedStatement.executeUpdate() which is really just updating the lastlogin column of the same table with the current date.
My application servlet is running on Glassfish and uses a jdbc connection pool defined on it. The problem is that at about 200 concurrent executions per second of the process described above, PreparedStatement.executeUpdate() returns 0 instead of 1 at around 20% of the time. The Glassfish server is on a Sunfire X2100 platform running solaris 10 and has 2 gb ram, while the database on the other end is a Oracle 10G R2 on a PC clone Pentium 4 with 512mb ram also running on Solaris 10.
This failure rate is too high so what can I do to reduce it?
Thanks in advance,
- Owen

Answer 1

Owen_Ilagan wrote:
Hello,
200 per second? That's a pretty decent load. Well, I was told that that was the acceptable load for the same app running on a standard pentium 4 machine I don't see how you can talk about "acceptable load" for a given piece of hardware without taking into consideration what the application is doing. A read-mostly web app will be very different from one that's transaction and/or computation intensive.
so I would like to get better performance from this Sunfire X2100. Unless of course that figure is wrong... I've just recently started learning to scale my java applications and figuring out how to fine-tune the servers my programs would be running on. I think this is a good article:
http://www.javaworld.com/javaworld/jw-06-2006/jw-0619-tuning.html?page=1
I don't know where that setting is on Glassfish so its on default. Is there an optimal setting for it? I run JMeter on a different machine. Good - your clients aren't competing for memory with the server that way.
Again, I dont seem to recall seeing a setting like that on Glassfish. The current pool setting is at Initial size 8, maximimum size of 32. I already tried increasing it to 200+ but there was no noticeable improvement so I set it back to 32. That's sufficient. You don't need 1 connection per user because of the pool. I use 5:1 as a rule of thumb.
Threads in my worker pool? Hmmm, let me just clarify that I'm running a rather simple web servlet application using the 1.5 SDK and its not a full-blown EE application. Doesn't matter. There is one thread per incoming request. If the worker thread pool is exhausted the requests are queued up. There's an optimal setting for that, too.
Well, I dont run into any SQL errors so there is no stack trace to log. Huh? You mean your PreparedStatement can return 0 and not have an exception?
What happens if you try to UPDATE a user record that isn't in the database? Is that possible?
When PreparedStatement.executeUpdate() is called, it returns 0 instead of 1. I did put the call inside a try-catch to handle java.sql.SQLExceptions but its not throwing one.Interesting. See question above.
I hope so.Difficult, but you sound like you're doing a rigorous job.
%