Develop Reference

EF6 slow first query implications on deployment

Knowing that Entity Framework is slow on a cold query (first query after model compilation), I am doing some of the standard work around methods to speed it up. Mainly pre-compiled views as well as making a dummy http request on the client side as soon as the application loads to trigger a query to start the model process.
My question here is specifically around how this works for a deployed application. For example, if I deploy this on Azure, is it the first cold query for the entire application that will trigger the model compilation, or will this slow cold query happen for each individual user that uses the application? In simple terms, does it happen once and only once, or every time a user hits the site for a new session?

The EF slow start is triggered from the first request/s coming into the web server that requires database services.
A couple points to note,
If you deploy to an Azure web app, ensure that the 'AlwaysOn' application setting is enabled. If not, after a given time period the web app will be suspended and the next request will trigger another cold start.
Similarly if you deploy to a VM with IIS you'll need to check the application recycling settings.
When you deploy a new version of the application code, the process will need to be restarted which will cause another slow start.
A good approach to mitigate such slow starts is by using deployment slots and pre-warming slots before sending actual user traffic to it. This is straightforward to achieve using Azure Web App deployment slots.

100 % CPU by IIS process by Service Model-4 module after the wcf request has passed

I have a problem I'm fighting for a week now. I have a WCF service running in IIS 8.5 on Windows Server 2012 R2 and a windows service client who is making one or two requests at each 30 seconds. At some point (usually withing two hours of the service running) one of the requests is causing the service app pool (separated from other app pools) process to gain CPU usage. In IIS worker process section can be seen that this request never ends and is hanging in ServiceModel-4 module in AuthenticateRequest state (i.e most likely it is in infinite loop somewhere). At some point another such request is added to the first one, until they become four, staying forever and causing 100 % CPU usage (there are 4 logical processors on the machine). What I did to investigate , fix this problem:
used wcf tracing and custom logging to determine where the problem is. Wcf tracing actually shows all the requests made to the server passed succesfully in milliseconds (!) (at the same time wcf tracing on the client side shows of course time out on the same requests). Custom logging also is showing that the service code is calling returtn of the requested operation. The result of the method are two simple dto objects, so no possible serialization issue and also there are no enpoint behaviors or wathever custom code which is execting before sending reply from the service (except the method code, which, as I mentioned returns successfully).
used iis failed request tracing which shows the request reaching the ServiceModel-4 without continuing with the following information:
ModuleName : ServiceModel-4.0
Notification: AUTHENTICATE_REQUEST
HttpStatus: 500
HttpReason: Internal Server Error
HttpSubStatus: 0
ErrorCode: The operation completed succesfully (0x0)
used Debug Diag for tracing requests continuing more than 10 minutes and saw the threads which are running long time. The stack trace is as follows:
or as follows:
I've seen these are called from iis process. Since thiese are .Net function I suspected first corrupted .Net installation, moreover there were both .Net4.5 and .Net4 installed on the server (which I don't know how exactly could happen). So:
I deinstalled .Net4 and From windows features on/off i turned off .Net4.5 features, restarted and after that i turned them on, restarted, without success
after that I by same way reinstalled the IIS (from Windows features). Again no success.
Does not have any more ideas.

it seems I have found the answer (but havent used Dot Trace or other tools). There was an access to a Generic Dictionary from multiple threads. This seems to be a known problem:
https://blogs.msdn.microsoft.com/tess/2009/12/21/high-cpu-in-net-app-using-a-static-generic-dictionary/
https://blogs.msdn.microsoft.com/asiatech/2009/05/11/asp-net-application-100-cpu-caused-by-system-collections-generic-dictionary/
Actually I noticed this problem in the beggining of the research but ruled it out, because i couldn't reproduce it (probably because I havent't testing the dictionary in iis app, of course I received various exceptions, but not a 100 % Cpu) and mainly because all logs showed that the code, accessing the dictionary has passed, also the stack trace above has nothing to do with the dictionary.
However I think that the problem happened during the serialization of this dictionary (which is data contract) which explains the logged information.
Still cannot explain how this exactly is happening. If anyone can explain it I think it will be a good knowledge for everyone.

