Like many server products, PaperCut makes heavy use of network resources. The PaperCut application server receives inbound network connections from user clients, release stations, print servers, and web browsers. It will establish outbound connections to your external database server (if you have this configured). The print monitoring components will establish outbound connections to the PaperCut application server. This activity this can result in many connections network connections being used.
On high volume sites this can result in the operating system’s TCP/IP limits to be reached. If this occurs problems may occur on your PaperCut server, like not being able to establish a connection to the PaperCut web interface, or seeing errors in your PaperCut logs that look like the following:
No buffer space available (maximum connections reached?)
server socket listen failed. (10055)
If this occurs it may be useful to check the current connections using the netstat utiliity, which will show all the connections and their states.
The most common cause of problems is a large number of closed connections staying in the TIME_WAIT state. These connections consume resources and can cause the problems described above. By tuning the operating system TCP parameters these problems can be avoided.
Tuning the number of ephemeral TCP ports
When outbound network connections are established they are assigned a new port to use for that connection (these are known as ephemeral TCP ports). These ports are unique to each connection, so are a limited resource on busy systems. By default Windows 2003 and earlier only allowed a maximum of around 4000 ephemeral ports (1024 are reserved and the max is set to 5000). In Windows 2008, Microsoft changed the default to around 16383 ephemeral ports (see here). And Linux defaults to around 32000 ports.
For sites running Windows 2003 or earlier, we recommend setting increasing this to the new Microsoft default of 16383. This is described in the following Microsoft KB article:
A server restart is required after making this change.
Tuning the TCP wait timeout
The TCP wait timeout specifies the time that must elapse before the operating system can release a closed connection and reuse its resources. The Windows default for this setting is 120 seconds (2 minutes). This is a conservative default which may be appropriate for extremely slow network connections, but a shorter period is more appropriate for busy servers on fast intranets. As a comparison, the default wait timeout on Linux is 60 seconds.
We recommend setting the TCP wait timeout on Windows to 60 seconds. To do this set the registry key described in the following article to 60 seconds (or 3C in hex):
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.