I have write a test code in a new web application as below:
public ActionResult Index()
{
Logger.Write("start Index,threadId:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
MyMethodAsync(System.Web.HttpContext.Current.Request);//no await and has warning
Logger.Write("end Index,threadId:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
return View();
}
private async Task MyMethodAsync(HttpRequest request)
{
Logger.Write("start MyMethodAsync,threadId:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
await SomeMethodAsync(request);
Logger.Write("end MyMethodAsync,threadId:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
}
And here is the log:
2017-11-15 19:55:31.904 start Index,threadId:35
2017-11-15 19:55:31.919 start MyMethodAsync,threadId:35
2017-11-15 19:55:31.919 end Index,threadId:35
2017-11-15 19:55:53.324 end MyMethodAsync,threadId:46
The client brower will receive response at about 2017-11-15 19:55:32 and it accord with my understanding. In my actual project production environment,it writes the same log as above, However, the client brower received response in about 22 seconds later at about 2017-11-15 19:55:54. It seems that even the main thread complete the work, the main thread do not return the response until the new thread complete the work.
I have debug this problem serveral days. Could you help me please?
async-await does not change the HTTP protocol. The request goes to the server, the server produces a response and sends it to the client.
It just changes how ASP.NET requests are processed by ASP.NET.
And it doesn't make the request handling faster. Quite the contrary.
But it does use more thread pool threads and makes the server more responsive under heavy load.
Related
WHAT I HAVE:
My code flow is like this:
(1) construct request
(2) POST to URL
(3) Write results to output directory
#Bean
public IntegrationFlow validateRequest() {
return IntegrationFlows.from("REQUEST_CHANNEL")
.channel(c -> c.executor(new SimpleAsyncTaskExecutor()))
.handle(requestModifier, "constructRequest")
.handle(Http.outboundGateway("POST_URL", restTemplate)
.httpMethod(HttpMethod.POST)
.mappedRequestHeaders("ab*", "TraceabilityID", authenticator.getToken())
.charset("UTF-8")
.expectedResponseType(Response.class))
.handle(outputWriter, "writeToDir");
}
WHAT I NEED:
The timeout for the POST_URL is 20000 ms.
My code tries to write the response before it receives a timeout and gives a null pointer exception.
Which of the below approaches should I use?
-> Add wait() to Http.outboundGateway so that the thread waits for atleast 20 s for a response.
-> Make the whole thread sleep for 20 sec. Can you please give me an example for this?
I'm trying to figure out why my webservice is so slow and find ways to get it to respond faster. Current average response time without custom processing involved (i.e. apicontroller action returning a very simple object) is about 75ms.
The setup
Machine:
32GB RAM, SSD disk, 4 x 2.7Ghz CPU's, 8 logical processors, x64 Windows 10
Software:
1 asp.net mvc website running .net 4.0 on IISEXPRESS (System.Web.Mvc v5.2.7.0)
1 asp.net web api website running .net 4.0 on IISEXPRESS (System.Net.Http v4.2.0.0)
1 RabbitMQ messagebus
Asp.net Web API Code (Api Controller Action)
[Route("Send")]
[HttpPost]
[AllowAnonymous)
public PrimitiveTypeWrapper<long> Send(WebsiteNotificationMessageDTO notification)
{
_messageBus.Publish<IWebsiteNotificationCreated>(new { Notification = notification });
return new PrimitiveTypeWrapper<long>(1);
}
The body of this method takes 2ms. Stackify tells me there's a lot of overhead on the AuthenticationFilterResult.ExecuteAsync method but since it's an asp.net thing I don't think it can be optimized much.
Asp.net MVC Code (MVC Controller Action)
The RestClient implementation is shown below. The HttpClientFactory returns a new HttpClient instance with the necessary headers and basepath.
public async Task<long> Send(WebsiteNotificationMessageDTO notification)
{
var result = await _httpClientFactory.Default.PostAndReturnAsync<WebsiteNotificationMessageDTO, PrimitiveTypeWrapper<long>>("/api/WebsiteNotification/Send", notification);
if (result.Succeeded)
return result.Data.Value;
return 0;
}
Executing 100 requests as fast as possible on the backend rest service:
[HttpPost]
public async Task SendHundredNotificationsToMqtt()
{
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 100; i++)
{
await _notificationsRestClient.Send(new WebsiteNotificationMessageDTO()
{
Severity = WebsiteNotificationSeverity.Informational,
Message = "Test notification " + i,
Title = "Test notification " + i,
UserId = 1
});
}
sw.Stop();
Debug.WriteLine("100 messages sent, took {0} ms", sw.ElapsedMilliseconds);
}
This takes on average 7.5 seconds.
Things I've tried
Checked the number of available threads on both the REST service and the MVC website:
int workers;
int completions;
System.Threading.ThreadPool.GetMaxThreads(out workers, out completions);
which returned for both:
Workers: 8191
Completions: 1000
Removed all RabbitMQ messagebus connectivity to ensure it's not the culprit. I've also removed the messagebus publish method from the rest method _messageBus.Publish<IWebsiteNotificationCreated>(new { Notification = notification }); So all it does is return 1 inside a wrapping object.
The backend rest is using identity framework with bearer token authentication and to eliminate most of it I've also tried marking the controller action on the rest service as AllowAnonymous.
Ran the project in Release mode: No change
Ran the sample 100 requests twice to exclude service initialization cost: No change
After all these attempts, the problem remains, it will still take about +- 75ms per request. Is this as low as it goes?
Here's a stackify log for the backend with the above changes applied.
The web service remains slow, is this as fast as it can get without an expensive hardware upgrade or is there something else I can look into to figure out what's making my web service this slow?
We have a simple application in ASP.NET Core which calls a website and returns the content. The Controller method looks like this:
[HttpGet("test/get")]
public ActionResult<string> TestGet()
{
var client = new WebClient
{
BaseAddress = "http://v-dev-a"
};
return client.DownloadString("/");
}
The URL which we call is just the default page of an IIS. I am using Apache JMeter to test 1000 requests in 10 seconds. I have always the same issue, after about 300-400 requests it gets stuck for a few minutes and nothing works. The appplication which holds the controller is completely frozen.
In the performance monitor (MMC) I see that the connection are at 100%.
I tried the same code with ASP.NET 4.7.2 and it runs without any issues.
I also read about that the dispose of the WebClient does not work and I should make it static. See here
Also the deactivation of the KeepAlive did not help:
public class QPWebClient : WebClient
{
protected override WebRequest GetWebRequest(Uri address)
{
var request = base.GetWebRequest(address);
if (request is HttpWebRequest)
{
((HttpWebRequest)request).KeepAlive = false;
}
return request;
}
}
The HttpClient hast the same issue, it does not change anything
With dependency injection like recommended here there is an exception throw that the web client can't handle more request at the same time.
Another unsuccessful try was to change ConnectionLimit and SetTcpKeepAlive in ServicePoint
So I am out of ideas how to solve this issue. Last idea is to move the application to ASP.NET. Does anyone of you have an idea or faced already the same issue?
I'm writing my own SignalR Client on Java and I'm facing some troubles.
At first I want to implement PersistentConnection logic. My server code is taken from example:
public class Battle : PersistentConnection
{
protected override Task OnConnectedAsync(IRequest request, string connectionId)
{
return Connection.Broadcast("Connection " + connectionId + " connected");
}
protected override Task OnReconnectedAsync(IRequest request, IEnumerable<string> groups, string clientId)
{
return Connection.Broadcast("Client " + clientId + " re-connected");
}
protected override Task OnReceivedAsync(IRequest request, string connectionId, string data)
{
// return Connection.Broadcast("Connection " + connectionId + " sent ");
return Connection.Send(connectionId, "Connection " + connectionId + " sent ");
}
protected override Task OnDisconnectAsync(string connectionId)
{
return Connection.Broadcast("Connection " + connectionId + " disconncted");
}
protected override Task OnErrorAsync(Exception error)
{
return Connection.Broadcast("Error occured " + error);
}
}
Judging by .NET client code, I understood that in order to connect to server client should:
1) Send request to http://myserver/battle/negotiate and get ConnectionId from response
2) Send request to http://myserver/battle/connect?transport=longPolling&connectionId=<received_connection_id>
My question is waht should client do to maintain connection? How should it listen to server broadcasting messages?
Another issue is that I receive no response when I'm trying to send message from client to server after connection has been established. I send request to http://myserver/battle/send?transport=longPolling&connectionId=<received_connection_id>. Method OnReceivedAsync is always called, but I get no response (independently of data sent).
I'd be grateful for any explanations on my questions and on internal principles of SignalR work.
Thanks in advance.
I've tried to do the same thing that you are doing! I've implemented a SignalR-client for Android and I called it SignalA. :) Have a look at it on github.
There are several methods of communication used in SignalR. My understanding is that SignalR will use the best one it determines will work with the given connection.
The general idea behind long polling is this: The client sends a request to the server with a long timeout period. Say 2 minutes or 5 minutes. If the server has a message to send to the client, it then responds to the client request with the message. Otherwise the request will eventually timeout, at which point the client initiates a new request. So, basically, the client is nearly always in a call to the server. The server only ever answers when it has a message for the client. So the client could send the request to the server and say, 90 seconds later, the server gets a message for the client.
For more information, read the Long Polling section of this Wikipedia article: http://en.wikipedia.org/wiki/Push_technology
But for the specifics, you really need to examine the .NET code closely. Hopefully this overview will give you enough to understand what's going on there, though.
We just recently noticed that executionTimeout has stopped working on our website. It was definitely working ~last year ... hard to say when it stopped.
We are currently running on:
Windows-2008x64
IIS7
32bit binaries
Managed Pipeline Mode = classic
Framework version = v2.0
Web.Config has
<compilation defaultLanguage="vb" debug="false" batch="true">
<httpRuntime executionTimeout="90" />
Any hints on why we are seeing Timetaken all the way up to ~20 minutes. Would compilation options for DebugType (full vs pdbonly) have any effect?
datetime timetaken httpmethod Status Sent Received<BR>
12/19/10 0:10 901338 POST 302 456 24273<BR>
12/19/10 0:18 1817446 POST 302 0 114236<BR>
12/19/10 0:16 246923 POST 400 0 28512<BR>
12/19/10 0:12 220450 POST 302 0 65227<BR>
12/19/10 0:22 400150 GET 200 180835 416<BR>
12/19/10 0:20 335455 POST 400 0 36135<BR>
12/19/10 0:57 213210 POST 302 0 51558<BR>
12/19/10 0:48 352742 POST 302 438 25802<BR>
12/19/10 0:37 958660 POST 400 0 24558<BR>
12/19/10 0:06 202025 POST 302 0 58349<BR>
Execution timeout and time-taken time two different things. Although, the size of the discrepancy is troubling.
time-taken includes all of the network time in the request/response (under certain conditions.). The network transfer time easily outstrips the amount of time a request really takes. Though, normally, I'm used to just seconds of difference not minutes.
Execution timeout refers only to the amount of time the worker process spent processing the request; which is just a subset of time-taken. It only applies if the debug attribute is set to false; which it looks like you have.
Of course, assuming the first request you listed took the full 90 seconds of allowed time out, that still leaves 13.5 minutes left in the time-taken window to transfer essentially 24k of data. That sounds like a serious network issue.
So, either you have a serious transport issue or there is another web.config file somewhere in the tree where the requests are being processed that either sets debug to true or increases the execution timeout to something astronomical.
Another possibility is that the page itself has either the debug attribute set or it's own timeout values.
I have a theory but I'm not sure how to prove it. I've done something similar to cbcolin and logged the time when the request starts from within the BeginRequest event handler. Then when the request times out (1 hour later in our case) it is logged in the database and a timestamp recorded.
So here is the theory: ASP.NET only counts time that the thread is actually executing, not time that it is asleep.
So after BeginRequest the thread goes to sleep until the entire POST body is received by IIS. Then the thread is woken up to do work and the executionTimeout clock starts running. So time spent in the network transmission phase is not counted against the executionTimeout. Eventually the site wide Connection Timeout is hit and IIS closes the connection, resulting in an exception in ASP.NET.
BeginRequest and even PreRequestHandlerExecute all get called before the POST body is transferred to the web server. Then there is a long gap before the request handler is called. So it may look like .NET had the request for 30 minutes but the thread wasn't running that long.
I'm going to start logging the time that the request handler actually starts running and see if it ever goes over the limit I set.
Now as to control how long a request can stay in the transmittions phase like this on a per URL basis I have no idea. On a global level we can set minBytesPerSecond in webLimits for the application. There is no UI for it that I can find. This should kick ultra slow clients in the transmission phase.
That still wont solve the problem for DoS attacks that actually send data.
I came across this article 2 days ago when I had the same problem. I tried everything, it worked on my local machine but did not work on the production server. Today, I have a workaround that fixes the problem and would like to share. Microsoft seems to not apply timeout to IHttpAsyncHandler and I take advantage of that. On my system, I only have 1 handler that is time-consuming, so this solution works for me.
My handler code looks like this:
public class Handler1 : IHttpAsyncHandler
{
public bool IsReusable
{
get { return true; }
}
public void ProcessRequest(HttpContext context)
{ }
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
//My business logic is here
AsynchOperation asynch = new AsynchOperation(cb, context, extraData);
asynch.StartAsyncWork();
return asynch;
}
public void EndProcessRequest(IAsyncResult result)
{ }
}
And my helper class:
class AsynchOperation : IAsyncResult
{
private bool _completed;
private Object _state;
private AsyncCallback _callback;
private HttpContext _context;
bool IAsyncResult.IsCompleted { get { return _completed; } }
WaitHandle IAsyncResult.AsyncWaitHandle { get { return null; } }
Object IAsyncResult.AsyncState { get { return _state; } }
bool IAsyncResult.CompletedSynchronously { get { return false; } }
public AsynchOperation(AsyncCallback callback, HttpContext context, Object state)
{
_callback = callback;
_context = context;
_state = state;
_completed = false;
}
public void StartAsyncWork()
{
_completed = true;
_callback(this);
}
}
In this approach, we actually do not do anything asynchronously. AsynchOperation is just a fake async task. All of my business logic is still executed on the main thread which does not change any behavior of the current code.