Discuz!稳定性

有个很哲理的话：复杂的系统，稳定性必然下降。Discuz!的插件制作人员参差不齐。很容易导致Web服务死掉。

而且通常毛病出在频繁的读取数据库，导致连接数过大。
最近woodk总是访问不上，也不是特别清楚具体的原因。
从昨天装上Google Analytics开始分析数据量，并且查看系统错误日志。
大体定位在RSS在升级的时候出现错误，还有就是PLUGIN的问题。

刚才关了论坛的RSS功能。先看看是不是不会无缘无故死了。

另外，发现APM-Server这个东西太复杂了。可能APM-Express的稳定性更加高，再挂就换APM-Express了。坚信简单即稳定。

Ruby Deployment and Scaling

Rails的部署与伸缩

在Rails发布的时候，选择发布平台是开发人员关心的问题。Rails可以在很多Web服务器上运行，只要实现了CGI协议的Web服务器都可以，这是Rails的最低。

　　　　　　　　容易部署　　　速度　　　　伸缩
WEBrick　　　　★★★★★　　★★　　　　　★
Apache-CGI　　　★★★★　　　★　　　　　★★
Apache-fcgi　　　　★　　　　★★★★　　　★★★★
lighttpd-fcgi　　　　★★　　★★★★★　　★★★★★
(上图来自应用Rails进行敏捷Web开发　P22 各种部署选择比较)

虽然没有提及IIS，不过肯定也有模块可以在上面跑。

优化考虑：
lighttpd:占用，轻量级。建议只在上面提供图片，JavaScript，样式表，中等规模的文件下载以及其他静态的页面。但不建议存放至关重要的数据，因为lighttpd据说存在一些严重的稳定性问题，在进行大量文件传输时候也有问题。

案例:rapidreportig.com压力测试

Rapid Reporting 将他们的“身份及收入验证 引擎”运行在Rails系统上。美国1000强的抵押担保商有80%都使用这套引擎，每月处理2百万次抵押申请交易。

一开始，，Rapid Reporting希望检验Rails是否能够胜任，因此他们从10台集群机器向一个应用程序进行压力测试，每秒3千次请求。真是的应用程序大概需要每秒300次请求，并执行一系列的业务逻辑。因此，处理抵押业务必须遵循GLBA，因此很多地方都需要检查授权许可、生成查账索引。

应用程序使用PostgreSQL作为数据库，lighttpd作为web服务器，每台应用服务器运行大约10个FastCG进程，在一台虚拟服务器上用IP隧道技术实现负载均衡。使用这种部署方式，就可以随时增减FastCGI进程，而不必重启web server。由此又可以实现进程管理的自动化：用一个守护进程监视负载情况，当负载达到峰值时分配更多的FastCGI进程。