Yes, the speed increase is actually quite remarkable when visiting for example heavy newspaper portals and such. Nice!

[ Reply to This | # ]

It would be nice to know.
Thanx

[ Reply to This | # ]

To answer to myself:
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

[ Reply to This | # ]

This probably turns on support for HTTP keepalive, ie using the same socket connection for all the requests rather than opening separate sockets for each request. See HTTP 1.1 RFC :
http://www.cis.ohio-state.edu/cs/Services/rfc/rfc-text/rfc2068.txt
section 8.1
booger....

[ Reply to This | # ]

Wow. it is a lot faster. Why isn't it on by default? Is there some problem caused by it which might make them choose not to turn it on? I couldn't see anything in the FAQ...

[ Reply to This | # ]

If in fact this does turn on HTTP KeepAlive, this would drastically increase the number of active threads handled by the web server at a given point, this is one reason for not using this as a default setting. This increases the workload handled by the server as the client sessions are changed from a stateless connection to a persistent connection, requiring the server to keep open threads instead of re-using them. In a nutshell, it reduces connection time as a session can re-use the same thread instead of opening a new one, but it causes a larger performance hit to web servers handling the sessions.

[ Reply to This | # ]

No, KeepAlive is what you actually meant. KeepAlive is an option (can be turned off both on the browser side and on the server side) in which the client and server can reuse the open connection. This does have somewhat impact on the server, since the connection (and hence thread/process) remains open (in case the client did not close it correctly) for a certain amount of time before it times out. My webserver had about 10% processing hit when ALL clients were using KeepAlive. That's not that much, considering you do less process forking and handle all requests much faster.

Pipelining in contrast enables the client to ask for several files at once, without having to wait for the end of the first transmission. The server can also send any file in chunks, interleave the requested chunks as needed etc. This actually reduces both server load and network load, is generally friendly to everyone, network infrastructure including.

The reasong it's turned of by default is because it could introduce bugs, both on the untested client-side and on the server-side, since there could be servers not handling pipelining as they should...

Go read the Mozilla FAQ somebody else pointed out.

[ Reply to This | # ]

This really made a huge speed difference on my iBook 600/640/20 running 10.2.2! Thanks for the great tip! Just another reason to love Chimera...can't remember the last time I launched IE for anything.

[ Reply to This | # ]

WOW, this really works very well. I think it has done more than just speed up browsing. Over all my browser seems faster. I agree with the other people on how great this browser is. I have not used IE in a very long time, and with this speed bump I don't think I will be using IE anytime soon.

[ Reply to This | # ]

Hi
thanks for this hint!
shouldn't be placed in user.js instead.
maybe after a update it is erased?

Rene

[ Reply to This | # ]

Has anyone gotten user.js to WORK?

I think there is a pretty good body of evidence from the past few Chimera tips, that user.js doesn't seem to be read on some users' systems. Like mine for instance. :)

[ Reply to This | # ]

For me anyway, the user.js file seems to be ignored, though some on the web say otherwise. From what I understand, if you write 'user_pref' in the prefs.js file, Chimera will leave it alone. That's the only way I can make pref file changes happen...

[ Reply to This | # ]

From my experience:

user.js only works with user_pref() calls, not pref() calls, which is moot anyway as pref() calls aren't saved out to file when Chimera quits

when a user_pref() call is put in user.js and Chimera is started (Chimera has to be shut down prior to putting the call in), when Chimera quits it saves the user_pref() to prefs.js, making putting it in user.js pretty pointless.

[ Reply to This | # ]

Oh! Well, if that's the case, then yeah, pretty pointless...

[ Reply to This | # ]

Okay, well I think I found something!

I ripped all the crap I had put into my prefs.js and put them into my user.js file. Then I loaded Chimera and quit it. No luck on getting those changes to take effect (the easy one to "see" was showing history in the sidebar)...BUT! When I loaded Chimera and went into the Preferences window, then quit chimera--VIOLA!--Chimera sucked the user_prefs from user.js and put them into prefs.js!

So it looks like you have to monkey with Chimera's prefs pane to get the "import" to work. The reason to use user.js (rather than just sticking things into prefs.js) is so that you can easily keep your hacks separate from Chimera's defaults, and they won't get periodically, and mysteriously, "eaten".

[ Reply to This | # ]

Call me a newbie, but while prefs.js is right in front of me, I can't find any file named user.js at all. It just isn't there. Can anyone explain?

--Doc.

[ Reply to This | # ]

just create a new plain text file in TextEdit, paste the lines in, and save in the same directory as your Prefs.js file with the name "User.js". worked great for me. when you open and close the prefs pane in Navigator the User.js settings get copied into the Prefs.js file.

[ Reply to This | # ]

i love chimera and i love this tip!
much faster now on my powerbook in 10.2.1
thank you

[ Reply to This | # ]

It seems accelerate the browsing.... Thanks for the great tip!

[ Reply to This | # ]

I seem to remember problems with pipelining in Mozilla in accessing secure sites (https) which was eventually fixed. I wonder if this fix has been encorporated into chimer/navigator. If it isn't maybe that is why there is no "check box" to easily enable it in the preferences. I havn't really tried it yet on secure sites so I don't know if this is the case or not.
Any ideas/experiences?

[ Reply to This | # ]

I just tried payapl. It seems ok.. Paypal uses secutiy http....

[ Reply to This | # ]

Reading all those positive comments about Chimera let me feel quite frustrated... I tried to use Chimera as my primary browser but couldn't. Some pages won't load, displaying instead a blank page, like :
www.macplus.org/magplus/depeches.php
www.macosx.be
www.bosch.dk/
pages.sbcglobal.net/anhchiyork/
http://www.amutat-eshnav.org.il/
http://www.engilutions.com/
Same thing happens with Netscape 7 and Mozilla 1.2b
No one seems to be able to find a solution for this...
If anyone has a clue, I'll be happy to read it.

[ Reply to This | # ]

Interesting, indeed. I loaded the first 2 links OK, but bosch.dk failed for me. In that case, it seems to be the fault of the creator, using CSS2 styles in ways that are specific to IE browsers, which is wrong. I admit that doesn't help you much. You could try to complain to the site owner.

[ Reply to This | # ]

Like the title states: SWEET! Great speed improvement on my Pismo laptop.

[ Reply to This | # ]