<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Shining Ray &#187; 论文</title>
	<atom:link href="http://shiningray.cn/category/papers/feed" rel="self" type="application/rss+xml" />
	<link>http://shiningray.cn</link>
	<description>一缕阳光</description>
	<lastBuildDate>Mon, 21 Jun 2010 07:11:46 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>浅析Ruby on Rails部署方案</title>
		<link>http://shiningray.cn/ruby-on-rails-deployment-schemes.html</link>
		<comments>http://shiningray.cn/ruby-on-rails-deployment-schemes.html#comments</comments>
		<pubDate>Wed, 30 Apr 2008 06:24:34 +0000</pubDate>
		<dc:creator>ShiningRay</dc:creator>
				<category><![CDATA[解决方案]]></category>
		<category><![CDATA[论文]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[ruby]]></category>
		<category><![CDATA[部署]]></category>

		<guid isPermaLink="false">http://shiningray.cn/?p=170</guid>
		<description><![CDATA[2006初，我接到了公司分配的一个遗留项目，让我负责一个基于C/S的系统的服务器端。其实是系统是基于HTTP协议的，因为负责客户端的同事对于服务器端编程不甚了解，虽然使用PHP对熟悉C＋＋的他来说是驾轻就熟，但是在进一步实现更多的功能和更高的性能上就捉襟见肘了。项目是在非常突然的情况下交给我的，因为该同事在客户端上有更多的事情要做。我在分析了他的数据库结构和PHP源代码之后，决定按照与客户端的通讯协议重写他的服务器端。为了能应付老板苛刻的时间限制，我打算使用正在学习的Ruby on Rails。后来，项目在功能上非常顺利地交付了。 两年过去了，随着客户端数量的不断增加、客户端功能的增加、与服务器端交互数据的增加、老板对功能的要求不断增加，我在这个项目上走了不少弯路，尤其是在部署——或者说是架构——方面。 我遇到的最大的问题就在于并发链接数上。服务器与客户端的每次交互的数据量并不大，但内容无法缓存。起初用的是Nginx/Apache+Mongrel 的部署方式，但当遇到大量并发请求时，常常会遇到Mongrel进程死掉的情况。而客户端的用户在无法登录客户端的时候，经常会反复尝试，加重了服务器的负担、导致最后所有的Mongrel进程都挂掉。 最后，经过不懈努力，在现有的3台低端服务器上，可以满足每天500万次的请求。在这里，我将我的一些心得和研究成果总结出来，与大家分享。 文档地址：http://docs.google.com/Doc?id=ddcvzh74_28f9xppqfh 文章发布在Google Docs上，欢迎大家在其上做批注，有意见和建议也可以在此留言。文章按照知识共享“署名 3.0 中国大陆”许可协议发布，欢迎转载。]]></description>
			<content:encoded><![CDATA[<p>2006初，我接到了公司分配的一个遗留项目，让我负责一个基于C/S的系统的服务器端。其实是系统是基于HTTP协议的，因为负责客户端的同事对于服务器端编程不甚了解，虽然使用PHP对熟悉C＋＋的他来说是驾轻就熟，但是在进一步实现更多的功能和更高的性能上就捉襟见肘了。项目是在非常突然的情况下交给我的，因为该同事在客户端上有更多的事情要做。我在分析了他的数据库结构和PHP源代码之后，决定按照与客户端的通讯协议重写他的服务器端。为了能应付老板苛刻的时间限制，我打算使用正在学习的Ruby on Rails。后来，项目在功能上非常顺利地交付了。</p>
<p>两年过去了，随着客户端数量的不断增加、客户端功能的增加、与服务器端交互数据的增加、老板对功能的要求不断增加，我在这个项目上走了不少弯路，尤其是在部署——或者说是架构——方面。</p>
<p>我遇到的最大的问题就在于并发链接数上。服务器与客户端的每次交互的数据量并不大，但内容无法缓存。起初用的是Nginx/Apache+Mongrel 的部署方式，但当遇到大量并发请求时，常常会遇到Mongrel进程死掉的情况。而客户端的用户在无法登录客户端的时候，经常会反复尝试，加重了服务器的负担、导致最后所有的Mongrel进程都挂掉。</p>
<p>最后，经过不懈努力，在现有的3台低端服务器上，可以满足每天500万次的请求。在这里，我将我的一些心得和研究成果总结出来，与大家分享。 </p>
<hr />
<p>文档地址：<a href="http://docs.google.com/Doc?id=ddcvzh74_28f9xppqfh">http://docs.google.com/Doc?id=ddcvzh74_28f9xppqfh</a></p>
<p>文章发布在Google Docs上，欢迎大家在其上做批注，有意见和建议也可以在此留言。文章按照<a href="http://creativecommons.org/licenses/by/3.0/deed.zh">知识共享“署名 3.0 中国大陆”许可协议</a>发布，欢迎转载。</p>
]]></content:encoded>
			<wfw:commentRss>http://shiningray.cn/ruby-on-rails-deployment-schemes.html/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>
