On 11/04/2013 12:23 a.m., Youssef Ghorbal wrote:
> I was aware of that page.
> As you said, it's often RPS so it's not relevant for me.
It is more relevant than you seem to think. Squid processing overheads
are tied tightly to the request parsing and ACL testing processes. These
are relatively fixed overheads for each request regardless of the
request size.
IIRC the 50Mbps traffic was on average HTTP request traffic objects in a
medium sized ISP - we do not have any good detaisl on what that average
was though. With very little extra overheads the same proxy on same
hardware might also reach 100Mbps. All that is required is the avg
object size to go from, for example, 16KB to 32KB which are both within
the bounds of "average HTTP traffic" sizes (11-63KB).
Amos
>
> Youssef
> --------------------
> On Apr 10, 2013, at 2:02 PM, Kinkie <gkinkie_at_gmail.com> wrote:
>
>> You probably want to check http://wiki.squid-cache.org/KnowledgeBase/Benchmarks
>>
>> Unfortunately the benchmarks reported are often expressed as RPS and
>> not bandwidth.
>>
>>
>>
>> On Wed, Apr 10, 2013 at 1:21 PM, Youssef Ghorbal <djo_at_pasteur.fr> wrote:
>>> On Apr 10, 2013, at 10:37 AM, Kinkie <gkinkie_at_gmail.com> wrote:
>>>
>>>> On Tue, Apr 9, 2013 at 11:35 PM, Youssef Ghorbal <djo_at_pasteur.fr> wrote:
>>>>> Hello,
>>>>>
>>>>> Is there any recent figures about max throughput to be expected from a squid 3.x install (on recent hardware) in the scenario of a single stream downloading a large file (> 1GB) (read not cacheable)
>>>>> I'm aware that's not a performance metric per se, but it's one of the scenarios we have to deal with.
>>>>>
>>>>> Few weeks ago, Amos talked about 50Mb/s (client + server) for a squid 3.1
>>>> Hi,
>>>> 50mb/s seems a very conservative estimate to me; in that scenario
>>>> Squid is essentially acting as a network pipe.
>>>> Assuming this is a lab (and we can thus ignore bandwidth and latency
>>>> on the internet link), the expectation is that this kind of scenario
>>>> for squid will be CPU and network I/O bound, so in order to give any
>>>> sensible answer we'd need to know what kind of network interface you
>>>> would use (fast-ethernet? Giga-ethernet copper? Giga-ethernet fiber?
>>>> Even faster?), what kind of CPU and what kind of system architecture
>>>> (server-class? pc-class? virtual?)
>>> I'm agree, it's a LAB and we can ignore bandwidth and latency of Internet link. And it's exactly what you said it's a scenario where Squid is essentially acting as a network pipe.
>>> Here is a summary of the hardware :
>>> - 1Gb ethernet NIC (copper) : the same of client and server traffic.
>>> - 16GB RAM
>>> - 2 CPUs Quad Core (Xeon E5420 2.5Ghz per core) : I think that the many cores are not relevent since a single stream will eventually be handled by a single core.
>>> - FreeBSD 8.3 amd64
>>>
>>> What I'm seeing right now is ~50Mb/s on 3.1 release (as Amos said earlier) which seems very conservative estimate to me too, and I was seeking infos on what can be expected in a perfect world.
>>> If it's the current best figures I can get, that's fine and I'll not be looking to optmise anything else. If it can do a lot better (let's say 10 times better) I'll try to investgate time to reach this (upgrade to the last release, tune the configuration, tune the system etc)
>>>
>>> Youssef
Received on Thu Apr 11 2013 - 10:13:40 MDT
This archive was generated by hypermail 2.2.0 : Thu Apr 11 2013 - 12:00:03 MDT