Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring 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
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

tomcat middleware settings

Posts: 10
  • 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?
Saloon Keeper
Posts: 22248
Android Eclipse IDE Tomcat Server Redhat Java 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: 10
  • 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.
They worship nothing. They say it's because nothing is worth fighting for. Like this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic