WEB·攻城志

 假设启动的varnish服务如下：
./varnishd -f ../etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:3500

注意：1. varnish服务本身，启动默认端口80；如果需要重新指定启动的端口使用 -a选项 ,如-a 0.0.0.0:8080
           2. -T 选项指定了varnish服务本身的管理端口，正是利用这个端口完成一些不关闭varnish服务而使新配置生效。

操作步骤：
1、登陆到管理接口：
    >telnet 127.0.0.1 3500
    >help  (利用该命令可以得到很多的修改帮助)
返回：
200 377    
help [command]
ping [timestamp]
auth response
quit
banner
status
start
stop
stats
vcl.load <configname> <filename>
vcl.inline <configname> <quoted_VCLstring>
vcl.use <configname>
vcl.discard <configname>
vcl.list
vcl.show <configname>
param.show [-l] [<param>]
param.set <param> <value>
purge.url <regexp>
purge <field> <operator> <arg> [&& <field> <oper> <arg>]…
purge.list

使用命令
vcl.load new.vcl /usr/local/varnish/etc/varnish/new.vcl (编译出错的话会有提示，成功会返回200)
200
然后使用
vcl.use new.vcl (成功后同样会返回200)
200
此时新的配置文件已经生效！

在管理MySQL、初始化服务器、克隆从服务器和进行备份/还原操作时，复制、压缩和解压大文件（常常是跨网络的）是很常见任务。

今天在High Performance MySQL上面看到如何高效地传输复制文件介绍给大家

这里面要用到NetCat，一个Linux下的高效读、写TCP/UDP连接的工具

具体操作如下：

1.在客户端运行如下命令：

$ nc -l -p 12345 | gunzip -c – > /var/lib/mysql/mydb/mytable.MYD

在CentOS下要不用参数-p?

2.在服务器端运行如下命令

$gzip -c – /var/lib/mysql/mydb/mytabale.MYD | nc -q 1 server2 12345

或者直接用tar命令

$ nc -l -p 12345 | tar xvzf –

$ tar cvzf – /var/lib/mysql/mydb/mytable.MYD | nc -q 1 server2 12345

利用NetCat比先在源服务器上面压缩再传输更高效一些，它将压缩、复制文件和传输的另一端解压缩文件全部放在一个步骤里完成。因为磁盘活动被降低到只要在服务器上面读，在目标服务器上面写，所以极大地降低了磁盘I/O。

也可用用SSH实现，但是SSH需要加密传输，而NetCat是直接把“裸”数据进行跨网传输。

nginx 目前有这么几种cache方式：

1. proxy_store方式

location / {
    root /home/html/;
###启用proxy_store，指定nginx将代理返回的文件保存
    proxy_store on;
###让后端不要返回压缩（gzip或deflate）的内容，保存压缩后的内容会引发乱子。
    proxy_set_header Accept-Encoding ”;
###临时目录，这个目录要和/home/html在同一个硬盘分区内
    proxy_temp_path /home/tmp;
    if ( !-f $request_filename )
    {
        proxy_pass http://www.sudone.com/;
    }
}
原理就是找不到文件时通过proxy_pass指定的源服务区地址抓取文件保存到本地，proxy_store完全是在本地服务器保存了一个跟源服务器一模一样的目录结构，真的很强大，但缺点就是无法限制空间大小，如果本地服务器空间比源服务器小，很容易就把硬盘空间撑爆了，所以需要定时清理一些文件以保证服务器空间。

2.基于memcached的缓存

nginx对memcached有所支持，但是功能并不是特别之强，性能上还是非常之优秀。

location /mem/ {
    if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
    {
     set $memcached_key "$1";
     memcached_pass     192.168.1.2:11211;
    }
    expires 70;
}

这个配置会将http://sudone.com/mem/abc指明到memcached的abc这个key去取数据。

nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。

3、基于第三方插件ncache

ncache是新浪开发的一个不错的项目，它利用nginx和memcached实现了一部分类似squid缓存的功能，关于这个插件的使用可以参考：

http://code.google.com/p/ncache/
但NCache is now in nginx core , you can use it as nginx proxy cache 
NCache is out of maintaince from 2009.1.1 （NCache已经停止更新很久了，但已经集中到nginx内核了，应该就是nginx0.7.44版本新加入的proxy_cache功能了，见下一个cache方式）

4、nginx新开发的proxy_cache功能

从nginx-0.7.44版开始，nginx支持了类似squid较为正规的cache功能，目前还处于开发阶段，支持相当有限，这个缓存是把链接用md5编码hash后保存，所以它可以支持任意链接，同时也支持404/301/302这样的非200状态。

 

