I have a newly deployed mvc app on a win2008 server box.
I am trying to troubleshoot some very strange ie6 behaviour when over https. if a ie6 user connects to the webserver over https a simple post back or ajax call takes around 1 minute to complete, no errors are raised on the browser, it just sits there ticking away for about a minute, then completes as expected (both server and client as expected). the same post back or ajax call over http works in < 2 seconds.
There are no errors or events raised on the server, so i am flying blind here.
has anyone experienced this behaviour before, any ideas? with no errors or events to work with im not sure where to start. any other browser over https works fine, just ie6.
cheers
andrew
a quick follow up on this one. on further investigation the issue was only occurring on windows 2000 ie6 machines, xp and ie6 was ok. I guess from these results there must be something in the encryption/decryption framework on windows 2000 conflicting with the iis7 server.
I have managed to convince the windows 2000 ie6 users that its time to upgrade!
This brings up another question, when, if at all, do you think its acceptable to block certain versions of software from your web apps?
andrew
Related
Good day.
Background: ASP.NET MVC 3 / SignalR.
I'm developing typical chat component which will be used in a big portal. I wrote small emulator which opens new window with chat component and new SignalR connection in it.
The problem:
Everything works fine, but: Suddenly i noticed that if i open more than X windows/tabs with same component in one browser - server stops to receive any responses from any clients connected with it.
The X is:
5 for IE and Chrome
14 for FF.
I suppose it's a browser issue, because the value differs from one to another. Additionally i noticed that requests can stay pending for minutes! And there is no timeout..
Maybe someone faced with something like this, or know what can cause this strange behavior?
Thanx in advance, Jan.
I'm going to assume you're using IIS 7/7.5 on windows 7. If you are indeed using Windows7 then you need to use IIS Express since it only supports 10 concurrent connections (Client OS limit). Alternatively you can use Windows Server to get the full benefits of IIS.
This is the first post in three days of googling that came close to my experience. I am using the .NET client and have tried isolating the issue by creating an app with just the problem areas. The difference in our situation is this: I don't seem to have some connection limit on the client. In fact, I have no issues until I deploy my .Net hub to the windows server 2008 hyper vps. IIS express runs everything as smooth as butter. I've checked to make sure the asynchronous services and features are running and I've followed the performance tuning articles that david mentions in the documentation, adjusting the setting for thread queue maximums and the like. Note that the minute-two minute delays you describe are identical to mine. I updated to the latest version of SignalR (.4) from nuget and it broke my solution for some reason.
Can you tell me what version you're on? I suspect it could have something to do with security on the physical host where my vps is running. I am going to try it on a different virtualization platform to rule out hyper v issues.
Please, see my answer here: Is there a way to get number of connections in Signalr hub group?
The idea is to overwrite connectionid.
I have a new IIS7 box running Windows Server 2008 Web Edition (x64), and I have set up an existing classic ASP site there. The site works fine and super speedy for the most part, but will randomly hang (about 1 out of 20 or so requests). By hanging, I mean I will click a page from the browser, and the browser (Crome on Mac) never responds -- it just continually loads until I finally get the following error after about 3 or so minutes:
Error 7 (net::ERR_TIMED_OUT): The operation timed out.
I'm pretty sure this is a Chrome-specific error, so I'm not too hung up on the actual error, but the cause of the time out. The site connects to a SQL 2005 server on the same network, but I'm pretty sure this isn't a SQL timeout, as that would happen within 30 seconds, and give me a specific error about SQL. I think this is an issue w/ my site, or the server.
Note that often after seeing this, I can simply stop the request and reload the page, and it will load just fine, super speedy again.
I'm not even sure where to begin troubleshooting this. I have to figure this out, otherwise this will mean a new server purchase down the drain.
Thanks in advance for any suggestions.
I've noticed a few more things about this problem. It'll happen more often after I've published files to the server (even static content like js or css files). It'll also happen occasionally on other sites running ASP.NET. Namely I've noticed the timeout on dotnetkicks.com which is also running IIS 7.5. Again, this only occurs in Chrome.
I've also tried uninstalling and re-installing Chrome but the problem continues. My next step is to try this from a couple different computers running Chrome outside my network.
UPDATE (April 29, 2011)
So I moved to Colorado a couple weeks ago and I haven't seen this problem occur even once since I moved. That leads me to conclude that 1.) my internet connection in Dallas was flaky and 2.) Chrome was less forgiving of a poor connection than other browsers. And of course, it basically rules out any possibility of there being a problem at the server's end.
A while ago I wrote a webserver which I'm using on a site of mine.
When I navigate to another page in Chrome while the images from this homemade webserver are still loading, they stay cached as only half-loaded.
Is this a known bug in Chrome, or an issue with my implementation of the HTTP protocol?
My webserver uses E-Tags for caching.
First Rule of Programming: It's your fault
Start with your code, and investigate
further and further outward until you
have definitive evidence of where the
problem lies.
You need to apply this rule here. What are the chances that Chrome, when communicating with Apache, is likely to exhibit this kind of bug deep into it's 6 (at least) major iteration?
I would put a traffic analyser onto your server and view the exchanges carefully. Next I would compare them with those from a well-established web server like Apache and note any differences.
Two Win2003 servers running ASP.NET sharing same SQL Server, one is DEV the other is LIVE. They are both clones of each other, one is the development box. The dev box is going really slow but I noticed it even happens on a 404 response even. When I browse to a fake URL with either domain to get a 404, the dev box was like 1.4 seconds and other box was like 200ms. So it wasn't recent code changes. Is there some IIS configuration or web.config setting that would cause this?
(I did a traceroute to both and it turned out equal)
It could be a lot of things:
The DEV machine is resolving or trying to resolve the clients' DNS name.
The DEV machine has to perform a DNS query for the DB machine.
The DEV machine not using connection pooling (check the connection string).
Is the KeepAlive setting the same in both machines?
Is there any AD authentication involved? Could that be slower from DEV?
What if you do the POST locally on DEV? Is it still slow?
Are you on the actual dev console?
If so, is it a Firefox or WebKit IPv6 issue? Many of us devs have IPv6 available on our own boxes, and some browsers are pretty slow with it if it's not set up completely. Try using IE and see if you get a fast response on your dev box.
When I access local apps in Chrome, it takes several seconds for the page to display. Same with Firefox until I disabled IPv6 in its config.
Since even a 404 Not Found is slow, that says it probably isn't related to your DB, unless perhaps you're doing some sort of logging or other DB access from Global.asax or an HttpModule.
Have you looked in the Windows error log to see if any errors are being reported?
If ping and tracert from your client to both servers looks OK, and if it also looks OK from the web servers to the DB, then you might look at things like:
Hardware problems (flakey network cables are a common culprit). Maybe try swapping your live and dev machines, and see if the problem stays on the same hardware. Flakey disks can also cause slowness as the controller retries.
IIS-related configuration errors. If the site works and is just slow, you might look at your back-end logging, tracing, etc, if you have any.
You might also look into upgrading to Win 2008. IIS 7 has some much-improved debug facilities, including things like Failed Request Tracing.
This problem is beginning to annoy.
After my machine (Vista Ultimate) has been up for a while, running my ASP.NET web site project for debugging in VS2008 results in Internet Explorer "hanging". It doesn't seem to get past the network access stage, you know when it says "Loading web site", or "Waiting for".
I've attached a screenshot of IE. Note the status bar. It stays like that forever. I have to restart it and cross my fingers for it to work the next time. Invariably, it doesn't.
This happened with IE7 and IE8.
I am using the ASP.NET Web Development Server/Cassini. I have tried restarting this each time which seemed ot have got it, but then not so any more.
I'm up to date on patches.
ie screenshot http://img40.imageshack.us/img40/5446/iehanging.png
So thankfully Microsoft have finally released Security Essentials.
This meant I could de-install AVG (Free and paid-for versions) from my machine.
Hey presto, it works!
I would check the following
1) that your not starting IE against the webserver againt the wrong port, if your using the development IIS then it changes ports at times. That combined with you setting up the browser to launch against a the old port could create this problem.
2) Stop the local IIS and restart it (Again make sure your pointing towards the correct port)
3) Make sure you dont have any hung IE in task manager ( this happens to me sometimes ). Basiclly you have a IE in task manager that uses less then 1mb of ram and does not show on the taskbar, if thats the case kill them.
This doesn't sound, strictly speaking, like a hang. Can that tab/other tabs be navigated to other sites? Is your machine configured to use a proxy?
Is the request actually sent? Using Fiddler2 from www.fiddler2.com with the URL http://ipv4.fiddler:56125/ will show you, and help determine where in IE the problem might be.
I just had a similar problem that took about a week to unravel. Using AVG 9 Business Edition.
I'm on a Windows 7 machine with Visual Studio 2010 SP1, debugging ASP.NET sites running in IIS, with the same "hang" behavior you're seeing. Disabling LinkScanner and Online Shield in AVG fixed the problem.