DRCRON's questions

After reading this blog post by Ben Strong, I started looking on the internet for information on how the Initial Window size could be manipulated on Microsoft Windows Server 2003 (R2, 64bit in case it matters).

Turns out that there is some information on tuning TCP/IP for Windows, but I couldn't find anything that would allow me to change the Initial Window size. Does anyone know if there is a TCPIP tuning guide for Windows-web servers, or at least some information on how to accomplish this specific feat?

As you can see from the title, our output cache is not working. We only recently noticed but it did at one time work (verifiable with a hidden timestamp at the bottom of the page; we cache for 3600 seconds using varybyparam="*"). We attempted to isolate the piece of code that is causing the problem (either the page is not entering the cache, it is immediately invalidated, or the key used to cache it is unique and the cached page can't/won't be found) and it turns out that when we commend out this line:

System.Web.HttpContext.Current.Response.AppendCookie(objCookie)

from a cookie-class that caching starts working perfectly!

We're not sure how long caching hasn't been working but the suspicion is that a Microsoft Windows Update slipped through QA. We have verified on an older, un-patched virtual server that output caching works perfectly (although the environment isn't 100% like our production so there's some doubt in there) and that we don't need to make any changes to our code to get it to work. Only on our production servers (Win2k3, x64 but app pools running in 32bit mode, IIS 6, .Net 2.0) do we experience this problem.

Days of googling only turned up references to output caching breaking for SharePoint after MS11-100 was applied. We've hit a brick wall and have contact Microsoft Support but was wondering if anyone in the community has run into this issue, something similar, or just has ideas about how to fix.

To simplify our environment, at it's most atomic level, we have a .NET website running on IIS 6 on one server and the website depends on data from a MS SQL 2005 database on another server.

We have duplicated this infrastructure at a geographically distant site for DR purposes. We rsync .NET code files to the remote IIS server. We log ship our SQL data to a remote SQL server.

It seems that we could do something similar in Amazon's cloud. Use EC2 machines backed by EBS volumes. The advantage being that we could use smaller machines at a lower-cost until we actually had a need to fail over, in which case we could spin up much larger machines to handle the load and attach the pre-existing EBS volumes.

This project is only in the discovery/exploration phase and we could benefit from some veteran experience in the community using Amazon AWS. Things that come to mind as being immediately helpful:

1. Does anyone have any experience running MS SQL Server 2005 in AWS? Performance is bound to suffer for OLTP loads like that generated by database-driven websites, but where did your virtual SQL server work and fail (i.e. disk i/o was crap...we could handle ~5k transactions/sec on our physical server and with a similarly spec'ed virtual machine our capacity was halved).

2. In the long-run, after working in all unanticipated costs of operating a DR solution in the cloud, did you actually save any money? Where were the hidden costs?

3. If you were moving data up to Amazon in an automated fashion, how were you handling that? Flat files are easy, but if you are running SQL or Exchange, I'm particularly interested in which tools you used.

4. Is there a way to write directly to an EBS volume, or are you forced to attach EBS volumes to EC2 instances and work with the OS?

5. If you had the misfortune of having to fail over to AWS to handle a production load, how did it perform as a DR solution? Obviously everyone's recovery objectives are different, so I guess I'm really just wondering where AWS was rather elegant/advantageous and where it just fell flat on it's face for you

Other insights and reality checks are all appreciated. TIA for taking the time to share what you know with the community and me.

We have a SQL 2005 64bit SP2 server running on Windows 2003 R2 SP2. It also has Reporting Server installed and that serves as it's primary function.

Over the course of approximately a week, connecting from SSMS via named pipes gets increasingly slower until a point is reached where SSMS won't connect at all, throwing the ever-popular "Named Pipes Provider, error 40 - Could not open a connection to SQL Server".

At this point, connecting via TCP/IP is still functional and incredibly fast, but SQL jobs are failing (this is my primary concern) and users can't connect via SSMS unless they change how they're connecting (less of a worry).

I have never in all my years working on SQL seen an issue such as this. There server in no way appears to be strained/over-worked (16 cores, 16GB of RAM, 12GB dedicated solely to SQL)...named pipes just gets increasingly slower until it dies.

I'm hoping that someone out there has run into this before and figured out a way to solve their issue. Or perhaps someone has some interesting way to troubleshoot this issue.