I work with a fairly large WebAPI web service, and we have started to discuss performance monitoring.
The idea is to capture the End-To-End performance, which for our WebAPI would include a TCP connection, SSL handshake, F5 firewall and load balancing, and WebAPI receiving the request and sending the response. I think we are more concerned with receiving, processing, and sending data than the connection establishment.
My (maybe misguided) question is this:
If I were to capture the Start and End times for requests using
Application_BeginRequest and _EndRequest, would that essentially
account for End-To-End timing?
In other words, disregarding the (probably minimal) times it would take to establish the connection from the client to the WebAPI, would the BeginRequest and EndRequest methods account for receiving the entire HttpRequest from the client, processing the WebAPI methods, and sending the entire HttpResponse to the client?
Would that get me close to measuring the total time it takes a client to send a request to the server (with possibly large body data), processing time, and time to send the response to the client (with large body data)? Or would I be missing a large part of the receiving and sending?
No, BeginRequest isn't the first event in the pipeline. There are several steps and processes that occur outside of the BeginRequest within IIS. See this article for more information: https://msdn.microsoft.com/en-us/library/bb470252.aspx
A helpful, and free tool for you to visualize the process and provide profiling on your development system is available from Stackify. Check out Prefix, it can provide you full timing information on your development system.
In production, you can use other solutions, such as Stackify's production monitoring and profiling, or New Relic
Related
1- Client application sends a a request to an http server (ashx file, IHttpHandler).
Remark-1: Client is a .dll which will be hosted by other stand alone applications.
Remark-2: Server was first developed as a web service, then for unknown reasons it became very slow, so we implemented it from scratch.
2- Server registers the request in database so that a long duration process is performed on data.
3- Client needs to get notified when the process is finished.
First thing that crossed my mind was implementing a Timer in client. Although I'm not sure if it is ok to do it inside of a host application which is not aware of such usage.
Then it crossed my mind if there may be a something useful in TcpListener or lower layers of socket programming instead of a high frequency timer and flooding server with update requests.
So, I appreciate any suggestion on proper way of doing this task.
UPDATE:
After giving some order to my codes, I update requirements like this:
1- Server "Broadcast"s ID of clients, like: "Client-a, read your instructions", then "Client-c", "Clinet-j",... . This is not mission critical, if a client looses the broadcast, it will return after one minute by a timer tick and will check instructiosn.
2- This server is gona be hosted on a shared hosting plan, at least at first. Solution must be acceptable in boundary of share hosting.
3- preferably all clients connect to the only one socket. No usage of extra resources.
Any recommendation is appreciated.
I'm traying to send many short independent http POST requests to simple .NET webapi app. Requests are created in loop and each of them is sended using new TCP connection. Whats important here each http request only writes to server without waiting for any response. So loop is based on operations:
create request
open socket
write request
close socket
In such scenerio webapi app (ASP.NET MVC 5.2.7) hosted on IIS 10 does not receive any of incoming requests. Control is never transferred to corresponding method in ApiController. I've notice that additional sleep (ex 100ms) added between socket write and close eliminates problem. But minimazing sleep length causes increase number of missing requests. Also waiting for socket read (response) is a fix. But its not satisfying. I cannot wait for server response or add additional delay.
Whats interesting here pile of created requests is not a problem. Even one request created in such manner does not appear in the other side.
What could be a reason of such behavior?
I've tested similar webapi app in ASP.NET Core 2.1. Kestrel handles all requests as it should. Also sending these request to simple TcpListener server works.
We have an WebApi json rest service written in C# for .Net 4.0 running in AWS. The service has a /log endpoint which receives logs and forwards the logs onto logstash via tcp for storage.
The /log endpoint uses Task.Factory.StartNew to send the logs to logstash async and returns StatusCode.OK immediately. This is because we don't want to client to wait for the log to be sent to logstash.
All exceptions are observed and handled, also we don't care if logs are lost because the service is shutdown or recycled from time to time as they are not critical.
At first the flow of logs was very low, probably 20 or 30 per hour during peek time. However we have recently started sending larger amounts of logs through, can be well over a thousand per hour. So the question now is that by using Task.Factoring.StartNew are we generating a large number of threads, i.e. 1 per request to the /log endpoint or is this managed somehow by a thread pool?
We use nLog for internal logging but are wondering if we can pass the logs from the /log endpoint to nlog to take advantage of its async batching features and have it send the logs to logstash? We have a custom target that will send logs to a tcp port.
Thanks in advance.
A Task in .NET does not equal one thread. It's safe to create as many as you need (almost). .NET will manage how many threads are created. .NET will not start more tasks than the hardware can handle.
I want to consume the API messages in c#.net and the response it may come continuously/frequently. Team suggest me to use Web sockets. But I consume the API thru HTTP. Can any one give idea which is better and advantages of Web-socket in continuous receiving the messages as well as in HTTP
HTTP normally uses a request/response model. It does not allow the server to send data to the client, unless the client first requested it. This can be worked around by letting the client regularly poll the server, or by using the long polling technique where the server delays the response until data is available. In both cases, the client will need to regularly make a new request (though less often with long polling).
Web sockets remove these limitations so that polling or long polling is no longer needed.
You may try with ASP.NET SignalR which able to send and receive messages via HTTP. You can achieve real-time web functionality to your messaging application. It's able to have server code push content to connected clients instantly, rather than having the server wait for a client to request new data.
Have a look at these samples -> http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
I am trying to use a COMET solution using ASP.NET .
Trouble is I want to implement sending and notification part in the same page.
On IE7, whenever I try to send a request, it just gets queued up.
After reading on internet and stackoverflow pages I found that I can only do 2 simultaneous asyn ajax requests per page.
So until I close my comet Ajax request, my 2nd request doesn't get completed, doesn't even go out from the browser. And when I checked with Firefox I just one Ajax comet request running all time..so doesn't that leave me one more ajax request?
Also the solution uses IRequiressessionstate for Asynchronous HTTP Handler which I had removed. But it still creates problems on multiple instances of IE7.
I had one work around which is stated here http://support.microsoft.com/kb/282402
it means we can increase the request limit from registry by default is 2.
By changing "MaxConnectionsPer1_0Server" key
in hive "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
we can increase the number of requests.
Basically I want to broadcast information to multiple clients connected to a server using Comet and the clients can also send messages to the Server.
Broadcasting works but the send request back to server doesn't work.
I'm using IIS 6 and ASP.NET .
Are there any more workarounds or ways to send more requests?
References :
How many concurrent AJAX (XmlHttpRequest) requests are allowed in popular browsers?
AJAX, PHP Sessions and simultaneous requests
jquery .ajax request blocked by long running .ajax request
jQuery: Making simultaneous ajax requests, is it possible?
You are limited to 2 connections, but typically that's all you need - 1 to send, 1 to receive, even in IE.
That said, you can totally do this; we do it all the time in WebSync. The solution lies in subdomains.
The thing to note is that IE (and other browsers, although they typically limit to 6 requests, not 2) limits requests per domain - but that limitation is for the entire domain excluding subdomains. So for example, you can have 2 requests open to "www.stackoverflow.com" and 2 more requests open to "static.stackoverflow.com", all at the same time.
Now, you've got to be somewhat careful with this approach, because if you make a request from the www subdomain to the static subdomain, that's considered a cross-domain request, so you're immediately limited to not using direct XHR calls, but at that point you have nevertheless bypassed the 2 connection limit; JSONP, HTML5, etc, are all your friend for bypassing the cross-domain limitations.
Edit
Managing with > 1 instance of IE comes back to the same problem. The limitation applies across all instances. So, if you have two browsers open, and they're both using comet, you're stuck with 2 long-polling connections open. If you've maximized your options, you're going to be connecting those long-polling requests to something like "comet.mysite.com", and your non-long-polling requests will go to "mysite.com". That's the best you'll get without going into wildcard DNS.
Check out some of our WebSync Demos; they work in 2 instances of IE without a problem. If you check out the source, you'll see that the DNS for the streaming connection is different from the main page; we use JSONP to bypass the cross-domain limitation.
The main idea in COMET is to keep one client-to-server request open, until a response is necessary.
If you design your code properly, then you don't need more than 2 requests to be open simultaneously. Here's how it works:
client uses a central message send-receive loop to send out a request to the server
server receives the request and keeps it open.
at some point, the server responds to the client.
the client (browser) receives the response, handles it in its central message loop.
immediately the client sends out another request.
repeat
The key is to centralize and asynchronize all communications in the client. So you will never need to have 2 open requests.
But to answer your question directly, no, there are no additional workarounds.
Raise the connection limit or reduce the number of connections you use.