{"id":38287,"date":"2025-10-28T06:33:01","date_gmt":"2025-10-28T10:33:01","guid":{"rendered":"https:\/\/www.eginnovations.com\/blog\/?p=38287"},"modified":"2025-10-28T06:33:01","modified_gmt":"2025-10-28T10:33:01","slug":"scaling-java-web-applications-choosing-between-microsoft-windows-and-linux-os","status":"publish","type":"post","link":"https:\/\/www.eginnovations.com\/blog\/scaling-java-web-applications-choosing-between-microsoft-windows-and-linux-os\/","title":{"rendered":"Scaling Java Web Applications: Choosing Between Microsoft Windows and Linux OS"},"content":{"rendered":"
\n

Java is one of the most widely used platforms for supporting web applications. According to RedMonk<\/a> and TIOBE<\/a> rankings, Java has consistently remained in the top 4 most popular programming languages worldwide, with millions of developers actively using it<\/a>. Industry-standard application servers such as WebLogic, WebSphere, Tomcat, and JBoss all run on Java and power a large share of enterprise workloads and Java web applications.<\/p>\n

When you deploy a Java web application, a key decision is the choice of operating system. While Java is platform-independent, the underlying OS still influences performance, scalability, and manageability. Very often, the choice of OS comes down to what technologies the admin team is most comfortable with. In many enterprises and use cases, Windows dominates\u2014as of 2024, Windows Server still accounts for nearly 72% of enterprise server deployments\u2014while Linux adoption continues to grow rapidly (source: Linux Statistics 2025 – TrueList<\/a>), especially in cloud and container-native environments. However, Linux can be a challenge for those admins who may be more familiar with GUI-based administration in Windows.<\/p>\n

In this blog, we will highlight key performance and operational differences between Windows and Linux for supporting Java web applications today. Our analysis is based on a real-world case of troubleshooting a malfunctioning Java web application at a large global enterprise.<\/p>\n

<\/span>Java Web Application Deployment<\/span><\/h2>\n

We were tasked with optimizing performance and troubleshooting sporadic issues that occurred with a multi-tier web application. Apache Tomcat 10.1 was the web application server and Microsoft SQL 2019 was the database server in use. Both the application server and the database were on dedicated systems running Microsoft Windows Server OS 2019. JDK 17 was the version of Java in use. As the application was accessed by 1000s of remote clients, a redundant cluster of application server and database server pairs was in use. While application performance overall was acceptable, we noticed that every few days some of the application logic failed and there were also synchronization errors between the application servers.<\/p>\n

<\/span>Troubleshooting Performance Issues: Trial and Error<\/span><\/h2>\n

The first thing we did was benchmark the system performance of the application server and database. We did not see a large number of connections to the database server and all the key SQL parameters were normal, indicating that there was no bottleneck in the database tier. On the Tomcat application server also, there were no resource bottlenecks (see Figure 1).<\/p>\n

\"CPU<\/a><\/p>\n

Figure 1: CPU & Memory utilization in the Java web application tier indicating that the server resource usage levels where within acceptable limits<\/div>\n

Synthetic application checks configured to run throughout the day every 5 minutes showed availability failures at several times during the day. Analyzing the failures, we could see \u201cConnection Refused\u201d messages on the client \u2013 indicating that the server refused to accept connection requests from the client. To isolate whether the issue was network related or not, we configured the synthetic checks to run from within the server itself. These checks targeted the local address of the server and therefore, would not involve any network communication. Even after this change, we observed availability failures (see Figure 2).<\/p>\n

\"Graph<\/a><\/p>\n

Figure 2: 83% Uptime of the application, due to multiple drops in availability monitoring<\/div>\n

We then configured the availability checks to target a different port on the application server (one that was not used by the clients). When a dedicated port was used for the synthetic checks, we did not find any availability errors. If the application had been the cause of the bottleneck, we would have seen availability errors even with a dedicated port being used for the synthetic checks. Analysis of the Java web application\u2019s CPU and heap memory usage (see Figure 3) showed no bottlenecks, as expected.<\/p>\n

\"A<\/a><\/p>\n

Figure 3: JVM Heap memory consumption<\/div>\n\n\n\n
\"\"<\/td>\n\n
The fact that there were connection drops seen for connections made internal to the server pointed to an issue in the server, rather than somewhere in the network.<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Our analysis indicated that the server OS was a bottleneck. However, a review of the key server resources (CPU, memory, disk, network) did not reveal any issues. We even doubled the capacity of the system \u2013 by doubling the CPU and memory configured \u2013 and that did not stop the application issues from occurring.<\/p>\n

\"A<\/a><\/p>\n

Figure 4: Number of TCP connections established on the server over time<\/div>\n

A common reason for connection refused errors is over utilization of ephemeral TCP ports on a server. Analysis of TCP connections in different stages indicated that at no time was the server seeing more than 3000 connections in different states, with less than 400 TCP connections established at most times (see Figure 4), whereas the total limit of ephemeral ports was configured to 49000. Hence, the server was not reaching the TCP ephemeral ports limit either. Yet connections were being refused periodically.<\/p>\n

\n
\n

What are TCP Ephemeral Ports?<\/p>\n

\"\"A TCP ephemeral port is a temporary, automatically assigned port number that a client machine uses to establish a connection with a server. Unlike well-known server ports (like 80 for HTTP), ephemeral ports are dynamic, short-lived, and used only for the duration of a single communication session, after which they become available for reuse. These ports are essential for enabling client-to-server communication by providing a unique, temporary endpoint for each outgoing connection, preventing conflicts and allowing for multiple simultaneous connections.<\/p>\n<\/div>\n<\/div>\n

We proceeded to disable all the security software on the system, but the application connection availability errors continued.<\/p>\n

Further application and OS tuning was attempted:<\/p>\n