On 3/3/19, Dirk Munk <[email protected]> wrote: > Lee wrote: >> On 3/3/19, David H. Durgee <[email protected]> wrote: >>> Dirk Munk wrote: >>>> The next item on the performance enhancements is pipelining. With >>>> pipelining several several http requests are packed into one TCP >>>> packet. >>>> >>>> 1. network.http.pipelining = true >>>> >>>> 2. network.http.pipelining.maxrequests = 64 >>>> >>>> Up to 64 requests into one tcp packet, seems a bit much perhaps, but >>>> remember that the network buffer sizes were increased to 32 MB. >>>> >>>> With all the changes I made so far, Seamonkey is unrecognisable fast >>>> now. >>> >>> Have you done any testing to optimize these settings? I have often seen >>> diminishing returns as parameters are increased. How much improvement >>> do you see with halving your figures as an example? Perhaps that would >>> suffice and leave more memory available for other parameter tuning. >>> >>> As I noted in an earlier post in this thread, it would be nice if >>> someone could put together an article on tuning SeaMonkey for systems >>> with more memory. This might need to be broken out by platform, as I am >>> sure that Windows differs from Linux that differs from OS X. >> >> It looks like there was a mozilla project to figure out the best >> settings: >> https://wiki.mozilla.org/Project_Dory >> I have no idea what a "Hasal test framework" is, but their idea of >> "extreme" doesn't match mine: >> - The tests are conducted using default values of the prefs along >> with 2 extreme values in 2 directions (larger and smaller). >> - network.buffer.cache.size for most test cases, the default (32768) >> performs similarly with a larger value (65536). > > I did not claim more performance, but instead a big drop in CPU cycles. > My Ethernet NIC has 512 receive buffers allocated, and it seem a buffer > has a size of 2 kB. So if the NIC has 1 MB buffer space, then Seamonkey > should have more, and the standard .8 MB is less.
I don't think it's quite that direct a relationship, but SeaMonkey certainly needs enough buffer space to drain all the traffic sent to it vs. leaving it queued up in the operating system buffers. Which is why I'm hoping someone who knows the code can figure out if network.buffer.cache.size is the buffer size used to get the [socket?] data from the OS or not. >> One item not on their list that used to make a difference is >> network.http.request.max-start-delay >> but with pipelining / spdy / http2 or moz bumping up the default # of >> connections however long ago it might not make any difference now. >> >> In any case, making a list of setting changes that might help is a >> good idea. Items mentioned so far are: >> >> browser.cache.disk.enable = 0 (false) >> >> browser.cache.memory.capacity = 4194304 (4 GB) >> browser.cache.memory.max_entry_size = -1 (no per entry limit) >> >> network.buffer.cache.size = 262144 (256 kB) >> network.buffer.cache.count = 128 >> >> network.http.pipelining = true >> network.http.pipelining.maxrequests = 64 >> >> Did I miss any? >> >> Lee > > No, that is about it at the moment. With those settings, Seamonkey > behaves much and much better and faster with me. But keep in mind, I > always have many tabs open, so if you just have a few tabs open, things > may be different. I haven't been seeing any stalls or slowdowns, so it's just a guessing game for me about what changes might actually help the people that have been complaining about SM stalling. It's a whole lot easier troubleshooting if you can actually see the trouble for yourself :) Lee _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
