On Mon, 05 Sep 2011 20:23:02 +0200, David Touzeau wrote:
> Dear
>
> I would like to create a kind of law calculation in order to quickly
> calculate server performances to store squid...
>
> I know there is a lot of parameters that should make e this
> calculation
> more complex, but this is just to be generic.
>
"generic" is not possible. It boils down to what _your_ users are doing
is different to _my_ users.
> For example :
>
> I have 150 users :
> -----------------------------------
>
> Memory : 750K per users = 150x750=112 Mb memory + 300Mb for the
> system =
> 512 Mb minimal.
> Hard disk cache : 50Mb/user = 150*50 = 7.5Go minimal stored disk
> size
> for cache..
>
> Is it make sense ?
Your aim makes sense in a way. The metric of "per user" does not relate
to resource usage though.
This is solely because one user could be making no requests at all or
several thousand per second. And they can switch between these
behaviours and random values in between without notice. I have seen a
network happily serving 15K users with one Squid on a 50MBit uplink, and
also a GigE network brought to its knees by just a few users. "Normal"
web traffic in both cases.
The Squid relevant metrics are closer tied to requests per second, or
the internal Mbps line speed of HTTP requirements.
Minimal stored disk size is always zero. Maximal is best at <80% of the
size of the disk you plug in. Moderated by at most 2^24 objects per
cache_dir. This is a fixed limit, so performance there is relative to
your average cacheable object size. Disks are best sized along the
lines of: 2^24 * avg object size. Overall disk count multiply that out
by req-per-sec to the time you want things cached by or run out of $$ to
buy disks.
Memory consumption is dominated by the disk index (10-15 MB index / 1
GB of storage). And by cache_mem storage, which will suck up every spare
byte you can give it until itself starts to suffer those 2^24 object
limits. per-User/connection requirements are measured in KB, so these
days not really worth worrying over.
Amos
Received on Tue Sep 06 2011 - 04:15:55 MDT
This archive was generated by hypermail 2.2.0 : Tue Sep 06 2011 - 12:00:02 MDT