这里首先感谢莫大分享的文档
包转发线速的衡量标准是以单位时间内发送64byte的数据包（最小包）的个数作为计算基准的。对于千兆以太网来说，计算方法如 下：1,000,000,000bps/8bit/（64 + 8 + 12）byte=1,488,095pps 说明：当以太网帧为64byte时，需考虑8byte的帧头和12byte的帧间隙的固定开销。故一个线速的千兆以太网端口在转发64byte包时的包转 发率为1.488Mpps。快速以太网的线速端口包转发率正好为千兆以太网的十分之一，为148.8kpps。
*对于万兆以太网，一个线速端口的包转发率为14.88Mpps。
*对于千兆以太网，一个线速端口的包转发率为1.488Mpps。
*对于快速以太网，一个线速端口的包转发率为0.1488Mpps。
一般来说，组成Web站点体系结构有如下几个基本元素。
浏览器
因为Web浏览器标准、简单且普遍使用，所以它可以称得上是一个接近理想状态的图形用户接口（Graphical User Interface，GUI）。
目前比较流行的浏览器有：IE，firefox，opera，safari等，所以必须要了解其的相关特性，这也利于更好的利用这些特性来做相关架构的设计。
负载均衡
最简单的莫属DNS轮询（Round Robin DNS）方式了，但是不建议使用，因为下面的三个原因迫使你特别小心：
1. Round Robin DNS无法实现真正的负载均衡，但是在一些简单情况下还是能够均衡负载。真正的负载均衡是监测服务器的使用情况，以及根据该使用情况来分配连接，以便能始终将连接分配给那些有足够的容量来处理这些连接的服务器。
当Round Robin集中的一台服务器比其他服务器慢很多时，就会产生一种称为”护航（convoying）“的特殊情况，这时用户会列队等待速度较慢的服务器，而较快的服务器则未被使用。真正的负载均衡不会出现这样的问题。
2. RRDNS不会视图解决服务器的失效问题。用户仍然会被引导到失效的服务器上。真正的负载均衡可以提高站点的可用性，因为如果一台服务器出现故障，那么其他的服务器会自动接过该服务器的负载。
3. RRDNS很难保持用户的状态，特别是使用session的业务，比如某个用户在发表文章或者回复的时候，应用程序会对该用户的session保存在当前的服务器上，但是当用户写好文章或者回复开始提交后，因为RRDNS，结果发现用户提交到了另外的服务器上，因为新的服务器上没有用户的session，提示用户未登陆等警告信息，所以会导致提交失败。
很多情况，情况当要从dns里删除失效的IP时，会发现DNS的更新非常慢，因为很多LOCAL DNS并不遵循相关规范，这样有许多用户的LOCAL DNS服务器的缓存里仍会保留这个失效的IP，而且保留的时候甚至会很久，在国内特别是小的ISP常会这么做。
IP级别的负载均衡
这里常见的软件的实现方式有LVS，值得骄傲的是LVS是由国人章文嵩开发的，其简单高效，当然也需要配合其他的HA软件来实现”三H“。通过IP级别的负载均衡可以避免上述的RRDNS弊端。
当然也可以使用硬件均衡设备。
Web服务器
目前常用开源的Web服务器有：Apache、Nginx、Lighttpd等。
Web服务器的内容和日志应当分开保存到各自专用的磁盘上，这样可以避免他们相互干扰。
中间件
任何与一端的Web服务器和另一端的数据库交互的软件都可以被成为中间件。中间件的好处可以使结构清晰简单，可以提高整体性能。
数据库
数据库表可以通过某种方式被定义、镜像、分割、部署，以使之发挥最大的性能。数据库的优化是们深奥的学问，一个好的数据库管理员（Database Administrator，DBA）身价也是不菲的。
目前常见的DB有：mysql、oracle等。
虽然Web站点体系基本上是上述几个方面，但是影响Web性能确有更多的因素，只要把握上述几个方面，逐步排除和优化，我想结果一定不会差。
graphicsmagick和ImageMagick一样，都是图像处理软件，目前我们就在用ImageMagick，今天看到两者的比较，让我心动准备实测一下graphicsmagick，官方有份是两者的Benchmark报告，点这里查看。
InfoWorld历年的开源软件大奖都相当有分量，不过国内知道或者关注这个奖项的用户并不是特别多。InfoWorld 2008年的“开源软件大奖”最新出炉，CHIP软件社区乘此机会将InfoWorld 2008年的“开源软件大奖”中文化并进行整理，希望能够为中国用户带来便利，也希望能够为开源社区共享绵薄之力。
由于InfoWorld的评选软件范围广、类别多，很多时候在同一个类别中，桌面版软件和服务器版软件常常混杂在一起，限于时间和水平，这个专题的组织和本地化肯定有不妥甚至是错漏之处，欢迎用户和网友批评指正。
记得一年前发现很多手机上传的照片经过打水印后会损坏图片，后来经过多方搜索，终于找到了解决方案，当时解决后就没做一下记录，时隔一年，终于又要用到，可一时找不到解决方法，突然想起当年打包（rpm）时还留下源码，于是去jpeg-6b下的源代码进行md5比对，终于找到jdmarker.c该文件做过一些修改，赶紧记录：
修改如下：
/*
* WARNMS2(cinfo, JWRN_EXTRANEOUS_DATA, cinfo->marker->discarded_bytes, c);
*/
其实就是注释掉这段代码而已。
预先在存储节点上建立2级目录是个好方法，可以提高程序的执行效率，少了目录是否存在的判断。
同时也减少磁盘io的压力，毕竟一次性建好目录，以后是不会去调整的。
做DNS要更新各SP的网段，下面简单的总结一下早上获取教育网的经过。
其实很简单，首先去教育网官方去获取最新的IP段：
只要下载：http://www.nic.edu.cn/RS/ipstat/ 这个url里的数据，然后进行分析（可惜这个url必须在教育网内才可以正常访问）。
内容如下：
web 2.0海量小文件cache集群探讨(原创)
在互联网快速发展的背景下，特别是we2.0，网络上的数据内容呈几何级的增长，而其中增长最快并且最容易给技术架构带来挑战的就是数目庞大的小文件，如 何来解决这种高并发，大流量，小文件，热点不集中的问题，经过我们大量研究，实践之后，总结出这种海量小文件，高并发所存在的关键问题和解决方案。
我们先对比一下在web1.0的解决方案和web2.0的我们碰到的困难。
Web1.0
1、源数据量小，单台squid即可达到很高的命中率。
2、请求量大，用lvs+squid或者dns轮询即可解决问题。
3、squid服务器磁盘IO压力大，用超大内存做cache。
web 2.0
目前的瓶颈:
1、源数据数量很大，导致squid hash table 索引效率不高，Cache 命中率低。
为了提高对文件的访问效率，往往会在前端配置一个稍大容量的缓存。但由于小文件的数量极其庞大，应用对这些文件访问的随机性非常高，使得Cache 命中率极低，缓存失去了应有的作用，导致应用需要直接到后端存储系统上读取数据，给存储系统带来了极大的压力。刚开始就是我们也采用了昂贵的高端存储系统 NetApp，但是在用户高并发访问的情况下，存储系统经常出现长时间无响应的严重故障。
2、源数据容量巨大，海量文件检索效率低，从而也导致单台squid命中率很低。
有些频道数据容量会超过200T，单台squid只是杯水车薪，频繁的cache置换更是加剧了cache效率低下，再加上现有的存储系统无法有效管理海 量小文件，并且在单个目录下存放文件的数量有一定的限制，一旦文件数到达了一定规模之后，文件的检索速度就急剧下降。我们只能通过多级目录来组织存放大量 的小文件，随着目录深度的增加，文件的检索开销进一步增大，检索效率随之下降。
3、大量的cache导致的磁盘IO问题
由于目前单台cache容量已经达到上百G，文件系统瓶颈、磁盘IO问题也很快凸显。
4、压力过大导致的hit ratio抖动
cache 删除，写操作达到一定的比例,同时如果压力较高，会导致hit ratio呈线性下降。即使cache没down，但也因为命中率的下降而失去应有的作用。
5、特殊集群下的单台失效问题
在类url hash的集群下，单台cache失效会导致hash rehash，那么整个集群的squid命中率都会被冲击。
如何来解决这些问题，思路如下：
1、优化squid hash table 索引算法,
需要修改源squid代码
2、cache集群，用类url hash的方法，以增加cache容量
1)、wccp: cisco的路由器均有此功能
2)、carp: ISA,squid自身的7层调度协议
3)、url hash: nginx haproxy等7层代理
3、选择合适的文件系统
XFS使用更多的内存来作为自己的高速缓存，以尽可能的延迟零散的写操作，尽可能的执行批量写操作。
4、选择更合理的磁盘搭配策略，比如Raid策略或者单盘策略等
Raid 5，10 带来了不错的安全性，但是会导致磁盘IO效率低下，不做Raid的单盘性能最高，更适合单台服务器多squid进程模式。
5、集群下的单台cache失效的接管，以免单点故障，提高可用性。
针对以上分析，我们大量尝试了开源的一些产品，像LVS，Nginx，Squid，XFS等。
具体的软件组合和架构如下：
（1）、web服务器的选择，目前，大多数web服务器的处理能力有限，互联网广泛上使用的web服务器如Apache，其并发能力往往在2000以下， 这是由web服务器自身的设计模式（如多进程，无IO缓存等）决定的。因此，在较大规模的访问情况下，通常会表现出用户访问网站慢，web 服务器负载高。为什么选择Nginx? use linux epoll, sendfile and aio to improve the performanc，我们主要利用的是Nginx的第三方模块ngx_http_upstream_hash_module做反向代理。
部分代码如下：
upstream img{
server squid1:81;
server squid2:81;
hash $request_uri;
hash_again 0; # default 0
hash_method crc32; # default “simple”
}
server {
listen 80;
server_name images.gx.com;
location / {
proxy_pass http://img;
(３)负载均衡软件，我们选择了LVS+HA，用DR模式。目前我们运行环境中的LVS（2.6的内核），普通很稳定。我们主要用Heartbeat+ldirectord。
(4) 适合处理小文件的文件系统XFS。XFS 最佳表现之一在于：象 ReiserFS 一样，它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据，并且，通常仅当内存不足时，才会命令将数据写到磁盘时。当它将数据清仓（flushing）到磁盘时，其它 IO 操作在很大程度上似乎不受影响。
(5)其它优化
在客户端和服务器做大量有效的缓存策略;用更小的并且可缓存的图片（单张图片尽量不要超过200K）;尽量减少http请求;开起 keepalive减少tcp连接开销;优化tcp参数;起用多域名分域名策略;减少cookie影响等。
(6)关于优化题外：大配置和架构没有问题的前提下，有money的话应该首选硬件优化方案而不是软件细节优化。
整个架构如下图
后端存储垂直分割的规则如下(按00-ff散列)：
location ~ ^/[0-1][0-f]/ {
proxy_pass http://192.168.3.12;
}
location ~ ^/[2-3][0-f]/ {
proxy_pass http://192.168.3.11;
}
……..
以上这个架构的优化在于：
实现了高可用性，最大程度上防止单点，又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。
充分发挥机器的性能，架构可扩展性，层次分明。
最后，很重要的二点，1）要通过性能分析和监控，来找到系统瓶颈的临界点和薄弱点。监控分析是一切优化的重点，要以数据事实来调整策略。2）架构的负荷如果已经超过设计负荷的5~10倍，就要考虑重新设计系统的架构，我们这里仅仅讨论某一阶段的架构设计。
部份资料来源http://bbs.be10.com,http://www.dbanotes.net,http://ourlinux.net,特别感谢http://jsqyy.51.com,他在squid方面深有研究。
今天早餐：
|
昨日早餐：
|