This week's book giveaway is in the Beginning Java forum.
We're giving away four copies of Get Programming with Java (MEAP only) and have Peggy Fisher on-line!
See this thread for details.
Win a copy of Get Programming with Java (MEAP only) this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

tomcat middleware settings  RSS feed

Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I'm about to tune a Tomcat middleware server which needs to invoke a downstream call to another provider which takes approx. 100-150 ms to return.  I have a limited pool of downsteam connections.9

Limiting Tomcat connections to 50 and 250 threads, I've managed a load test of approx 60-75 transactions / sec, but surely this could be improved.

I was to gear up the service for maximum throughput and have wondered is anyone has done this before and can offer sggestions on to the server configuration?
Posts: 20149
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Matt!

I would think that the choke point isn't going to be Tomcat, but rather your limited number of downstream connections.

If you can only connect 9 requests at a time, then Tomcat is going to have to park further requests somehow. And I hope that you're not simply doing a wait() or spin operation until a downstream connection comes available!

A spin would be awful, since you're burning CPU to little purpose, but a wait is bad, too. Aside from the fact that it's expressly forbidden by J2EE standards, it locks up the thread running the request, which can thus back up the request thread pool, and eventually the input connection pool. Expanding those parameters simply allows the backup to spread even further, not increase your throughput rate.

So if you must park requests, consider queuing them instead. Using the ServletContextListener you can create an "engine" at application start-up time and by sharing a (synchronized) queue with the servlets, servlets can dump requests into the engine queue and query the engine to see when they're complete. Normally this would be overkill for a turnaround of under 200ms, but I'm taking it as a given that the ACTUAL turnaround time is 100-150ms PLUS the amount of time spent waiting for an available downstream channel.

Also note that the "engine" can safely spawn sub-threads (as long as you clean them up at shutdown time!), so it's perfectly fine if you spawn 9 threads, each with an instance of a service class and have them pull requests from the engine's request queue.
matt andrews
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Many thanks for the suggestion.

Reading up on the technique, it may be just what I require.
You’ll find me in my office. I’ll probably be drinking. And reading this tiny ad.
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!