For the popular:
1.varnish performance is 10~20 times higher than squid
2.squid 3.0 performance is higher than 2.6
This test will reveal the results,
Does the varnish architecture really improve so much performance
Whether the new version of Squid is improving in performance
The test will not be platform. Software, etc. optimize
Because of the optimal level of the relationship will greatly affect the results.
The data in this test can be used as the baseline data.
The proportional coefficients of the optimization and the non-optimal results of the individual software can be
The comparison results are calculated by ourselves. So the impact of individual software optimization or system optimization on the whole
It can be done by the reader on its own, using the baseline data for extrapolation.
Pages of a Web site
I will Taobao's home page to get to the local
As a Test object
Test page Download
Index_files
Platform:
PROXY:
CentOS 5.1 Minimal Installation
Wave NF190
Xeon 2.8
1G RAM
73G SCSI
Squid 2.6,squid 3.0,varnish 1.1.2
Web:
CentOS 5.1 Minimal Installation
Wave NF180
Xeon 2.8
1G RAM
73G SCSI
Nginx 0.6.31
CLIENT:
CentOS 5.1 Minimal Installation
Wave NF260
Xeon 2.4
512M RAM
36G SCSI
http_load-12mar2006
SWITCH:
DLink DES 1024r+
1.SQUID 2.6
Compilation parameters./Configure--prefix =/usr/local/squid26
Configuration file Visible_hostname test2. Hiadmin. Com
Http_port Accel Vhost Vport
Cache_peer 192.168.210.111 Parent 0 no-query originserver name = Test1
ACL all src 0.0.0.0/0.0.0.0
Http_access Allow all
Cache_log/var/log/squid26/cache. Log
2.Squid 3.0
Compilation parameters./Configure--prefix =/usr/local/squid30
Configuration file Visible_hostname test2. Hiadmin. Com
Http_port Accel Vhost Vport
Cache_peer 192.168.210.111 Parent 0 no-query originserver name = Test1
ACL all src 0.0.0.0/0.0.0.0
Http_access Allow all
Cache_log/var/log/squid30/cache. Log
3.Varnish 1.1.2
Compilation parameters./Configure--prefix =/usr/local/varnish
Configuration file Backend Default {
Set backend. Host = "192.168.210.111";
Set backend. Port = "80";
}
Run parameters varnishd-f/Usr/local/varnish/default. Vcl-a 0.0.0.0:80
4.Nginx 0.6.31
Compilation parameters./Configure--prefix =/Usr/local/nginx
Configuration file worker_processes 10;
Events {
worker_connections 1024;
}
http {
include mime. types;
default_type Application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index. HTML index. htm;
}
error_page 502 503 504 /x. html;
location =/x. html {
root html;
}
}
}
5.http_load
Run parameters./http_load-parallel 1000-seconds URLs. Txt
URLs. Txt
http://192.168.210.222/index.html
6.SQUID 2.7
Compilation parameters./Configure--prefix =/usr/local/squid27
Configuration file Visible_hostname test2. Hiadmin. Com
Http_port Accel Vhost Vport
Cache_peer 192.168.210.111 Parent 0 no-query originserver name = Test1
ACL all src 0.0.0.0/0.0.0.0
Http_access Allow all
Cache_log/var/log/squid27/cache. Log
Test results
Dot image magnification
The light yellow in the icon is 500 for the client to appear only once or several times during the crawl process
Orange is more frequent for 500 crawl errors
Red for almost every time there are 500 crawl errors
It's worth noting that Squid 3.0
The number of 500 occurrences in 500 concurrent connections is many
But the crawl failure rate dropped when you were 1000.
CPU and memory occupancy rate
Dot image magnification
Varnish has maintained good CPU and memory usage
But by the time the 1000 concurrent numbers
You'll find CPU usage up to 103%.
That's right. I didn't make a mistake. In 5 tests, Varnish's 1000 concurrency test has been hovering between 101~103 and the CPU occupancy rate.
It may be that varnish's connection pool isn't particularly good. When larger than varnish processing, more CPU resources are used to process
Squid 3.0 seems to be a big spender of CPU and memory.
may be related to newer versions and more features (although nothing in this case is useless)
Squid 2.6 maintains a good posture, stable CPU occupancy and memory footprint. This shows why the most used in the market is the reason for it.
More details can be downloaded from this form
Varnish-vs-squid3
Although Varnish has a surprising CPU footprint (and surprisingly more than processing power)
But the surge in memory and CPU usage when dealing with oversized links is not satisfying
But it shows a fetchs/second at the maximum load.
It's actually about 8% higher than squid 2.6.
The experiment shows that, in a more stable production environment, varnish can not replace the old generation of squid 2.6
But it has already posed a significant challenge to squid 3.0.
If Squid 3.0 doesn't deliver better performance and stability than his products
It is possible that the throne of the best reverse agent will be varnish.
No matter what
The subject of this test. Varnish is 10 times times or 20 times times more likely to perform than squid.
proved impossible to achieve.
Although the test data volume full of 100M bandwidth may affect the accuracy of the test.
But the number of simultaneous connections brought about by higher bandwidth is likely to explode the CPU and memory of the varnish host.
Conclusion
1.varnish in high load at the cost of CPU and memory, compared to squid 2.6 increase by 8%, but is not 10 times times 20 times times.
2.squid 3.0 performance is lower than 2.6. Rather than higher. Instead, 3.0 is the least stable and the worst performing.
3.SQUID 2.7 Performance is lower than 2.6, but CPU and memory occupancy rates are better controlled.
====================================================== Squid 2.6 2.7 3.0 3.1 and Varnish 2.1.5 performance comparison test
Http://www.cnblogs.com/littlehb/archive/2012/02/21/2360787.html
Description
Use the stress test software siege,http_load to test these agent software, testing different sizes of files and various concurrent numbers.
Squid version selection, taking into account the actual use of some of the requirements, and reference to some other articles (
For example: http://www.php-oa.com/2009/12/02/cache%e8%bd%af%e4%bb%b6%e7%89%88%e6%9c%ac%e9%80%89%e6%8b%a9.html
), did not choose to compare the old squid 2.5.
Clear the file cache and restart the agent software before each test.
This test serves only as a data reference and does not fully simulate the complex network requests (requests, file requests of various sizes) in the production environment.
First, test environment:
Hardware: Intel Xeon E5410 @ 2.33GHz * 2,16g memory, SATA 500G * 4 (RAID 10)
Install Squid 2.7
./configure-prefix=/opt/squid2.7-enable-xmalloc-statistics--enable-async-io=320--with-maxfd=65536- Enable-useragent-log-enable-referer-log-enable-epoll-disable-poll-enable-large-cache-files- Disable-internal-dns-enable-linux-netfilter-enable-truncate-enable-x-accelerator-vary- enable-follow-x-forwarded-for-with-large-files-with-pthreads-enable-storeio= "Aufs,coss,diskd,ufs"- Enable-kill-parent-hack-enable-gnuregex-enable-cache-digests-enable-delay-pools-enable-stacktraces- enable-default-err-language=simplify_chinese-enable-err-languages= "Simplify_chinese 中文版"--enable-auth= " Basic "--enable-basic-auth-helpers=" NCSA "--enable-snmp
Attention:
1, do not use-enable-dlmalloc This compilation parameters, or run for a period of time will be the error FATAL:xcalloc:Unable to allocate 1 blocks of 4112 bytes!
Reference:
Http://www.mail-archive.com/squid-users@squid-cache.org/msg48804.html
Http://www.mail-archive.com/squid-users@squid-cache.org/msg40839.html
The general meaning is that dlmalloc is squid in some system itself malloc too bad situation substitution scheme, Dlmalloc is already very old, and does not support 2G above memory (more interesting is used Squid 3.0 also used this parameter, but normal operation, Memory usage is configured over 10G, and possibly 3.0 has special processing compatible with this compilation configuration.
Squid 3 Compilation Parameters:
www:/srv#/opt/squid3/sbin/squid-v
Squid cache:version 3.0.stable25
Configure options: '--prefix=/opt/squid3 '--enable-dlmalloc '--enable-gnuregex '--enable-async-io=160 ' Enable-removal-policies=heap,lru '--enable-delay-pools '--enable-storeio=ufs,aufs,null '--DISABLE-WCCP '-- Enable-kill-parent-hack '--disable-select '--enable-auth=basic '--with-aio '--disable-ident-lookup ' with-filedescriptors=65536 '--enable-err-languages=simplify_chinese '--enable-default-err-languages=simplify_ Chinese '
The 3.1 compilation parameters are basically the same as 3.0.
Squid Several versions use basically the same squid.conf, performance related to several configurations as follows:
Cache_mem 4000 MB
maximum_object_size_in_memory MB KB
#cache_dir
Cache_dir Aufs/srv/squid_cache 20480 16 256
Maximum_object_size 4096 KB
Varnish:
Tar zxf varnish-2.1.5.tar.gz
CD varnish-2.1.5
./configure--prefix=/opt/varnish
Run Parameters:
/opt/varnish/sbin/varnishd-u www-g www-f/opt/varnish/etc/varnish/aipai.vcl-a 0.0.0.0:8080-s file,/srv/varnish_ Cache/cache/varnish_cache.data,1g-w 1024,51200,10-t 3600-t 0.0.0.0:30000
Second, test results:
60s per Test
Test command: Siege-b-C 100-t 60s URL
The data recorded in the table is: Transaction rate, Unit: request/S
Typical test results:
da01:~/siege-2.69# Siege-b-C 500-t 60s http://www.aipai.com:8080/about/map.html
* * Siege 2.69
* * Preparing concurrent users for battle.
The server is now under siege ...
Lifting the server siege ... done.
transactions:653211 Hits
availability:100.00%
Elapsed time:59.35 secs
Data transferred:1238.43 MB
Response time:0.05 secs//average corresponding time
Transaction rate:11006.08 trans/sec/sec processing speed per second, request/s
throughput:20.87 mb/sec//Network throughput
concurrency:498.86//Maximum concurrent number
Successful transactions:653212//number of successful processing
Failed transactions:0//failure handling number
Longest transaction:3.01//maximum request processing time
Shortest transaction:0.00
For a detailed description of the test results, interested friends please refer to Siege's documentation, which is already labeled with a few key data.
Test 1:
Target url:http://www.aipai.com:8080/about/map.html, test small file request, File size: 6221 byte
Concurrent 10
Concurrent 100
Concurrent 500
Concurrent 1000
Squid 2.6 STABLE23
8207
11211
11016
10451
Squid 2.7 STABLE9
8261
11409
11006
10002
Squid 3.0 STABLE25
8524
9762
8138
8768
Squid 3.1.11
6421
6832
5990
5834
Varnish 2.1.5
10875
10251
11459
11412
Ps:siege using more than 1000 concurrent errors will be an error.
Test 2:
Target url:http://www.aipai.com:8080/c7/pjg_kscqimgnaiys.html, test our website typical page request, File size: 75356 byte
Concurrent 10
Concurrent 100
Concurrent 500
Concurrent 1000
Squid 2.6 STABLE23
4554
6382
6625
6696 (4 failed)
Squid 2.7 STABLE9
4164
6234
6565
6588
Squid 3.0 STABLE25
4366
5315
5190
5153
Squid 3.1.11
3697
4217
4357
4075
Varnish 2.1.5
6618
6781
6775
5714
Test 1, Test 2 summary:
Test 1, Test 2 is a URL to the pressure, the main test mem_hit software processing capacity.
1, squid 2.6 in the Squid group is basically the fastest, in the test 2 concurrent 1000 when the start is not very stable, there are 4 connection timed out.
2, Squid 2.7 of the results and 2.6 in a horizontal line, slightly less.
3, squid from 3.0 began to rewrite with C + +, now it seems that the performance gap with the 2.7/2.6 is still very obvious, 3.1 from the performance point of view than 3.0 worse (squid brother, not for the function loss too much performance AH).
4, varnish in most of the test is in the lead, some projects poor (varnish test results are not very stable, there are some swing). Varnish performance is better than squid, but it is far from what some articles claim to be 10 times times as squid.
Test 3:
Further simulation of the production environment, from the actual running Squid access log intercepted 50,000 URLs to test.
Each test is extended to 2 minutes.
Concurrent 10
Concurrent 100
Concurrent 500
Concurrent 1000
Squid 2.6 STABLE23
2839
5485
6722
6604
Squid 2.7 STABLE9
2981
5215
6789
6742
Squid 3.0 STABLE25
2863
4294
4345
3859
Squid 3.1.11
2682