http://note.sdo.com/u/1357765468/n/gXtJs~jyx99FnM01o0012E

1.Squid，很古老的反向代理软件，拥有传统代理、身份验证、流量管理等高级功能，但是配置太复杂。它算是目前互联网应用得最多的反向缓存代理服务器，工作于各大古老的cdn上。

2.Varnish是新兴的一个软件，设计简单，更符合目前互联网的应用，很多公司都采用了varnish这个软件，比如微博的openapi  http://open.t.sina.com.cn 。Varnish是基于内存缓存，重启后数据将消失。

3.nginx nginx的反向代理缓存是通过一个模块实proxy_cache来实现的，目前这个模块还在完善中，但是很多公司已经开始使用了。

 

群里总是有人在问cache用什么，有varnish，squid，apache，nginx这几种，到底是我们用什么架构cache。

1、从这些功能上。varnish和squid是专业的cache服务，而apache，nginx这些都是第三方模块完成。

2、要做cache服务的话，我们肯定是要选择专业的cache服务，优先选择squid和varnish。

varnish本身的技术上优势要高于squid，它采用了“Visual Page Cache”技术，在内存的利用上，Varnish比Squid具有优势，它避免了Squid频繁在内存、磁盘中交换文件，性能要比Squid高。varnish是不能cache到本地硬盘上的。

还有强大的通过Varnish管理端口，可以使用正则表达式快速、批量地清除部分缓存

squid的优势在于完整的庞大的cache技术资料，和很多的应用生产环境（这应该与squid早出来有关）。

3、谈谈nginx，nginx是用第三方模块ncache做的缓冲，其性能基本达到varnish，但在架构中nginx一般作为反向（静态文件现在用nginx的很多，并发能支持到2万+）。在静态架构中，如果前端直接面对的是cdn活着前端了4层负载的话，完全用nginx的cache就够了。

4、本人觉得如果是在apache服务上提升性能，做一些本地cache是完全可以的，但如果在系统架构中用apache做cache服务，那就有点牛头不对马尾了。

—————————————

以下是转载了一个同学的测试数据

一，测试环境

1，硬件是奔腾双核，机子三年前买的。系统是archlinux

2，测试varnish和squid的时候，web服务用的apache

3，测试apache的时候，启动了5个进程，不过随着压力的增加，进程会增加的。

4，测试nginx的时候，启动了十个nginx进程，20个php-cgi进程

5，varnish，squid，nginx用的是反向代理的形势，也就是说访问图片的时候，要先透过缓存工具

二，测试

1，varnish

[root@BlackGhost bin]# /usr/local/bin/webbench -c 100 -t 20 http://127.0.0.1:8080/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1:8080/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
100 clients, running 20 sec.

Speed=476508 pages/min, 47258114 bytes/sec.
Requests: 158836 susceed, 0 failed.

varnish的缓存效率命中率真的好高，看下图：

访问了这么次，没有缓存只有一次，效率真的很高。

2，squid

[root@BlackGhost bin]# /usr/local/bin/webbench -c 100 -t 20 http://localhost:9000/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://localhost:9000/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
100 clients, running 20 sec.

Speed=133794 pages/min, 7475018 bytes/sec.
Requests: 44598 susceed, 0 failed.

从测试效果来说，squid挺让我失望的，在测试前，我心里是这样估计的，缓存最好的是varnish，其次是squid，然后nginx，最后是apache，现在呢，squid是最差的。后来我看了一下log文件，发现正常情况下，缓存和没有缓存的比率不是1：2，如果在高压力下，缓存和没有缓存的比率更小。

3，apache

[root@BlackGhost conf]# /usr/local/bin/webbench -c 100 -t 20 http://localhost/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://localhost/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
100 clients, running 20 sec.

Speed=160890 pages/min, 15856005 bytes/sec.
Requests: 53630 susceed, 0 failed.

4，nginx

[root@BlackGhost conf]# /usr/local/bin/webbench -c 100 -t 20 http://localhost:10000/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://localhost:10000/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif
100 clients, running 20 sec.

Speed=304053 pages/min, 30121517 bytes/sec.
Requests: 101351 susceed, 0 failed.

从上面的测试结果我们可以发现，varnish > nginx > apache > squid，我想这个结果，根大家预期的结果有点出入，因为squid做老牌文件缓存工具怎么会这么差呢，squid的命中率低，我在网上查了一下，很多人都是这样的，这个可能根个人配置有关系，也许真正的高手，才能让squid发挥最大功力。

http://www.cnblogs.com/google4y/archive/2011/09/19/2181251.html