Tuning
You probably don't need to do this! You can easily make
localProxy behave much worse by tinkering. But if you feel you must ...
If it's configured properly, the speed will be entirely
dependent on your fastest ISP's proxy speed and your network connection.
There's nothing you can do about that, but ... If localProxy is not configured
properly, or you have many proxies in the configuration, it will take some
time to learn the fastest strategies and proxies to use. It takes localProxy
a few requests using each one of those proxies to find the best ones to
use. The ones which don't work at all, or are very slow will slow you down
a lot in the early stages (first 5-10 minutes of browsing, say). How to
fix this?
Here are some tips:
- In the following, note that you may temporarily disable
any proxy (or whole commStrat) in the configuration by selecting the proxy
in the GUI and checking the 'this host is disabled' checkbox. Or more permanently,
by adding a 'isEnabled' tag with a zero value in the user configuration. This
enables you to remove them from the running configuration, but save them
in the configuration file, for later repeat testing until you are sure they
need to be removed permanently. Disabling complete commStrats may be useful
when unsure whether a particular commStrat is successful or not. Disabling
'all' and then reenabling a particular service, commStrat, layer 0 host and
(for commStrat 1) layer 1 host is a very good way to examine the behaviour
of a particular proxy in a particular mode.
- For the first 5 minutes, say, surf to pages with a lot of components,
maybe click the 'train me' button a few times. A page full of thumbnail
pictures will do the same thing and might be more interesting to look at
too :-). If a lot of the page components fail to load, refreshing the page
is an easy way to exercise localProxy a bit more. Be aware that once things
are cached in your browser, surfing to that page again no longer exercises
localProxy much, unless the page has changed (like CNN does often).
- Note any error messages in the command window from localProxy (depending
on the version, you may need to bump up the debug level to see some of
these)
- More than a few connection timeouts on the same proxy:port mean
that proxy is not working at all (today!), and should be removed from the
configuration file completely. Reselect the configuration whenever you modify
this file to get the new values into the built configuration.
- Bad response codes like 503, 500, etc. from proxies indicate that
they are likely to be firewalled/access controlled, so remove those too.
Be sure to remove the right one though (it is not always easy to know whether
the error is being caused by a local ISP 'agent' proxy, or the remote one).
- Watch the speeds in the log window. Remove the very slow proxies
by disabling them in your user configuration - leave at least one local and
one remote though! A semi-automated way to do this (for layer 0 proxies)
is to run statProxy on the config, and merge the results back into the config
once a week, or so:
perl statProxy.pl -t all -l config-User0.xml > test.out
perl mergeHosts.pl test.out config-User0.xml
- Remember that any given proxy may be down or slow today, but better
tomorrow, so keep retrying the ones you remove until you're sure they
are really dead. Keep a copy of the original configuration file to go back
to occasionally. OTOH, you may have many and wish to keep only the good,
reliable ones.
- If your remote proxies are all bad, or you want to try new ones,
get a new hosts.zip from the proxyTools CVS at sourceForge. LP will unzip
and use it as soon as you 'Start services'.
- Be sure to get the syntax correct when you edit the configuration
file. Refer to the original one for this. Better - use mergeHosts to update
it all the time.