subject:"\[squid\-users\] squid performance"



 I want to share the results with the community on the squid wikis. How
 to do that?


 We are collecting some ad-hoc benchmark details for Squid releases at
 http://wiki.squid-cache.org/KnowledgeBase/Benchmarks. So far this is not
 exactly a rigourous testing, although following the methodology for stats
 collection (as outline in the intro section) retains consistency and
 improves comparability between submissions.

 Since you are using a different methodology, please feel free to write up a
 new article on it. The details you just posted looks like a good start. We
 can offer wiki or static web page, or reference from our benchmarking page
 to a blog publication of your own.


Yes sure that would be great. I will write a blog post and post here aswell


 Some results from the tests are:

 Server response size = 200 Bytes
 New means keep-alive were turned
 Keep-alive mean keep-alive were used with 100 http req/conn
 C= concurrent requests


   HTTP   HTTPS
  New
 | Keep-Alive   New| Keep-Alive

 RPS
c= 50   6466 | 20227
1336 | 14461
c= 100 6392 | 21583
   1303 | 14683
c = 2005986 | 21462
1300 | 13967

 Throughput(mbps)
c = 50   26|
 82.45.4 | 59
c=100   25.8 | 88
5.25 | 60
 c=200  24 | 88
  5.4 | 58

 Latency(ms)
 c= 50  7.5 | 2.7
 36 | 3.75
 c= 10015.8 | 5.27
 80 | 8
c=200  26.5 | 11.3
 168 | 18


The SSL numbers seem pretty low to me on such a powerful machine. Do
you think these can be improved somehow.
For HTTPS i was using 1024 Bytes key size. The ciphers being selected
between ab and squid and between squid and
lighttpd were  TLS_RSA_WITH_AES_256_CBC_SHA and
TLS_DHE_RSA_WITH_AES_256_CBC_SHA respectively



 With this results I profile squid with perf tool and got some
 results that I could not understand. So my question are related to
 them


 Thank you. Some very nice numbers. I hope they give a clue to anyone still
 thinking persistent connections need to be disabled to improve performance.


 For the HTTS case, the CPU utilization peaks around 90% on all cores
 and the perf profiler gives:

 24.63%squid  libc-2.15.so [.] __memset_sse2

 6.13%squid  libcrypto.so.1.0.0   [.] bn_sqr4x_mont

  4.98%squid  [kernel.kallsyms][k] hypercall_page

|

--- hypercall_page

   |

   |--93.73%-- check_events


 Why is so much time spent in one instruction by squid? and too a
 memset instruction! Any pointers?


 Squid was originally written in C and still has a lot of memset() calls
 around the place clearing memory before use. We have made a few attempts to
 track them down and remove unnecessary usages but a lot still remain.
 Another attempt was tried in the more recent code, so you may find a lower
 profile rating in the current 3.HEAD.

 Also check whether you have memory_pools on or off. That can affect the
 amount of calls to memset().


Memory pools were ON. I did not change the default behavior


 Since in this case all CPU power is being used so it is understandable
 that  the performance cannot be improved here. The problem arises with
 the HTTP case.


 On the contrary, code improvements can be done to reduce CPU cycle
 requirements by Squid, which in turn raise the performance. If your
 profiling can highlight things like memset() or Squid functions in the
 current consuming large amounts of CPU effort can be targeted at reducing
 those occurances for best work/performance gains.


Yes obviously code improvements can be done. What I mean to say was
that in the current scenario with
the current code base these will stay constant

 For the plain HTTP case, the CPU utilization is only around 50-60% on
 all the cores and perf says:


 8.47%squid  [kernel.kallsyms][k] hypercall_page
--- hypercall_page
|--94.78%-- check_events

 1.78%squid  libc-2.15.so [.] vfprintf
 1.62%squid  [kernel.kallsyms][k] xen_spin_lock
 1.44%squid  libc-2.15.so [.] __memcpy_ssse3_back


 These results show that squid is NOT CPU bound at this point. Neither
 is it Network IO

Re: [squid-users] Squid performance profiling

On Thu, Jun 20, 2013 at 5:21 PM, Marcus Kool
marcus.k...@urlfilterdb.com wrote:


 On 06/20/2013 06:51 AM, Amos Jeffries wrote:



 If anyone is interested with very detailed benchmarks, then I can provide
 them.


 Yes please :-)

 PS. could you CC the squid-dev mailing list as well with the details. The
 more developer eyes we can get on this data the better. Although please do
 test a current release first, we have significantly
 changed the ACL handling which was one bottleneck in Squid, and have
 altered the mempools use of memset() is several locations in the latest
 3.HEAD code.

 Amos


 I understand that Amos is eager to get more tests and more results about
 the latest enhancements, but as Amos himself also stated earlier, please
 use a released version of Squid for testing since the test results for
 3.3.x or 3.4.x are interesting for admins of Squid who can consider
 upgrading,
 but test results for 3.HEAD are not useful for them since they are not
 likely
 to consider an upgrade to 3.HEAD.

Yes sure I can do that.


 And if you have spare resources, it would be interesting to perform the
 same test for 3.3.5 and 3.2.11 to see the differences between releases.
 And of course, when 3.4 comes out, perform the test again...

 The test that you performed is very nice. I am sure that many like this.
 But I also like to see the full squid.conf. Just for transparency and
 maybe to suggest an optimisation tweak.

 Thanks
 Marcus



--
Regards,
-Ahmed Talha Khan

Re: [squid-users] Squid performance profiling

On Fri, Jun 21, 2013 at 10:41 AM, Alex Rousskov
rouss...@measurement-factory.com wrote:
 On 06/20/2013 10:47 PM, Ahmed Talha Khan wrote:
 On Fri, Jun 21, 2013 at 6:17 AM, Alex Rousskov wrote:
 On 06/20/2013 02:00 AM, Ahmed Talha Khan wrote:
 My test methodology looks like this

 generator(apache benchmark)---squid--server(lighttpd)
 ...
 These results show that squid is NOT CPU bound at this point. Neither
 is it Network IO bound because i can get much more throughput when I
 only run the generator with the server. In this case squid should be
 able to do more. Where is the bottleneck coming from?


 The bottleneck may be coming from your test methodology -- you are
 allowing Squid to slow down the benchmark instead of benchmark driving
 the Squid box to its limits. You appear to be using what we call a best
 effort test, where the request rate is determined by Squid response
 time. In most real-world environments concerned with performance, the
 request rate does not decrease just because a proxy wants to slow down a
 little.


 Then the question becomes why squid is slowing down?

 I think there are 2.5 primary reasons for that:

 1) Higher concurrency level (c in your tables) means more
 waiting/queuing time for each transaction: When [a part of] one
 transaction has to wait for [a part of] another before being served,
 transaction response time goes up. For example, the more network sockets
 are ready at the same time, the higher the response time is going to
 be for the transaction which socket happens to be the last one ready
 during that specific I/O loop iteration.


Are these queues maintained internally inside squid? What can be done
to reduce this?

 2a) Squid sometimes uses hard-coded limits for various internal caches
 and tables. With higher concurrency level, Squid starts hitting those
 limits and operating less efficiently (e.g., not keeping a connection
 persistent because the persistent connection table is full -- I do not
 remember whether this actually happens, so this is just an example of
 what could happen to illustrate 2a).

Can you point me to some of the key ones and their impact? So that I
can test by changing
these limits and seeing if it enhances/degrades the performance. Also,
any tweaks in
the network stack that might help with that. I am primarily interested
in enhancing the SSL performance.



 2b) Poor concurrency scale. Some Squid code becomes slower with more
 concurrent transactions flying around because that code has to iterate
 more structures while dealing with more collisions and such.


 Well all that can be done on this front is that I have to wait for
the changes to go in.

 There is nothing we can do about #1, but we can improve #2a and #2b
 (they are kind of related).


 best effort tests also
 give a good measure of what the proxy(server) can do without breaking
 it.

 Yes, but, in my experience, the vast majority of best-effort results are
 misinterpreted: It is very difficult to use a best-effort test
 correctly, and it is very easy to come to the wrong conclusions by
 looking at its results. YMMV.


 Do you see any wrong conclusion that I might have made in
interpreting these results?

 BTW, a persistent load test does not have to break the proxy. You only
 need to break the proxy if you want to find where its breaking point
 (and, hence, the bottleneck) is with respect to load (or other traffic
 parameters).



Sure

 Do you see any reason from the perf results/benchmarks
 why squid would not be utilizing all CPU and giving out more requests
 per second?

 In our tests, Squid does utilize virtually all CPU cycles (if we push it
 hard enough). It is just a matter of creating enough/appropriate load.


Why would it not do in my test setup? I does use all CPU cores to the
fullest in the case of HTTPS, but not in the case
of HTTP as i pointed out earlier

 However, if you are asking whether Squid can be changed to run faster
 than it does today, then the answer is yes, of course. There is still a
 lot of inefficient, slow code in Squid.


 HTH,

 Alex.




--
Regards,
-Ahmed Talha Khan

Re: [squid-users] Squid performance profiling



 I understand that Amos is eager to get more tests and more results about
 the latest enhancements, but as Amos himself also stated earlier, please
 use a released version of Squid for testing since the test results for
 3.3.x or 3.4.x are interesting for admins of Squid who can consider
 upgrading,
 but test results for 3.HEAD are not useful for them since they are not
 likely
 to consider an upgrade to 3.HEAD.

 And if you have spare resources, it would be interesting to perform the
 same test for 3.3.5 and 3.2.11 to see the differences between releases.
 And of course, when 3.4 comes out, perform the test again...

 The test that you performed is very nice. I am sure that many like this.
 But I also like to see the full squid.conf. Just for transparency and
 maybe to suggest an optimisation tweak.


Here is my squid conf:
I am using squid as a normal forward proxy with SSL bump.

You would be able to see that I have not tampered with the
memory_pools or ssl_session much.

*SQUID.CONF**
cache_effective_user madmin

always_direct allow all
ssl_bump allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

# No need for caching
cache deny all

#Dont need logs for benchmarks
access_log none

# SMP scale
workers 8

# Turn off ICAP for the benchmarks
icap_enable off

#Only for benchmarks
http_access allow all

# Dynamic certificate generation
sslcrtd_program /usr/local/squid-3.3/libexec/ssl_crtd -s
/usr/local/squid-3.3/var/lib/ssl_db -M 4MB
sslcrtd_children 10


#PORTS
http_port 10.174.198.149:3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/home/madmin/squid/ca.pem
key=/home/madmin/squid/ca.pem
https_port 10.174.198.149:3129 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/home/madmin/squid/ca.pem
key=/home/madmin/squid/ca.pem


**





 Thanks
 Marcus



--
Regards,
-Ahmed Talha Khan

Re: [squid-users] Squid performance profiling

2013-06-21 Thread Alex Rousskov

On 06/21/2013 04:34 AM, Ahmed Talha Khan wrote:
Then the question becomes why squid is slowing down?

I think there are 2.5 primary reasons for that:

1) Higher concurrency level (c in your tables) means more
waiting/queuing time for each transaction: When [a part of] one
transaction has to wait for [a part of] another before being served,
transaction response time goes up. For example, the more network sockets
are ready at the same time, the higher the response time is going to
be for the transaction which socket happens to be the last one ready
during that specific I/O loop iteration.

Are these queues maintained internally inside squid? What can be done
to reduce this?

Resource contention is a property of the workload. While optimizations
targeted at making Squid spend fewer resources (e.g., CPU cycles) per
transaction or adding more resources (e.g., CPU cores) effectively
reduce contention as a side effect, there is nothing you can do to
reduce it directly.

2a) Squid sometimes uses hard-coded limits for various internal caches
and tables. With higher concurrency level, Squid starts hitting those
limits and operating less efficiently (e.g., not keeping a connection
persistent because the persistent connection table is full -- I do not
remember whether this actually happens, so this is just an example of
what could happen to illustrate 2a).

Can you point me to some of the key ones and their impact? So that I
can test by changing
these limits and seeing if it enhances/degrades the performance. Also,
any tweaks in
the network stack that might help with that. I am primarily interested
in enhancing the SSL performance.

I doubt #2a is a bottleneck here so if you want to optimize Squid, I
would recommend looking at other areas. Please note that I was simply
answering your why Squid slows down question, not outlining an
optimization plan.

I am not sure there is consensus among Squid developers regarding the
best optimization plan, but I can offer a few starting points:

* To enhance SSL performance, try hardware SSL accelerators. OpenSSL
supports some. Or are you already using them? Also, session caching may
be important. We will be posting a patch adding SSL session cache for
SMP Squid shortly. Sorry, I cannot answer most of your earlier questions
about session caching without additional research/checking, but I can
tell you that SMP session caching currently does not work at all (but
will work, at least for some forms of sessions, with the pending patch).

* To enhance overall Squid performance for small responses, I would
recommend focusing on reducing re-parsing and memory copying. The
StringNG project underpins many of the latter optimizations.

* To enhance overall Squid performance for large responses, especially
cached ones, I would focus on eliminating linear scans of in-memory pieces.

There are many other problematic areas and OS tweaks, of course. Some
are known and some are yet to be discovered. Their importance varies
depending on your workload and environment. If these changes, tweaks,
and optimizations were easy (or were backed by a lot of demand), we
would have done them already.

2b) Poor concurrency scale. Some Squid code becomes slower with more
concurrent transactions flying around because that code has to iterate
more structures while dealing with more collisions and such.

Well all that can be done on this front is that I have to wait for
the changes to go in.

Waiting is one of at least three options you have:
http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Do you see any wrong conclusion that I might have made in
interpreting these results?

