On 11/12/2013 9:24 p.m., Dr.x wrote: > hi , > in my opinion > 100 users is not soo much http requests > and smp is not the right solution >>>>>>>>>>>> > > you can tune squid parameters and optimize squid , u dint need SMP . > > smp is limited to object size 32 k and in my opinion it will be less hits > than squid without smp. > > SMP can help u when u have multicore machine and u have a huge http requests > and wantto balance the http requesst among ur cores . > > > and agian , here , im asking Amos about SMP>>>>> > > can we after using SMP to get more BW saving ?? assume we fixed all other > parameters of squid and want to make comparision Well. Sadly there currently seems to be a loss on caching, amount depending on your starting HIT ratio and traffic sizes. Like you said the 32KB size limit is a bit nasty. Thankfully we are about to get collapsed-forwarding and large-rock features which should allow better ratios as larger objects can be HIT cross-worker in SMP. Assuming all the non-SMP-aware features of Squid were SMP-aware you should see no difference in HIT ratio and similar metrics between a single-process instance and a SMP instance. Cache ratio is a property of the traffic itself and depends on how much storage space Squid has (ie how far back it in the flow it can cache). The difference and behaviours we must work around today is mostly due to the incomplete nature of SMP support in Squid. (Hint for people to sponsor or do work on those issues). > > assume i have server without smp and save about 40 MBps > > can i reach this value after SMP ??? I think so. But what you will have to do to get there is probably more config hackery than you would want to do for the gains. SMP in Squid today is offering simplicity of configuration when scaling out on multi-processor machines to take advantage of costs already paid for the hardware. With some amount of bandwidth savings on the side. Amos
