What really happens when the web server fails ? I know the usual thing that the Website will be down and the page I have requested is inaccessible.
The cause might be external like too many incoming requests but what really happens in the inner workings of the server that leads to such a condition ?
I might be congestion due to lack of bandwidth or the VM/server that is containing the info/web page
Related
My web app sits behind a Nginx. Occasionally, the loading of my web page takes more than 10 seconds, I used Chrome DevTools to track the timing, and it looks like this:
The weird thing is, when the page loads slowly, the initial connection time is always 11 seconds long. And after this slow request, subsequent loading of the same page becomes very fast.
What is the possible problem that cause this?
P.S. If this is caused by a resource limitation on my server, can I see some errors/warnings in some system log?
The initial connection refers to the time taken to perform the initial TCP handshake and negotiating an SSL (where applicable). The slowness could be caused by congestion, where the server has hit a limit and can't respond to new connections while existing ones are pending. You could look into some performance enhancements in your Nginx configuration.
Use dig command to check you domain name resolution process.
if return multi answer section, check these ips is valid.
You should eliminate the file incallings which are pointing to not-existing files. I had the same issue at a customer where a 404 image caused the problem, as it delayed the loading of other files.
I have an ASP.NET Web API application running behind a load balancer. Some clients keep an HTTP busy connection alive for too much time, creating unnecessary affinity and causing high load on some server instances. In order to fix that, I wish to gracefully close a connection that is doing too much requests in a short period of time (thus forcing the client to reconnect and pick a different server instance) while at same time keeping low traffic connections alive indefinitely. Hence I cannot use a static configuration.
Is there some API that I can call to flag a request to "answer this then close the connection" ? Or can I simply add the Connection: close HTTP header that ASP.NET will see and close the connection for me?
It looks like the good solution for your situation will be the built-in IIS functionality called Dynamic IP restriction. "To provide this protection, the module temporarily blocks IP addresses of HTTP clients that make an unusually high number of concurrent requests or that make a large number of requests over small period of time."
It is supported by Azure Web Apps:
https://azure.microsoft.com/en-us/blog/confirming-dynamic-ip-address-restrictions-in-windows-azure-web-sites/
If that is the helpful answer, please mark it as a helpful or mark it as the answer. Thanks!
I am not 100% sure this would work in your situation, but in the past I have had to block people coming from specific IP addresses geographically and people coming from common proxies. I created an Authorized Attribute class following:
http://www.asp.net/web-api/overview/security/authentication-filters
In would dump the person out based on their IP address by returning a HttpStatusCode.BadRequest. On every request you would have to check a list of bad ips in the database and go from there. Maybe you can handle the rest client side, because they are going to get a ton of errors.
Write an action filter that returns a 302 Found response for the 'blocked' IP address. I would hope, the client would close the current connection and try again on the new location (which could just be the same URL as the original request).
Getting this error message in the browser:
Attention!!!
The transfer attempted appeared to contain a data leak!
URL=http://test-login.becreview.com/domain/User_Edit.aspx?UserID=b5d77644-b10e-44e0-a007-3b9a5e0f4fff
I've seen this before but I'm not sure what causes it. It doesn't look like a browser error or an asp.net error. Could it be some sort of proxy error? What causes it?
That domain is internal so you won't be able to go to it. Also the page has almost no styling. An h1 for "Attention!!!" and the other two lines are wrapped in p tags if that helps any.
For anyone else investigating this message, it appears to be a Fortinet firewall's default network data-leak prevention message.
It doesn't look like an ASP.NET error that I've ever seen.
If you think it might be a proxy message you should reconfigure your browser so it does not use a proxy server, or try to access the same URL from a machine that has direct access to the web server (and doesn't use the same proxy).
This is generated from an inline IPS sensor (usually an appliance or a VM) that is also configured to scan traffic for sensitive data (CC info, SSNs etc). Generally speaking, the end user cannot detect or bypass this proxy as it is deployed to be transparent. It is likely also inspecting all SSL traffic. In simple terms, it is performing a MITM attack because your organizational policy has specified that all traffic to and from your network be inspected.
Links to articles would also be appreciated--I don't know the terminology to search for.
I'm looking to learn how a web application can allow for server-to-client communications. I know the web was not designed for this and that it has been something of a hurdle, and am just wondering what the state of this is, and what the best practices are.
An alternative is constant or occasional polling via ajax, but is it possible for web servers to maintain stateful connections to a web client?
Edit: Another way to ask this question is how does StackOverflow tell a page that new posts are available for it to display that little bar at the top?
StackOverflow polls the server to check if there is more data.
What you're looking for is Comet.
To get true two way communications from a browser you need to use a plugin technology like Silverlight, Flash, et al. Those plugins can create TCP connections that can establish a two way persistent connection with a server socket. Note that you can't really establish the TCP connection with the HTTP server so you'd have to create an additional server agent to do the communicating back to the browser.
Basically it's a completely differnet deployment model to what AJAX sites like Stackoverflow, Gmail etc. use. They all rely on the browser polling the server at set intervals.
Web browsers really aren't set up to handle this sort of communication. The communication is a one way street where the web server is listening on a port (typically 80 or 443) for for information to be sent to it.
I just read the link on comet, and it's interesting approach, but what has to be remembered is that it is still technically being opened by the client. The server is sending code for it to execute, but the browser is ultimately in control and determines when the server communicates with it.
With today's web browsers the server can never technically execute a message being sent to it without the help of the browser. Technically you might be able to get around that by executing some Active X control on the client machine...but I haven't tried it.
You can't, HTTP is stateless. A long time ago Netscape implemented HTTP Push but it wasn't a sucess.
I'd use polling with a web service or similar; no plugin (that is Flash, Java,Silverlight) will have rights in its sandbox to use raw sockets so it'll be a waste of time trying to implement it that way.
I have an IIS7 web application which primarily serves web service requests. As part of our solution we have two web servers and a load balancer, and the load balancer requests a page from each of its load balanced boxes periodically. The page the load balancer loads is named "Health.aspx", it does not have a code behind, and the entire contents of the file Health.aspx is:
OK
However we are observing occasional 400 errors from the load balancer when requesting this page throughout the day which causes the load balancer to eject the machine from its rotation for a period of time.
While there are potentially a number of things which could be causing a problem here I wanted to start at the web boxes themselves and determine whether a nearly empty *.aspx page with no code behind could cause periodic problems.
You should create Health.html and just use that instead. That will also give you some idea of whether it's ASP.NET giving you the 400 problems or IIS.
"400 errors" covers a wide range of potential issues, from a simple not found 404 to bad request 401, and forbidden 403.
Some of these could be caused by bad network cables, nics, lousy load balancer, overloaded server(s), etc.
Incidentally, no, a web page with no code behind is not going to throw that. Also, I'd probably do a little something more in the health.aspx to verify that the server is actually functioning. Like run a calulation or make a simple database request. After all, IIS could simply be caching the file.
Turns out that the problem was just the sheer number of requests and an untimely response time (or really request time - our client connections are very slow) for handling the requests. Requests for Health.aspx were getting caught up with slow client connections and the default MaxConcurrentRequestsPerCPU of 12 was artificially limiting our actual number of requests/second. Increasing this number to 100 - based on carefully testing our hardware against load for our particular application - solved the problem.