I have Microsoft server 2012R2 running active directory. I have another computer that queries AD data. The queries work fine except when AD server is freshly rebooted. The query takes about 30 seconds for AD server to reply. After that, all queries are fast, taking half second or less.
It seems that AD server is caching something before replying. Is subsequent query fast because the AD server cached some data?
The queries are done using port 636 with TLS.
Is there anything I can do to speed up the initial query?
Thanks
Checked DNS settings and can't see unusual settings.
Related
I just migrated a copy of our production database up to Azure SQL. After finishing the migration, I pointed the connection string of our Test instance to the Azure SQL database, then I tried to run the app.
Because I had changed the web.config, of course, I was not logged out. So, I tried to log in, and I got a database timeout issue.
I looked at the usage chart in the Azure Portal, and just the task of logging in pegged it to 100%. So, I upped the DTU allotment from the default of 10 to 100 (which of course made it a lot more expensive) and then tried again.
Same result.
Seriously? How high do I need to set the DTU's so that I can just log in? I'd be curious to know your experience. For just the most simple operations, what should I expect to have to set the DTU allotment to?
Running SQL Server 2014 Express on our domain. We use Windows Authentication to log on. All queries are performed in stored procedures.
Now, the system runs fine for all our users - except one. When he logs on (using our software), all queries take around 10 times longer (e.g. 30 ms instead of 2 ms). The queries are identical, the database is the same, the network speed is the same, the operative system is the same, the SQL Server drivers are the same, connection pooling is the same, DNS is the same. Changing computer does not help. The problem seems to be linked to the account being used.
What on Earth may be the cause for this huge performance hit?
Please advise!
I would try rebuilding the SP (by running an ALTER statement that duplicates its existing structure) to force SQL Server to recompile. I don't know every way SQL Server caches things but it can definitely create distinct execution plans for different types of connections so I wouldn't be surprised if your slow user is running a version with an inefficient execution plan.
http://www.sommarskog.se/query-plan-mysteries.html
Here's my situation:
Both users are using the same Microsoft Access front end.
Both users have the same version of the SQL Server Native Client 10.0 ODBC driver.
Both users have the same version of Microsoft Office 2007 installed.
Both users are opening the same report with the same parameter values.
One takes 2 minutes, the other takes an hour.
The issue travels with the user, it happens regardless of which PC they log into on the network.
I checked the SQL passed to SQL Server and it is different. The one that runs quickly is standard T-SQL. The one that hangs is sending a parameterized query that has a terrible execution plan. I can't figure out what is causing it to send one query for one user and a different query for another user.
Since the issue travels with the user regardless of which PC they are on. This makes me think that it is some sort of obscure group policy setting or active directory setting that is part of the users account that is being replicated from PC to PC. Which probably means it's in the registry somewhere. But I am having a difficult time tracking down what that registry key is. Does anyone have any ideas?
We are having some strange performance issues and I was hoping somebody may be able to point us in the right direction. Our scenario is an ASP.NET MVC C# website using EF4 POCO in IIS 7 (highly specced servers, dedicated just for this application).
Obviously it's slow on application_startup which is to be expected, but once that has loaded you can navigate the site and everything is nice and snappy 0.5ms page loads (we are using Mini-Profiler). Now if you stop using the site for say 5 - 10 minutes (we have the app pool recycle set to 2 hours and we are logging so we know that it hasn't been recycled) then the first page load is ridiculously slow, 10 - 15 seconds, but then you can navigate around again without issue (0.5ms).
This is not SQL queries that are slow as all queries seem to work fine after the first page hit even if they haven't been run yet so not caching anywhere either.
We have done a huge amount of testing and I can't figure this out. The main thing I have tried so far is to Pre generate EF views but this has not helped.
It seems after looking at Sql Server Profiler after 5 minutes give or take 30 seconds with no activity in Sql Server Profiler and no site interaction a couple of "Audit Logout" entries appear for the application and as soon as that happens it then seems to take 10 - 15 seconds to refresh the application. Is there an idle timeout on Sql Server?
This should work if you use the below in your connection string:
server=MyServer;database=MyDatabase;Min Pool Size=1;Max Pool Size=100
It will force your connection pool to always maintain at least one connection. I must say I don't recommend this (persistant connection) but it will solve your problem.
Are you using LMHOSTS file? We had same issue. LMHOSTS file cache expires after 10 minutes by default. After system has been sitting idle for 10 minutes the host would use Broadcast message before reloading the LMHOSTS file causing the delay.
It seems after looking at Sql Server Profiler after 5 minutes give or
take 30 seconds with no activity in Sql Server Profiler and no site
interaction a couple of "Audit Logout" entries appear for the
application and as soon as that happens it then seems to take 10 - 15
seconds to refresh the application. Is there an idle timeout on Sql
Server?
This is telling me that the issue most likely lies with your SQL server and/or the connection to it rather than with your application. SQL server uses connection pooling and SQL will scavange these pools every so often and clean them up. The delay you appear to be experiencing is when your connection pools have been cleaned up (the audit logouts) and you are having to establish a new connection. I would talk/work with your SQL database people.
For testing, do you have access to a local/dev copy of the database not running on the same SQL server as your production app? If not, try and get one setup and see if you suffer from the same issues.
I would run "SQL Server Profiler" against SQL Server and capture a new trace while reproducing the problem by accessing the site after being idle 5-10 mins. After that look at the trace. Specifically, look for entries in which ApplicationName starts with "EntityFramework...". This will tell you what is EF doing at that moment. There could be some issue with custom caching on top of EF, or some session state that is expiring (check sessionState timeout in web.config)
Since it is the first run (per app?) that is slow, you may be experiencing the compilation of the EDMX or the LINQ into SQL.
Possible solutions:
Use precompiled views and precompiled queries (may require a lot of refactoring).
http://msdn.microsoft.com/en-us/library/bb896240.aspx
http://blogs.msdn.com/b/dmcat/archive/2010/04/21/isolating-performance-with-precompiled-pre-generated-views-in-the-entity-framework-4.aspx
http://msdn.microsoft.com/en-us/library/bb896297.aspx
http://msdn.microsoft.com/en-us/magazine/ee336024.aspx
Dry run all your queries on app start (prior to first request is received).
You can run queries with a fake input (e.g. non existing zero keys) on a default connection string (can be to an empty database). Just make sure you don't throw exceptions (use SingleOrDefault() instead of Single() and handle null results and 0-length list results on .ToList()).
Create a simple webpage that accesses the SQL Server with a trivial query like "Select getDate()" or some other cheap query. Then use an external service like Pingdom or other monitor to hit that page every 30 seconds or so. That should keep the connections warm.
Try to overwrite your timeout in the web.config like in this example:
Data Source=mydatabase;Initial Catalog=Match;Persist Security Info=True
;User ID=User;Password=password;Connection Timeout=120
If it works, this is not a solution..just a work around.
In our case the application was hosted in Azure App Service Plan and was having similar problem. Turned out to be a problem of not configuring virtual network. See the question/answer here - EF Core 3.1.14 Recurring Cold Start
I am trying to get our DBA's to enable DTC on a cluster of SQL Server 2005. Unfortunately they keep refusing. Their argument that they would need to set up a dedicated host for DTC (Could take months!!) as it is not a matter of ticking a few boxes. Is this true? How intrusive is DTC on a shared environment such as a SQL farm. Do I have an argument against this?
Thanks
Had to tone down the original response your 'DBA' team deserve!
In response to your questions:
Dedicated server - Not at all. Everywhere I've worked with clusters, the DTC service is installed when the cluster is commissioned. Typically it sits in its own resource group or within the cluster group. If in its own group its usually sits on whichever server is hosting the cluster group.
Intrusive? - Absolutely not. It should be installed when the cluster is created, as per MS best practice.
Do you have an argument? - You most certainly do. The links below should cover the why and how for getting it installed:
MSDTC and SQL on a Cluster
Clustered SQL Server do's, dont's and basic warnings
DTC needs to be enabled and running on both sides of the connection. In my organization, it took some research to figure out which four boxes to check and then some hand-holding to get those boxes checked on all db servers, all app servers and most laptops. There's still a couple of hold-out developer laptops... but they're ok as long as they don't write. :)
You should have some driving scenario (such as an atomic multiple database write) to hit the DBA's over the head with. Give them some time to guess at alternatives... then let them know that DTC is the only hammer for this kind of nail.
I'm unsure of the implications of DTC on a SQL farm. I imagine the whole farm could get involved in the transaction if it involves enough data... which can't be a good thing.