Speeding Up Freenet

Speeding up your Freenet access

Try using browsers such as Mozilla/Firefox that do link prefetching (make sure prefetching is enabled, too!). This way, even if you don't visit every link in a site, you'll still be helping them all to propagate between nodes, speeding up subsequent accesses not only for yourself, but for everyone else, too. An easy, painless way to do your part as a good freenet citizen. :-)

You may notice that Freenet runs pretty slowly in some browsers, and that after opening many links simultaneously, all but one of them seem to grind to a halt. To fix this, you must increase the maximum number of connections that can be established at one time. In Mozilla/Firefox, this is done by opening the URL "about:config" (just type it into the URL box as shown, without the quotes, of course) and changing the following items to the suggested values (type "conn" in the Filter box and hit Enter to narrow the list down and make them easier to find):

network.http.max-connections (256)

network.http.max-connections-per-server (192)

network.http.max-persistent-connections-per-proxy (128)

network.http.max-persistent-connections-per-server (64)

If you have a slow modem connection, don't increase them too much, though. :-) Thank the ppl on IIP @ #freenet and #anonymous for this tip. The reason this works is because browsers limit the number of simultaneous connections to any individual site. Since every page you access on freenet is considered to be one host (127.0.0.1:8888 by default), instead of as on the general Internet, where every site is a different IP, you can only do a few things at the same time without this fix.

As a webmaster, if you have multiple pages, normally users are stuck having to wait for each page to load. The trick (which my site uses) is to precache the sites by tricking the browser into loading them like images. This is very easy to do, and makes multi-page freenet sites viable. Observe the source of my frontpage to determine how this is done. Change my webpages in the pic links with your own, of course, and don't precache the same page you are currently on. It's just dumb, but in case you accidentally do, it probably won't recurse and jam up (unlike the iframes method, which potentially could). I also recommend caching the current activelink of each edition. Helps ppl on the older pages to see the new activelink. However, it's recommended that it isn't done on the front page. Also, for edition-based sites, prioritize precaching over future edition activelinks if you want to take full advantage of precaching.

What happens theoretically is that the browser loads an image first into the cache (when the page loads) and then checks the file type. By abusing this, we can load HTML pages or anything on the page, and since they're at the bottom of the page, those links will be the last things loaded. Provided the user has images turned on (so it wont work on lynx), this will work. Obviously, precaching things on the same page you are currently on won't work. I'm recommending that all people considering using multi-page sites use this method.

Comment: It's better to use the iframe tag as using the img tag can confuse text based browsers. While you're at it, use iframe to include your description.txt and NIMs, if you use them, this will help these rarely retrieved files to be cached by many nodes.

The great thing about precaching using the method in Tip 3 is that you can also use this method on your links page to load the frontpage of all your links, speeding up jumps to them, effectively reducing the effect of the lag problem. The more ppl do this, the faster that freenet will seem to users, as idle time isn't wasted. It's recommended you cache the targets the links are pointed to over the activelinks (unless they point to binary files or something). DON'T precache links on the normal internet or you will get anonymity warnings whenever someone visits your page, and for good reason, too. Only precache items within freenet that don't throw any warnings. Check the source of my links page to test the technology and see the source.

(added 2004-4-18 by dolphin)

If you haven't already checked out all the great hints and tips available on the Mozilla/Firefox web pages, do yourself a favor and go there now! Well, not just yet, actually. Read this first. :-)

Mozilla and Firefox, by default, will wait approximately 250 ms from the time a connection to a site is established before they actually begin rendering a page. This annoying delay can be disabled by editing the file user.js under your Mozilla/Firefox profile directory ($HOME/.mozilla/default/*.slt/ for Mozilla, or $HOME/.phoenix/default/*.slt/ for Firefox). Create a new user.js file under this directory if you don't already have one, and add this to it:

// This one makes a huge difference. Last value in milliseconds (default is 250)

user_pref("nglayout.initialpaint.delay", 0);

You should also try enabling pipelining, which speeds up the processing of http requests, by adding this to your user.js as well:

// Enable pipelining

user_pref("network.http.pipelining", true);

user_pref("network.http.pipelining.firstrequest", true);

user_pref("network.http.proxy.pipelining", true);

user_pref("network.http.pipelining.maxrequests", 100);

These do seem to help!

   -- dolphin

UPDATE (added 2005.01.20): The changes listed above and the file named "user.js" are the same across systems and for Firefox 1.0. The directory where the configuration file goes (or exists already) can be found (for Firefox 1.0)...

On Windows XP/2000,
%App Data%\Mozilla\Firefox\Profiles\default.xxx\, where xxx is a random string of 3 characters. Just browse to C:\Documents and Settings\[User Name]\Application Data\Mozilla\Firefox\Profiles\ and the rest should be obvious.

On Windows 95/98/Me,
C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\default.xxx\

On Linux,
~/.mozilla/firefox/default.xxx/.

On Mac OS X,
~/Library/Application Support/Firefox/Profiles/default.xxx/.

     -- a helpful freenet citizen (for the person who asked)  ;)

Use a Container to group together files that rarely change, i.e. your logo, CSS stylesheet, etc. Make sure that the files inside the container rarely change, as every time one file in the container changes, caching for all files in that container are lost. Containers ease things for both you and your visitors. It's much easier to view a site using containers since less files are being retrieved and it's much easier to insert such a site for the same reason.