recently i am getting slow browsing while uplink is available.


Log Details


root#tail store.log

1151990716.715 RELEASE -1 FFFFFFFF 072127E76ECB50541044F3C0A4C766A5 200 1151990
940 -1 -1 text/html -1/1149 GET http://adopt.hotbar.com/adopt.jsp?
1151990717.810 RELEASE -1 FFFFFFFF 052F768EBDF31B39A3118BDE8ABA97D1 200 1151990
857 -1 631152000 text/html 628/628 GET http://rad.msn.com/ADSAdClient31.d
ll?
1151990718.144 RELEASE -1 FFFFFFFF E149AFA630E94D5BA82DFEFC4C2FE8F4 404 1151990
858 -1 -1 text/html 13/13 POST http://activex.microsoft.com/object
s/ocget.dll
1151990718.654 SWAPOUT 01 00081441 7B9FE0CA4C1F4E3CBAEF960612259060 200 1151990
940 1140684330 -1 image/gif 2558/2558 GET


root#tail cache.log

2006/07/04 08:12:16| /cache1/squid/05/87/00058749
2006/07/04 08:35:29| storeAufsOpenDone: (2) No such file or directory
2006/07/04 08:39:59| /cache3/squid/01/89/00018970
2006/07/04 08:40:53| storeAufsOpenDone: (2) No such file or directory
2006/07/04 08:41:58| /cache4/squid/01/8C/00018C8E
2006/07/04 08:42:38| squidaio_queue_request: WARNING - Queue congestion
2006/07/04 08:43:43| storeAufsOpenDone: (2) No such file or directory
2006/07/04 10:07:38| storeAufsOpenDone: (2) No such file or directory
2006/07/04 10:07:38| /cache1/squid/01/07/000107F0




root#tail access.log

1151991002.544 1468 10.0.0.136 TCP_MISS/200 693 GET http://ad5.speedbit.com/cgi-bin/ads9.dll? - DIRECT/212.143.22.110 -
1151991002.549 553044 10.0.0.136 TCP_MISS/206 7077551 GET http://httpdl5.de.nero.com/software/..._eng_no_yt.exe - DIRECT/62.93.192.42 application/octet-stream
1151991002.657 47 10.0.0.136 TCP_HIT/200 7705 GET http://images.speedbit.com/dapmediap...files-180b.gif - NONE/- image/gif



Any one have idea whats the problem.

High Performance Web Caching With Squid
Squid is an excellent open source web caching proxy package, but it requires quite a lot of tuning to achieve the kind of performance seen in commercial proxies. This article presents several independently useful ideas for tuning a web caching system. If all of them are implemented, extremely high performance can be achieved from modest hardware. Further, this article will describe, for illustrative purposes, a web cache that I recently built for prototype purposes. This box was tested before and after tuning using the Polygraph web cache benchmarking suite and performance climbed from about 50 reqs/second to over 100 reqs/second. A very large difference for no extra hardware expense. This article assumes that you already know how to install and configure Squid, but would like to achieve faster response times and be able to handle much heavier loads with your web cache.

I feel obligated to warn you that this process is not for the faint of heart, there will be patching, compiling, configuring, and dragons on this journey. But this is one area where putting in a day or two of hard work can pay off very big. But, if after reading through this, you find yourself saying, "Huh?", you might want to consider purchasing one already built (Swell Technology sells them) or pay a Linux nerd to build one for you using these instructions.

Getting the Most From Your Hardware

Squid can easily be crippled by disks that are not performing up to spec. Web caching is an "I/O bound" application, meaning that it can only go as fast as it gets the data onto and off of the storage media. So the first thing necessary is to ensure you have the right hardware for caching.

Hard Disks

You will need to use either 7200 RPM UDMA 66 drives or fast (7200 or 10k RPM) SCSI drives. A good UDMA 66 drive with the appropriate controller can perform nearly as well as a comparable SCSI drive for significantly less money. However, if you choose UDMA, keep in mind that the CPU will need to be slightly faster to make up for additional cycles used for I/O.

I've chosen for my system 2 Seagate Barracuda 13.6 GB 7200 RPM UDMA 66 hard disks. IBM and Maxtor also make excellent performing 7200 RPM drives. In my tests the Seagate edged out the Maxtor which edged out the IBM, each by a very small margin.

Processor

Squid in it's default configuration, as found in RPM's or in a standard compile, does not need a very fast CPU to support 1 or 2 disks. However, a large performance boost can be achieved by using a threaded version of Squid. The threads will use a lot of CPU horsepower. So, if you are going to use threads as documented below, consider getting a rather fast processor. A 550MHz K6-2 is what I've chosen for my system. Something near that speed should be about right for a single or dual disk system.

RAM

It's pretty easy to calculate the amount of RAM needed for any given web cache. A safe number is 10MB RAM for every 1 GB of cache space on disk. I usually allot a little more than this when using a threaded Squid. Of course, you also need to figure out what your system uses for other things and subtract that from the total of available RAM. For my prototype unit I've chosen 256 MB.

Hi abakali,

it was interesting to read all the points mentioned by you..... but i think this article is still incomplete.... Can you tell us where is this full artical..........(as I was looking for the stuff patching, compiling, configuring, and dragons )


Thanks....