I have a single server running a .NET web application and a SQL Server database (2008 Standard). I'm planning to move the database onto a separate server but in order to provision the network hardware I'd like to benchmark the data throughput between the web application and the database. Can port 1433 be monitored internally? If so is there any tool native to Windows 2008 R2 that can do this, or would I need some 3rd party application like WireShark? My connection string is referencing the database using server=localhost, is it still possible to tap into 1433 to see the bandwidth used on this port?
Essentially I'm trying to determine if I need a Gbit or 100 Mbit connection between the web server and database server. Any thoughts on this would be much appreciated.
UPDATE 8th July
I hashed out the above as I realise it's largely irrelevant. For some reason I thought there would be a big cost difference between a 100 Mbit and 1 Gbit switch. Only the cheapo home user switches are 100 Mbit. As others have pointed out, Wireshark will not pickup activity between IIS and the SQL server on the same box. I'm putting in a 1Gbit managed switch for now and I'll use either Wireshark or the built in monitoring on the switch to see what's going on later. I don't think it will be anywhere close to the physical transfer limits imposed by the hardware.
Best Answer
As I understand it, you want to monitor network traffic in between a web application hosted in IIS and SQL Server, both of which are running on the same server. This is going to be complicated by a few things:
Most packet sniffers don't support monitoring traffic over a loopback interface like you are using if your web app connects to SQL Server on localhost or 127.0.0.1. Microsoft's Message Analyzer is an exception, but it is beta, doesn't appear to have much in the way of visualisation or analysis tools, and doesn't appear to be exportable to a format that network sniffers with decent throughput analysis tools can read.
The traffic won't be analysable if you're using shared memory or local named pipes instead of TCP to connect to SQL Server.
Wireshark also doesn't know what process IDs the packets were sent or received from, which could be a problem depending on your filtering requirements.
Wireshark has good visualisation and analysis tools compared to other network sniffers, though, including throughput graphs and statistics on conversations. What I've done in the past where I needed to filter on process ID was to capture with nmcap or Network Monitor, and then import to Wireshark to do the analysis. None of these will work if you're connecting over the loopback, though, or connecting via local named pipes or shared memory.
I agree with the advice to just get a 1 gbps switch if possible, even if you don't need it today. If you don't need it now, you might later, and it's easier to upgrade in a planned manner while your app is performing well rather than in an emergency where the network is saturated.
A few times a year I encounter a web app that is managing to saturate a 100mbps link to a database server, so I don't think this is an outlandish scenario. Many of the applications I support are not well designed, though, so this may never be a problem for you if you're using common-sense design principles like not retrieving giant results on every page view.