2

A client is running an ASP.NET web site on an IIS Server (on Windows Server 2008 R2). It's a dedicated physical server, at an external host, and, for the most part, the site runs fine.

The client has noticed, however, that the web site sometimes becomes unresponsive when we are transferring files to it via FTP. We are using the built-in Windows FTP server on this box. We generally copy files up using Beyond Compare, or a simple FTP client, like WinSCP. In these cases, we are copying up .aspx pages and .pdf files, not DLLs or config file changes, so IIS should not be restarting the asp.net worker process or anything like that.

Looking at Resource Monitor while the transfer is happening shows the network utilization getting up to about 25%. CPU, memory, and disk usage are all reasonable.

Could the FTP transfer be soaking up all the bandwidth available to the server? If so, is there a way for me to limit the bandwidth that the Microsoft FTP server uses? I've looked around for information on that, and it seems like that might not be possible. I know that it can be done with, for instance, Serv-U, so I've been thinking of switching to that.

I'm not sure yet how much bandwidth the host is providing, by the way, but I'm looking into that.

Improve this question

1 Answer 1

Reset to default
2

We are using the built-in Windows FTP server on this box

Sorry, WHICH One? There is the old one and the new one - unless the throw the old out out with R2, not sure ;)

Looking at Resource Monitor while the transfer is happening shows the network utilization getting up to about 25%. CPU, memory, and disk usage are all reasonable

That is quite a lot, espeically when this is one transfer stream. What do you mean with "disc usage are reasonable" - seconds per IO is in which range? THat is about the only counter relevant.

Could the FTP transfer be soaking up all the bandwidth available to the server?

Yes. Given that FTP is trivial processing wise that is even quite normal.

I'm not sure yet how much bandwidth the host is providing, by the way, but I'm looking into that.

I think this is likely the main point here. Note that you dont even say what link you have - 25% network ultilization mean differnet things on a 100mbit or 1000mbit physical link to start with.

I would somehow say you use 25 mbit and likely are on a shared link?

Try putting in a QOS profile and prioritize FTP lower ;)

Improve this answer
2
  • We are using the FTP service that is manageable thru IIS Manager. The path to it that I see in the service properties is "C:\Windows\system32\svchost.exe -k ftpsvc". Not sure if that's the old or new one. Good point about the network link -- it's 100 Mbps. I'll have to do another test and look at the secs/IO #. I didn't really look at that this morning.
    – Andrew Huey
    May 23, 2012 at 13:42
  • Secs/IO is the ONLY metric that is relevant - when that goes up, you are overloaded. All others (queue length etc.) require a LOT of interpretation - that one tells you straight how fast the IO is on the hardware, which is the only thing that really matters.
    – TomTom
    May 23, 2012 at 15:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .