Search code examples
restjakarta-eeejbjms

Design factors that need to considered for application with very high Transactions Per Second (TPS)


I am about to work on an application that need to handle high transactions per second (around 5000). The application needs to provide REST interface, with server side technologies including EJB, JMS, Infinispan.

Could you please let me know briefly the best practices that need to be considered while designing the application that needs to handle high volume of requests. Also please point to some resources which give more information.

Some of the factors that comes to mind are

1. Asynchronous processing (Servlet 3.0) support for REST
2. Stateless, as suggested by JB Nizet
3. Optimizing Data access(Second level hibernate cache, Cache read only data, proper column indexing)
4. Queuing long running tasks (JMS)


Solution

  • A lot of it is going to come down to specifics, as @JBNizet said.

    How much hardware can you throw at the problem? Again, per @JBNizet, a stateless API scales really nicely in a cluster. Enough hardware can solve any performance problem - it becomes a cost tradeoff between solving performance in hardware vs. software.

    Can you design your resources so they are cache friendly? Anything you can cache will save you a boatload.

    Can you set up a reverse-proxy server like Squid to keep cached calls out of your data access layer?

    Absolutely look at configuring your L2 cache and optimizing your database access layer. You'll want to do some reading on caching in a cluster .. there are different ways to keep your clustered caches in sync.

    At a certain point, this becomes a a performance testing problem, too. Automate a suite of test calls to the API, hook up JVisualVM, and see where your bottlenecks are. Keep an eye on Hibernate, in particular. You may be better off in some cases with using custom SQL, especially if there are large differences between your data layer and your API layer.