Ensure you know the server

When you will start to investigate your application performances, before or during profiling, it is therefore important to understand what the server does to know what you should expect in terms of performances. At runtime, the server is part of your application. This means that if the server has a bug (it is still a software like anyone, so it can have bugs or issues even if widely tested), or a performance bottleneck, you will directly be impacted.

Some servers can be embedded with your application, and some can't. Yet, in any case, you will need to ensure you validate your application as well (as your server) to fully understand your runtime and be able to have an impact on it if needed.

Here the choice of your server will be very impacting. You may need to ask yourself what to do in case the server has a bug or a performance bottleneck. In the following, you will find some criteria you can investigate before the benchmark or when starting the development:

Until recently, Java EE philosophy was to host applications. This is where was coming the application server name. The intent, which is still valid today, was to ensure the server is managed by another team than the application (typically, operation team and development team).

Yet, with Docker and embeddable containers (Apache TomEE, Wildfly Swarm, Payara micro, and so on), the operation responsability started being reconsidered and developers have more and more control over the server. This means that you will then ask yourself the same question (how can I easily patch my server?), but also that you will need an expert developer either from your development team or from a computer support company.