这篇文章虽然是将ror的,但是对于整个web开发还是非常有意义的，我也总结了下这篇文章，发现web程序还是很有共性的.
1:负载均衡器
大型网站肯定不是单台服务器的,为了做负载均衡,一般用F5,DNS轮询.我们公司所有的静态页面则采用NGINX做代理,后端挂SQUID服务器.NGINX的代理模块能够根据url地址HASH到某组服务器上,NGINX做负载均衡,SQUID组则考虑容灾问题.
2:WEB缓存服务器
原来我们公司使用文件cache,在新版本中使用squid作为页面缓存,squid组根据不同地区做IDC分布,形成了分布式的系统.从实际效果上看,文件cache更容易控制,程序使用比较灵活.考虑到不同的应用ncache可能逐步替代squid.
3:后端服务器
后端服务器就是应用服务器,主要通过F5挂在squid服务集群后面,处理的都是动态请求,每台机器每天50万的请求,cpu负载也不高,并发请求没有超过100,使用的是apache1.3,lamp的组合.
先写到这儿 干活了…………………………………………………….
JavaEye网站的RoR性能优化经验谈
JavaEye网站从2006年9月11日上线基于RoR的2.0版本开始，到现在已经运行了将近一年半了。在这一年半的时间里，JavaEye网站的每日PV从最开始的5万，缓慢增长到了现在的60万。随着网站负载的不断增加，我们也在不断尝试和调整网站的性能，积累了不少第一手RoR应用性能优化的实战经验。虽然我们并不是RoR性能优化的权威专家，我们所积累的经验也许并不是最优实践，但是作为国内最早涉足RoR商业运营的互联网网站之一，我们非常乐意分享和交流我们的实战经验，以帮助后来者节省必要的摸索时间。
RoR惊人的开发速度恐怕是每个互联网创业者都梦寐以求的，但是随着网站流量的不断增大，可能大多数采用RoR的网站或迟或早会遇到RoR的性能瓶颈，我的一个朋友capitian说过一句很有意思的话：“RoR应用做到后来，总有自己修改底层的冲动”。就我所了解和掌握的情况来看，很多RoR网站都过早的遇到了性能瓶颈，一个很普遍的现象就是：RoR应用的CPU负载要远远高于数据库的负载。这是一个有点违背常理的现象，因为我们知道，硬盘IO速度要比内存慢得多，所以一般Web应用的性能瓶颈往往会出现在数据库IO上，因此优化数据库访问，进行对象缓存是非常有效的性能优化手段。但是一旦应用服务器负载比数据库还高的话，单纯的对象缓存就无用武之地了。下面我们从几个方面分别谈一谈如何进行RoR的性能优化：
应用的部署
RoR应用的部署包括操作系统，Web服务器，应用服务器和数据库四个方面：
一、操作系统
1、发行版本
RoR适合于部署在Unix类操作系统上面，通常比较多的人使用RHEL/CentOS/Ubuntu，我们比较偏爱SuSE Linux，对于我们服务器使用的AMD Opteron x86_64的CPU来说，SLES要比RHEL有更多的优化。另外应该尽量使用64位版本操作系统，以充分发挥x86_64 CPU的性能，并且x86_64的Linux很多Kernel参数也大很多，代价就是需要更多的物理内存。
2、文件系统
Linux最常用的文件系统是ext3，但我们使用的是Reiserfs文件系统。Reiserfs在读写大量小文件的目录性能非常高，即使处理目录下面直接存放10万个文件，性能仍然不会下降。我们知道默认情况Rails会对每个浏览器会话在硬盘生成session文件，一个繁忙的网站，临时文件目录下面有上万乃至几万个session文件是很常见的现象。对于这种目录下面几万个小文件的存取，reiserfs要比ext3性能高一个数量级。如果希望对session文件有更好的存取性能，可以把临时目录链接到Linux的内存文件系统/dev/shm目录下面，这样实际上session文件的存取都是直接内存操作了，这种方式唯一的问题在于不能支持群集部署。如果你已经升级到了Rails2.0，可以采取把session保存到Cookie里面的方式，既可以避免服务器处理session的开销，而且还支持群集部署，是大规模网站部署的首选方式。
3、内核的网络参数调整
对于流量很大的网站来说，默认的Linux内核网络参数偏小，因此如果你的网站流量非常大，或者上传下载大文件比较多，可以针对性的调整内核网络参数，扩大内核的TCP接收数据和发送数据的Buffer缓冲区大小，比方说：
引用
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
net.ipv4.tcp_rmem=4096 65536 524288
net.ipv4.tcp_wmem=4096 65536 524288
参数具体调整，可以Google相关的Linux内核参数的文档，这里不展开详谈。
二、Web服务器
Web服务器首选Lighttpd，因为Lighttpd在和后端的应用服务器通讯方式上做了足够的优化：当POST大数据量的时候，Lighttpd在完整的接收客户端浏览器的数据之后，才会一次性发送给应用服务器；同样的，Lighttpd也是一次性把应用服务器处理的页面数据全部接收，不设置Buffer Size的限制。因此Lighttpd能够尽最大可能的减轻应用服务器的负担，减少应用服务器用于处理数据传输的延迟，更加有效的利用应用服务器资源。这方面的详细的论述请看：RoR部署方案深度剖析。
关于Lighttpd的安装可以参考在Linux平台上安装和配置Ruby on Rails详解，这里仅谈Lighttpd的性能优化的几个要点：
1、网络IO调度方式
Linux Kernel 2.6支持sysepoll方式调度网络IO，能够处理极高的并发连接请求，Lighttpd可以通过配置文件打开sysepoll支持：
引用
server.event-handler = “linux-sysepoll”
2、网络IO传输方式
Linux Kernel 2.6支持sendfile方式传输数据，Lighttpd可以通过配置文件打开sendfile支持：
引用
server.network-backend = “linux-sendfile”
此外Lighttpd还支持应用服务器参与的文件下载控制X-sendfile，详细的论述请看：RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能
3、文件状态缓存
Lighttpd通过stat()调用获得文件被修改的信息，来决定当请求同一个静态文件资源的时候，是否需要再次读取硬盘文件。但是每次stat()调用也有一定的开销，Lighttpd支持通过Fam Server来减少stat调用。即每次当文件被修改之后，Kernel会发送一个消息通知Fam Server，而Lighttpd会通过进程间通讯连接Fam Server，可以知道文件是否被修改的信息，不必再每次调用stat()。
引用
server.stat-cache-engine = “fam”
4、限定POST Size
为了避免黑客恶意的攻击服务器，伪造超大Post数据包轰炸Web服务器和应用服务器，可以限制Request请求的大小，例如限制为10MB：
引用
server.max-request-size = 10240
5、日志文件
Lighttpd是单进程单线程的服务器，调度网络IO性能是极高的，但是在某些极端情况下，单进程服务器也有风险，即一旦被某操作系统调用挂住，整个服务器就没有办法响应请求了。比方说服务器其他进程导致的IO WAIT很高，操作系统的buffer又不够的时候，Lighttpd在大量的写access log就有被挂住的可能性。因此如果Lighttpd日志对你的参考价值不大，可以考虑关闭掉。像JavaEye网站每天Lighttpd产生430万条log，对硬盘IO也是一个不小的负担，既然已经开着Rais的production.log，那么Lighttpd的access log没什么参考价值了，那就关掉它。
Lighttpd的性能优化请看其作者写的文章：
http://trac.lighttpd.net/trac/wiki/Docs%3APerformance
三、应用服务器
Ruby的应用服务器可以使用FastCGI，或者Mongrel，如果我们使用Lighttpd的话，FastCGI是最好的搭配。
1、FastCGI和Lighttpd的通讯方式
如果FastCGI和Lighttpd是在同一台服务器，那么建议采用Unix Socket通讯，这种通讯方式比TCP要快一些，FastCGI可以通过Lighttpd自带的spawn-fcgi命令行工具启动，创建socket文件，而Lighttpd监听socket文件。如果两者不在同一台服务器，需要群集部署，那就必须采用TCP Socket通讯，方式是一样的。
2、FastCGI进程应该开多少个合适？
Rails是单进程方式运行的，理论上来说，开几个FastCGI进程，就只能并发响应几个请求。对于繁忙的网站来说，峰值期间每秒有几十个动态请求是很正常的事情，但实际上FastCGI进程并不需要开那么多。这是因为前端的Web服务器在处理用户浏览器连接，发送Request请求需要相当长的时间，在FastCGI处理完请求释放该连接以后，Web服务器还需要相当长的时间才能把页面数据完整的发送到客户端浏览器。用户在点击一个链接以后，等待1-2秒，页面内容就显示出来，这对用户的感觉来说已经是非常快的了，而FastCGI用于处理该请求可能只需要0.1秒，那么一个FastCGI进程虽然并不能够真正的并发运行，但实际上的效果是他可以在1秒之内处理10个请求，让10个用户在同时访问网站的过程当中感觉不到明显的延迟。
因此FastCGI需要开多少个，取决于你的网站峰值期间每秒有多少个用户请求过来，而你的FastCGI又能够以多快的速度处理请求。比方说你的网站峰值期间每秒有50个动态请求，FastCGI在峰值期间处理每个请求需要0.2秒，那么实际上你只需要开10个FastCGI进程就足够了，为了应付突发的峰值请求，你可以在这个计算量上面增加一些余量，比方说15-20个进程，肯定是绰绰有余了。
关于FastCGI的性能优化，可以参考Lighttpd作者的文章，虽然他是针对PHP跑FastCGI写的，但对RoR也有参考价值：
http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI
四、数据库
JavaEye网站使用MySQL5.0.XX版本，数据库引擎是InnoDB。关于MySQL数据库的调优，推荐大家看MySQL Performance Blog，作者是一个MySQL性能调优方面的专家，并且提供MySQL咨询服务。他的博客上面有很丰富的关于MySQL调优的文章和演讲文稿，特别是关于InnoDB方面，非常深入。JavaEye的数据库调优就是根据他的InnoDB演讲文稿来调整的，一般说来，有几个需要调整的参数：
innodb_buffer_pool_size
这个参数很重要，越大越好，对于专用的数据库服务器一般建议开服务器内存的50%以上。
query_cache_size
查询缓存，对于查询的性能提高有很大帮助，但不宜开得过大，查询缓存的过期可能很频繁，过大查询缓存反而降低性能，增加服务器开销
innodb_flush_method = O_DIRECT
针对InnoDB的数据文件，关闭操作系统的文件缓冲，由于InnoDB自己有巨大的Buffer Pool，操作系统对文件的读写缓冲功能反而会降低MySQL的InnoDB的IO性能。
最后针对数据库的SQL优化来说有两点原则：
1、对数据库表要适当的创建索引
特别是出现在where查询条件当中字段，和关联查询当中的外键，要高度注意。
2、尽量避免大表的全表扫描和数据库的硬盘IO
查询比较慢的SQL要explain一下，看看是否发生了全表扫描，采取各种措施减少或者避免大表的全表扫描问题，例如拆分表等等。
最后针对MySQL数据库运行情况，我们可以用show status; 和 show innodb status\G 来监测。
Rails应用程序的优化
Rails应用程序优化包括ruby解析器的优化，缓存的使用，以及应用代码级别的优化。Stefans Kaes曾经在Railsconf 2006有一个Rails应用程序优化的演讲，他的演讲PPT是极好的Rails性能优化指南，可以在这里下载:http://www.javaeye.com/topic/24508。他还编写了一个用于Rails性能测试的软件包RailsBench，大家可以参考。由于Stefans Kaes的代码优化文档已经写的非常详细了，因此我就不在一一复述，只提出几点对性能影响比较大的方面：
一、ruby解析器的优化
ruby的解析器性能是很糟糕的，ruby早期的主要用途是取代perl写批量处理的脚本的，并不是为服务器应用编写的，因此在内存分配策略上非常不适合服务器应用。Stefans Kaes编写了一个ruby GC的补丁文件，在railsbench下载包里面提供了。虽然当前Railsbench提供的GC补丁只有针对ruby 1.8.4和1.8.5版本的，但是在ruby 18,6上面使用1.8.5的GC补丁也完全没有问题。GC补丁的作用主要是针对Rails应用开大了ruby的内存堆，可以有效提高内存堆的利用率，降低GC的频率。根据Stefans Kaes提供的测试数据，打补丁并且调整参数以后，GC的频率下降到只有原来的1/10还不到。降低GC频率尽管并不能够提高单个请求的执行速度，但是可以增加整体应用的负载能力。
我们在JavaEye的服务器上也使用了GC补丁，并且根据推荐参数进行了调整。在使用GC补丁之后，Web服务器的CPU负载下降了大概15%左右，效果非常显著。当然开大内存堆的代价就是ruby进程会多消耗内存，在我们的服务器上，ruby打补丁之后多消耗了50%左右的物理内存。
二、缓存的使用
1、对象缓存
JavaEye上面关于对象缓存的讨论很多，我们也提供了JavaEye这方面很多数据，因此不展开了。RoR可以使用两个对象缓存，一个是CachedModel，类似Hibernate，比较简单，对Model的CRUD操作自动进行缓存；另外一个是cache_fu，需要自己编码来添加对象缓存，但提供了更多高级机制，目前我们使用的是cache_fu。在使用对象缓存的情况下，应该把查询方法的:include去掉，避免关联查询无法利用缓存的现象。
2、查询缓存
对于统计类耗时查询，如果不要求实时性，那么可以使用memcache-client将查询结果缓存到memcached里面，例如博客排行榜之类。
3、页面局部缓存
对象缓存和查询缓存都是降低数据库访问负载的，但如果RoR的负载很高，那么只能依靠页面局部缓存了。传统的互联网web1.0网站很流行采用动态页面静态化技术来提高网站的负载，但是对于web2.0网站来说，每个页面都带有登陆用户的个人信息，页面的很多部分需要实时更新，例如投票，点击统计，digg，显示用户在线状态等等，动态页面静态化非常困难。当然如果你非要采用动态页面静态化，技术上也不是实现不了，可以通过AJAX请求来处理静态页面的动态部分，但是这种解决方案的开发成本过高，而且性能未必会有明显的改善，大家看看新浪和搜狐博客就知道这种技术被应用的有多糟糕了。
web2.0网站比较常用使用页面局部缓存，一种情况是页面不需要实时更新的，那么只需要设置一个合理的过期时间就行了，这种情况我们目前使用的比较多；另外一种情况是虽然不需要实时更新，但是会在用户执行某些操作后需要缓存过期，比方说博客个人主页的很多页面，这种情况下缓存过期策略会比较复杂，考虑到合理的开发成本，我们尚未对这样的页面使用局部缓存。
此外，Rails的页面局部缓存有一个缺点，就是和页面查询结果对应的Action当中的查询语句要放在View里面，否则每次action里面的查询还是会被执行，但是这样做会破坏程序代码良好的MVC结构。这种情况下，也可以采用另外一个Cache插件: better rails caching，在缓存页面的同时可以缓存Action当中的查询语句。
三、应用代码的优化
Stefans Kaes的文档里面对应用代码的优化进行了非常详细的介绍，因此我这里只提两个比较重要的注意事项：
1、link_to
Rails的link_to是非常慢的，它的代码实现过于复杂，特别是Rails1.2引入了REST以后，大量的命名路由被使用，这些命名路由还需要通过一次method_missing，那就更加缓慢了。因此对于被频繁使用的内部URL地址，一定要自己用字符串拼接方式改写，可以很明显提高View的render性能。此外类似的helper还有很多，例如button_tag，image_tag啥啥的，如非必要，尽量不用他的helper
2、正则表达式
ruby的正则表达式也是极慢，例如auto_fix这个helper的正则表达式就比较复杂，造成的结果就是一但大量使用auto_fix，View的render就明显变慢，类似依赖正则表达式进行字符串过滤的helper有很多，如果需要频繁大量使用，请先自行做benchmark。
Rails应用程序的内存泄漏问题和解决
内存泄漏是服务器端程序经常遇到的，有时候内存泄漏问题会让人很头疼，总体来说，Rails的内存泄漏问题比Java要少得多，这是因为Java内存泄漏最常见的三种情况在Rails当中不存在：
1、HttpSession导致的内存泄漏
Java程序员喜欢往session里面丢很多东西，最糟糕的是竟然有很多框架软件也肆无忌惮往session里面丢状态数据，但Rails的session是不放在内存里面的，所以无此烦恼。
2、数据库连接释放不彻底
Java的数据库连接池释放不彻底，以及查询游标释放不彻底，都必然导致内存泄漏。Rails没有数据库连接池，而是每个进程持有一个长连接，因此不存在这个问题，而且由于持有长连接，也不存在Java里面的OpenSessionInView的烦恼。
3、用静态变量持有全局共享数据
Java程序员很喜欢通过静态全局变量来持有共享数据，但共享数据忘记清理的话，也很容易导致内存泄漏，Ruby是SNA架构，多进程服务器模式，进程间无法共享数据，反而避免了全局共享数据带来的麻烦。
但是Rails应用有一种情况：在Ruby代码中调用C写的第三方ruby类库的时候，很容易导致内存泄漏，但这种内存泄漏反而在Java中极其罕见。Ruby本身有GC来管理内存堆，但是代码一旦调用C写的第三方ruby类库，内存堆的分配权就掌握在第三方C库的实现上面了，如果这个C库的代码质量不够好，内存泄漏就不可避免。由于ruby本身性能很差，因此计算量大的功能往往依赖底层的C库来实现，这下内存泄漏的潘多拉魔盒就打开了！而Java性能比较好，功能都是纯Java编写，基本上看不到需要依赖第三方C库的情况，因此比较安全。
JavaEye也面临着内存泄漏的困扰，这方面困扰主要来自于Rmagic。Rmagick调用ImageMagick的C库来完成图片的操作，从我们的监测来看，RMagick大多数情况下会缓慢的泄漏内存，在某些特定的图片操作上会急剧的泄漏内存。解决办法就是用mini_magick替代Rmagick，mini_magick是直接调用ImageMagick的mogrify命令，另起一个进程来操作图片，操作完进程就结束了，绝无后患，由于Linux的fork进程开销不大，因此也不必担心性能问题。
此外，调用第三方C库的ruby代码编写都需要高度小心，比方说JavaEye使用ferret实现全文检索，根据应用的需要调用ferret的API来编写自己的analyzer，其中在实现token_stream方法上面使用了XXXAnalyzer.new和XXXToken.new，XXXFilter.new，结果内存急剧泄漏，经过检查发现是Analyzer对象不能被反复创建，改成创建后缓存该对象就好了，但是Filter和Token对象却必须每次创建，此外ferret的PerAnalyzerFilter也有内存泄漏问题。由于类库是用C编写的，单纯看API文档或者看源代码片断一般无法判断出里面的内存泄漏陷阱的。
当遇到了难以解决和定位的内存泄漏问题，Ruby也有类似Java的内存Profiler工具：
1、Memory Profiler
一个纯ruby编写的内存探测器，原理很简单，就是用ruby的对象引用计数器ObjectSpace.each_object去遍历内存堆中的每个ruby对象，进行统计和分析。用起来很简单，非常适合于开发环境下侦测内存泄漏问题，但不能用在生产环境下，极度影响Rails性能。
2、Bleak_house
Bleak_house给Ruby解析器打了补丁，插入相关的指令，可以从底层探测整个ruby内存堆中对象的情况，然后你可以定期dump出来完整的内存堆里面的所有对象，再用bleak工具去分析dump文件，他比上面的工具分析的信息要全面，可以在测试环境和预发布环境下使用，但在生产环境下，也会对应用的性能产生很大的影响，要慎用。
JavaEye网站在RoR性能方面的经验就全部分享给大家了，也希望做RoR的朋友都拿出来自己的经验和大家分享，共同学习和促进RoR的应用和普及。
(图1)
（图2）
(图3)
）
