I have an autocomplete service that executes in under 1ms - perfect! This is a timing of the method.
When I built this service outside of the project, the service call would take a total of 5ms. The service is a ASMX, and returns a JSON result.
But once I integrated this service into the real project it now takes 200ms, although the method call is actually still executing in 1ms. So it must be serialization, ASP.NET pipeline or IIS.
The project is so big it's hard to know exactly what HttpModules/Handlers are running.
So my question is, is there a simple profiler a can place on a HTTP request in IIS that will tell me how long each stage takes?
BTW this all on my local box, before anyone says network speed!
Many Thanks,
Ash.
You can use Failed Request Tracing, but for status code 200:
Related
In IIS, I have an ASP.net web application that makes many behind-the-scenes calls to an IIS-hosted WCF service.
I never had any issues during development. However, since deploying to a few test servers at work, our tester was reporting that some of the calls were seemingly randomly failing. I verified that indeed, some of those behind the scenes webapp->service calls were failing with a "(417) Expectation Failed". Hitting the back-button and attempting the action again always worked.
A common solution I kept seeing online was https://stackoverflow.com/a/7358457/1669011
After adding that to my web config, the error continued to happen, but instead of returning a 417, would end up returning the results of my web.config's applicationInitialization remapManagedRequestsTo page.
I feel like the web.config fix I mentioned above has just allowed my web application to accept the full body of the response rather than failing when it realised it wasn't the wcf response it was expecting.
So if random services in WCF are returning the results of remapped requests that occur during Application Initialization, does that indicate that my WCF services in IIS are constantly totally shutting down?
What might cause my WCF service to randomly be in a state of "application initialization"? I'm hoping this is just a server issue and nothing to do with my application, as this has come out of nowhere and is risking an upcoming deploy.
Thanks for any assistance
My guess would be time (or very serious exceptions).
Specifically, if the server hosting the WCF service is not being hit often enough, it will shut down the application. Follow the instructions here to ensure the WCF site is not being unloaded: How to keep a WCF site online?.
If it's exceptions, you have not provided enough information to diagnose the issue.
This is ASP.NET ASMX Web Service / .NET Framework 4.0.
In web service, I want to execute one method on another thread something like “Fire and Forget” so that Web Service returns some value in response immediately to web site. That method on another thread could take 10 minutes after Web Service returns response immediately to Web site. Also, I do not need return value of that method.
I have tested this scenario using ThreadPool.QueueUserWorkItem and it seems that thread started using ThreadPool will still keep executing even after Web Service returns response back to Web site. Am I correct here? Also is there a better way to achieve this?
The problem is that every now and then, ASP.NET will recycle the app pool. Because it doesn't know about your background task, it will not be considered and will be aborted when the AppDomain is disposed.
Most of the time, the work will complete, but if you run for long enough, you will encounter this scenario.
There are two solutions:
1) The "proper" way is to write a Windows Service that runs outside ASP.NET. You can send instructions to the Service over WCF.
2) The "quick and dirty" way is to write a hidden web service in your ASP.NET site that is never called by users. Your app starts an asynchronous request to the hidden service and then returns its own result to the user, without waiting.
ASP.NET does not know that the request to the hidden service came from inside your app - it just treats it as another request. Because ASP.NET knows about this request, it will not abort it when it recycles.
When calling an asp.net web service from a windows mobile device project, I am catching an exception ( WebException ) and the response inside that seems to be "BadRequest".
This is occurring on a live system but not locally in development. But they both have the same build....
When we point our development code at the live web service we get the BadRequest error again. Is there any way I can get more information about this error?
We use Elmah for logging and can confirm no exceptions are being thrown in the web service itself, in fact, it isn't even getting invoked!
Bad Request is a generic error which means the server didn't even bother looking much at the request from the client because it was significantly malformed in some way (service receive buffer lengths exceeded, etc.).
Try to send the server something simpler from the client until it works and/or gives a different (more precise) error.
Unfortunately, server exception handling or viewing traffic on the wire with a tool like Fiddler is probably not going to be helpful in this scenario.
It would help to know which version of web services this is (ASP.NET 2.0, WCF, etc.).
We have an application that hits a web service successfully, and the data returned updates our DB. What I'm trying to do is allow the user to continue using other parts of our web app while the web service processes their request and returns the necessary data.
Is this asynchronous processing? I've seen some console app samples on the msdn site, but considering this is a web form using a browser I'm not sure those samples apply. What if the user closes the browser window mid request? Currently we're using the Message Queue which "waits" for the web service to respond then handles the DB update, but we'd really like to get rid of that.
I'm (obviously) new to async requests and could use some help figuring this out. Does anyone have some code samples or pertinent articles I could check out?
Yes, what you're describing is async processing.
The best solution depends to some degree on the nature of the web services call and how you want to handle the results. A few tips that might help:
One approach is to send a request from the initial web request to a background thread. This works best if your users don't need to see the results of the call as soon as it completes.
Another approach is to have your server-side code make an async web services call. This is the way to go if your users do need to see the results. The advantage of an async call on the server side is that it doesn't tie up an ASP.NET worker thread waiting for results (which can seriously impair scalability)
Your server-side code can be structured either as a web page (*.aspx) or a WCF service, depending on what you want to have it return. Both forms support async.
From the client, you can use an async XMLHTTP request (Ajax). That way, you will receive a notification event when the call completes.
Another approach for long-running tasks is to write them to a persistent queue using Service Broker. This works best for things that you'd like users to be able to start and then walk away from and see the results later, with an assurance that the task will be completed.
In case it helps, I cover each of these techniques in detail in my book, along with code examples: Ultra-Fast ASP.NET.
If you're not blocking for a method return you're doing asychronous processing. Have a look at Dino Esposito's article on using AJAX for server task checking.
You can perform asynchronous web service calls using both Web Service Enhancements (WSE) and Windows Communication Foundation (WCF) in your C# code. WSE is discontinued, so its use is not recommended. Generically speaking, if you were to terminate program execution in the middle of an asynchronous call before the response returned, nothing bad would happen; the client would simply not process the result, but the web service would still be able to perform its processing to completion.
If your client web application is responsible for updating the DB, then without anything else in your client code, quitting in the middle of an asynchronous operation would mean that the DB was not updated. However, you could add some code to your client application that prevented the browser from quitting entirely while it is waiting for an asynchronous response while preventing new web service calls from being run after Close is called (using Javascript).
You have 2 distinct communications here: (1) from web browser to web application and (2) from web application to web service.
diagram http://img697.imageshack.us/img697/6713/diagramo.png
There is no point of making (2) asynchronous: you still would have to wait for web service to finish processing request. If you end HTTP request from browser to web application the client would have no clue what the result of request was.
It is much better to make asynchronous request from web browser to your web application. Ajax is ideal for that. In fact, that's what it was created for. Here's couple of links to get you started:
jQuery Ajax
ASP.NET AJAX
What is the difference between Web Services Asynchronous Call and Asynchronous Task's.
We are working an a ASP.NET application that requires to make a call to a Web Service Method that will process thousand rows of data. This process usually takes between 2 to 3 minutes (maybe more maybe less it depends of the amount of Data). So we run all the time in Timeout's on that specific page.
So we decided to go in rout of calling this Web Service Method Asynchronously, but we had a conflict caused by HTTP handler of one of the UI component's that we are using. Well lucky on that case we could remove the page from the httphandler directives.
So far no issues, but here it comes the question, a coworker find out that we can use instead of Asynchronous Webs Services Call, wrap a Synchronous call in a Asynchronous Task in the ASP.NET page and be able to keep the directives to the component, and execute the Web Service Method with out getting a Timeout.
So now my concern is what kind of issues we can find using Asynchronous Task's instead of an Asynchronous Call.
Thank you in advance.
Web services should not be used in this manner by the way. There's a reason HTTP timeouts are so low. You should have the Web service trigger the task either by setting a flag in the DB that an actual service picks up on or the web service should spawn a process.
If I understand your scenario, there should be no issues. In both cases, your page is asynchronous. In both cases, you don't wait for the service to complete - you give up the request thread while the service is running. In both cases, your page takes the same amount of time to execute as it would if you had called the service synchronously.