Can a web application hosted on another machine receive data from a local .NET application without sending data to the server?

Some information:
I've got a USB scale attached to a local machine that's being read by a .NET application. I've also got a web server that needs to get these scale readings and display it to the end user in a browser window(IE 10).
We have a solution now that does this already, by having the win app send data to the web server which relays it back to the user with a jscript control. It does the job, but it causes performance issues as the scale is constantly updating and sending data to the server and back, and if there's a delay it causes all sorts of issues. so I'm looking for a solution that DOES NOT send this data over HTTP at all, but still displays in the web form.
It seems like it should be easy to just have the jscript retrieve this same data somehow but it's apparently not so simple. There's security issues, among other things. I've looked into things like Silverlight and ActiveX controls, which seem like they may be capable of doing the job but I was hoping there would be a better(or just simpler) way of doing it, perhaps with jscript directly. I thought of just using some local file that both of these applications can access but it seems like there would be issues with permissions and synchronization. Any thoughts?

I don't know that you would consider this simple, but it seems as if a more correct way to do it would be to setup a web service on the computer that is connected to the scale and then query this web service using ajax from the browser.

How to debug a C# service that stops for no reason on production server

We have implemented a pair of services in C# that send and receive faxes. These services have been running flawlessly for several years on several servers - until last week.
One of our clients upgraded to Windows Server 2012. We installed the services and all hellbroke loose.
Basically, one of the services appears to work for several minutes, and then, for some unknown reason - goes to the OnStop method. So someone, or something - is stopping it, but I don't know what it is.
How could I go about debugging this? I am new to C# and this is not my code.
Any help would be appreciated.

Is interesting the fact you are sending and receiving faxes: It colud be related to some Session 0 Insolation introduced with windows server 2008/2012, that could cause problem in graphic related services.
If you have some chanches to run the server on a developement machine, using a Windows7/8 box and a SYSTEM user, you can probably reproduce the problem.

If it only stops on the production server, it is reasonable that there is something different about the production server than your development server/workstation.
It is probably unlikely that you're allowed to hook a debugger into something on the production server, but the best way to handle this is just to log the he** out of the code.
You should introduce enough logging to figure out:
Where it stops
Why it stops (my money is on an exception)
The state of the application at that time (related to the crash)
This will probably have to be done in iterations, unless you go all out to begin with.
Services and logging go hand in hand, so just implement it.

CPU usage goes high in Asp.Net MVC application while longer process run by other utility

I have one application which is developed in ASP .NET MVC 3 which using a SQL server database.
Apart from this, I have one console application which calls an external web service and update the same database with the information and business rules. (Basically we iterate the records from Web service and process the business rule and update the same database), we have configured the console application with Windows scheduler to process it periodically.
The problem is, when my Console application runs periodically, it uses the 100% CPU usage (because we're getting more than 2000 records from web service), and because of that my current MVC application is gets haging OR sometime works very very slow because both application are configured on same windows server.
Could anybody please do let me know that How would I resolve this problem where I want both the things on same server because I have central database used by both application.
Thanks in advance.

You haven't given any detail that anyone can really provide resolution, so I'll simply suggest how I would approach it.
First, I would review the database schema with a DBA to make sure there aren't things like table locks (or if there are, come up with strategies to compensate for them). I would then use the SQL Server profiler to see where (or if) there are any bottle necks in SQL server while these things are running. I would then profile the console application to make sure it's not doing something it doesn't need to be doing. I might even consider profiling the web site to see if there's anything in there that might be contributing to slowness.
After that, I would figure out how to get rid of the Console application and work its functionality into the site. Spawning another application on a given web request is not scalable. More than a couple of those come in at once and you've got the potential to bog the server down very easily.