闲谈 Web 图片服务器

闲谈 Web 图片服务器
作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/web/web_image_server.html



现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储
把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器
无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名
如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数 问题(参见对该问题的测试 )。

前几天有个朋友在线上问我，"一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?" ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉 的留言】

雅虎 Web 优化 14 条
关于雅虎 YSlow 工具倡导的 优化 14 条规则 ，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看--介绍这 14 条规则的页面本身也只能得到 70 多分...其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache
很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明 ，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。

服务器端的 Cache
在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。

高解析图片问题
如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题
很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)...这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些"截屏"得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。

--EOF--

图片处理工具的选择
可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report ，如果图片处理量巨大，性能问题又怎能不考虑?