Welcome!

Microservices Expo Authors: Pat Romanski, Gopala Krishna Behara, Sridhar Chalasani, Tirumala Khandrika, Elizabeth White

Blog Feed Post

Getting the maximum performance of your Java processes

therore-concurrent provides self-tuning thread-pools helping you to make the most of your system.

Recently, I have been working in the optimization of an OLTP system. The software has a SEDA architecture (Staged Event Driven Architecture) with lots of threads doing little works. I had to fight with the hard task of adjusting a hundred of parameters. Each of those parameters affected some others and so on.

For example if the number of concurrent database connections is set too low, it would cause a contention in getting connections. On the contrary, if that number is set too high, it could cause a lock-contention in the database when the threads want to access to some shared resources (index, row, block, etc.)

Even more, not always the processing of an event requires the same type of resources. A sudden change in the type of events that are being treated, can turn an optimal configuration into a suboptimal.

One of the most significant parameters is the number of threads assigned for each component. It is difficult to choose a good value if you don’t know how much the threads use each type of resource and how much are they coupled between each other.

Usually certain tasks have a higher priority and should be processed as soon as possible. This further complicates the choice of the configuration. Enforcing priorities and maximizing throughputs are opposite goals therefore it is necessary to define the scope of both.

In my experience a huge configurability can work against you. In a medium/big SOA system with a lot of service communications and complex workload profiles that even change over time, is almost impossible to get the optimal value for each of those parameters. Because of that I found interesting to develop a library that might be able to adapt quickly at runtime in order to make the most of the system.

Self-tuning thread-pool

Nowadays creating threads manually is not very common. Instead of that, thread-pools are frequently used. A thread-pool manages the creation and allocation of threads. JDK comes with some interesting and useful classes for managing threads. I list two of the most important:

  • ThreadPoolExecutor is a very flexible and configurable thread-pool that supports customization of queue size, minimum and maximum pool size, keep-alive time, etc.
  • Executors is a convenient class that creates thread-pools for the most usual cases.

I have developed the library therore-concurrent that takes advantage of those classes and extends some functionalities. The library contains analogous to the above classes.

  • SelfTuningExecutorService is a thread-pool that implements a mechanism for searching a good value for the pool size. The algorithm tries to maximize the throughput respecting the thread-pool priorities.
  • SelfTuningExecutors acts as the factory of SelfTuningExecutorService. It is recommended to use it as a singleton.

The following charts show how quickly SelfTuningExecutorService finds the optimal value.

selftuning_poolsize_executions_chart

Using SelfTuningExecutors directly

  • Add the dependency to the pom
  • <dependency>
        <groupId>net.therore</groupId>
        <artifactId>therore-concurrent</artifactId>
        <version>1.1.0</version>
    </dependency>
    

  • The following snippet shows how can it be used.
  • SelfTuningExecutors executors = SelfTuningExecutors.defaultSelfTuningExecutors();
    ExecutorServicce service = executors.newSelfTuningExecutor("executor-for-test", corePoolSize, initPoolSize
           , maximumPoolSize, priority, queueSize);
    service.execute(task);
    

The only new parameters are initPoolSize and priority.

  • initPoolSize is the initial amount of threads assigned to the pool.
  • priority is a positive number that works for SelfTuningExecutorService to limit the number of threads of this pool regarding others.

Integrating SelfTuningExecutors with Quartz Scheduler

Quartz-Scheduler has his own thread-pool interface and its name is “ThreadPool” (not surprise). The class SelfTuningThreadPool that is in the artifact therore-concurrent-quartz implements such interface. Integrating it is very easy, follow these steps:

  • Add the dependency to the pom
  • <dependency>
        <groupId>net.therore</groupId>
        <artifactId>therore-concurrent-quartz</artifactId>
        <version>1.1.0</version>
    </dependency>
    

  • Change the configuration properties of quartz
  • # org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
    # org.quartz.threadPool.threadCount = 1
    # org.quartz.threadPool.threadPriority = 5
    org.quartz.threadPool.class = net.therore.concurrent.quartz.SelfTuningThreadPool
    org.quartz.threadPool.corePoolSize = 1
    org.quartz.threadPool.initPoolSize = 1
    org.quartz.threadPool.maximumPoolSize = 100
    org.quartz.threadPool.priority = 5
    org.quartz.threadPool.queueSize = 2
    

Integrating SelfTuningExecutors with Apache Camel

I love Apache Camel. It offers a lot of components supporting integration with different technologies. But if none of them actually help you yet, it’s pretty easy to make your own component.

