Closed Bug 543938 Opened 15 years ago Closed 14 years ago

Max Connections/Pipelining Causes sites to lag until restart

Categories

(Core :: Networking, defect)

All
macOS
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 486769

People

(Reporter: slayerlp5, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.16) Gecko/2009120123 Camino/2.0.1 (like Firefox/3.0.16) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.16) Gecko/2009120123 Camino/2.0.1 (like Firefox/3.0.16) I upped my max http connections as well as enabled pipelining and upped the max there. I have been told these values by a networking expert and know that they are supported by all servers, which leads me to conclude that this is a Camino bug. If I start browsing intensely with multiple tabs open sites will being to lag and time out. The sites work perfectly once I restart Camino. Sometimes this will happen with casual browsing too. Please fix this ASAP, as pipelining is one of the major reasons I use camino and this is a huge setback for me. Thank you. Reproducible: Always Steps to Reproduce: 1. Enable pipelining 2. Up the max connections 3. Up the max connections for http/pipelining per server Actual Results: Sites stick at 'transferring data' or 'looking up', or even 'waiting for' and then time out. They continue to do so until Camino is restarted.. Expected Results: Sites load consistently extremely fast
You didn't say what values your "networking expert" said were OK, but I'd wager your "networking expert" isn't as expert as the reasonably large group of developers who arrived at the decision to make the default values the defaults. At any rate, there's no way this can possibly be a Camino bug, since all that networking code is in Core, so kicking to Core for further triage.
Component: General → Networking
Product: Camino → Core
QA Contact: general → networking
Thank you for putting this in the correct section. I will tell you now that in older nightly builds of Camino (around 5 months ago?) I used these same connection/pipelining settings and never had any trouble. That is why I am lead to believe that it is a more recent bug. Thanks.
If you can hunt down a regression window (when it broke, specifically), and also find out which Firefox builds exhibit the same problems, that'll help, too. Finally, specific sites that have problems with your settings are going to be necessary to replicate this, along with the exact settings you're using. cl
I wish I could but my computer with the specific build that worked is now busted [needs a new HD]. However, here are the settings: Max Connection: 64 Per server: 20 Pipelining Max Requests: 16 This occurs on literally ANY site, as I mentioned above. Possibly the only sites that I don't notice it so much are the simplest of sites, such as http://google.com
I have been experiencing this more and I actually think it may have something to do with what happens when a pipeline connection times out. The rest of the loading process doesn't continue until it does so. I feel like after a second or two the core should automatically force timeout.
(In reply to comment #4) > Pipelining Max Requests: 16 This setting won't work anyways, as I believe this is hard coded to maximum of 8 requests. http://kb.mozillazine.org/Network.http.pipelining.maxrequests Every "networking expert" always says that more is better, but this isn't the case. You might see a speed up on some sites by setting this to the default of 4, but in my experience, you're going to have more problems enabling pipelining then you'll see benefits. In my not so expert opinion, you're better off leaving it disabled and leaving all of your network settings at default. Mozilla knows best, it is their browser after all. =)
I am working to make pipelining operate better and more safely.. its a slow process - but over in bug 599164 a patch attached removes the hard limit.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.