Lee wrote:
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.
Look at it from this way. With my 300Mb/sec internet connection it takes
just over 1 second to fill that 32 MB network cache I created with my
settings. How long does it take for some web pages to load?
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
Indeed.
I haven't mentioned stability until now, but with these settings
Seamonkey hasn't crashed these last days, and it used to do that once or
twice per day.
Someone wrote that Seamonkey isn't fast compared with other browsers. I
completely disagree. With the default settings, Seamonkey is just
starving for resources, and can't show its true potential with today's
computers and internet connections.
This is exactly what I have seen so often in the past with operating
systems and applications. The hardware resources increased dramatically,
and no one thought of increasing configuration parameters so that these
resources can actually be used.
I would appreciate some feedback from the developers. Perhaps
Frank-Rainer can test these parameters, and give us his opinion?
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
