Hopefully this is all making, sense and if anyone needs me to clear anything up, I would definitely be happy to do so.
The cluster ip address itself is on the same subnet as the two dbnet interfaces of the two nodes. From what I can tell, the two nodes communicate over these interfaces (MGnet and DBnet, don't know if that's what we called them or if that's the default naming convention) and they are on separate subnets.
Our cluster has two nodes - each with two virtual network interfaces. So my question is, does this even make sense? From what I've read, named pipes to remote hosts lowers performance. I'm not able to connect to the dev db via named pipes, but prepending "np:" to the prod server name in the connect string brings connection times down to <100ms. The problem with our app is that it makes TONS of connections and our logs show that they are all taking that long. Also, it seems that subsequent connections to our dev box always happen instantly for a long time after (a couple of hours probably, I haven't timed it) while the production database "resets" the connections after a couple minutes so connections are usually 1500 ms. $(get-date) - $start | ft -AutoSize TotalMillisecondsĪnd I consistently see a 1000 msec difference in connection times between the two environments. $SqlConnection.ConnectionString = "Server = $SQLServer Initial Catalog=SP2013_Farm_Config Enlist=false Integrated Security = True" I've tested a simple connect and disconnect with this powershell script - $SqlConnection = New-Object There are some noticeable differences between our the two environments - namely, dev is not a cluster while prod is an active/passive 2 node cluster. Connections to the sql server are taking 3 times longer in production, compared to our development environment. Database connections consume resources on the server and the connecting application. However, there are connection, size, and App Engine specific limits in place. There are no QPS limits for Cloud SQL instances. I'm trying to troubleshoot an issue we've been having with one of our applications and was able to narrow it down to our sql server. Connections from localhost may be used by some internal Cloud SQL processes. I only stumbled upon cliconfg in google searching a way to force our application to use named pipes. Our production environment is now making connections in less time than our dev environment. onced I changed it to point to the actual database name, everything went back to normal. It turned out our clients were configured in cliconfg to talk to our SQL server via an alias that pointed the name to the ip address of the cluster interface.
0 kommentar(er)
