Created attachment 691738 [details] Holy **** balls batman User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20121212 Firefox/20.0 Build ID: 20121212034329 Steps to reproduce: Created `network.http.max-connections-per-server;8` in config and went on http://spasche.net/files/parallel_connections/ Actual results: 20 simultaneous connections to the same server is what happened Expected results: 12 less sim. connections if my maths is up to scatch
That pref has been dropped. These are what we use now: network.http.max-connections network.http.max-persistent-connections-per-server network.http.max-persistent-connections-per-server
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Hi, How do we achieve the same thing now then? Many servers will flat-out block concurrent requests above, say, 10. `network.http.max-persistent-connections-per-server` is set to 6. You can see there's 20 concurrent req's in the picture above. I'm behind a proxy, so there might be something funny going on there? In fact, it seems to bypass the `network.http.max-persistent-connections-per-server` pref altogether when you're behind a proxy. `network.http.max-persistent-connections-per-proxy` is set to 32 (by default). Cheers
(In reply to tyyiut from comment #2) > Hi, > > How do we achieve the same thing now then? Many servers will flat-out block > concurrent requests above, say, 10. > do you have a URL for this? It doesn't match my experience.
(In reply to tyyiut from comment #5) > https://www.nearlyfreespeech.net/help/access_denied#enough they just shot themselves in the foot, eh? Any proxy shared across users, or independent tabs, etc will blow through that. any others?
Not that I know of, actually, but NFSN are quite popular. I don't know if it's got something to do with my proxy setup, but Firefox will use `network.http.max-persistent-connections-per-proxy` for HTTP connections, but will revert to `network.http.max-persistent-connections-per-server` for HTTPS, it would seem. In any case, it doesn't make sense that `network.http.max-persistent-connections-per-proxy` will trump `network.http.max-persistent-connections-per-server`, I think. You may be behind a proxy, but shouldn't the per-server limit still apply? Wasn't this the function of `network.http.max-connections-per-server`?
SSL is end to end (admittedly, tunneled through the proxy) which is why it is accounted for differently. the proxy limit is to protect the proxy from being overwhelemed (though in general this is historical, devices don't really struggle with connection termination these days and if they do they should be fixed. nginx is a good example of how it can be done to very large scales) - but it needs to be more than the per-server limit or you wouldn't be able to get any sharding parallelism, etc..
Yes, but there's no per-server limit at all if you're behind a proxy. Is that not an issue?
(In reply to tyyiut from comment #9) > Yes, but there's no per-server limit at all if you're behind a proxy. Is > that not an issue? that's up to the proxy to implement if it wants one.
I don't think that approach is very pragmatic, but all right. It's been an interesting discussion, thanks!
it probably reflects my feelings that NFSN is just inventing a problem for itself that ought to be fixed differently. Most hosting providers want more parallelism because it gives better response times for their customers (which is why they invented sharding) and the issues involved in connection management at scale are very solvable today.
Fair enough. This definitely isn't my area of expertise, so I can't comment. Cheers
Sent email to support@NearlyFreeSpeech.NET pointing them here, since the resolution seems to be that they should fix their servers.
Assignee: nobody → english-us
Status: RESOLVED → REOPENED
Component: Networking: HTTP → English US
Ever confirmed: true
Product: Core → Tech Evangelism
Resolution: INVALID → ---
Summary: network.http.max-connections-per-server originally absent, has no effect → Tech evangelism: encourage sites to not limit connections per browser.
Version: Trunk → unspecified
NFSN replied with following. I've invited them to reopen this bug or create a new one if they wish to pursue further. "The host referenced above responded that the incorrect interpretation of material available on their site led to the erroneous conclusion that they would be negatively impacted by this bug report. They expressed the opinion that the bug report reflects an incorrect design decision with regard to Firefox proxy handling, but stated that they did not anticipate that it would adversely affect them or their customers."
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
Then perhaps putting the original title back and a WONTFIX would be more appropriate?
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.