I believe you shared test results and asked good questions about them
pretty much without interpreting those results. Please correct me if I
am wrong.

Why would it not do in my test setup? I does use all CPU cores to the
fullest in the case of HTTPS, but not in the case
of HTTP as i pointed out earlier

I have already speculated about that. In summary, your HTTP workload is
probably not giving Squid enough CPU work to do. HTTPS adds more CPU
work, of course. Needless to say, it is rather risky for me to criticize
a test based on a high-level description and a results table. I hope you
will forgive me if my guess ends up being wrong!

Thank you,

Alex.

Re: [squid-users] Squid performance profiling

2013-06-21 Thread Amos Jeffries


On 21/06/2013 10:34 p.m., Ahmed Talha Khan wrote:

On Fri, Jun 21, 2013 at 10:41 AM, Alex Rousskov
rouss...@measurement-factory.com wrote:

On 06/20/2013 10:47 PM, Ahmed Talha Khan wrote:

On Fri, Jun 21, 2013 at 6:17 AM, Alex Rousskov wrote:

On 06/20/2013 02:00 AM, Ahmed Talha Khan wrote:

My test methodology looks like this

generator(apache benchmark)---squid--server(lighttpd)

...

These results show that squid is NOT CPU bound at this point. Neither
is it Network IO bound because i can get much more throughput when I
only run the generator with the server. In this case squid should be
able to do more. Where is the bottleneck coming from?



The bottleneck may be coming from your test methodology -- you are
allowing Squid to slow down the benchmark instead of benchmark driving
the Squid box to its limits. You appear to be using what we call a best
effort test, where the request rate is determined by Squid response
time. In most real-world environments concerned with performance, the
request rate does not decrease just because a proxy wants to slow down a
little.



Then the question becomes why squid is slowing down?

I think there are 2.5 primary reasons for that:

1) Higher concurrency level (c in your tables) means more
waiting/queuing time for each transaction: When [a part of] one
transaction has to wait for [a part of] another before being served,
transaction response time goes up. For example, the more network sockets
are ready at the same time, the higher the response time is going to
be for the transaction which socket happens to be the last one ready
during that specific I/O loop iteration.


Are these queues maintained internally inside squid? What can be done
to reduce this?


The queue is created in a single step by the kernel. It responds with a 
set of FD with I/O events to be handled. Squid is then expected to 
iterate over them and do the I/O.
Like Alex said there is nothing that can be done about that queue 
itself. Looping over it fast and scheduling multiple internal Calls at 
once is tempting but just offloads the delay from the 
select/poll/epoll/kqueue loop to the AsyncCall queue, the visible/total 
delay remains constant (or possibly worse if they are double queued).





2a) Squid sometimes uses hard-coded limits for various internal caches
and tables. With higher concurrency level, Squid starts hitting those
limits and operating less efficiently (e.g., not keeping a connection
persistent because the persistent connection table is full -- I do not
remember whether this actually happens, so this is just an example of
what could happen to illustrate 2a).

Can you point me to some of the key ones and their impact? So that I
can test by changing
these limits and seeing if it enhances/degrades the performance. Also,
any tweaks in
the network stack that might help with that. I am primarily interested
in enhancing the SSL performance.


Much of the lag in SSL is due to the handshake exchanges it requires. 
There are a small amount of bytes in each direction wasting entire 
packet round-trip times just to set it up, followed by the processing 
overheads of actually crypting the bits.


The certificate generation process is a well-known slow process, there 
is nothing that can be done there as it relies heavily on the random 
number generator in the machine. SSL-bump with certificate generation 
uses caching to avoid that to some extent - it would be worthwhile 
testing how often (if at all) your benchmarks are held up waiting for 
new certs to be created.





2b) Poor concurrency scale. Some Squid code becomes slower with more
concurrent transactions flying around because that code has to iterate
more structures while dealing with more collisions and such.


  Well all that can be done on this front is that I have to wait for
the changes to go in.


There is nothing we can do about #1, but we can improve #2a and #2b
(they are kind of related).



best effort tests also
give a good measure of what the proxy(server) can do without breaking
it.

Yes, but, in my experience, the vast majority of best-effort results are
misinterpreted: It is very difficult to use a best-effort test
correctly, and it is very easy to come to the wrong conclusions by
looking at its results. YMMV.


  Do you see any wrong conclusion that I might have made in
interpreting these results?


BTW, a persistent load test does not have to break the proxy. You only
need to break the proxy if you want to find where its breaking point
(and, hence, the bottleneck) is with respect to load (or other traffic
parameters).



Sure


Do you see any reason from the perf results/benchmarks
why squid would not be utilizing all CPU and giving out more requests
per second?

In our tests, Squid does utilize virtually all CPU cycles (if we push it
hard enough). It is just a matter of creating enough/appropriate load.


Why would it not do in my test setup? I does use all CPU cores to the
fullest in the case of HTTPS, but

[squid-users] Squid performance profiling

2013-06-20 Thread Ahmed Talha Khan

Hello All,

I have been trying to benchmark the performance of squid for sometime
now for plain HTTP and HTTPS traffic.

The key performance indicators that i am looking at are Requests Per
Second(RPS), Throughput(mbps) and Latency (ms).

My test methodology looks like this

generator(apache benchmark)---squid--server(lighttpd)


All 3 are running on seperate VM on AWS.
The specs for all the machines are
8 VCPU @ 2.13 GHZ
16 GB RAM
Squid using 8 SMP workers to utilize all cores

In all these tests I have made sure that the generator and server are
always more powerful than squid. For latency calculation, Time per
request is calculated with and without squid inline and the difference
between them is taken.

I am using a release 3.HEAD just prior to the release of 3.3.

I want to share the results with the community on the squid wikis. How
to do that?

Some results from the tests are:

Server response size = 200 Bytes
New means keep-alive were turned
Keep-alive mean keep-alive were used with 100 http req/conn
C= concurrent requests


 HTTP   HTTPS
New
| Keep-Alive   New| Keep-Alive

RPS
  c= 50   6466 | 20227
  1336 | 14461
  c= 100 6392 | 21583
 1303 | 14683
  c = 2005986 | 21462
  1300 | 13967

Throughput(mbps)
  c = 50   26|
82.45.4 | 59
  c=100   25.8 | 88
  5.25 | 60
   c=200  24 | 88
5.4 | 58

Latency(ms)
   c= 50  7.5 | 2.7
   36 | 3.75
   c= 10015.8 | 5.27
   80 | 8
  c=200  26.5 | 11.3
   168 | 18


With this results I profile squid with perf tool and got some
results that I could not understand. So my question are related to
them


For the HTTS case, the CPU utilization peaks around 90% on all cores
and the perf profiler gives:

24.63%squid  libc-2.15.so [.] __memset_sse2

6.13%squid  libcrypto.so.1.0.0   [.] bn_sqr4x_mont

4.98%squid  [kernel.kallsyms][k] hypercall_page

  |

  --- hypercall_page

 |

 |--93.73%-- check_events


Why is so much time spent in one instruction by squid? and too a
memset instruction! Any pointers?

Since in this case all CPU power is being used so it is understandable
that  the performance cannot be improved here. The problem arises with
the HTTP case.

For the plain HTTP case, the CPU utilization is only around 50-60% on
all the cores and perf says:


8.47%squid  [kernel.kallsyms][k] hypercall_page
  --- hypercall_page
  |--94.78%-- check_events

1.78%squid  libc-2.15.so [.] vfprintf
1.62%squid  [kernel.kallsyms][k] xen_spin_lock
1.44%squid  libc-2.15.so [.] __memcpy_ssse3_back


These results show that squid is NOT CPU bound at this point. Neither
is it Network IO bound because i can get much more throughput when I
only run the generator with the server. In this case squid should be
able to do more. Where is the bottleneck coming from?

If anyone is interested with very detailed benchmarks, then I can provide them.


--
Regards,
-Ahmed Talha Khan

Re: [squid-users] Squid performance profiling

2013-06-20 Thread Amos Jeffries


On 20/06/2013 8:00 p.m., Ahmed Talha Khan wrote:

Hello All,

I have been trying to benchmark the performance of squid for sometime
now for plain HTTP and HTTPS traffic.

The key performance indicators that i am looking at are Requests Per
Second(RPS), Throughput(mbps) and Latency (ms).

My test methodology looks like this

generator(apache benchmark)---squid--server(lighttpd)


All 3 are running on seperate VM on AWS.
The specs for all the machines are
8 VCPU @ 2.13 GHZ
16 GB RAM
Squid using 8 SMP workers to utilize all cores


Using 8 workers is probably not a godo idea. The recommended practice is 
to use one core per worker and leave at leave one spare core for the 
kernels usage. Squid does pass a fair chunk of work to the kernel for 
I/O, while each workers will completely max out as many CPU cycles as it 
can grab from its own core. If there is no core retained for kernel 
usage those two properties will result in CPU contention slowdown as 
Squid and kernel fight for cycles.




In all these tests I have made sure that the generator and server are
always more powerful than squid. For latency calculation, Time per
request is calculated with and without squid inline and the difference
between them is taken.

I am using a release 3.HEAD just prior to the release of 3.3.


Then please upgrade to 3.3 stable release or a current 3.HEAD . There 
have been a few memory leaks and issues resolved in the time since 3.3 
was released which are fixed in the current stable. There are also 
additional performance improvements in the current 3.HEAD which will be 
in 3.4 when it branches.




I want to share the results with the community on the squid wikis. How
to do that?


We are collecting some ad-hoc benchmark details for Squid releases at 
http://wiki.squid-cache.org/KnowledgeBase/Benchmarks. So far this is not 
exactly a rigourous testing, although following the methodology for 
stats collection (as outline in the intro section) retains consistency 
and improves comparability between submissions.


Since you are using a different methodology, please feel free to write 
up a new article on it. The details you just posted looks like a good 
start. We can offer wiki or static web page, or reference from our 
benchmarking page to a blog publication of your own.


If you are intending to publish the results I do highly recommend that 
you settle on a packaged and numbered version of Squid so others can 
replicate the tests or do additional compartive testing on the same 
code. The 3.HEAD is a rolling release that is relatively difficult to 
locate the exact sources for any given revision,  the numbered packages 
can be referenced from our permanent archives in your description.




Some results from the tests are:

Server response size = 200 Bytes
New means keep-alive were turned
Keep-alive mean keep-alive were used with 100 http req/conn
C= concurrent requests


  HTTP   HTTPS
 New
| Keep-Alive   New| Keep-Alive

RPS
   c= 50   6466 | 20227
   1336 | 14461
   c= 100 6392 | 21583
  1303 | 14683
   c = 2005986 | 21462
   1300 | 13967

Throughput(mbps)
   c = 50   26|
82.45.4 | 59
   c=100   25.8 | 88
   5.25 | 60
c=200  24 | 88
 5.4 | 58

Latency(ms)
c= 50  7.5 | 2.7
36 | 3.75
c= 10015.8 | 5.27
80 | 8
   c=200  26.5 | 11.3
168 | 18


With this results I profile squid with perf tool and got some
results that I could not understand. So my question are related to
them


Thank you. Some very nice numbers. I hope they give a clue to anyone 
still thinking persistent connections need to be disabled to improve 
performance.



For the HTTS case, the CPU utilization peaks around 90% on all cores
and the perf profiler gives:

24.63%squid  libc-2.15.so [.] __memset_sse2

6.13%squid  libcrypto.so.1.0.0   [.] bn_sqr4x_mont

 4.98%squid  [kernel.kallsyms][k] hypercall_page

   |

   --- hypercall_page

  |

  |--93.73%-- check_events


Why is so much time spent in one instruction by squid? and too a
memset instruction! Any pointers?


Squid was originally written in C and still has a lot of memset() calls

Re: [squid-users] Squid performance profiling

2013-06-20 Thread Marcus Kool




On 06/20/2013 06:51 AM, Amos Jeffries wrote:




If anyone is interested with very detailed benchmarks, then I can provide them.


Yes please :-)

PS. could you CC the squid-dev mailing list as well with the details. The more 
developer eyes we can get on this data the better. Although please do test a 
current release first, we have significantly
changed the ACL handling which was one bottleneck in Squid, and have altered 
the mempools use of memset() is several locations in the latest 3.HEAD code.

Amos


I understand that Amos is eager to get more tests and more results about
the latest enhancements, but as Amos himself also stated earlier, please
use a released version of Squid for testing since the test results for
3.3.x or 3.4.x are interesting for admins of Squid who can consider upgrading,
but test results for 3.HEAD are not useful for them since they are not likely
to consider an upgrade to 3.HEAD.

And if you have spare resources, it would be interesting to perform the
same test for 3.3.5 and 3.2.11 to see the differences between releases.
And of course, when 3.4 comes out, perform the test again...

The test that you performed is very nice. I am sure that many like this.
But I also like to see the full squid.conf. Just for transparency and
maybe to suggest an optimisation tweak.

Thanks
Marcus

Re: [squid-users] Squid performance profiling

2013-06-20 Thread Alex Rousskov

On 06/20/2013 02:00 AM, Ahmed Talha Khan wrote:

 My test methodology looks like this
 
 generator(apache benchmark)---squid--server(lighttpd)
...
 These results show that squid is NOT CPU bound at this point. Neither
 is it Network IO bound because i can get much more throughput when I
 only run the generator with the server. In this case squid should be
 able to do more. Where is the bottleneck coming from?

