I have looked at similar articles on this topic without actually getting a solution to the problem i'm facing.
I have a c# web service that contains two threads and they all started and worked perfectly when tested on the ASP.NET development server on my development machine, which might suggest that the code is in order.
Since I intend to deploy it on IIS 7.5, I decided to test it on a local copy of IIS. On IIS, I noticed that the threads refuse to start. Before I resorted to using threads, I have used System.Timers Timer, and System.Threading Timer with the same behaviour, that is, the Timers worked on my ASP.NET development server but refused to work when tested on IIS. Please, What could be the reason for this and what do I do to solve this bottleneck.
Thanks so much for your contributions.
I just learnt the hard way that I wasn't supposed to use threads in the web service. After removing the threads, it still worked fine.
Related
I have performance issue with ASP.NET Web API app hosted as Azure Web App. After deploying the first request to web service is really slow (we are talking about seconds here). Subsequent requests work just fine without extra delay.
"Always on" feature works fine keeping the app from unloading but this does not solve my issue. I do not want this first request to warm up the service (BTW - should it be warmed up?).
I've used diagnostic and profiling tools in Azure without finding the root cause of this thing. I've used Application Insights as well. It seems like one function of mine needs much more time to execute during this first request - debugging the app locally I did not notice any performance issue with mentioned function.
How can I fix this?
Thanks!
This bit me as well. "Always On" will only make automated calls to your service root - think about slapping the process every time so it won't fall sleep.. We don't use this in our PROD services, we rather have an Azure Availability Test invoking a Ping() endpoint every 5 mins - two birdies, one stone. Besides, AlwaysOn will generate 404 errors in App Insights if you don't have anything in the root..
A totally different thing is warming up each one of the endpoints so they could get JIT-ed and ready, and I have not found anything better than a warm-up script with the whole list of endpoints to call, it is not perfect but it works. So every time you do a deployment o do a restart this will automatically run and your first calls won't be hurt.
Have a look at this article.
I hope this helps
I have an MVC application that send an e-mail periodically using Quartz.NET. Although the published application works properly on IIS, it cannot works after recycling application pool or restarting the application on IIS. Searching on the web I found several post suggesting to make some changes on config files or IIS, but none of them working properly. So, is there any method to solve the problem? I need a solution that can be applied on application side (or on IIS side if it is simple just making a config changes, etc.). I think this is a common problem when keeping an application on IIS, isn't it?
Note: I use Windows Server 2008 and IIS 7.5.
You do not mention in your question where your application is going to run so I guess it's going to be hosted in-house.
Following your comment I gather you do not have any problems installing and running a Windows Service on your server.
My suggestion - and something I've implemented in the past - is to use the ASP.NET MVC application only as a UI where you create, delete or suspend your jobs/triggers which will be persisted in a database so, whatever happens to your application, you won't lose your jobs/triggers and they will be executed as soon as the application goes back on-line.
The database will be shared with the other layer, the Windows Service, which will be responsible for running your scheduled jobs.
First step is to setup and use AdoJobStore to store Quartz.Net data. As you can see in the post there are a few providers you can use.
Second step is to create and configure your Windows Service. I would use TopShelf to host it. The implementation is very simple and straightforward; plus you can use the Quartz.Net integration provided here.
If you go through the documentation you won't find any problem integrating the solution.
Quartz.Net depends on some configuration you have to add in your app.config/web.config. In this answer there's a detail explanation about the configuration and AdoJobStore.
There are a few things to remember implementing this type of solution.
Your Web Application is going to set the property threadPool to ZeroSizeThreadPool in your config:
<add key="quartz.threadPool.type" value="Quartz.Simpl.ZeroSizeThreadPool, Quartz" />
or in your code:
properties["quartz.threadPool.type"] = "Quartz.Simpl.ZeroSizeThreadPool, Quartz";
and it's never going to start the Scheduler (your windows service is going to use that).
I'm unable to execute the following from a asp.net web application.
System.Diagnostics.Process.Start("Notepad.exe");
The project builds without errors and it works fine locally. On the live server, it just times out. I spent hours researching this online, only to find that there are others that have had the same problem. So far nothing has worked for me. Most replies seem to suggest looking at permissions. Our IT Director isn't sure how to resolve this issue either.
You probably run the web app on IIS Express locally. That means anything like opening Notepad can work, as it runs under your account in your session.
However, running on full IIS is completely a different thing, as revealed in my blog post,
https://blog.lextudio.com/2015/04/web-application-differences-in-visual-studio-and-iis/
Even if Notepad is opened in that way, it is in session 0 on IIS server side, and you cannot see it.
If you attempt to open Notepad in JavaScript at client side, you might also be forbidden to do so, as browsers run client side web apps in sandboxes, which removes access to the operating system resources.
Usually only web apps that explore the security holes in web browsers can launch Notepad by bypassing sandboxing as well as other security protection mechanism, and you probably won't be allowed to do so in a normal web app.
We have a ASP.NET 2.0 (i know it's old!) website hosted on a Windows 2003 server and IIS 6.0. The application periodically crashes after every two months.
We have tried to analyse the memory consumption and other things by using Telerik and very recently Riverbed.
Any idea what should we be looking for?
UPDATE: After searching the WWW I stumbled upon this a fix where they tell that we can increase the request queue limit to stop this issue. Although the root cause analysis is still desirable.
This question is really around analysis - how do I analyze what's causing the problem?
Situation - we have a C# webservice configured through IIS 7.5, and a website in the same intranet domain hitting the webservice with POST and GET methods. Server is windows 2008 r2 64-bit, C# is 4.0. The first call of the day is slow (30-60 seconds), though I have not checked if I try again later in the day is it slow as well. Subsequent calls are 2-3 seconds. When checked using FireFox web console or firebug, the time is spent on "Waiting" for the webservice.
Things I've tried :-
Setting no recycle time for the webservice AppPool
Setting no idle time-out for the webservice AppPool
Setting proxy bypassonlocal = true and usesystemdefault = false in case it's a proxy look up issue
Nothing's worked so far. My thought is that even if it's C# compile to machine code on first run, it shouldn't 'expire' if the AppPool does not time-out or recycle, yet it is slow everyday.
So flat out of options, how do I go about trying to find the source of the problem? Any diagnostics I can run on the server to check what the webservice is doing?
From your description it sounds as if your webservice might be going to sleep given the first call after a period of inactivity is slow and subsequent calls are faster.
I've seen this behaviour occur on many of my .NET IIS applications, can be frustrating to say the least!
This is however, default .NET behaviour, but there are ways of keeping your application awake, especially as of .NET4.
I refer you to the following article as a first step. Give it a go and see if this makes any difference for you:
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
Good luck!