ASP.NET MVC Debugging Very Slow - SQL Server Express Connection Issue? - c#

I am developing an application in ASP.NET MVC, using SQL Server Express as the backend and Cassini as the development web server (the one that comes with Visual Studio 2008).
The application performance is blazingly fast (nearly instantaneous page switches). However, spinning up the debugger is painfully slow; it takes about 30 seconds from the time I hit F5 to the time the ASP.NET welcome page comes up.
I have noticed a similar delay when loading SQL Server Management Studio Express, and another delay when I open a table in my database for the first time for viewing. After I open my first table, everything goes smoothly.
Given the behavior of SQL Server Management Studio Express, I suspect that the problem lies in making the initial connection to SQL Server Express. Is this really where the problem is, and if so, how can I fix it?

I'd check the auto_close property on the database.
sp_dboption 'MyDatabaseName', 'autoclose'
I think the default on express might be to set autoclose to on. When that is set to TRUE, the server will close the database and free all resources from it when there are no users in the database. Setting autoclose to FALSE will tell the server to hang on to the database so that it's in the ready state regardless of users being in the database or not.
See here for more info.

If it's only slow when debugging, then there are several chokepoints to consider:
Applications start off slower when debugging because of the precompilation the JITer has to do whenever the assemblies are rebuilt.
If you're compiling and debugging every time, it may be your compilation that's slow, not so much your application performance. How long does it take for the browser to appear once you hit F5? If you have multiple projects in your solution, building them will take time. Try setting up a build configuration that excludes class projects (make sure to rebuild them manually when necessary)
I haven't had any trouble with Cassini, but you might try IIS just for grins.
Just a few thoughts, HTH.

I finally solved the problem by rebuilding my TCP/IP stack, using Netshell from a Command Prompt window. Apparently I was getting a TCP/IP timeout.
netsh int ip reset c:resetlog.txt
http://support.microsoft.com/kb/299357

In my case I was getting exceptions being thrown and caught which were visible in the Debug > Output window which was massively slowing down my app as it was being debugged.
I ended up enabling the break on exceptions as outlined here and then just fixing the code so not so many exceptions were being thrown
Why is ASP.NET throwing so many exceptions?

Related

How to detect/recover from slow SQL server I/O in a C# program

I have a C# .NET based program which runs 24/7 checking for and processing data in SQL Server. This program runs fine all day long, but a little after 2AM each morning, something happens on my customer's server which causes SQL to report slow I/O. SQL reports something like the following in its logs:
SQL Server has encountered 129 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\tempdb.mdf] in database id 2. The OS file handle is 0x0000000000000D9C. The offset of the latest long I/O is: 0x00000007ce0000
There are usually several of these message logged each morning, one after another.
Sometimes my program loses the connection to SQL server and exits, after which it is automatically restarted by a service. Other times my program stops responding and I have to manually kill and restart the process in the morning.
My customer's IT has not been able to identify the cause of the slowdown, so I'm trying to change my program or connection settings to reliably detect the problem and exit, or overcome it in some other way.
I've searched, but can't find anything online related to this sort of issue.
Any help would be greatly appreciated.
I would suggest you a little different solution as you said any help would be appreciated.
As I understand you do not know what is causing the problem and in my opinion you should focus on getting the knowledge what it is.
In your situation the best would be to ask your customer to set SQL Server Profiler for the time that is being under suspection that causes the problems. This is the tool that harvest all SQL Server activity. I have used this many times at my work.
For the question how to set SQL Server Profiler you would find easily the answer on google. This is quite easy and intuitive.
Be prepare to catch lots of queries, but you can filter them easily too.
Based on the logs in SQL Server Profiler you would know what is causing the problem and you can fix it in your application.
Let me know if this helped.

MVC so slow on server

