Lessons in scaling
In my last post I wrote about some strange threading behavior in tomcat 6. After a couple weeks of struggling between iBatis, our app, our connection pool and even trying the NIO connector we finally narrowed it down to the connection pool.
For some unknown reason, DBCP wasn’t taking the connections back into the pool. The result was the thread that was using them would hang and eventually tomcat would hang. How on earth DBCP has lived as long as it has with this problem is beyond me. We tried everything, even manually pulling the connection out of iBatis and closing it. Nothing worked. I could get DBCP to lock up with a connection pool of 150 and a user load of 50. Go figure.
c3p0 to the rescue
Thankfully there is another popular connection pool out there and it is c3p0. We swapped it in nice and easy (thanks Spring!) and presto, all our troubles went away. I could even overload the app (more concurrent users than connections available) and it wouldn’t die. It got slow, but it wouldn’t die.
Thanks to my finding, we swapped out DBCP as the pool that ActiveMQ was using and solved a few problems there as well.
Now our bottleneck is the communication between the application and our search engine, SOLR. That is to be expected somewhat as it opens an HTTP connection. We use SOLR for more than search however, it is also our navigation engine by means of faceting so needless to say we make a lot of calls to it. A little caching will solve that problem though and should be fairly easy to implement.
What are the lessons learned?
Don’t think any piece of the puzzle is immune to being the problem. My initial thoughts were that since DBCP has been around so long it couldn’t possibly be the problem. I spent most of my time in iBatis since I was new to it and thought maybe we were just doing something wrong.
In the end we were able to run load tests that were several times the capacity that our old (current) site sees. A good sign indeed.
Two tools helped more than anything else. JMeter for our load testing and JConsole, the built in JMX application for monitoring. With JConsole it was easy to see what threads were being locked, what they were waiting on and how many threads were running. Very, very handy indeed.
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
replica designer handbags,provide you the best quality,selection and price you can only find in the top specialty stores,Keeping you abreast of the lastest trends and providing the convenience of shopping from home. replica handbags
replica handbags ,
You might also wish to have a look at BoneCP (http://jolbox.com) — my benchmarks show that it’s faster than both C3P0 and DBCP.
Cheers!
I always buy an essay and custom written essay about this good topic.
gemahrv0421
Replica Handbags
lOUIS VUITTON Handbags
Louis Vuitton handbags on sales $99 each one, buy now at
Designer Handbags on
sales
Nice post. ghd pink.This post is different from what I read on most blog. cheap ugg boots.And it have so many valuable things to learn. Evening gowns. Thank you for your sharing! Mother of bride dresses
Very happy I can comment here! Best wishes for this day. Thank you very nice article. Thank you for sharing Thank you very nice article. Thank you for sharing

Man, if I had known before that you were using DBCP I would have told you to replace that first. We found all kinds of nasty stuff (thread locks, pool leaks) in it when we were working through performance issues around the ‘04 or ‘06 mid-term election here at CNN. As soon as we found c3p0 we replaced it everywhere.