J2EE Applications on Wintendo Servers September 2nd, 2003
I've spent the last 6 years avoiding Wintendo administration. I've been wildly successful in this endeavor.
Then last week happened. What a nightmare. I was tasked with setting up a dual Xeon with 4GB of RAM to host a networked J2EE application (using JBoss and Tomcat) that's been in the pipeline for 2 years. Not a problem. I had to handle the installation and configuration remotely. Also not a problem. The problem was the choice of operating system: Wintendo 2000 Server.
Life's too short for this shit. Really. Thinking back to the time when people were still buying Microsoft's "lowest total cost of ownership" lie, I have to laugh.
Anyway, it was horrible. I wouldn't want my worst enemy to go through that. So in the interests of reduced global hair loss, I humbly offer my notes from the ordeal. May they serve you well.
-
Use of the /3GB boot.ini switch radically reduces the number of PTEs available. This results in a very low limit on concurrent threads.
If you don't need >2GB virtual address space per process, don't enable /3GB. If you can't live without it, see this article for information on tuning SystemPages to increase available PTEs.
-
The default Wintendo 2000 TCP connection backlog is ridiculously low (20). This is a problem for when the server is configured to ramp the number of connection handlers up as load increases. See this article for information on enabling dynamic backlog handling.
-
The default Wintendo 2000 local user socket limit is ridiculously low (5000). This is a problem when the server accesses resources (such as databases and application containers) over the network. See this article for information on increasing this limit to the defaults found on most sensible server platforms.
-
The default Wintendo 2000 TCP TIME_WAIT delay is ridiculously high (240 seconds). This is a problem for servers establishing and releasing new connections at a high rate. See this article for information on tuning TcpTimedWaitDelay down to a more reasonable value, like 60 seconds. Note that this violates RFC 1122, although the default value of 240 seconds already violates the standard.
-
[SPECULATION]
Wintendo 2000 imposes an immutable limit on the number of open files / handles allowed for a process started from a CMD.EXE prompt. See the Java Service Wrapper Site for information on installing JBoss-Tomcat as an NT service using the Java Service Wrapper.
-
[SPECULATION]
Wintendo 2000 imposes a 48MB heap limit for processes started via the desktop (22MB for Terminal Services desktops). The solution for (5) above applies. Terminal Services, how ironic.
I don't have KB article references to support (5) and (6). I read stuff that led me to believe them, but didn't record references. However, running Jboss-Tomcat as an NT service avoided undiagnosed resource starvation problems not covered in (1) through (3).
With these changes made, a Wintendo 2000 server can be made to service a serious JBoss-Tomcat deployment configured to operate under the kind of load that Unix-like operating systems tend to handle out of the box. The host is able to service at least 2,000 concurrent connections without application server failure.
The entire experience was cosmic; I've transcended surprise. Which is fortunate, because two hours after I finished setting up the system, its motherboard died.
hi there, thanks for the article. pls. share more. 4/5 years ago, someone building a JMS stack was asking me advice for increasing windows connection limit(I guess he was using win2k). I could not help him much -- wish that this post was available at that time.