浏览 3061 次
|
锁定老帖子 主题：对一篇关于RoR部署方案文章的疑问
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-01-16
仔细阅读了"RoR部署方案深度剖析"这篇文章，个人觉得有必要推荐大伙去阅读另一个Robin的一篇文章“对一篇关于RoR部署方案文章的疑问”
Robin Lu 写道 从昨天的log来看,财帮子”200 OK状态的Ruby动态请求”在一百九十万以上,如果按照那篇文章中提到的javaeye的”70万200 OK状态的Ruby动态请求”,应该是javaeye的两倍以上,接近三倍的样子.
"RoR部署方案深度剖析"这篇文章似乎闭贴了，只有另开一贴发出来。 PS: 财帮子对其部署方案透露得似乎不多，可惜了。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2008-01-16
石锅拌饭 写道 robbin 写道 Apache/Nginx的接收缓冲区都只开了8KB，如果页面比较大，Mongrel就没有办法一次性把数据全部推给Web服务器，必须等到Web服务器把接收缓冲区的8K数据推到客户浏览器端以后，清空缓冲区，才能接收下一个8KB的数据。这种情况下，Mongrel必须和Web服务器之间进行多次数据传输，才能完成整个Web响应的过程，显然没有一次性把页面数据全部推给Web服务器快。
只有几个问题,application layer的读缓存和读的次数是否影响到socket另一端写socket的次数的? 写socket的次数是否和另一段socket read的次数对应? Web服务器向到客户端socket的写操作在什么情况下会被阻塞? 文中的一些观点和说法好像多少混淆了应用层和传输层的概念. 其实他没有理解我要说的意思。Mongrel在这种情况下并不会被阻塞住，因为Mongrel在执行完Rails实例以后就解锁了，但是Mongrel当中有n个用户线程在切换，每个线程持有一个StringIO对象正在执行write操作。如果Mongrel连接Lighttpd的话，StringIO的write操作一下就执行完了，该线程就结束掉了。但是Mongrel如果连接Apache/Nginx的话，write操作就会一直等下去，那么Mongrel里面就会有很多这样的线程来回切换，那么你说哪个速度快？哪个开销大呢？ 石锅拌饭 写道 robbin 写道 我们假设使用服务器端程序控制带权限的文件下载，某用户下载的是一个100MB的文件，该用户使用了多线程下载工具，他开了10个线程并发下载，那么每个线程Mongrel在响应之后，都会把整个文件读入到内存的StringIO对象当中，所以总共会创建出来10个StringIO对象保存10份文件内容，所以Mongrel的内存会一下暴涨到1GB以上。而且最可怕的是，即使当用户下载结束以后，Mongrel的内存都不会迅速回落，而是一直保持如此高的内存占用，这是因为Ruby的GC机制不好，不能够及时进行垃圾回收。
Mongrel处理rails request和静态文件使用的是不同的handler.处理静态文件用的是DirHandler,DirHandler没有通过调用response的 start方法使用到StringIO,而是直接调用了response的send_file方法,直接write socket.验证过程非常简单,自己起一个mongrel,在public下放一个100M的文件,通过浏览器下载一下.在我的mac上,本来是76M 的mongrel,在下载结束后是74M,下载过程中也一直小于80M,最低到过68M.无论是过程中还是结束后,都没有出现占用内存暴涨的现象. 他显然没看我的这段话的前提条件： 使用服务器端程序来控制带权限的文件下载，关于这个问题的详细论述，请看RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能，他反驳的的事情和我原文说的事情根本就不是一码事。 石锅拌饭 写道 首先,我不太赞同复杂的就好,简单的就不专业这样的观点,Unix philosophy也不是这样的.其次,mongrel也不是mongrel_rails start就能部署到产品环境的.
这话说的有点莫名其妙， 我只说过大多数人更喜欢简单的方式，而不愿意尝试复杂的方式，怎么就引申到我认为简单的就不专业上来了？ 至于后面这句话我就更不明白想说啥了。 |
| 返回顶楼 | |
|
发表时间：2008-01-16
myxex 写道 仔细阅读了"RoR部署方案深度剖析"这篇文章，个人觉得有必要推荐大伙去阅读另一个Robin的一篇文章“对一篇关于RoR部署方案文章的疑问”
Robin Lu 写道 从昨天的log来看,财帮子”200 OK状态的Ruby动态请求”在一百九十万以上,如果按照那篇文章中提到的javaeye的”70万200 OK状态的Ruby动态请求”,应该是javaeye的两倍以上,接近三倍的样子.
"RoR部署方案深度剖析"这篇文章似乎闭贴了，只有另开一贴发出来。 PS: 财帮子对其部署方案透露得似乎不多，可惜了。 其实性能优化方案无非就是那些大家都知道的方面，例如缓存，代码优化等等，推荐你看看这个： http://www.iteye.com/topic/24508 |
| 返回顶楼 | |