The bottleneck may be coming from your test methodology -- you are
allowing Squid to slow down the benchmark instead of benchmark driving
the Squid box to its limits. You appear to be using what we call a best
effort test, where the request rate is determined by Squid response
time. In most real-world environments concerned with performance, the
request rate does not decrease just because a proxy wants to slow down a
little.

When we want to find the bottleneck, we often tell Web Polygraph to
increase proxy load until things start to break. In this persistent
load mode, Polygraph does not allow the proxy to determine the request
rate. It keeps pounding the proxy [at the configured rate], just like
real users would. I do not know whether ab can do it, but I would not be
surprised if it can. plugStill, I would recommend that you use a
benchmarking tool designed to test proxies rather than origin servers
:-)./plug


Cheers,

Alex.

Re: [squid-users] Squid performance profiling

2013-06-20 Thread Ahmed Talha Khan

On Fri, Jun 21, 2013 at 6:17 AM, Alex Rousskov
rouss...@measurement-factory.com wrote:
 On 06/20/2013 02:00 AM, Ahmed Talha Khan wrote:

 My test methodology looks like this

 generator(apache benchmark)---squid--server(lighttpd)
 ...
 These results show that squid is NOT CPU bound at this point. Neither
 is it Network IO bound because i can get much more throughput when I
 only run the generator with the server. In this case squid should be
 able to do more. Where is the bottleneck coming from?

 The bottleneck may be coming from your test methodology -- you are
 allowing Squid to slow down the benchmark instead of benchmark driving
 the Squid box to its limits. You appear to be using what we call a best
 effort test, where the request rate is determined by Squid response
 time. In most real-world environments concerned with performance, the
 request rate does not decrease just because a proxy wants to slow down a
 little.

Then the question becomes why squid is slowing down? It is not CPU
bound, neither is it Network bound. What
can cause squid to not utilize all the resources that it can. I agree
to your point of view that in real-world
environments the situation is more like webpolygraph(or spirent,
avalanche for that matter) but best effort tests also
give a good measure of what the proxy(server) can do without breaking
it. Do you see any reason from the perf results/benchmarks
why squid would not be utilizing all CPU and giving out more requests
per second?


 When we want to find the bottleneck, we often tell Web Polygraph to
 increase proxy load until things start to break. In this persistent
 load mode, Polygraph does not allow the proxy to determine the request
 rate. It keeps pounding the proxy [at the configured rate], just like
 real users would. I do not know whether ab can do it, but I would not be
 surprised if it can. plugStill, I would recommend that you use a
 benchmarking tool designed to test proxies rather than origin servers
 :-)./plug

I plan to test it with webpolygraph also when I get the due time and
resources. But for now I want to make sense of the lower
numbers. BTW, ab cannot do this constant request rate model testing


 Cheers,

 Alex.




--
Regards,
-Ahmed Talha Khan

Re: [squid-users] Squid performance profiling

2013-06-20 Thread Alex Rousskov

On 06/20/2013 10:47 PM, Ahmed Talha Khan wrote:
 On Fri, Jun 21, 2013 at 6:17 AM, Alex Rousskov wrote:
 On 06/20/2013 02:00 AM, Ahmed Talha Khan wrote:
 My test methodology looks like this

 generator(apache benchmark)---squid--server(lighttpd)
 ...
 These results show that squid is NOT CPU bound at this point. Neither
 is it Network IO bound because i can get much more throughput when I
 only run the generator with the server. In this case squid should be
 able to do more. Where is the bottleneck coming from?


 The bottleneck may be coming from your test methodology -- you are
 allowing Squid to slow down the benchmark instead of benchmark driving
 the Squid box to its limits. You appear to be using what we call a best
 effort test, where the request rate is determined by Squid response
 time. In most real-world environments concerned with performance, the
 request rate does not decrease just because a proxy wants to slow down a
 little.


 Then the question becomes why squid is slowing down? 

I think there are 2.5 primary reasons for that:

1) Higher concurrency level (c in your tables) means more
waiting/queuing time for each transaction: When [a part of] one
transaction has to wait for [a part of] another before being served,
transaction response time goes up. For example, the more network sockets
are ready at the same time, the higher the response time is going to
be for the transaction which socket happens to be the last one ready
during that specific I/O loop iteration.

2a) Squid sometimes uses hard-coded limits for various internal caches
and tables. With higher concurrency level, Squid starts hitting those
limits and operating less efficiently (e.g., not keeping a connection
persistent because the persistent connection table is full -- I do not
remember whether this actually happens, so this is just an example of
what could happen to illustrate 2a).

2b) Poor concurrency scale. Some Squid code becomes slower with more
concurrent transactions flying around because that code has to iterate
more structures while dealing with more collisions and such.

There is nothing we can do about #1, but we can improve #2a and #2b
(they are kind of related).


 best effort tests also
 give a good measure of what the proxy(server) can do without breaking
 it.

Yes, but, in my experience, the vast majority of best-effort results are
misinterpreted: It is very difficult to use a best-effort test
correctly, and it is very easy to come to the wrong conclusions by
looking at its results. YMMV.

BTW, a persistent load test does not have to break the proxy. You only
need to break the proxy if you want to find where its breaking point
(and, hence, the bottleneck) is with respect to load (or other traffic
parameters).


 Do you see any reason from the perf results/benchmarks
 why squid would not be utilizing all CPU and giving out more requests
 per second?

In our tests, Squid does utilize virtually all CPU cycles (if we push it
hard enough). It is just a matter of creating enough/appropriate load.

However, if you are asking whether Squid can be changed to run faster
than it does today, then the answer is yes, of course. There is still a
lot of inefficient, slow code in Squid.


HTH,

Alex.

Re: [squid-users] Squid performance with high load

2013-03-31 Thread Hasanen AL-Bana

On Sun, Mar 31, 2013 at 3:20 AM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 31/03/2013 9:07 a.m., Hasanen AL-Bana wrote:

 The above config for cache_dirs is not working probably.


 You are top-posting.
 . Why?
 .. There is no above config.
Sorry , it is the new gmail composer...



 I can see the aufs dir growing rapidly while the Rock directory has
 been created but it is empty !


 ---
 Store Directory Statistics:
 Store Entries  : 1166040
 Maximum Swap Size  : 174080 KB
 Current Store Swap Size: 85456552.00 KB
 Current Capacity   : 4.91% used, 95.09% free

 Store Directory #0 (rock): /mnt/ssd/cache/
 FS Block Size 1024 Bytes

 Maximum Size: 30720 KB
 Current Size: 760592.00 KB 0.25%
 Maximum entries:   239
 Current entries:  5942 0.25%
 Pending operations: 137 out of 0
 Flags:

 Store Directory #1 (aufs): /mnt/sas1/cache/store1
 FS Block Size 4096 Bytes
 First level subdirectories: 32
 Second level subdirectories: 512
 Maximum Size: 143360 KB
 Current Size: 84695960.00 KB
 Percent Used: 5.91%
 Filemap bits in use: 1159378 of 2097152 (55%)
 Filesystem Space in use: 121538556/-1957361748 KB (-5%)
 Filesystem Inodes in use: 1176103/146243584 (1%)
 Flags:
 Removal policy: lru
 LRU reference age: 0.17 days

 On Sat, Mar 30, 2013 at 5:10 PM, Hasanen AL-Bana hasa...@gmail.com
 wrote:

 Thank you Amos for clarifying these issues.
 I will skip SMP and use single worker since Rock limit my max object
 size to 32kb when used in shared environments.
 My new cache_dir configuration looks like this now :

 cache_dir rock /mnt/ssd/cache/ 30 max-size=131072
 cache_dir aufs /mnt/sas1/cache/store1  140 32 512


 NP: Rock is a 'slot'-based database format and does not support objects
 larger than 32KB, unless you are using the experimental large-rock code.
 max-size will be capped down to max-size=32767. You should have seen a
 warning about that when starting or reconfiguring Squid.

 To prevent the AUFS dir filling wil small objects that can best be served
 from Rock, you will also need min-size= parameter on the AUFS. Otherwise
 Squid will base selection on capacity loading and will determine that the
 1.4TB dir has more free space than the 300GB Rock one.


Ok , according to the Wiki at
http://wiki.squid-cache.org/Features/RockStore , the max size is
limited to 32kb if I work in shared environment. I have only one
worker now and my rock max-size is set to 131072.
To make it work , I had to change my cache_dir selection algorithm to
round-robin.



 I have enabled store.log to be used with some other software
 collecting data from it

 my disks are now mounted with

 noatime,barrier=0,journal_async_commit,noauto_da_alloc,nobh,data=writeback,commit=10

 I will keep the list posted with my results.
 Thanks.


 Amos

Re: [squid-users] Squid performance with high load

2013-03-30 Thread Amos Jeffries


On 30/03/2013 6:33 a.m., Hasanen AL-Bana wrote:

Hi,

I am running squid 3.2 with an average of 50k req/min. Total received
bandwidth is around 200mbit/s.
I have problem when my aufs cache_dirs reaches size above 600GB.
Traffic starts dropping and going up again , happening every 20~30 minutes.
I have more that enough RAM in the system (125GB DDR3 !) , All disks
are SAS 15k rpm, one of them is and SSD 450GB.
So hardware should not cause any problem and I should easily spawn
multiple squid workers any time.
So what could cause such problems ?


#1 - AUFS is *not* SMP-aware component in Squid.

Each of the two workers you are using will be altering the on-disk 
portion of the cache without updating the in-memory index. When the 
other worker encounters these over-written files it will erase them.


For now you are required to use the macros hacks to split the cache_dir 
lines between the workers.



#2 - you have multiple cache_dir per disk. Or so it seems from your 
configuration. Is that correct?


 * squid load balances between cache_dir treating them as separate 
physcal HDD when it comes to loading calculations.


* the memory requirement for indexing these 1.6 TB of disk space is 
~24GB per worker plus the 20GB of shared emmory cache == 68GB of RAM.




I advise to you inform Squid about the real disk topology it is working 
with. No more than one AUFS cache_dir per physical disk and allocate the 
cache_dir size to ~80-90% the full available disk space. With each 
worker assigned to use a sub-set of the AUFS cache_dir and associated disks.


For best performance and object de-duplication you should consider using 
rock cache_dir for small objects. They *are* shared between workers, and 
can also share disk space with an AUFS disk.




Thank you.


include /etc/squid3/refresh.conf


cache_mem 20 GB

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly
plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT


http_access allow localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow localnet
http_access allow localhost

http_access allow all


Sure, why bother having security at all?


  maximum_object_size_in_memory 512 KB
  memory_cache_mode always
  memory_replacement_policy heap GDSF
  cache_replacement_policy heap LFUDA
  store_dir_select_algorithm least-load
  max_open_disk_fds 0
  maximum_object_size 200 MB

  cache_swap_high 98
  cache_swap_low  97


# access_log stdio:/var/log/squid3/access.log
  access_log none
  cache_log /var/log/squid3/cache.log
  cache_store_log stdio:/var/log/squid3/store.log


Usually the log you want to use is access_log, with the store debug log 
(cache_store_log) disabled.



  workers 2

cache_dir aufs /mnt/ssd/cache/store1 5 32 512
cache_dir aufs /mnt/ssd/cache/store2 5 32 512
cache_dir aufs /mnt/ssd/cache/store3 5 32 512
cache_dir aufs /mnt/ssd/cache/store4 5 32 512
cache_dir aufs /mnt/ssd/cache/store5 5 32 512
cache_dir aufs /mnt/ssd/cache/store6 5 32 512
cache_dir aufs /mnt/ssd/cache/store7 5 32 512


cache_dir aufs /mnt/sas1/cache/store1  5 32 512
cache_dir aufs /mnt/sas1/cache/store2  5 32 512
cache_dir aufs /mnt/sas1/cache/store3  5 32 512
cache_dir aufs /mnt/sas1/cache/store4  5 32 512
cache_dir aufs /mnt/sas1/cache/store5  5 32 512
cache_dir aufs /mnt/sas1/cache/store6  5 32 512
cache_dir aufs /mnt/sas1/cache/store7  5 32 512
cache_dir aufs /mnt/sas1/cache/store8  5 32 512
cache_dir aufs /mnt/sas1/cache/store9  5 32 512
cache_dir aufs /mnt/sas1/cache/store10  5 32 512
cache_dir aufs /mnt/sas1/cache/store11  5 32 512
cache_dir aufs /mnt/sas1/cache/store12  5 32 512


cache_dir aufs /mnt/sas2/cache/store1  5 32 512
cache_dir aufs /mnt/sas2/cache/store2  5 32 512
cache_dir aufs /mnt/sas2/cache/store3  5 32 512
cache_dir aufs /mnt/sas2/cache/store4  5 32 512
cache_dir aufs /mnt/sas2/cache/store5  5 32 512
cache_dir aufs /mnt/sas2/cache/store6  5 32 512
cache_dir aufs /mnt/sas2/cache/store7  5 32 512
cache_dir aufs /mnt/sas2/cache/store8  5 32 512
cache_dir aufs /mnt/sas2/cache/store9

Re: [squid-users] Squid performance with high load

2013-03-30 Thread Hasanen AL-Bana

Thank you Amos for clarifying these issues.
I will skip SMP and use single worker since Rock limit my max object
size to 32kb when used in shared environments.
My new cache_dir configuration looks like this now :

cache_dir rock /mnt/ssd/cache/ 30 max-size=131072
cache_dir aufs /mnt/sas1/cache/store1  140 32 512

I have enabled store.log to be used with some other software
collecting data from it

my disks are now mounted with
noatime,barrier=0,journal_async_commit,noauto_da_alloc,nobh,data=writeback,commit=10

I will keep the list posted with my results.
Thanks.

