Recently I run in to the MAXUserPort issue I binged again to see if there are other bloggers that have this fixed. I saw a good post from Tristan Kingston ( I could not find my own post ;-(
Source :http://blogs.technet.com/b/tristank/archive/2008/03/11/maxuserport-what-it-is-what-it-does-when-it-s-important.aspx
MaxUserPort controls "outbound" TCP connections
MaxUserPort is used to limit the number of dynamic ports available to TCP/IP applications.
It’s never going to be an issue affecting inbound connections. MaxUserPort is not the right answer if you think you have an inbound connection problem.
(I don’t know why, I just know it is. Probably something to do with constraining resource use on 16MB machines, or something.)
To further simplify: it’s typically going to limit the number of outbound sockets that can be created. Note: that’s really a big fat generalization, but it’s one that works in 99% of cases.
If an application asks for the next available socket (a socket is a combination of an IP address and a port number), it’ll come from the ephemeral port range allowed by MaxUserPort. Typically, these "next available" sockets are used for outbound connections.
The default range for MaxUserPort is from 1024-5000, but the possible range is up to 65534.
When You Fiddle MaxUserPort
So, why would you change MaxUserPort?
In the web server context (equally applicable to other application servers), you’d usually need to look at MaxUserPort when:
– your server process is communicating with some type of other system (like a back-end database, or any TCP-based application server – quite often http web servers)
And:
– you are not using socket pooling, and/or
– your request model is something like one request = one outbound TCP connection (or more!)
In this type of scenario, you can run out of ephemeral ports (between 1024 and MaxUserPort) very quickly, and the problem will scale with the load applied to the system, particularly if a socket is acquired and abandoned with every request.
When a socket is abandoned, it’ll take two minutes to fall back into the pool.
Discussions about how the design could scale better if it reused sockets rather than pooling tend to be unwelcome when the users are screaming that the app is slow, or hung, or whatever, so at this point, you’d have established that new request threads are hung waiting on an available socket, and just turn up MaxUserPort to 65534.
What Next? TcpTimedWaitDelay, natch
Once MaxUserPort is at 65534, it’s still possible for the rate of port use to exceed the rate at which they’re being returned to the pool! You’ve bought yourself some headroom, though.
So how do you return connections to the pool faster?
Glad you asked: you start tweaking TcpTimedWaitDelay.
By default, a connection can’t be reused for 2 times the Maximum Segment Lifetime (MSL), which works out to 4 minutes, or so the docs claim, but according to The Lore O’ The Group here, we reckon it’s actually just the TcpTimedWaitDelay value, no doubling of anything.
TcpTimedWaitDelay lets you set a value for the Time_Wait timeout manually.
As a quick aside: the value you specify has to take retransmissions into account – a client could still be transferring data from a server when a FIN is sent by the server, and the client then gets TcpTimedWaitDelay seconds to get all the bits it wants. This could be sucky in, for example, a flaky dial-up networking scenario, or, say, New Zealand, if the client needs to retransmit a whole lot… and it’s sloooow. (and this is a global option, as far as I remember).
30 seconds is a nice, round number that either quarters or eighths (depending on who you ask – we say quarter for now) the time before a socket is reusable (without the programmer doing anything special (say, SO_REUSEADDR)).
If you’ve had to do this, at this point, you should be thinking seriously about the architecture – will this scale to whatever load requirements you have?
The maths is straightforward:
If each connection is reusable after a minimum of N (TcpTimedWaitDelay) seconds
and you are creating more than X (MaxUserPort) connections in an N second period…
Your app is going to spend time "waiting" on socket availability…
Which is what techy types call "blocking" or "hanging". Nice*!
Fun* KB Articles:
http://support.microsoft.com/kb/319502/
http://support.microsoft.com/kb/328476
Recently I run in to the MAXUserPort issue I binged again to see if there are other bloggers that have this fixed. I saw a good post from Tristan Kingston ( I could not find my own post ;-(
Source :http://blogs.technet.com/b/tristank/archive/2008/03/11/maxuserport-what-it-is-what-it-does-when-it-s-important.aspx
MaxUserPort controls "outbound" TCP connections
MaxUserPort is used to limit the number of dynamic ports available to TCP/IP applications.
It’s never going to be an issue affecting inbound connections. MaxUserPort is not the right answer if you think you have an inbound connection problem.
(I don’t know why, I just know it is. Probably something to do with constraining resource use on 16MB machines, or something.)
To further simplify: it’s typically going to limit the number of outbound sockets that can be created. Note: that’s really a big fat generalization, but it’s one that works in 99% of cases.
If an application asks for the next available socket (a socket is a combination of an IP address and a port number), it’ll come from the ephemeral port range allowed by MaxUserPort. Typically, these "next available" sockets are used for outbound connections.
The default range for MaxUserPort is from 1024-5000, but the possible range is up to 65534.
When You Fiddle MaxUserPort
So, why would you change MaxUserPort?
In the web server context (equally applicable to other application servers), you’d usually need to look at MaxUserPort when:
– your server process is communicating with some type of other system (like a back-end database, or any TCP-based application server – quite often http web servers)
And:
– you are not using socket pooling, and/or
– your request model is something like one request = one outbound TCP connection (or more!)
In this type of scenario, you can run out of ephemeral ports (between 1024 and MaxUserPort) very quickly, and the problem will scale with the load applied to the system, particularly if a socket is acquired and abandoned with every request.
When a socket is abandoned, it’ll take two minutes to fall back into the pool.
Discussions about how the design could scale better if it reused sockets rather than pooling tend to be unwelcome when the users are screaming that the app is slow, or hung, or whatever, so at this point, you’d have established that new request threads are hung waiting on an available socket, and just turn up MaxUserPort to 65534.
What Next? TcpTimedWaitDelay, natch
Once MaxUserPort is at 65534, it’s still possible for the rate of port use to exceed the rate at which they’re being returned to the pool! You’ve bought yourself some headroom, though.
So how do you return connections to the pool faster?
Glad you asked: you start tweaking TcpTimedWaitDelay.
By default, a connection can’t be reused for 2 times the Maximum Segment Lifetime (MSL), which works out to 4 minutes, or so the docs claim, but according to The Lore O’ The Group here, we reckon it’s actually just the TcpTimedWaitDelay value, no doubling of anything.
TcpTimedWaitDelay lets you set a value for the Time_Wait timeout manually.
As a quick aside: the value you specify has to take retransmissions into account – a client could still be transferring data from a server when a FIN is sent by the server, and the client then gets TcpTimedWaitDelay seconds to get all the bits it wants. This could be sucky in, for example, a flaky dial-up networking scenario, or, say, New Zealand, if the client needs to retransmit a whole lot… and it’s sloooow. (and this is a global option, as far as I remember).
30 seconds is a nice, round number that either quarters or eighths (depending on who you ask – we say quarter for now) the time before a socket is reusable (without the programmer doing anything special (say, SO_REUSEADDR)).
If you’ve had to do this, at this point, you should be thinking seriously about the architecture – will this scale to whatever load requirements you have?
The maths is straightforward:
If each connection is reusable after a minimum of N (TcpTimedWaitDelay) seconds
and you are creating more than X (MaxUserPort) connections in an N second period…
Your app is going to spend time "waiting" on socket availability…
Which is what techy types call "blocking" or "hanging". Nice*!
Fun* KB Articles:
http://support.microsoft.com/kb/319502/
http://support.microsoft.com/kb/328476
After today there is no mainstream support for windows 2003. So get your servers ready for windows 2008 R2 .There is still the extended Support. But the OS is 7 years old, almost every product that is older than 7 years need a replacement. think about your home desktop,TV,dishwasher etc the Extended support end at 14-07-2015
Sure you can wait till the NEXT version of windows in 201x. But can you wait ?, can you ? ,are you sure ? What about the security and all the benefits of windows 2008R2 you want to skip this? maybe now but I’m sure by the end of this year you need windows 2008R2 if you want to keep up with the market.
Do you still use IE6 ? no you are running the latest version because the security is better. And what about the migration/adoption time in your organization ? .
Think Proactive ! if you have software assurance you are already paying for the windows 2008R2 release so why not upgrading. Our company always waits for the service pack , well there is a service/feature pack it is still in beta but it brings new stuff for windows 2008R2 play with it and get ready and avoid a forced migration because you need some app that is only running on windows 2008R2.
Below are several links to the Windows 2008R2 resources.
Windows 2000 End-of-Support Solution Center
Support for Windows 2003 ends on July 13, 2010!
The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000 to Windows 7 or Windows Server 2008 R2.
For more information please see the Microsoft Support Lifecycle Policy.
Planning and AssessingMigrating Server RolesMigrating SQL ServerNetworking Server RolesSmall Business ServerClient MigrationApplication CompatibilityAsk the CommunityAssisted Support
Planning and Assessing
Planning and Assessing a Migration or Upgrade to Windows Server 2008 R2
A direct upgrade from Windows 2000 to Windows Server 2008 R2 is not supported. The resources below provide information about migration paths.
Windows Server 2008 R2 Product Home Page
Visit the Windows Server Home Page for product information, trial software, purchasing options, technical resources, case studies and more.
Windows Server 2008 R2 System Requirements
Before upgrading your system from Windows 2000 to Windows 2008 R2, be sure your hardware meets the Windows Server 2008 R2 system requirements. Assuming your hardware meets the requirements for Windows Server 2008 R2, upgrading is a two-step process. You must first upgrade your system to Windows Server 2003 SP2 (or later) and then upgrade to Windows Server 2008 R2.
Windows Server 2008 R2 Upgrade Paths
This document outlines supported and unsupported upgrade paths for editions of the Windows Server 2008 R2 operating system.
Assessment and Planning Toolkit for Windows Server 2008 R2
The Microsoft Assessment and Planning (MAP) Toolkit is a powerful inventory, assessment, and reporting tool that can securely assess IT environments for various platform migrations and virtualization without the use of any software agents. NOTE: The oldest operating system supported by this tool is Windows Server 2003 SP2.
Windows Server Migration Tools
Administrators can use Windows Server Migration Tools to migrate server roles, features, operating system settings, and other data and shares to computers that are running Windows Server 2008 R2. NOTE: The oldest operating system supported by this tool is Windows Server 2003 SP2.
Windows Server 2008 R2 Deprecated Features
This document provides is a list of deprecated features and functionalities in Windows 7 and Windows Server 2008 R2 and is intended for IT professionals who are updating operating systems in a commercial environment.
Microsoft Deployment Toolkit
Microsoft Deployment Toolkit 2010 (MDT 2010) provides a common console with the comprehensive tools and guidance needed to efficiently manage deployment of Windows 7 and Windows Server 2008 R2.
Planning and Assessing a Migration or Upgrade to Windows 7
The Windows 7 SP1 and Windows Server 2008 R2 SP1 Betas are concurrent releases that we’ve packaged together in a single download for a more streamlined and cost effective deployment. Businesses can begin realizing the advancements of the Windows Server platform for virtualization through two key features: Dynamic Memory and RemoteFX.
Dynamic Memory Overview
“We found that we could increase the number of virtual machines per Hyper-V server by 25 to 50 percent with Dynamic Memory. For some Hyper-V servers, we even went from 4 to 7 virtual machines—a 75 percent increase!”
- David Feng, IT Director, Sporton International
Windows Server 2008 R2 Hyper-V introduces a new feature, called Dynamic Memory, in the Windows 7 SP1 and Windows Server 2008 R2 SP1 Beta releases. It allows customers to achieve increased density when they’re consolidating physical servers into a virtual realm, providing them with predictable performance and linear scalability. With Dynamic Memory, IT administrators are able to pool available memory on a physical host and then dynamically dole that memory out to virtual machines running on the host, based on current workload needs.
For a technical overview of the new Dynamic Memory feature, download the Dynamic Memory Technical Overview whitepaper.
RemoteFX Overview
“We save 70 to 80 hours each month by delivering classes remotely using RemoteFX in Windows Server 2008 R2 SP1. At our billing rate of $250 an hour, that’s more than $200,000 a year.”
– Rand Morimoto, President, Convergent Computing
RemoteFX, a key feature of Remote Desktop Services (RDS) lets IT administrators deliver a rich graphics experience to end-users through virtualized desktops. Using new protocol enhancements between Windows Server 2008 R2 and Windows 7, end users can now access virtual machines on a wide variety of target devices and still get a rich graphics experience with server-side graphics processing.
Learn more about RemoteFX and download the Remote Desktop Services Datasheet.
