It regularly happens in enterprise projects that developers try to prematurely optimize applications without proper verification. Examples for this are the usage of caching, configuring pools, and application server behavior, without sampling sufficient measurements before and after tweaking.

It's highly advisable to not consider to use these optimizations before there is an identified performance problem. Proper performance sampling and measurements in production, as well as investigating the constraining resource, are a necessity before changing the setup.

In the vast majority of cases, it's sufficient to go with convention over configuration. This is true for both the JVM runtime as well as the application server. If developers take a plain Java EE approach with the default application server configuration, they won't likely run into issues with premature optimization.

If technical metrics indicate that the current approach is not sufficient for the production workload, only then is there a need to introduce change. Also, engineers should validate the necessity of the change over time. Technology changes and an optimization that provided remedy in previous runtime versions might not be the best solution anymore.

The approach of convention over configuration and taking the default configuration first also requires the least amount of initial effort.

Again, experience shows that a lot of issues originated from prematurely introducing change without proper verification beforehand.