On Sat, Mar 30, 2013 at 12:57 PM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 30/03/2013 6:33 a.m., Hasanen AL-Bana wrote:

 Hi,

 I am running squid 3.2 with an average of 50k req/min. Total received
 bandwidth is around 200mbit/s.
 I have problem when my aufs cache_dirs reaches size above 600GB.
 Traffic starts dropping and going up again , happening every 20~30
 minutes.
 I have more that enough RAM in the system (125GB DDR3 !) , All disks
 are SAS 15k rpm, one of them is and SSD 450GB.
 So hardware should not cause any problem and I should easily spawn
 multiple squid workers any time.
 So what could cause such problems ?


 #1 - AUFS is *not* SMP-aware component in Squid.

 Each of the two workers you are using will be altering the on-disk portion
 of the cache without updating the in-memory index. When the other worker
 encounters these over-written files it will erase them.

 For now you are required to use the macros hacks to split the cache_dir
 lines between the workers.


 #2 - you have multiple cache_dir per disk. Or so it seems from your
 configuration. Is that correct?

  * squid load balances between cache_dir treating them as separate physcal
 HDD when it comes to loading calculations.

 * the memory requirement for indexing these 1.6 TB of disk space is ~24GB
 per worker plus the 20GB of shared emmory cache == 68GB of RAM.



 I advise to you inform Squid about the real disk topology it is working
 with. No more than one AUFS cache_dir per physical disk and allocate the
 cache_dir size to ~80-90% the full available disk space. With each worker
 assigned to use a sub-set of the AUFS cache_dir and associated disks.

 For best performance and object de-duplication you should consider using
 rock cache_dir for small objects. They *are* shared between workers, and can
 also share disk space with an AUFS disk.



 Thank you.


 
 include /etc/squid3/refresh.conf


 cache_mem 20 GB

 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
 acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
 acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
 acl localnet src fc00::/7   # RFC 4193 local private network range
 acl localnet src fe80::/10  # RFC 4291 link-local (directly
 plugged) machines

 acl SSL_ports port 443
 acl Safe_ports port 80  # http
 acl Safe_ports port 21  # ftp
 acl Safe_ports port 443 # https
 acl Safe_ports port 70  # gopher
 acl Safe_ports port 210 # wais
 acl Safe_ports port 1025-65535  # unregistered ports
 acl Safe_ports port 280 # http-mgmt
 acl Safe_ports port 488 # gss-http
 acl Safe_ports port 591 # filemaker
 acl Safe_ports port 777 # multiling http
 acl CONNECT method CONNECT


 http_access allow localhost manager
 http_access deny manager
 http_access deny !Safe_ports
 http_access deny CONNECT !SSL_ports

 http_access allow localnet
 http_access allow localhost

 http_access allow all


 Sure, why bother having security at all?


   maximum_object_size_in_memory 512 KB
   memory_cache_mode always
   memory_replacement_policy heap GDSF
   cache_replacement_policy heap LFUDA
   store_dir_select_algorithm least-load
   max_open_disk_fds 0
   maximum_object_size 200 MB

   cache_swap_high 98
   cache_swap_low  97


 # access_log stdio:/var/log/squid3/access.log
   access_log none
   cache_log /var/log/squid3/cache.log
   cache_store_log stdio:/var/log/squid3/store.log


 Usually the log you want to use is access_log, with the store debug log
 (cache_store_log) disabled.


   workers 2

 cache_dir aufs /mnt/ssd/cache/store1 5 32 512
 cache_dir aufs /mnt/ssd/cache/store2 5 32 512
 cache_dir aufs /mnt/ssd/cache/store3 5 32 512
 cache_dir aufs /mnt/ssd/cache/store4 5 32 512
 cache_dir aufs /mnt/ssd/cache/store5 5 32 512
 cache_dir aufs /mnt/ssd/cache/store6 5 32 512
 cache_dir aufs /mnt/ssd/cache/store7 5 32 512


 cache_dir aufs /mnt/sas1/cache/store1  5 32 512
 cache_dir aufs /mnt/sas1/cache/store2  5 32 512
 cache_dir aufs /mnt/sas1/cache/store3  5 32 512
 cache_dir aufs /mnt/sas1/cache/store4  5 32 512
 cache_dir aufs /mnt/sas1/cache/store5  5 32 512
 cache_dir aufs /mnt/sas1/cache/store6  5 32 512
 cache_dir aufs /mnt/sas1/cache/store7  5 32

Re: [squid-users] Squid performance with high load

2013-03-30 Thread Hasanen AL-Bana

The above config for cache_dirs is not working probably.
I can see the aufs dir growing rapidly while the Rock directory has
been created but it is empty !

---
Store Directory Statistics:
Store Entries  : 1166040
Maximum Swap Size  : 174080 KB
Current Store Swap Size: 85456552.00 KB
Current Capacity   : 4.91% used, 95.09% free

Store Directory #0 (rock): /mnt/ssd/cache/
FS Block Size 1024 Bytes

Maximum Size: 30720 KB
Current Size: 760592.00 KB 0.25%
Maximum entries:   239
Current entries:  5942 0.25%
Pending operations: 137 out of 0
Flags:

Store Directory #1 (aufs): /mnt/sas1/cache/store1
FS Block Size 4096 Bytes
First level subdirectories: 32
Second level subdirectories: 512
Maximum Size: 143360 KB
Current Size: 84695960.00 KB
Percent Used: 5.91%
Filemap bits in use: 1159378 of 2097152 (55%)
Filesystem Space in use: 121538556/-1957361748 KB (-5%)
Filesystem Inodes in use: 1176103/146243584 (1%)
Flags:
Removal policy: lru
LRU reference age: 0.17 days

On Sat, Mar 30, 2013 at 5:10 PM, Hasanen AL-Bana hasa...@gmail.com wrote:
 Thank you Amos for clarifying these issues.
 I will skip SMP and use single worker since Rock limit my max object
 size to 32kb when used in shared environments.
 My new cache_dir configuration looks like this now :

 cache_dir rock /mnt/ssd/cache/ 30 max-size=131072
 cache_dir aufs /mnt/sas1/cache/store1  140 32 512

 I have enabled store.log to be used with some other software
 collecting data from it

 my disks are now mounted with
 noatime,barrier=0,journal_async_commit,noauto_da_alloc,nobh,data=writeback,commit=10

 I will keep the list posted with my results.
 Thanks.

 On Sat, Mar 30, 2013 at 12:57 PM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 30/03/2013 6:33 a.m., Hasanen AL-Bana wrote:

 Hi,

 I am running squid 3.2 with an average of 50k req/min. Total received
 bandwidth is around 200mbit/s.
 I have problem when my aufs cache_dirs reaches size above 600GB.
 Traffic starts dropping and going up again , happening every 20~30
 minutes.
 I have more that enough RAM in the system (125GB DDR3 !) , All disks
 are SAS 15k rpm, one of them is and SSD 450GB.
 So hardware should not cause any problem and I should easily spawn
 multiple squid workers any time.
 So what could cause such problems ?


 #1 - AUFS is *not* SMP-aware component in Squid.

 Each of the two workers you are using will be altering the on-disk portion
 of the cache without updating the in-memory index. When the other worker
 encounters these over-written files it will erase them.

 For now you are required to use the macros hacks to split the cache_dir
 lines between the workers.


 #2 - you have multiple cache_dir per disk. Or so it seems from your
 configuration. Is that correct?

  * squid load balances between cache_dir treating them as separate physcal
 HDD when it comes to loading calculations.

 * the memory requirement for indexing these 1.6 TB of disk space is ~24GB
 per worker plus the 20GB of shared emmory cache == 68GB of RAM.



 I advise to you inform Squid about the real disk topology it is working
 with. No more than one AUFS cache_dir per physical disk and allocate the
 cache_dir size to ~80-90% the full available disk space. With each worker
 assigned to use a sub-set of the AUFS cache_dir and associated disks.

 For best performance and object de-duplication you should consider using
 rock cache_dir for small objects. They *are* shared between workers, and can
 also share disk space with an AUFS disk.



 Thank you.


 
 include /etc/squid3/refresh.conf


 cache_mem 20 GB

 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
 acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
 acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
 acl localnet src fc00::/7   # RFC 4193 local private network range
 acl localnet src fe80::/10  # RFC 4291 link-local (directly
 plugged) machines

 acl SSL_ports port 443
 acl Safe_ports port 80  # http
 acl Safe_ports port 21  # ftp
 acl Safe_ports port 443 # https
 acl Safe_ports port 70  # gopher
 acl Safe_ports port 210 # wais
 acl Safe_ports port 1025-65535  # unregistered ports
 acl Safe_ports port 280 # http-mgmt
 acl Safe_ports port 488 # gss-http
 acl Safe_ports port 591 # filemaker
 acl Safe_ports port 777 # multiling http
 acl CONNECT method CONNECT


 http_access allow localhost manager
 http_access deny manager
 http_access deny !Safe_ports
 http_access deny CONNECT !SSL_ports

 http_access allow localnet
 http_access allow localhost

 http_access allow all


 Sure, why bother having security at all?


   maximum_object_size_in_memory 512 KB
   memory_cache_mode always
   memory_replacement_policy heap GDSF

Re: [squid-users] Squid performance with high load

2013-03-30 Thread Amos Jeffries


On 31/03/2013 9:07 a.m., Hasanen AL-Bana wrote:

The above config for cache_dirs is not working probably.


You are top-posting.
. Why?
.. There is no above config.


I can see the aufs dir growing rapidly while the Rock directory has
been created but it is empty !

---
Store Directory Statistics:
Store Entries  : 1166040
Maximum Swap Size  : 174080 KB
Current Store Swap Size: 85456552.00 KB
Current Capacity   : 4.91% used, 95.09% free

Store Directory #0 (rock): /mnt/ssd/cache/
FS Block Size 1024 Bytes

Maximum Size: 30720 KB
Current Size: 760592.00 KB 0.25%
Maximum entries:   239
Current entries:  5942 0.25%
Pending operations: 137 out of 0
Flags:

Store Directory #1 (aufs): /mnt/sas1/cache/store1
FS Block Size 4096 Bytes
First level subdirectories: 32
Second level subdirectories: 512
Maximum Size: 143360 KB
Current Size: 84695960.00 KB
Percent Used: 5.91%
Filemap bits in use: 1159378 of 2097152 (55%)
Filesystem Space in use: 121538556/-1957361748 KB (-5%)
Filesystem Inodes in use: 1176103/146243584 (1%)
Flags:
Removal policy: lru
LRU reference age: 0.17 days

On Sat, Mar 30, 2013 at 5:10 PM, Hasanen AL-Bana hasa...@gmail.com wrote:

Thank you Amos for clarifying these issues.
I will skip SMP and use single worker since Rock limit my max object
size to 32kb when used in shared environments.
My new cache_dir configuration looks like this now :

cache_dir rock /mnt/ssd/cache/ 30 max-size=131072
cache_dir aufs /mnt/sas1/cache/store1  140 32 512


NP: Rock is a 'slot'-based database format and does not support objects 
larger than 32KB, unless you are using the experimental large-rock code. 
max-size will be capped down to max-size=32767. You should have seen a 
warning about that when starting or reconfiguring Squid.


To prevent the AUFS dir filling wil small objects that can best be 
served from Rock, you will also need min-size= parameter on the AUFS. 
Otherwise Squid will base selection on capacity loading and will 
determine that the 1.4TB dir has more free space than the 300GB Rock one.




I have enabled store.log to be used with some other software
collecting data from it

my disks are now mounted with
noatime,barrier=0,journal_async_commit,noauto_da_alloc,nobh,data=writeback,commit=10

I will keep the list posted with my results.
Thanks.


Amos

[squid-users] Squid performance with high load

2013-03-29 Thread Hasanen AL-Bana

Hi,

I am running squid 3.2 with an average of 50k req/min. Total received
bandwidth is around 200mbit/s.
I have problem when my aufs cache_dirs reaches size above 600GB.
Traffic starts dropping and going up again , happening every 20~30 minutes.
I have more that enough RAM in the system (125GB DDR3 !) , All disks
are SAS 15k rpm, one of them is and SSD 450GB.
So hardware should not cause any problem and I should easily spawn
multiple squid workers any time.
So what could cause such problems ?

Thank you.


include /etc/squid3/refresh.conf


cache_mem 20 GB

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly
plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT


http_access allow localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow localnet
http_access allow localhost

http_access allow all

coredump_dir /usr/local/squid/var/cache/squid


# SNONO-SYSTEMS CONFIGURATION

 http_port 3128
 http_port 3129 intercept
 snmp_port 3401
 snmp_access allow localhost

 qos_flows tos
 qos_flows local-hit=0x30

 maximum_object_size_in_memory 512 KB
 memory_cache_mode always
 memory_replacement_policy heap GDSF
 cache_replacement_policy heap LFUDA
 store_dir_select_algorithm least-load
 max_open_disk_fds 0
 maximum_object_size 200 MB

 cache_swap_high 98
 cache_swap_low  97


# access_log stdio:/var/log/squid3/access.log
 access_log none
 cache_log /var/log/squid3/cache.log
 cache_store_log stdio:/var/log/squid3/store.log
 logfile_rotate 1
 minimum_expiry_time 60 seconds
 request_header_max_size 64 KB
 reply_header_max_size 64 KB
 request_body_max_size 0 KB
 client_request_buffer_max_size 128 KB
 cache_effective_user proxy
 cache_effective_group proxy
 visible_hostname snono-systems
 fqdncache_size 8096
 pipeline_prefetch on
 max_filedescriptors 5

 workers 2

