Re: [squid-users] Http Req/sec Once more

Given that you're running a SMP system, you'd probably get improved
performance by moving to a v2.4 kernel. A lot of the kernel processing,
like network traffic, was serialized in v2.2.x.

Are staying with the older kernel because of reliability concerns? I
know that the v2.4 kernels got off to a rocky start, but I've found
v2.4.17 to be very stable in the 6 weeks since it was released.

On Wednesday 06 February 2002 11:36 pm, khiz code wrote:
> Hello Joe
> Gosh . u still remember me .. guess ppl dont kinda tend to forget pests
> so very soon ;-)
>
> i Have a compaq proliant 5500 series
> dual P11 Xeon 550 Mhz
> 512 megs Ram
> 5 SCSI Ultra -2 10000 rpm disks of 9 GB each .. the cache dirs are
> spread over 4 disks as 3GB slices for a total cache size of 12 GB ..
> each on a seperate reiserfs partition
> compaq Netelligent 10/100 mbps nics
> this is redhat 6.2 with 2.2.19 kernel compiled with ip_wccp as a
> module.. picked up the patch from ur site
> FD_SETSIZE is 16384
> my start up scripts
> echo 1 >/proc/sys/net/ipv4/ip_forward
> echo 16384>/proc/sys/fs/file-max
> echo 32768 >/proc/sys/fs/inode-max
> echo 8192 >/proc/sys/net/ipv4/tcp_max_syn_backlog
> echo 1024 65000 >/proc/sys/net/ipv4/ip_local_port_range
> echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
> echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
> echo 0 > /proc/sys/net/ipv4/tcp_sack
> echo 0 > /proc/sys/net/ipv4/tcp_timestamps
> echo 5>/proc/sys/net/ipv4/tcp_syn_retries
> echo 10 >/proc/sys/net/ipv4/route/gc_interval
> echo 2>/proc/sys/net/ipv4/route/gc_min_interval # used these for
> avoiding the dst cache overflow msgs that i used to get
> echo 30 >/proc/sys/net/ipv4/route/gc_timeout
>
> echo "60 1000 128 256 500 3000 500 1884 2" >/proc/sys/vm/bdflush
> echo "256 512 1024" >/proc/sys/vm/freepages
>
> Yes i have read all the docs on your website
>
> Do i need to furnish some more info
> awaiting responses ..
>
> TIA
> Khiz
>
> --- Joe Cooper <joe@swelltech.com> wrote:
> > khiz code wrote:
> > > Hi all and joe especially
> > >
> > > joe, i remember u giving me approximate statistics abt the capacity
> > > in
> >
> > terms of
> >
> > > req/sec for a T1 line
> > > in myscenario i am connected to my upstream via a E1 (2.048 Mbps)
> > > my clients connect to me via leasedlines
> > > i have oversold my E1 capacity ( like all good ISPs ;-) abt 2
> > > times to
> >
> > abt 5
> >
> > > Mb/s
> > > so will the statistics change in terms of req/sec that the cache
> > > will
> >
> > receive
> >
> > > sorry for being so dumb. once more ...
> > > one more thing
> > > commercial boxes like cisco, netcache etc give statisctics in
> > > terms of connections/sec that the box can handle
> > >
> > > my linux box has time-wait period of 60s
> > > tcp_max_syn_backlog = 8192
> > > local_port_range 1025 64000
> > >
> > > how can i calculate the number of simultaneous connections that
> > > this squid
> >
> > box
> >
> > > can sustain for web traffic ..assuming that only squid runs on the
> > > box
> >
> > Hehehe... How long is a piece of string, Khiz?
> >
> > You haven't told us anything about your box. Here is what I sell for
> > one or two T1 links these days:
> >
> > 800MHz Celeron (can't get a 633 anymore, which also would be plenty
> > of power)
> > 256MB RAM
> > 1 x 7200 RPM 30GB disk
> >
> > These boxes will sustain about 60-70 reqs/sec of real traffic without
> > sweating. Short (30 minute) bursts of loads of over 100 reqs/sec are
> > probably possible.
> >
> > However, a client population suitable for a single T1 will never
> > generate that high of a sustained load. Our single T1 ISP clients
> > are seeing about 35 reqs/sec or less at their peak periods and their
> > caches aren't working very hard even when doing extra stuff like
> > running redirectors or acting as ICP peers (even our old 850 boxes
> > which were only 450MHz K6-2 with 192MB RAM). You can't make your
> > users browse only cache hits, so the speed of your cache isn't really
> > your upper bound if you have a T1.
> >
> > Have you read my caching deployment guide at the Swell Technology
> > site? It has some information about all of this stuff. I've also
> > specified all of our machines based on reqs/sec and bandwidth they
> > will handle--that ought to give you some rough ideas about what Squid
> > can do on given hardware if well tuned. (Some of this information is
> > going away soon, or being altered significantly, when our new website
> > goes up March 1st or thereabouts. So more up to date information and
> > a lot more of it will be on the site, but probably less specific for
> > the kind of info you are looking for--so enjoy it while it is
> > available.) --
> > Joe Cooper <joe@swelltech.com>
> > http://www.swelltech.com
> > Web Caching Appliances and Support
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
Received on Fri Feb 08 2002 - 20:59:11 MST