I have made a website. Locally it works fine, no problems at all. But when I publish it to the server (VPS) it runs terribly slow. It takes almost 37 seconds for the homepage to load. While locally it takes like 400 ms.
I have no idea what to do because I tried a lot:
Removing EF 6 and replaced it with dapper
Using display templates instead of for each-loops and partials
Removing all ViewEngines and adding only Razor.
Checking duplicate queries (found one, fixed it)
Checked unnecessary queries and used joins
Checked if some functions are called to many times (loops)
Tried to PreCompile during publishing
It became faster local. From 900 ms to 350 ms.
But on the server nothing seems to help. So I turned to the server.
For web application:
Checked if debug was set on true on the server (was always false)
Changed the connection string from (local) to 127.0.0.1,1234 (I use a port due to hackers. Port is not the real one in this example).
Published as debug, not release
Server settings:
Tried for force 32bit for the AppPool
Put the web application in an own AppPool
Disabled the ipv6
Shutdown other AppPools
Turned off the Windows FireWall (don't worry, turned it up again)
Restarted the server again.
But then I noticed was that IIS Worker Process was using almost 1.7 GB memory, % of the memory and I was like "... What? Why?". Later I saw it was using 2.7 GB.
I installed Glimpse on the web application. But I cannot find out what the problem could be.
Some information of the techniques I use in the project:
3 layer: Business, Data, Web
DI with Unity
Bootstrap for design, jQuery
EntityFramework 6 in the first version, Dapper in second
MVC 5
AspNet Identity for user management
VPS information:
4 GB
Intel(R) Xeon(R) CPU E5-2680 v2 # 2.80Ghz
64-bit OS
Windows Server 2012
I can't think of any other information to give. So, if I missed something, just ask. If you want to check if out: Website is http://www.zatyscorner.com. I try to optimize the start page first so see what is happening.
Hopefully, someone can help me out.
Okay, so back at programming-school I was taught that you have to do a few things when there are performance issues: Check the server, check the code and.... Check the queries...
Well, in this case, the queries to SQL were the bad guys. I had one query that took 7700 records (give or take), took 10 from those and showed it... Yeah, that will cause a timeout and enormous amount of memory... Especially when 3 people are doing it at the same time.
Problem fixed! I am rebuilding most queries now with Dapper and I make sure the good amount of records are returned.
Feeling like a noob :(
I think changing the Application Pool's Identity to LocalSystem can help, check out this answer here.
I will also suggest you to enable output caching on your IIS if you haven't done yet. Enable it for all image files i.e. .png,.jpg, etc., .css files, html and cshtml files and js files too.
Here is how you can do it

Visual Studio development server unexpectedly executes Thread.Abort

The following code results in our Visual Studio 2012 development web server, or the alternative IISexpress, effectively killing the AppDomain of our WebApp by executing a Thread.Abort in all of it's constituent threads from the threadpool. What I do not understand is why? I cannot find anything documented which specifically states under what circumstances the web server would do this. Also, there is precious little from the "verbose" output of the web server itself.
This took several days worth of effort to track down. Normal debugging techniques proved worthless. I eventually had to resort to the tried and tested method of commenting out method bodies until I reached that "ah-ha" moment.
One of our developers had inadvertently created a temporary file and then closed it again deep within one of our ASP.NET services.
FileStream fs = File.Create(strFilePath);
|
fs.Close;
The strFilePath was accidentally set to the same location as the WebApp's assembly location. Namely:
var basePathUri = new Uri(Assembly.GetExecutingAssembly().CodeBase);
var strFilePath = Path.GetDirectoryName(Uri.UnescapeDataString(basePathUri.AbsolutePath));
It's worth saying, that this error is now corrected by correctly writing to the system temporary file space.
So once, again, we know this is bad practice, but why does the Visual Studio web server behave as it does?
PS
I know there is a deployment difference between a development web server and a production web server (e.g. apache or nginx) with regard to copying all content to a temporary ASP.NET location. In fact, this problem does not manifest in deployment.

How can I be more productive building MVC C# applications?

I'm a relatively new C# developer, and I'm finding myself roughly 1/5th as productive building C# MVC applications in VS 2010 than I was doing it previous in Zend using php by hand using vim.
I work in an iterative cycle of write tests / write code / run tests / integrate & debug problems.
This last step involves building the code using visual studio, debug > attach to process > w3wp.exe and then visiting http://localhost/App/ (localy copy of IIS 7.5) and trigging some event/etc that kicks the VS debugger into running.
Upon finding a bug / issue I then stop the debugger, fix it, recompile and repeat.
This is unbelievably slow.
Compiling the application takes maybe 2 seconds, but the first time loading up in the debugger takes about 60-80 seconds. Turning the debugger off improves the speed of this fractionally, but not significantly.
There is nothing special about my copy of IIS; it's just configured to run locally serving the project directory from the visual studio project.
My machine isn't fantastic, its a 3.0Ghz duel core running windows 7 with 4 GB of ram... but this is just beyond a joke. I'm spending more time staring at my screen waiting IIS to do something than I am writing code.
Subsequent page loads are obviously really quick, you know instant page loads.
The issue, I guess, is that IIS needs to run application startup and load files and do whatever it does with the application pool worker when I recompile, which means the initial startup is slow (IOC, web config files, etc).
...and yet, I can't seem to find many other people on the net complaining about this, so I guess it must be some combination of how the application is configured, how IIS is configured and my workflow which are messed up.
What am I doing wrong?
If there's no way around IIS startup, how should I be doing development to avoid this problem?
I think most people use the Built In Visual Studio Development Server (IIS-like). If you are running SP1 you can also use IIS Express which is more robust for larger and/or multi/cross website applications.
Right Click on your Web Application -> Properties -> Web Tab to select a Debug Server.
I agree with you, that it might have to do something with your local system. Obviously it's not possible for me to tell you how your system is missconfigured, but I would check that first in more detail.
Some other hints which might be helpful, even if they don't solve the root of the problem:
Use the build in development server as Erik proposes.
If you have only changed templates, you don't have to restart from scratch.
If you have good unit tests, you don't need to start the web application at all.
Does IIS 7.5 have app pools? If yes, you could restart just the app pool, which is much faster than restarting the whole IIS.
PS.: I have seen quite some strange behaviours when opening database connections, if the network is configured in a bad way. Even if it's on the local machine, you might have strange DNS lookups or something like that. Just as an additional hint about what to look for.

T-SQL Query always returns results in SSMS, but occasionally fails to return results when executed through .NET via ADO.NET

I am more than a little confused with an issue I have encountered 3 times in the past 2-3 months. The title of this question outlines the issue, but for more detail:
I have an SP which always returns results without issue when executed through SQL Server Mgmt. Studio, however very rarely (but enough to cause major headaches)- it will simply NOT return anything when it is called through a .NET console app.
I've checked the SQL Server and Windows Server error/application logs that I know of (SQL Server Logs and everything in Event Viewer on the Windows Server in which the SQL Server resides) and nothing appears amiss...
What in the heck could be the cause of this? The app, SP, and everything work just fine. It's just that when called from the .NET app, this SP fails to return data. I know the obvious solution would be to debug from VS and see the details of the connection (I also get no Exception when this happens) in the debugger from beginning to end of the SP execution, but this is not possible as the issue occurs out of the blue and is not reproducible. I want to prevent it from happening again.
Is this a possible spontaneously dropped SQL connection or what? Any thoughts, comments, and suggestions are greatly appreciated.
A common issue here is the SET options that are in play. This is not obvious, since you rarely set them explicitly from either SSMS or ADO.NET, but they can be different. In particular this can impact anything involving persisted indexed columns, sql xml, and a range of other behaviours; null-equality, concat-null, max-rows, schema-only (no data), interpretation of quotes, arith-abort, etc.
So: find what SET options are in play.
This can be an even bigger problem is some misbehaving code (either in the DB or the calling client) sets an option for some purpose and doesn't set it back. Especially if that code only runs occasionally.
IS thing thing dynamic at all? It could be you are creating a sql statement that doesn't work in some cases.
Profiling is the only thing to do to catch it in the act. See what values it sends when it doesn't behave as expected.

Categories

Resources