cache_dir aufs /mnt/ssd/cache/store1 5 32 512
cache_dir aufs /mnt/ssd/cache/store2 5 32 512
cache_dir aufs /mnt/ssd/cache/store3 5 32 512
cache_dir aufs /mnt/ssd/cache/store4 5 32 512
cache_dir aufs /mnt/ssd/cache/store5 5 32 512
cache_dir aufs /mnt/ssd/cache/store6 5 32 512
cache_dir aufs /mnt/ssd/cache/store7 5 32 512


cache_dir aufs /mnt/sas1/cache/store1  5 32 512
cache_dir aufs /mnt/sas1/cache/store2  5 32 512
cache_dir aufs /mnt/sas1/cache/store3  5 32 512
cache_dir aufs /mnt/sas1/cache/store4  5 32 512
cache_dir aufs /mnt/sas1/cache/store5  5 32 512
cache_dir aufs /mnt/sas1/cache/store6  5 32 512
cache_dir aufs /mnt/sas1/cache/store7  5 32 512
cache_dir aufs /mnt/sas1/cache/store8  5 32 512
cache_dir aufs /mnt/sas1/cache/store9  5 32 512
cache_dir aufs /mnt/sas1/cache/store10  5 32 512
cache_dir aufs /mnt/sas1/cache/store11  5 32 512
cache_dir aufs /mnt/sas1/cache/store12  5 32 512


cache_dir aufs /mnt/sas2/cache/store1  5 32 512
cache_dir aufs /mnt/sas2/cache/store2  5 32 512
cache_dir aufs /mnt/sas2/cache/store3  5 32 512
cache_dir aufs /mnt/sas2/cache/store4  5 32 512
cache_dir aufs /mnt/sas2/cache/store5  5 32 512
cache_dir aufs /mnt/sas2/cache/store6  5 32 512
cache_dir aufs /mnt/sas2/cache/store7  5 32 512
cache_dir aufs /mnt/sas2/cache/store8  5 32 512
cache_dir aufs /mnt/sas2/cache/store9  5 32 512
cache_dir aufs /mnt/sas2/cache/store10  5 32 512
cache_dir aufs /mnt/sas2/cache/store11  5 32 512
cache_dir aufs /mnt/sas2/cache/store12  5 32 512

===

and my refresh patterns are :

#general
 refresh_pattern \.(jp(e?g|e|2)|tiff?|bmp|gif|png)
  12560  99% 30240ignore-no-cache
ignore-no-store override-expire override-lastmod ignore-private
 refresh_pattern
\.(z(ip|[0-9]{2})|r(ar|[0-9]{2})|jar|bz2|gz|tar|rpm|vpu)
 12560  99% 30240ignore-no-cache ignore-no-store
override-expire override-lastmod ignore-private
 refresh_pattern \.(mp3|wav|og(g|a)|flac|midi?|rm|aac|wma|mka|ape)
  12560  99% 30240ignore-no-cache
ignore-no-store override-expire override-lastmod ignore-private
 refresh_pattern

[squid-users] squid performance is low because only 1 cpu is being used !!!!

2013-03-05 Thread Ahmad

hi ,.
i have centos 64 bit with kernel 3.7.5 compiled with tproxy features .
i noted  that in rush hour , squid squid guard is bypassing .
i noted that squid is using only 1 cpu .
here is output sample:
===
[root@squid squid-3.3.1]# mpstat -u
Linux 3.7.5 (squid) 03/05/2013  _x86_64_(24 CPU)

09:10:10 AM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal 
%guest   %idle
09:10:10 AM  all5.100.001.70   14.090.000.440.00   
0.00   78.67
[root@squid squid-3.3.1]# mpstat -P ALL 
Linux 3.7.5 (squid) 03/05/2013  _x86_64_(24 CPU)

09:10:17 AM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal 
%guest   %idle
09:10:17 AM  all5.100.001.70   14.090.000.440.00   
0.00   78.67
09:10:17 AM08.630.002.67   30.170.000.150.00   
0.00   58.37
09:10:17 AM1   12.350.014.50   27.910.000.440.00   
0.00   54.79
09:10:17 AM25.510.001.96   27.650.000.060.00   
0.00   64.81
09:10:17 AM37.170.002.16   22.100.000.060.00   
0.00   68.51
09:10:17 AM45.150.001.93   27.290.000.060.00   
0.00   65.56
09:10:17 AM57.630.001.83   18.540.000.060.00   
0.00   71.93
09:10:17 AM65.180.001.90   28.460.000.070.00   
0.00   64.40
09:10:17 AM76.730.001.45   14.060.000.050.00   
0.00   77.70
09:10:17 AM85.190.001.82   28.470.000.060.00   
0.00   64.46
09:10:17 AM96.950.001.28   10.670.000.040.00   
0.00   81.06
09:10:17 AM   105.540.001.78   28.100.000.060.00   
0.00   64.51
09:10:17 AM   116.680.001.259.020.000.050.00   
0.00   83.00
09:10:17 AM   121.300.000.439.270.000.000.00   
0.00   89.00
09:10:17 AM   138.050.003.832.680.002.610.00   
0.00   82.83
09:10:17 AM   143.370.001.557.860.000.790.00   
0.00   86.43
09:10:17 AM   156.850.003.272.390.002.120.00   
0.00   85.36
09:10:17 AM   163.490.001.618.030.000.830.00   
0.00   86.03
09:10:17 AM   171.780.000.203.020.000.120.00   
0.00   94.87
09:10:17 AM   181.240.000.388.080.000.000.00   
0.00   90.29
09:10:17 AM   194.860.002.172.640.001.510.00   
0.00   88.82
09:10:17 AM   201.150.000.348.030.000.000.00   
0.00   90.48
09:10:17 AM   215.070.002.272.260.001.570.00   
0.00   88.83
09:10:17 AM   221.160.000.358.830.000.000.00   
0.00   89.66
09:10:17 AM   231.750.000.161.750.000.000.00   
0.00   96.34
===
now i will try to migrate to squid 3.2 to the stable version ,
i had a look on 
http://wiki.squid-cache.org/ConfigExamples/MultiCpuSystem
now if i use squid 3.2 stable , will it support smp feature of using
multiple cpu by default  or i have compile it with smp enable ?
also , 
do i need more config to operate smp on it is configured by default ???


best regards

with my best regards



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-performance-is-low-because-only-1-cpu-is-being-used-tp4658844.html
Sent from the Squid - Users mailing list archive at Nabble.com.

Re: [squid-users] squid performance is low because only 1 cpu is being used !!!!

2013-03-05 Thread Amos Jeffries


On 6/03/2013 3:14 a.m., Ahmad wrote:

hi ,.
i have centos 64 bit with kernel 3.7.5 compiled with tproxy features .
i noted  that in rush hour , squid squid guard is bypassing .


Are you basing that on the detected possible bypass attack messages 
mentioned in threads from days back?
... that would mean the same thing if it were worded detected possible 
attack without naming the type of attack found.




i noted that squid is using only 1 cpu .


Yes. Squid has always been that way.
Having a dedicated CPU does not necessarily mean slow - the OS and 
helpers can use the other(s).



here is output sample:
===
[root@squid squid-3.3.1]# mpstat -u
Linux 3.7.5 (squid) 03/05/2013  _x86_64_(24 CPU)

09:10:10 AM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal
%guest   %idle
09:10:10 AM  all5.100.001.70   14.090.000.440.00
0.00   78.67
[root@squid squid-3.3.1]# mpstat -P ALL
Linux 3.7.5 (squid) 03/05/2013  _x86_64_(24 CPU)

09:10:17 AM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal
%guest   %idle
09:10:17 AM  all5.100.001.70   14.090.000.440.00
0.00   78.67
09:10:17 AM08.630.002.67   30.170.000.150.00
0.00   58.37
09:10:17 AM1   12.350.014.50   27.910.000.440.00
0.00   54.79
09:10:17 AM25.510.001.96   27.650.000.060.00
0.00   64.81
09:10:17 AM37.170.002.16   22.100.000.060.00
0.00   68.51
09:10:17 AM45.150.001.93   27.290.000.060.00
0.00   65.56
09:10:17 AM57.630.001.83   18.540.000.060.00
0.00   71.93
09:10:17 AM65.180.001.90   28.460.000.070.00
0.00   64.40
09:10:17 AM76.730.001.45   14.060.000.050.00
0.00   77.70
09:10:17 AM85.190.001.82   28.470.000.060.00
0.00   64.46
09:10:17 AM96.950.001.28   10.670.000.040.00
0.00   81.06
09:10:17 AM   105.540.001.78   28.100.000.060.00
0.00   64.51
09:10:17 AM   116.680.001.259.020.000.050.00
0.00   83.00
09:10:17 AM   121.300.000.439.270.000.000.00
0.00   89.00
09:10:17 AM   138.050.003.832.680.002.610.00
0.00   82.83
09:10:17 AM   143.370.001.557.860.000.790.00
0.00   86.43
09:10:17 AM   156.850.003.272.390.002.120.00
0.00   85.36
09:10:17 AM   163.490.001.618.030.000.830.00
0.00   86.03
09:10:17 AM   171.780.000.203.020.000.120.00
0.00   94.87
09:10:17 AM   181.240.000.388.080.000.000.00
0.00   90.29
09:10:17 AM   194.860.002.172.640.001.510.00
0.00   88.82
09:10:17 AM   201.150.000.348.030.000.000.00
0.00   90.48
09:10:17 AM   215.070.002.272.260.001.570.00
0.00   88.83
09:10:17 AM   221.160.000.358.830.000.000.00
0.00   89.66
09:10:17 AM   231.750.000.161.750.000.000.00
0.00   96.34


These all appear to be idle. Why would it be a good thing to swap the 
main Squid running state between CPU caches at peak load time?

That  wastes time and cycles.

Squid is designed to take one CPU and use it to max capacity - the code 
is not using that capacity very efficiently yet but we are working on 
that (assistance welcome).



===
now i will try to migrate to squid 3.2 to the stable version ,
i had a look on
http://wiki.squid-cache.org/ConfigExamples/MultiCpuSystem
now if i use squid 3.2 stable , will it support smp feature of using
multiple cpu by default  or i have compile it with smp enable ?
also ,
do i need more config to operate smp on it is configured by default ???


The default (at present) is that SMP support is built in when available 
at build time but disabled in the default configuration.


You need to set a SMP worker count to enable it. 
http://www.squid-cache.org/Doc/config/workers/


Note carefully the list of things on that SMP scaling wiki page whoch 
are listed as *NOT* supporting SMP yet, and how to prepare your 
configuration of them for SMP usage.


Amos

[squid-users] squid performance tunning

I have some Dell 1950 servers dedicated to squid in my production
environment. Each with 16GB RAM and 300G disk
As the website traffic grows, the load of squid becomes high at high
traffic time. Average load is higher than 10.

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.01  0.06  0.13 1.23 1.4528.87
0.004.13   2.19   0.04
sda1  0.00 0.01  0.06  0.11 1.23 1.4531.59
0.004.52   2.40   0.04
sdb   0.07 0.07  0.01  0.01 0.33 0.3259.88
0.00   19.75  15.74   0.03
sdc   0.00 2.08  9.13 104.4481.30  1066.74
20.22 0.50   11.95   1.73  19.63

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   3.500.003.75   24.340.00   68.41

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.00  0.50  0.00 2.00 0.00 8.00
0.04   70.00  70.00   3.50
sda1  0.00 0.00  0.50  0.00 2.00 0.00 8.00
0.04   70.00  70.00   3.50
sdb   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdc   0.00 0.00 21.50 186.00   204.00  3106.25
31.9117.76  100.55   2.63  54.65

Here is the squidclient mgr:info output

Squid Object Cache: Version 3.1.12
Start Time: Sun, 14 Aug 2011 19:39:15 GMT
Current Time:   Thu, 18 Aug 2011 04:41:20 GMT
Connection information for squid:
Number of clients accessing cache:  77651
Number of HTTP requests received:   40449309
Number of ICP messages received:0
Number of ICP messages sent:0
Number of queued ICP replies:   0
Number of HTCP messages received:   0
Number of HTCP messages sent:   0
Request failure ratio:   0.00
Average HTTP requests per minute since start:   8319.3
Average ICP messages per minute since start:0.0
Select loop called: 476454933 times, 0.612 ms avg
Cache information for squid:
Hits as % of all requests:  5min: 30.7%, 60min: 32.1%
Hits as % of bytes sent:5min: 40.5%, 60min: 43.2%
Memory hits as % of hit requests:   5min: 88.3%, 60min: 88.8%
Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
Storage Swap size:  120792244 KB
Storage Swap capacity:  90.0% used, 10.0% free
Storage Mem size:   5191632 KB
Storage Mem capacity:   100.0% used,  0.0% free
Mean Object Size:   20.61 KB
Requests given to unlinkd:  0
Median Service Times (seconds)  5 min60 min:
HTTP Requests (All):   0.00865  0.00865
Cache Misses:  0.01035  0.01035
Cache Hits:0.0  0.0
Near Hits: 0.00091  0.00091
Not-Modified Replies:  0.0  0.0
DNS Lookups:   0.0  0.0
ICP Queries:   0.0  0.0
Resource usage for squid:
UP Time:291725.519 seconds
CPU Time:   37204.391 seconds
CPU Usage:  12.75%
CPU Usage, 5 minute avg:19.42%
CPU Usage, 60 minute avg:   18.20%
Process Data Segment Size via sbrk(): 1012440 KB
Maximum Resident Size: 28552368 KB
Page faults with physical i/o: 2957
Memory usage for squid via mallinfo():
Total space in arena:  -1265560 KB
Ordinary blocks:   -1308538 KB 264611 blks
Small blocks:   0 KB  0 blks
Holding blocks: 20708 KB  9 blks
Free Small blocks:  0 KB
Free Ordinary blocks:   42978 KB
Total in use:  -1287830 KB 103%
Total free: 42978 KB -3%
Total size:-1244852 KB
Memory accounted for:
Total accounted:   -1781767 KB 143%
memPool accounted: 6606841 KB -531%
memPool unaccounted:   -7851693 KB 0%
memPoolAlloc calls: 10008474163
memPoolFree calls:  10065124847
File descriptor usage for squid:
Maximum number of file descriptors:   20480
Largest file desc currently in use:   4828
Number of file desc currently in use: 4703
Files queued for open: 178
Available number of file descriptors: 15599
Reserved number of file descriptors:   100
Store Disk files open:  22
Internal Data Structures:
5860834 StoreEntries
256880 StoreEntries with MemObjects
256646 Hot Object Cache Items
5860661 on-disk objects

