this is one that is confusing me completely.
This issue doesn't happen with IE, Firefox, Safari ONLY with Google Chrome. (I haven't tested other browsers).
Basically I run my own web server, IIS 7.5, and have a number of development websites on it which will be published and used in production from the same server. As there are a number of websites I must use Dynamic Idle times for Application Pools as resources are restricted.
Usually this wouldn't be an issue and is the way to do things seemingly based on Microsoft's best practices however there seems to be a problem with Chrome loading pages once the application pool has timed out/gone idle.
Now I understand that it takes time for the application pool to restart, which they do within seconds and serve content not long after, but with Chrome the application pool takes close to a minute to start.
This doesn't happen on first load of the website however - it only happens with subsequent loads within the same browser/session.
As I said this does not happen with IE, Firefox or Safari, the other browsers I have tested, the application pool restarts almost immediately.
I had thought that maybe this was a server side issue but since the other browsers work fine I can only figure that it is Chrome at fault. Yet I still want to make sure it isn't actually a server side issue.
Any one have any ideas?
I've just realized I posted this on Stack where it should be on Server Fault.
Sorry.
Anyway, something I wrote in the question prompted me to investigate further and I found this doesn't seem to be an application pool issue, although it could be, but more so a PHP-CGI issue. It might even be localized to my own machine.
Related
I have running a site serve both via https and http.
The issue only happen when access via https, steps are
open a chrome, first time to load the only single site in HTTPS, chrome stall this inital connection about 1second.
however any immediate subsequent refreshing the same page, only have zero to couples of milliseconds, can ignore.
put aside the page(don't interact with it, for a short while, may few minutes), then pick it up to refresh it, it will repeat from step #1(stall about 1 second, followed by any immediate refresh almost zero stalling)
This only happen when access the site by HTTPS, don't have this kind of issue when access by HTTP(always almost zero stalling).
Issue only seen in Chrome browser, but not safari and firefox(there is almost no stalled time), all tested in Mac OS
Would any one help to give some idea please? why the first loading introduce 1 second stalling? how to reduce that stalling time please
screenshot
sorry, this is really hard to explain the issue
I think i found the cause now, i was using a self-signed certificate for https connection, though i add it to browser exception list to trust it, it looks like chrome is being more strict on this(than others ), after switching to a trust CA signed cert. The chrome stalled time reduce to jus few millseconds for all request now, i am happy to close this question now
I have this 1 Mb file for testing purposes (though the issue applies to any file hosted at lptoronto.com): https://lptoronto.com/sandbox/test.png
It always loads instantly in Internet Explorer (both via http and https).
In Google Chrome (currently Version 63.0.3239.132 (Official Build) (64-bit) on Windows 10) the situation is as follows.
When fetched via http, this file loads instantly without an issue.
When fetched via https, the same file takes about 40 (!) seconds to load (with very rare and irregular exceptions, when it also loads fast via https on occasion).
Chrome network monitor shows that all that 40 seconds the image is being slowly but steadily downloaded at low speed, i.e. there is nothing like waiting for server response etc.
Here's the screencast showing IE and Chrome side-by-side loading the same image:
https://www.youtube.com/watch?v=M4cUuhG1YuM
From time to time the issue disappears for a few minutes or an hour, but then re-appears again, without me doing anything on my side.
Same behavior is observed on at least one other computer - the one of my colleague (different ISP, different location).
Needless to say that I'm testing in a clean environment - cache cleared, extensions, firewall, antivirus disabled, connection verified and measured etc.
No Chrome issue whatsoever with any other website, be it http or https.
Hosting provider is yet unable to troubleshoot on their end, but they're still trying to help (it takes some time). They tried disabling mod_deflate, re-installing SSL, disabling caching rules, but to no avail.
The same issue was once observed about 2 months ago. That time I asked the hosting provider to disable SSL completely just to be able to work on my website content. When they re-enabled SSL in less than a day, the issue has gone; but now it re-appeared again, and there is no clue as to what is going on.
The bottomline:
issue appears only in Chrome, only with certain site, only with https
changing only the browser solves the issue
changing only the protocol (https to http) solves the issue
I honestly tried to google out anything similar, but failed to.
I would appreciate if you try the link above in the incognito Chrome window and report the load/refresh time, and of course any ideas are more than welcome.
My macbook started freezing recently and I thought it might be due to shortage of memory. So I opened the activity monitor for the first time and I noticed there are some weird things happening with Chrome. Why are there so many Google Chrome Helper processes??
Is there any reason why there as so many processes?
Many thanks for your help
Well, for one, each tab of Chrome runs independently. So you'll see quite a few processes running due to that.
Another thing to keep in mind is extensions. Each of them usually run in their own process as well. If you have a lot of extensions running, they add up rather quickly.
I have a complex web app, which is working fine in desktop browsers, as well as in the Android native browser (which is part of why I got so long into this project before noticing this problem). The server setup is using the Typesafe Stack (Play/Akka/Scala), but I suspect that's not relevant to the question. Suffice it to say, it uses bog-standard transient session cookies to keep your login.
The problem is, in Chrome and Safari, that transient session appears to be too fragile, and very unpredictably so. In both cases, so long as I am working actively in the browser, everything is fine. But if I switch away from the browser for a while and return to it, it often loses the session cookie, forcing a re-login. Sometimes it takes an hour or two, sometimes just a few minutes -- I haven't yet been able to figure out a pattern.
Note that this doesn't involve closing the tab with my app in it, or manually closing the browser process. I would expect to be able to switch away from Chrome and come back to it using the app switcher and still have my session there; for some reason, though, it seems to be frequently and quickly losing the session cookie. This is a killer problem: users shouldn't be forced to re-login too often.
Any ideas or pointers to why these browsers might be losing their session cookies so easily? I've done lots of web development, but this is my first time seriously targeting mobile browsers, and I'm clearly missing something...
I have a weird problem with websockets and chrome (22.0.1229.79m) (I haven't coded authentication for other browsers yet so I cant test them). It seems like if I reload chrome 3 times, there will be a huge delay in connecting to my websocket server. The server is not delaying the connection, I tested this by connecting to it with another PC while chrome was delaying and it connected perfectly.
Is there anyway to fix this? This is a problem when I am switching servers receiving data. It will halt, and delay. This is really bad for user experience. I would assume this is strictly related to the chrome browser not closing the socket...
I have also seen this delay when creating multiple WebSocket connections from the same browser tab in Chrome within a short period of time. I believe this is to address a potential security issue with WebSockets which would allow a browser to be hijacked to do port scanning inside a network. By limiting the number of WebSocket connections that can happen within a given amount of time, you greatly limit the utility of a browser as a remote port scanner. In addition, the amount of information that is returned by onclose and onerror is intentionally limited for the same reasons.