With the changes made from Procedure 1 and 2, and a 2Mb connection, you can realise a sustained throughput of >100k, peaking at ~256k or more, with a ping response time of between 250 and 900ms

Procedure 1

First, open Firefox's advanced settings menu by running about:config from the address bar. Upon entering this address, you will see a long list of internal settings. Modify the following ones and set them to the suggested values shown here for maximum performance:

network.http.keep-alive.timeout:600 (300ms default is OK usually, but 600 is better.)
network.http.max-persistent-connections-per-proxy:16 (Default is 4)
network.http.pipelining:true (Default- false. Some old HTTP/1.0 servers can't handle it.)
network.http.pipelining.maxrequests:8 (No default)
network.http.proxy.keep-alive:true (Default- true, but double check)
network.http.proxy.pipelining:true (Default- false) - See NOTE1 below.

Afterwards, just restart the browser and experience the difference! For some automated additional performance hacks, check out the FasterFox extension. You also can do the same tweaks manually with the help of this page.

NOTE1: Proxy pipelining may not be well supported by Privoxy. For this reason, you may want to install Polipo and use that instead of Privoxy to get the performance benefits of pipelining. If you use Torbutton (which you should, if you want any anonymity at all), all of the Tor-relevant privacy scrubbing features of Privoxy are no longer necessary.

NOTE2: Do not use page prefetching. Disable this if it is enabled. Prefetching is a speculative feature, which assumes that you will read the pages referenced by the links in the current page you are viewing. This places undue load on the Tor network and clog your circuits with unnecessary traffic. Its unlikely you will read all the pages referenced by the current page, especially in the case of search engines results.

Procedure 2 - A Tor Non-Functional Requirement (NFR)

If you follow the previous authors work you should have well performing access. To go that bit further lets consider the ideal behaviour of our Tor client.

You will need: The on-line reference to Tor properties, that can be placed in torrc. Always back up this file before editing.

Lets think of a Non-Functional Requirement we might like to place on our Tor client.

* we want it to establish circuits as quickly as possible. If it takes too long to do this ignore them, by timing out the building of circuits quickly.
* now we have circuit build time-outs occuring more frequently, we need to encourage Tor to try to generate circuits more often.
* Once we have established a circuit, we are assuming its a good one and we dont want it being timed out by firewalls or anything else. We need to make sure a ping occurs on the circuit to prevent this.

Given this NFR, lets come up with some properties that may help satisfy it.

*

CircuitBuildTimeout NUM
o Try for at most NUM seconds when building circuits. If the circuit isn't open in that time, give up on it. (Default: 1 minute.) Force circuits that are quick to establish and thus likely to push traffic more quickly. Values as low as 2 seconds have been tried with good results, although this can cause severe damage to the Tor network if your network connection is simply not fast enough to establish any circuits in this time. The effect is a smaller 'Topological Radius' of servers used for Tor, ie the network connections available from your connection. Unfortunately, the smaller you make this number, the smaller the number of paths your client will use, and the less your anonymity.
*

NumEntryGuards NUM
o

If we are going to be decreasing the CircuitBuildTimeout, you want to increase the likelihood you have a guard node fast enough to build these fast circuits for you. NUM=5 to 8 are good choices here.
*

KeepalivePeriod NUM
o To keep firewalls from expiring connections, send a padding keepalive cell every NUM seconds on open connections that are in use. If the connection has no open circuits, it will instead be closed after NUM seconds of idleness. (Default: 5 minutes)
*

NewCircuitPeriod NUM
o Every NUM seconds consider whether to build a new circuit. (Default: 30 seconds) Lets make Tor ready to establish a new circuit more readily.

Settings that you may append to the end of the torrc configuration file are as follows:

# Try for at most NUM seconds when building circuits. If the circuit
# isn't open in that time, give up on it. (Default: 1 minute.)
CircuitBuildTimeout 5

# Increase the number of guards to increase the likelihood that
# you will have a few guards fast enoiugh to build these circuits.
NumEntryGuards 6

# Send a padding cell every N seconds to keep firewalls from closing
# our connections while Tor is not in use. (Default: 5 minutes)
KeepalivePeriod 60

# Force Tor to consider whether to build a new circuit every NUM
# seconds. (Default: 30 seconds)
NewCircuitPeriod 15

As an added bonus, with these settings the "New Identity" button in Vidalia also effectively becomes a "This circuit is WAY too slow" button that you can mash to get a faster, more responsive circuit if Tor ever starts choking up on you. This is necessary because sometimes circuits will start out fast, but then get overloaded as traffic from other clients bursts and overwhelms the slowest node in the path.