related parameters

cache_mem 5120 MB
maximum_object_size 51200 KB
maximum_object_size_in_memory 1024 KB

log_icp_queries off
cache_swap_low 90
cache_swap_high 95
hosts_file /etc/squid/hosts
cache_dir aufs /export/squid/cache 131072 32 256

Is there any idea I can

Re: [squid-users] squid performance tunning

2011-08-18 Thread Łukasz Makowski


W dniu 2011-08-18 08:19, Chen Bangzhong pisze:

I have some Dell 1950 servers dedicated to squid in my production
environment. Each with 16GB RAM and 300G disk
As the website traffic grows, the load of squid becomes high at high
traffic time. Average load is higher than 10.

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.01  0.06  0.13 1.23 1.4528.87
 0.004.13   2.19   0.04
sda1  0.00 0.01  0.06  0.11 1.23 1.4531.59
 0.004.52   2.40   0.04
sdb   0.07 0.07  0.01  0.01 0.33 0.3259.88
 0.00   19.75  15.74   0.03
sdc   0.00 2.08  9.13 104.4481.30  1066.74
20.22 0.50   11.95   1.73  19.63

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
3.500.003.75   24.340.00   68.41

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.00  0.50  0.00 2.00 0.00 8.00
 0.04   70.00  70.00   3.50
sda1  0.00 0.00  0.50  0.00 2.00 0.00 8.00
 0.04   70.00  70.00   3.50
sdb   0.00 0.00  0.00  0.00 0.00 0.00 0.00
 0.000.00   0.00   0.00
sdc   0.00 0.00 21.50 186.00   204.00  3106.25
31.9117.76  100.55   2.63  54.65

Here is the squidclient mgr:info output

Squid Object Cache: Version 3.1.12
Start Time: Sun, 14 Aug 2011 19:39:15 GMT
Current Time:   Thu, 18 Aug 2011 04:41:20 GMT
Connection information for squid:
 Number of clients accessing cache:  77651
 Number of HTTP requests received:   40449309
 Number of ICP messages received:0
 Number of ICP messages sent:0
 Number of queued ICP replies:   0
 Number of HTCP messages received:   0
 Number of HTCP messages sent:   0
 Request failure ratio:   0.00
 Average HTTP requests per minute since start:   8319.3
 Average ICP messages per minute since start:0.0
 Select loop called: 476454933 times, 0.612 ms avg
Cache information for squid:
 Hits as % of all requests:  5min: 30.7%, 60min: 32.1%
 Hits as % of bytes sent:5min: 40.5%, 60min: 43.2%
 Memory hits as % of hit requests:   5min: 88.3%, 60min: 88.8%
 Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
 Storage Swap size:  120792244 KB
 Storage Swap capacity:  90.0% used, 10.0% free
 Storage Mem size:   5191632 KB
 Storage Mem capacity:   100.0% used,  0.0% free
 Mean Object Size:   20.61 KB
 Requests given to unlinkd:  0
Median Service Times (seconds)  5 min60 min:
 HTTP Requests (All):   0.00865  0.00865
 Cache Misses:  0.01035  0.01035
 Cache Hits:0.0  0.0
 Near Hits: 0.00091  0.00091
 Not-Modified Replies:  0.0  0.0
 DNS Lookups:   0.0  0.0
 ICP Queries:   0.0  0.0
Resource usage for squid:
 UP Time:291725.519 seconds
 CPU Time:   37204.391 seconds
 CPU Usage:  12.75%
 CPU Usage, 5 minute avg:19.42%
 CPU Usage, 60 minute avg:   18.20%
 Process Data Segment Size via sbrk(): 1012440 KB
 Maximum Resident Size: 28552368 KB
 Page faults with physical i/o: 2957
Memory usage for squid via mallinfo():
 Total space in arena:  -1265560 KB
 Ordinary blocks:   -1308538 KB 264611 blks
 Small blocks:   0 KB  0 blks
 Holding blocks: 20708 KB  9 blks
 Free Small blocks:  0 KB
 Free Ordinary blocks:   42978 KB
 Total in use:  -1287830 KB 103%
 Total free: 42978 KB -3%
 Total size:-1244852 KB
Memory accounted for:
 Total accounted:   -1781767 KB 143%
 memPool accounted: 6606841 KB -531%
 memPool unaccounted:   -7851693 KB 0%
 memPoolAlloc calls: 10008474163
 memPoolFree calls:  10065124847
File descriptor usage for squid:
 Maximum number of file descriptors:   20480
 Largest file desc currently in use:   4828
 Number of file desc currently in use: 4703
 Files queued for open: 178
 Available number of file descriptors: 15599
 Reserved number of file descriptors:   100
 Store Disk files open:  22
Internal Data Structures:
 5860834 StoreEntries
 256880 StoreEntries with MemObjects
 256646 Hot Object Cache Items
 5860661 on-disk objects

related parameters

cache_mem 5120 MB
maximum_object_size 51200 KB
maximum_object_size_in_memory 1024 KB

log_icp_queries off
cache_swap_low 90

Re: [squid-users] squid performance tunning

2011-08-18 Thread Drunkard Zhang

 Median Service Times (seconds)  5 min    60 min:
        HTTP Requests (All):   0.00865  0.00865
        Cache Misses:          0.01035  0.01035
        Cache Hits:            0.0  0.0
        Near Hits:             0.00091  0.00091
        Not-Modified Replies:  0.0  0.0
        DNS Lookups:           0.0  0.0
        ICP Queries:           0.0  0.0

Response time is reasonable at this time, while, peak time capture is
good for performance tunning. Try atop 1 at peak time, this magic
tool can clear about bottleneck.

Try multi-instance, which can improve throughput dramaticlly. Docs's here:
http://wiki.squid-cache.org/MultipleInstances

CARP is another choice for extreme perf demand.
http://wiki.squid-cache.org/ConfigExamples/ExtremeCarpFrontend

Re: [squid-users] squid performance tunning

My cached objects will expire after 10 minutes.

Cache-Control:max-age=600

I don't know why there are so many disk writes and there are so many
objects on disk.

In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
is very low.

Can I increase the cache_mem？ or not use disk cache at all?


2011/8/18 Łukasz Makowski lukasz.makow...@itsoft.pl:
 W dniu 2011-08-18 08:19, Chen Bangzhong pisze:

 I have some Dell 1950 servers dedicated to squid in my production
 environment. Each with 16GB RAM and 300G disk
 As the website traffic grows, the load of squid becomes high at high
 traffic time. Average load is higher than 10.

 Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz
 avgqu-sz   await  svctm  %util
 sda               0.00     0.01  0.06  0.13     1.23     1.45    28.87
     0.00    4.13   2.19   0.04
 sda1              0.00     0.01  0.06  0.11     1.23     1.45    31.59
     0.00    4.52   2.40   0.04
 sdb               0.07     0.07  0.01  0.01     0.33     0.32    59.88
     0.00   19.75  15.74   0.03
 sdc               0.00     2.08  9.13 104.44    81.30  1066.74
 20.22     0.50   11.95   1.73  19.63

 avg-cpu:  %user   %nice %system %iowait  %steal   %idle
            3.50    0.00    3.75   24.34    0.00   68.41

 Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz
 avgqu-sz   await  svctm  %util
 sda               0.00     0.00  0.50  0.00     2.00     0.00     8.00
     0.04   70.00  70.00   3.50
 sda1              0.00     0.00  0.50  0.00     2.00     0.00     8.00
     0.04   70.00  70.00   3.50
 sdb               0.00     0.00  0.00  0.00     0.00     0.00     0.00
     0.00    0.00   0.00   0.00
 sdc               0.00     0.00 21.50 186.00   204.00  3106.25
 31.91    17.76  100.55   2.63  54.65

 Here is the squidclient mgr:info output

 Squid Object Cache: Version 3.1.12
 Start Time:     Sun, 14 Aug 2011 19:39:15 GMT
 Current Time:   Thu, 18 Aug 2011 04:41:20 GMT
 Connection information for squid:
         Number of clients accessing cache:      77651
         Number of HTTP requests received:       40449309
         Number of ICP messages received:        0
         Number of ICP messages sent:    0
         Number of queued ICP replies:   0
         Number of HTCP messages received:       0
         Number of HTCP messages sent:   0
         Request failure ratio:   0.00
         Average HTTP requests per minute since start:   8319.3
         Average ICP messages per minute since start:    0.0
         Select loop called: 476454933 times, 0.612 ms avg
 Cache information for squid:
         Hits as % of all requests:      5min: 30.7%, 60min: 32.1%
         Hits as % of bytes sent:        5min: 40.5%, 60min: 43.2%
         Memory hits as % of hit requests:       5min: 88.3%, 60min: 88.8%
         Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
         Storage Swap size:      120792244 KB
         Storage Swap capacity:  90.0% used, 10.0% free
         Storage Mem size:       5191632 KB
         Storage Mem capacity:   100.0% used,  0.0% free
         Mean Object Size:       20.61 KB
         Requests given to unlinkd:      0
 Median Service Times (seconds)  5 min    60 min:
         HTTP Requests (All):   0.00865  0.00865
         Cache Misses:          0.01035  0.01035
         Cache Hits:            0.0  0.0
         Near Hits:             0.00091  0.00091
         Not-Modified Replies:  0.0  0.0
         DNS Lookups:           0.0  0.0
         ICP Queries:           0.0  0.0
 Resource usage for squid:
         UP Time:        291725.519 seconds
         CPU Time:       37204.391 seconds
         CPU Usage:      12.75%
         CPU Usage, 5 minute avg:        19.42%
         CPU Usage, 60 minute avg:       18.20%
         Process Data Segment Size via sbrk(): 1012440 KB
         Maximum Resident Size: 28552368 KB
         Page faults with physical i/o: 2957
 Memory usage for squid via mallinfo():
         Total space in arena:  -1265560 KB
         Ordinary blocks:       -1308538 KB 264611 blks
         Small blocks:               0 KB      0 blks
         Holding blocks:         20708 KB      9 blks
         Free Small blocks:          0 KB
         Free Ordinary blocks:   42978 KB
         Total in use:          -1287830 KB 103%
         Total free:             42978 KB -3%
         Total size:            -1244852 KB
 Memory accounted for:
         Total accounted:       -1781767 KB 143%
         memPool accounted:     6606841 KB -531%
         memPool unaccounted:   -7851693 KB 0%
         memPoolAlloc calls: 10008474163
         memPoolFree calls:  10065124847
 File descriptor usage for squid:
         Maximum number of file descriptors:   20480
         Largest file desc currently in use:   4828
         Number of file desc currently in use: 4703
         Files queued for open:                 178
         Available number of file descriptors: 15599
         Reserved number of file

Re: [squid-users] squid performance tunning

2011-08-18 Thread Drunkard Zhang

2011/8/18 Chen Bangzhong bangzh...@gmail.com:
 My cached objects will expire after 10 minutes.

 Cache-Control:max-age=600

Static content like pictures should cache longer, like 1 day, 86400.

 I don't know why there are so many disk writes and there are so many
 objects on disk.

 In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
 is very low.

Maybe cause by disk read timeout. You used too much disk space, you
can shrink it a little by a little, until disk busy percentage reduced
to 80% or lower.

 Can I increase the cache_mem？ or not use disk cache at all?

I used all memory I can use :-)

Re: [squid-users] squid performance tunning


On 18/08/11 19:40, Drunkard Zhang wrote:

2011/8/18 Chen Bangzhong:

My cached objects will expire after 10 minutes.

Cache-Control:max-age=600


Static content like pictures should cache longer, like 1 day, 86400.


Could also be a whole year. If you control the origin website, set 
caching times as large as reasonably possible for each object. With 
revalidate settings relevant to its likely replacement needs. And always 
send a correct ETag.


With those details Squid and other caches will take care of reducing 
caching times to suit the network and disk needs and 
updates/revalidation to suit your needs. So please set it large.





I don't know why there are so many disk writes and there are so many
objects on disk.


All traffic goes through either RAM cache or if its bigger than 
maximum_object_size_in_memory will go through disks.


From that info report ~60% of your traffic bytes are MISS responses. A 
large portion of that MISS traffic is likely not storable, so will be 
written to cache then discarded immediately. Squid is overall 
mostly-write with its disk behaviour.


Likely your 10-minute age is affecting this in a big way. The cache will 
have a lot of storable object which are stale. Next request they will be 
fetched into memory, then replaced by a revalidation REFRESH (near-HIT) 
response, which writes new data back to disk later.