Camel’s team has thought very well the threading model. They use the concept (and interface) of ThreadPoolProfile which is a kind of thread-pool-template that you can use to instantiate several pools with the same configuration. If that is not enough, you can program your own implementation of ExecutorServiceManager, the Camel’s thread-pool provider. Simplifying, think about it like the Executors class of the JDK.

I’ve just done that, SelfTunigExecutorServiceManager is the name of my own implementation of ExecutorServiceManager. It is located in other maven module therore-concurrent-camel. I’ll explain how to use it.

  • Add the dependency to the pom
  • <dependency>
        <groupId>net.therore</groupId>
        <artifactId>therore-concurrent-camel</artifactId>
        <version>1.1.0</version>
    </dependency>
    

  • The following snippet contains two connected routes with SEDA component and SelfTunigExecutorServiceManager
  • SelfTunigExecutorServiceManager executorManager = new SelfTunigExecutorServiceManager(context);
    context.setExecutorServiceManager(executorManager);
    ThreadPoolProfile profile = new ThreadPoolProfile();
    profile.setId("self-tuning-profile");
    profile.setMaxPoolSize(100);
    profile.setMaxQueueSize(100);
    profile.setDefaultProfile(true);
    executorManager.setDefaultThreadPoolProfile(profile);        
    
    final String sedaEndpointUri = "seda:myseda?blockWhenFull=true&size=1";
    context.addRoutes(new RouteBuilder() {
       @Override
       public void configure() throws Exception {
           from("direct:in")
           .to(sedaEndpointUri);
       }
    });
    context.addRoutes(new RouteBuilder() {
       @Override
       public void configure() throws Exception {
           from(sedaEndpointUri)
           .threads(1, 100)
           .to("bean:mybean");
       }
    });
    
    ProducerTemplate template = context.createProducerTemplate();
    context.start();
    for (int i=0; i<ITERATIONS; i++) {
       template.sendBody("direct:in", "dummy string");
    }
    

Summary

I have figured out that there are many elements that might turn into selftuning ones. I chose ThreadPool because from my point of view is one of the most important, used and easy to test element.

Moreover, most of the modern libraries and frameworks feature different ways to extend their factories, providers and templates. All of that aims to develop general purpose classes and integrate them with lots of frameworks.

Read the original blog entry...

More Stories By Alfredo Diaz

Alfredo Diaz is a Java EE Architect with over 10 years of experience. He is an expert in SOA, real-time processing, scalability and HA. He is an Agile enthusiast.

Microservices Articles
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
As Enterprise business moves from Monoliths to Microservices, adoption and successful implementations of Microservices become more evident. The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Documenting hurdles and problems for the use of Microservices will help consultants, architects and specialists to avoid repeating the same mistakes and learn how and when to use (or not use) Microservices at the enterprise level. The circumstance w...
More and more companies are looking to microservices as an architectural pattern for breaking apart applications into more manageable pieces so that agile teams can deliver new features quicker and more effectively. What this pattern has done more than anything to date is spark organizational transformations, setting the foundation for future application development. In practice, however, there are a number of considerations to make that go beyond simply “build, ship, and run,” which changes how...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
Adding public cloud resources to an existing application can be a daunting process. The tools that you currently use to manage the software and hardware outside the cloud aren’t always the best tools to efficiently grow into the cloud. All of the major configuration management tools have cloud orchestration plugins that can be leveraged, but there are also cloud-native tools that can dramatically improve the efficiency of managing your application lifecycle. In his session at 18th Cloud Expo, ...
Traditional IT, great for stable systems of record, is struggling to cope with newer, agile systems of engagement requirements coming straight from the business. In his session at 18th Cloud Expo, William Morrish, General Manager of Product Sales at Interoute, will outline ways of exploiting new architectures to enable both systems and building them to support your existing platforms, with an eye for the future. Technologies such as Docker and the hyper-convergence of computing, networking and...
"We do one of the best file systems in the world. We learned how to deal with Big Data many years ago and we implemented this knowledge into our software," explained Jakub Ratajczak, Business Development Manager at MooseFS, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Containers, microservices and DevOps are all the rage lately. You can read about how great they are and how they’ll change your life and the industry everywhere. So naturally when we started a new company and were deciding how to architect our app, we went with microservices, containers and DevOps. About now you’re expecting a story of how everything went so smoothly, we’re now pushing out code ten times a day, but the reality is quite different.
Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...