In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
is very low.


Maybe cause by disk read timeout. You used too much disk space, you
can shrink it a little by a little, until disk busy percentage reduced
to 80% or lower.


Your Squid version is one which will promote HIT objects from disk and 
service repeat HITs from memory. Which reducing that disk-hit % a lot 
more than earlier squid versions would show it as.





Can I increase the cache_mem？ or not use disk cache at all?


I used all memory I can use :-)


Indeed, the more the merrier. Unless it is swapping under high load. If 
that happens Squid speed goes terrible almost immediately.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

2011-08-18 Thread Drunkard Zhang

2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 19:40, Drunkard Zhang wrote:

 2011/8/18 Chen Bangzhong:

 My cached objects will expire after 10 minutes.

 Cache-Control:max-age=600

 Static content like pictures should cache longer, like 1 day, 86400.

 Could also be a whole year. If you control the origin website, set caching
 times as large as reasonably possible for each object. With revalidate
 settings relevant to its likely replacement needs. And always send a correct
 ETag.

 With those details Squid and other caches will take care of reducing caching
 times to suit the network and disk needs and updates/revalidation to suit
 your needs. So please set it large.


 I don't know why there are so many disk writes and there are so many
 objects on disk.

 All traffic goes through either RAM cache or if its bigger than
 maximum_object_size_in_memory will go through disks.

 From that info report ~60% of your traffic bytes are MISS responses. A large
 portion of that MISS traffic is likely not storable, so will be written to
 cache then discarded immediately. Squid is overall mostly-write with its
 disk behaviour.

 Likely your 10-minute age is affecting this in a big way. The cache will
 have a lot of storable object which are stale. Next request they will be
 fetched into memory, then replaced by a revalidation REFRESH (near-HIT)
 response, which writes new data back to disk later.


 In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
 is very low.

 Maybe cause by disk read timeout. You used too much disk space, you
 can shrink it a little by a little, until disk busy percentage reduced
 to 80% or lower.

 Your Squid version is one which will promote HIT objects from disk and
 service repeat HITs from memory. Which reducing that disk-hit % a lot more
 than earlier squid versions would show it as.


 Can I increase the cache_mem？ or not use disk cache at all?

 I used all memory I can use :-)

 Indeed, the more the merrier. Unless it is swapping under high load. If that
 happens Squid speed goes terrible almost immediately.

Actually I disabled swap at all, and use a script to start squid
process immediately when killed by OS. OS will kill squid when OOM(Out
of memory).

Re: [squid-users] squid performance tunning

thanks you Amos and Drunkard.

My website hosts novels, That's, user can read novel there.

The pages are not truely static contents, so I can only cache them for
10 minutes.

My squids serve both non-cachable requests (works like nginx) and
cachable-requests (10 min cache). So 60% cache miss is reasonable.  It
is not a good design, but we can't do more now.

Another point is, only hot novels are read by users. Crawlers/robots
will push many objects to cache. These objects are rarely read by user
and will expire after 10 minutes.

If the http response header indicates it is not cachable(eg:
max-age=0), will squid save the response in RAM or disk? My guess is
squid will discard the response.

If the http response header indicates it is cachable(eg: max-age=600),
squid will save it in the cache_mem. If the object is larger than
maximum_object_size_in_memory, it will be written to disk.

Can you tell me when will squid save the object to disk? When will
squid delete the staled objects?




2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 19:40, Drunkard Zhang wrote:

 2011/8/18 Chen Bangzhong:

 My cached objects will expire after 10 minutes.

 Cache-Control:max-age=600

 Static content like pictures should cache longer, like 1 day, 86400.

 Could also be a whole year. If you control the origin website, set caching
 times as largeas reasonably possible for each object. With revalidate
 settings relevant to its likely replacement needs. And always send a correct
 ETag.

 With those details Squid and other caches will take care of reducing caching
 times to suit the network and disk needs and updates/revalidation to suit
 your needs. So please set it large.


 I don't know why there are so many disk writes and there are so many
 objects on disk.

 All traffic goes through either RAM cache or if its bigger than
 maximum_object_size_in_memory will go through disks.

 From that info report ~60% of your traffic bytes are MISS responses. A large
 portion of that MISS traffic is likely not storable, so will be written to
 cache then discarded immediately. Squid is overall mostly-write with its
 disk behaviour.

 Likely your 10-minute age is affecting this in a big way. The cache will
 have a lot of storable object which are stale. Next request they will be
 fetched into memory, then replaced by a revalidation REFRESH (near-HIT)
 response, which writes new data back to disk later.


 In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
 is very low.

 Maybe cause by disk read timeout. You used too much disk space, you
 can shrink it a little by a little, until disk busy percentage reduced
 to 80% or lower.

 Your Squid version is one which will promote HIT objects from disk and
 service repeat HITs from memory. Which reducing that disk-hit % a lot more
 than earlier squid versions would show it as.


 Can I increase the cache_mem？ or not use disk cache at all?

 I used all memory I can use :-)

 Indeed, the more the merrier. Unless it is swapping under high load. If that
 happens Squid speed goes terrible almost immediately.

 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

2011-08-18 Thread Kaiwang Chen

2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 19:40, Drunkard Zhang wrote:

 2011/8/18 Chen Bangzhong:

 My cached objects will expire after 10 minutes.

 Cache-Control:max-age=600

 Static content like pictures should cache longer, like 1 day, 86400.

 Could also be a whole year. If you control the origin website, set caching
 times as large as reasonably possible for each object. With revalidate
 settings relevant to its likely replacement needs. And always send a correct
 ETag.

 With those details Squid and other caches will take care of reducing caching
 times to suit the network and disk needs and updates/revalidation to suit
 your needs. So please set it large.


 I don't know why there are so many disk writes and there are so many
 objects on disk.

 All traffic goes through either RAM cache or if its bigger than
 maximum_object_size_in_memory will go through disks.

 From that info report ~60% of your traffic bytes are MISS responses. A large
 portion of that MISS traffic is likely not storable, so will be written to
 cache then discarded immediately. Squid is overall mostly-write with its
 disk behaviour.

Will a cache deny matching those non-storable objects suppress
storing them to disk?
And HTTP header 'Cache-Control: no-store' ?


 Likely your 10-minute age is affecting this in a big way. The cache will
 have a lot of storable object which are stale. Next request they will be
 fetched into memory, then replaced by a revalidation REFRESH (near-HIT)
 response, which writes new data back to disk later.


 In addtion, Disk hits as % of hit requests: 5min: 1.6%, 60min: 1.9%
 is very low.

 Maybe cause by disk read timeout. You used too much disk space, you
 can shrink it a little by a little, until disk busy percentage reduced
 to 80% or lower.

 Your Squid version is one which will promote HIT objects from disk and
 service repeat HITs from memory. Which reducing that disk-hit % a lot more
 than earlier squid versions would show it as.


 Can I increase the cache_mem？ or not use disk cache at all?

 I used all memory I can use :-)

 Indeed, the more the merrier. Unless it is swapping under high load. If that
 happens Squid speed goes terrible almost immediately.

 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10


Thanks,
Kaiwang

Re: [squid-users] squid performance tunning

Mean Object Size:   20.61 K
maximum_object_size_in_memory 1024 KB

So most objects will be save in RAM first, still can't explain why
there are so many disk writes.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   1.520.001.636.950.00   89.91

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.01  0.06  0.13 1.24 1.4528.96
0.004.16   2.20   0.04
sda1  0.00 0.01  0.06  0.11 1.24 1.4531.69
0.004.55   2.41   0.04
sdb   0.07 0.07  0.01  0.01 0.33 0.3159.88
0.00   19.77  15.75   0.03
sdc   0.00 2.08  9.16 104.9681.61  1071.39
20.21 0.575.02   1.73  19.75

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   2.380.003.38   10.380.00   83.88

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sda1  0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdb   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdc   0.00 4.50 11.00 293.00   104.00  3768.50
25.48 7.26   23.88   1.92  58.30

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   3.250.002.633.880.00   90.24

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sda1  0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdb   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdc   0.00 0.50 15.50 94.50   150.00   644.2514.44
0.423.79   1.95  21.50

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   3.000.002.883.380.00   90.75

Device: rrqm/s   wrqm/s   r/s   w/srkB/swkB/s avgrq-sz
avgqu-sz   await  svctm  %util
sda   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sda1  0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdb   0.00 0.00  0.00  0.00 0.00 0.00 0.00
0.000.00   0.00   0.00
sdc   0.00 4.00 13.50 241.50   134.00  1609.75
13.68 0.893.37   0.76  19.50



在 2011年8月18日 下午6:50，Chen Bangzhong bangzh...@gmail.com 写道：
 thanks you Amos and Drunkard.

 My website hosts novels, That's, user can read novel there.

 The pages are not truely static contents, so I can only cache them for
 10 minutes.

 My squids serve both non-cachable requests (works like nginx) and
 cachable-requests (10 min cache). So 60% cache miss is reasonable.  It
 is not a good design, but we can't do more now.

 Another point is, only hot novels are read by users. Crawlers/robots
 will push many objects to cache. These objects are rarely read by user
 and will expire after 10 minutes.

 If the http response header indicates it is not cachable(eg:
 max-age=0), will squid save the response in RAM or disk? My guess is
 squid will discard the response.

 If the http response header indicates it is cachable(eg: max-age=600),
 squid will save it in the cache_mem. If the object is larger than
 maximum_object_size_in_memory, it will be written to disk.

 Can you tell me when will squid save the object to disk? When will
 squid delete the staled objects?




 2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 19:40, Drunkard Zhang wrote:

 2011/8/18 Chen Bangzhong:

 My cached objects will expire after 10 minutes.

 Cache-Control:max-age=600

 Static content like pictures should cache longer, like 1 day, 86400.

 Could also be a whole year. If you control the origin website, set caching
 times as largeas reasonably possible for each object. With revalidate
 settings relevant to its likely replacement needs. And always send a correct
 ETag.

 With those details Squid and other caches will take care of reducing caching
 times to suit the network and disk needs and updates/revalidation to suit
 your needs. So please set it large.


 I don't know why there are so many disk writes and there are so many
 objects on disk.

 All traffic goes through either RAM cache or if its bigger than
 maximum_object_size_in_memory will go through disks.

 From that info report ~60% of your traffic bytes are MISS responses. A large
 portion of that MISS traffic is likely not storable, so will be written to
 cache then discarded immediately. Squid is overall mostly-write with its
 disk behaviour.

 Likely your 10-minute age is affecting this in a big way. The cache will
 have a lot of storable object which

Re: [squid-users] squid performance tunning


On 18/08/11 22:50, Chen Bangzhong wrote:

thanks you Amos and Drunkard.

My website hosts novels, That's, user can read novel there.

The pages are not truely static contents, so I can only cache them for
10 minutes.

My squids serve both non-cachable requests (works like nginx) and
cachable-requests (10 min cache). So 60% cache miss is reasonable.  It
is not a good design, but we can't do more now.


Oh well. Good luck wishes on that side of the problem.



Another point is, only hot novels are read by users. Crawlers/robots
will push many objects to cache. These objects are rarely read by user
and will expire after 10 minutes.

If the http response header indicates it is not cachable(eg:
max-age=0), will squid save the response in RAM or disk? My guess is
squid will discard the response.


Correct. It will discard the response AND anything it has already cached 
for that URL.


For non-hot objects this will not be a major problem. But may raise disk 
I/O a bit as the existing old stored content gets kicked out. Which 
might actually be a good thing, emptying space in the cache early. Or 
wasted I/O. It's not clear exactly which.




If the http response header indicates it is cachable(eg: max-age=600),
squid will save it in the cache_mem. If the object is larger than
maximum_object_size_in_memory, it will be written to disk.


Yes.



Can you tell me when will squid save the object to disk? When will
squid delete the staled objects?


Stale objects are deleted at the point they are detected as stale and no 
longer usable (ie a request has been made for it and updated replacement 
has arrived from the web server). Or if they are the oldest object 
stored and more cache space is needed for newer objects.



Other than tuning your existing setup there are two things I think you 
may be interested in.


The first is a Measurement Factory project which involves altering Squid 
to completely bypass the cache storage when an object can't be cached or 
re-used by other clients. Makes them faster to process, and avoids 
dropping cached objects to make room. Combining this with a cache deny 
rule identifying those annoying robots as non-cacheable would allow you 
to store only the real users traffic needs.
  This is a slightly longer-term project, AFAIK it is not ready for 
production use (might be wrong). At minimum TMF are possibly needing 
sponsorship assistance to progress it faster. Contact Alex Rousskov 
about possibilities there, http://www.measurement-factory.com/contact.html



The second thing is an alternative squid configuration which would 
emulate that behaviour immediately using two Squid instances.
 Basically; configure a new second instance as a non-caching gateway 
which all requests go to first. That could pass the robots and other 
easily detected non-cacheable requests straight to the web servers for 
service. While passing the other potentially cacheable requests to your 
current Squid instance, where storage and cache fetches happen more 
often without the robots.


 The gateway squid would have a much smaller footprint since it needs 
no memory for caching or indexing, and no disk usage at all.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

On 18/08/11 22:56, Chen Bangzhong wrote:
 Mean Object Size:   20.61 K
 maximum_object_size_in_memory 1024 KB
 
 So most objects will be save in RAM first, still can't explain why
 there are so many disk writes.
 

Well, I would check the HTTP response headers there. Make sure they are
containing Content-Length: header. If that is missing Squid is forced to
assume it will have infinite length and require disk backing for the
object until it is finished arriving.

The Mean Object Size: metric is measured on completely received and
stored objects. So does not really account for unknown length objects or
non-cacheable previous objects.

Amos
-- 
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning


On 18/08/11 22:53, Kaiwang Chen wrote:

2011/8/18 Amos Jeffriessqu...@treenet.co.nz:

On 18/08/11 19:40, Drunkard Zhang wrote:


2011/8/18 Chen Bangzhong:



snip



I don't know why there are so many disk writes and there are so many
objects on disk.


All traffic goes through either RAM cache or if its bigger than
maximum_object_size_in_memory will go through disks.

 From that info report ~60% of your traffic bytes are MISS responses. A large
portion of that MISS traffic is likely not storable, so will be written to
cache then discarded immediately. Squid is overall mostly-write with its
disk behaviour.


Will a cache deny matching those non-storable objects suppress
storing them to disk?
And HTTP header 'Cache-Control: no-store' ?


no-store header and cache deny directive have the same effect on 
your Squid. Both erase existing stored objects and erase the newely 
received one _after_ it is finished transfer.


 The difference is that the header applies everywhere receiving the 
object. The cache access control is limited to that one Squid instance 
testing it.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

thanks.

Before I try the gateway squid solution, I want to change one of my
squid to use memory cache only. I have 16GB RAM. now cache_mem is set
to 5GB.

I will try to increase it to 12GB and set cache_dir to null schma. I
do this because I am sure that my hot objects can be saved in RAM,
non-hot objects created by robots will stale  and the memory will be
reused.

Is that all I need to set squid to be a memory cache?




2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 22:50, Chen Bangzhong wrote:

 thanks you Amos and Drunkard.

 My website hosts novels, That's, user can read novel there.

 The pages are not truely static contents, so I can only cache them for
 10 minutes.

 My squids serve both non-cachable requests (works like nginx) and
 cachable-requests (10 min cache). So 60% cache miss is reasonable.  It
 is not a good design, but we can't do more now.

 Oh well. Good luck wishes on that side of the problem.


 Another point is, only hot novels are read by users. Crawlers/robots
 will push many objects to cache. These objects are rarely read by user
 and will expire after 10 minutes.

 If the http response header indicates it is not cachable(eg:
 max-age=0), will squid save the response in RAM or disk? My guess is
 squid will discard the response.

 Correct. It will discard the response AND anything it has already cached for
 that URL.

 For non-hot objects this will not be a major problem. But may raise disk I/O
 a bit as the existing old stored content gets kicked out. Which might
 actually be a good thing, emptying space in the cache early. Or wasted I/O.
 It's not clear exactly which.


 If the http response header indicates it is cachable(eg: max-age=600),
 squid will save it in the cache_mem. If the object is larger than
 maximum_object_size_in_memory, it will be written to disk.

 Yes.


 Can you tell me when will squid save the object to disk? When will
 squid delete the staled objects?

 Stale objects are deleted at the point they are detected as stale and no
 longer usable (ie a request has been made for it and updated replacement has
 arrived from the web server). Or if they are the oldest object stored and
 more cache space is needed for newer objects.


 Other than tuning your existing setup there are two things I think you may
 be interested in.

 The first is a Measurement Factory project which involves altering Squid to
 completely bypass the cache storage when an object can't be cached or
 re-used by other clients. Makes them faster to process, and avoids dropping
 cached objects to make room. Combining this with a cache deny rule
 identifying those annoying robots as non-cacheable would allow you to store
 only the real users traffic needs.
  This is a slightly longer-term project, AFAIK it is not ready for
 production use (might be wrong). At minimum TMF are possibly needing
 sponsorship assistance to progress it faster. Contact Alex Rousskov about
 possibilities there, http://www.measurement-factory.com/contact.html


 The second thing is an alternative squid configuration which would emulate
 that behaviour immediately using two Squid instances.
  Basically; configure a new second instance as a non-caching gateway which
 all requests go to first. That could pass the robots and other easily
 detected non-cacheable requests straight to the web servers for service.
 While passing the other potentially cacheable requests to your current Squid
 instance, where storage and cache fetches happen more often without the
 robots.

  The gateway squid would have a much smaller footprint since it needs no
 memory for caching or indexing, and no disk usage at all.

 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

2011-08-18 Thread Kaiwang Chen

2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 18/08/11 22:53, Kaiwang Chen wrote:

 2011/8/18 Amos Jeffriessqu...@treenet.co.nz:

 On 18/08/11 19:40, Drunkard Zhang wrote:

 2011/8/18 Chen Bangzhong:

 snip

 I don't know why there are so many disk writes and there are so many
 objects on disk.

 All traffic goes through either RAM cache or if its bigger than
 maximum_object_size_in_memory will go through disks.

  From that info report ~60% of your traffic bytes are MISS responses. A
 large
 portion of that MISS traffic is likely not storable, so will be written
 to
 cache then discarded immediately. Squid is overall mostly-write with its
 disk behaviour.

 Will a cache deny matching those non-storable objects suppress
 storing them to disk?
 And HTTP header 'Cache-Control: no-store' ?

 no-store header and cache deny directive have the same effect on your
 Squid. Both erase existing stored objects and erase the newely received one
 _after_ it is finished transfer.

  The difference is that the header applies everywhere receiving the object.
 The cache access control is limited to that one Squid instance testing it.

Great. What about Cache-Control: max-age=0 and Cache-Control:
no-cache responses? Does squid store them, hoping it is cheaper to
make a validatation than to fetch a whole fresh object? Which souce
code files describe the logic to deal with such cases?



 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10


Thanks,
Kaiwang

Re: [squid-users] squid performance tunning

2011-08-18 Thread Kaiwang Chen

在 2011年8月18日 下午9:07，Amos Jeffries squ...@treenet.co.nz 写道：
 On 18/08/11 22:56, Chen Bangzhong wrote:
 Mean Object Size:   20.61 K
 maximum_object_size_in_memory 1024 KB

 So most objects will be save in RAM first, still can't explain why
 there are so many disk writes.


 Well, I would check the HTTP response headers there. Make sure they are
 containing Content-Length: header. If that is missing Squid is forced to
 assume it will have infinite length and require disk backing for the
 object until it is finished arriving.

Will squid require disk backing despite of the object size, even it is
smaller than the receive buffer?
Not sure what is the default size of receive buffer, is it one of these?
read_ahead_gap 16 KB
tcp_recv_bufsize 0 bytes


 The Mean Object Size: metric is measured on completely received and
 stored objects. So does not really account for unknown length objects or
 non-cacheable previous objects.

 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10


Thanks,
Kaiwang

Re: [squid-users] squid performance tunning


On 19/08/11 02:40, Kaiwang Chen wrote:

2011/8/18 Amos Jeffriessqu...@treenet.co.nz:

On 18/08/11 22:53, Kaiwang Chen wrote:


2011/8/18 Amos Jeffriessqu...@treenet.co.nz:


On 18/08/11 19:40, Drunkard Zhang wrote:


2011/8/18 Chen Bangzhong:



snip



I don't know why there are so many disk writes and there are so many
objects on disk.


All traffic goes through either RAM cache or if its bigger than
maximum_object_size_in_memory will go through disks.

  From that info report ~60% of your traffic bytes are MISS responses. A
large
portion of that MISS traffic is likely not storable, so will be written
to
cache then discarded immediately. Squid is overall mostly-write with its
disk behaviour.


Will a cache deny matching those non-storable objects suppress
storing them to disk?
And HTTP header 'Cache-Control: no-store' ?


no-store header and cache deny directive have the same effect on your
Squid. Both erase existing stored objects and erase the newely received one
_after_ it is finished transfer.

  The difference is that the header applies everywhere receiving the object.
The cache access control is limited to that one Squid instance testing it.


Great. What about Cache-Control: max-age=0 and Cache-Control:
no-cache responses? Does squid store them,


max-age=0, that means discard immediately. Same as no-store to Squid.

no-cache on responses is borderline. I can't seem to find anything 
relevant to no-cache kicking off a refresh. The HTTP/1.1 support results 
show it acting like no-store when last tested. So probably not usable yet.


Luckily there is an overlap with the must-revalidate response directive. 
You can send that on the reply instead.


 hoping it is cheaper to
 make a validatation than to fetch a whole fresh object? Which souce
 code files describe the logic to deal with such cases?


If the object has not actually changed, the server sends 304 instead of 
a new object, and there is an ETag to identify that object both machines 
are talking about is identical. Then yes, revalidation is much smaller.
 Squid does not (yet) send If-None-Match on revalidations (accepts and 
relay it but does not create it), so there are a number of possible 
cases where revalidation fails to be smaller.



src/client_side_reply.cc  cacheHit() handles the reply when an object is 
found in storage (to determin if its usable, obsolete, or simply old). 
That makes use of various other process*() code and src/refresh.cc does 
the revalidation calculations.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning


On 19/08/11 02:10, Chen Bangzhong wrote:

thanks.

Before I try the gateway squid solution, I want to change one of my
squid to use memory cache only. I have 16GB RAM. now cache_mem is set
to 5GB.

I will try to increase it to 12GB and set cache_dir to null schma. I
do this because I am sure that my hot objects can be saved in RAM,
non-hot objects created by robots will stale  and the memory will be
reused.

Is that all I need to set squid to be a memory cache?



You have squid-3.1, so only comment out the cache_dir lines and set 
cache_mem to something large. null dir schema no longer exists.


 Remember that cache_mem still has an index to account for and the 
usual active traffic buffering stays present. Also that reconfigure will 
wipe the RAM cache to empty.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning

Amos, I want to find out what is filling my disk at 2-3MB/s. If there
is no cache related information in the response header, will squid
write the response to the disk?

In squid wiki, I found the following sentences:

Responses with Cache-Control: Private are NOT cachable.

Responses with Cache-Control: No-Cache are NOT cachable.

Responses with Cache-Control: No-Store are NOT cachable.

Responses for requests with an Authorization header are cachable ONLY
if the reponse includes Cache-Control: Public.
The following HTTP status codes are cachable:

200 OK
203 Non-Authoritative Information
300 Multiple Choices
301 Moved Permanently
410 Gone

My question is: If there is no Cache-control related information, such
as the following header

Server  nginx/0.8.54
DateThu, 18 Aug 2011 15:56:29 GMT
Content-Typeapplication/json; charset=UTF-8
Content-Length  1218
X-Cache MISS from zw12squid.my.com
X-Cache-Lookup  MISS from zw12squid.my.com:80
Via 1.0 zw12squid.my.com (squid/3.1.12)
Connection  keep-alive

will squid save it to disk?

Can you give me a detailed description about when will squid save the
object to disk?

thanks a lot for your kind help.



2011/8/18 Amos Jeffries squ...@treenet.co.nz:
 On 19/08/11 02:10, Chen Bangzhong wrote:

 thanks.

 Before I try the gateway squid solution, I want to change one of my
 squid to use memory cache only. I have 16GB RAM. now cache_mem is set
 to 5GB.

 I will try to increase it to 12GB and set cache_dir to null schma. I
 do this because I am sure that my hot objects can be saved in RAM,
 non-hot objects created by robots will stale  and the memory will be
 reused.

 Is that all I need to set squid to be a memory cache?


 You have squid-3.1, so only comment out the cache_dir lines and set
 cache_mem to something large. null dir schema no longer exists.

  Remember that cache_mem still has an index to account for and the usual
 active traffic buffering stays present. Also that reconfigure will wipe the
 RAM cache to empty.

 Amos
 --
 Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning


On 19/08/11 02:59, Kaiwang Chen wrote:

在 2011年8月18日 下午9:07，Amos Jeffriessqu...@treenet.co.nz  写道：

On 18/08/11 22:56, Chen Bangzhong wrote:

Mean Object Size:   20.61 K
maximum_object_size_in_memory 1024 KB

So most objects will be save in RAM first, still can't explain why
there are so many disk writes.



Well, I would check the HTTP response headers there. Make sure they are
containing Content-Length: header. If that is missing Squid is forced to
assume it will have infinite length and require disk backing for the
object until it is finished arriving.


Will squid require disk backing despite of the object size, even it is
smaller than the receive buffer?


_require_ it. No. Do it that way due to old code, yes maybe.

The amount of data waiting to be processed does not matter much. Could 
be zero bytes chunked encoded and a set of followup pipelined response 
headers. Until it is processed and stored somewhere Squid can't tell if 
its some bytes that happened to appear early, or the whole thing.


 The packet size, read_ahead_gap, and the receive buffer size (dynamic! 
1-64KB), and cache_dir min/max values all have an effect in that area. 
I believe it picks a cache area before continuing to read more bytes 
(but not completely certain).


If the cache_dir all have small maximum size limits and RAM looks bigger 
it will go there. In fact cache_dir usage for backing being practically 
welded in 3.1 series with large cache_mem have been showing signs of 
memory-backing instead on occasion. The other dev have projects underway 
to eliminate all that confusion in 3.2 anyways.



Not sure what is the default size of receive buffer, is it one of these?
read_ahead_gap 16 KB


sliding window of bytes to buffer unsent to the client. Mostly unrelated 
to the receive buffer. When in effect its the minimum buffer size.



tcp_recv_bufsize 0 bytes


The tcp_recv_bufsize is the maximum amount per read cycle (0 being use 
the OS sysctl details, which is usually 4KB). Default buffer is 
hard-coded as 1KB for most of 3.1 series. 4KB for older and newer 
releases (slow-start algorithm from 1KB turned out to be bad for speed 
on MB sized objects and no benefit for small ones).


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

Re: [squid-users] squid performance tunning