关于rails大容量网站部署的性能讨论

因为情况比较特殊,存储的数据不量大,也不是很复杂,有一个用C做的数据存取层,web那边直接就用socket进行连存接取数据,所以对web服务器来说,就没有了数据库存取,也确实是没用传统的CGI

puzzle
就是说memcached只能在一个jvm中了（而不是多个jvm或者多个机器）是吧？

如果那个memcached也掐不住了那就整个系统就over了是吧？（不过就读和写2个操作应该很坚固）

访问memcached要跨越jvm或者访问其他机器，是否意味着单次访问变慢（相对与inside jvm）？

我对提高单个机器的性能比较感兴趣，如果能不引入新的接口更好：
比如一个web srv使用memcached作为集群的实现手段，应用程序只要使用servlet和“无共享架构” 就可以实现scalable。

使用“无共享架构”对现有的web app有什么影响？设计新的系统需要注意什么呢？？？
比如使用ww2和hibernate已经很熟练了

持久层就要重新写一下，对测试的影响是非常大的，是不是就是说这种极端方法只要一两个地方用就够了？

你咋不自己看看memecached文档就在这里瞎猜呢

其实单次访问变慢是肯定的。而且这个可靠性可能还不如zzsczz说的使用单一服务器。它通过hash方式把数据分散保存到不同服务器上，其中的任意一台服务器宕掉(或者更恶劣的是出于半拒绝服务状态)，都会对cache产生很大的影响(宕掉的还好，如果是半拒绝服务状态，那么几乎每次该服务器的cache访问都需要达到cache的超时状态才结束)。
除非它有cache的raid或者多级hash.
所以它自己也说是缓存数据库访问的，和本机访问比，在性能上肯定会有不足。不过，基本上全局变量是很少的，而且访问也不会很频繁，这个问题应该不大。

是有这个问题的，我是想找一些比较通用的解决方式，不然自己定义缓存的内容，直接找一台机器，做专门的缓存层，后面的web服务器直接到这个缓存服务器搜索。只要内存大，加上一些其他的优化手段，缓存服务器的性能和安全性会更好。但这样的话，每次都要重新设计缓存，而且，我觉得，缓存这个东西，以后再替换也不是不可以的，所以找一个容易插拔更换的现成缓存产品比较经济

当时已经在梦中，只能瞎猜鸟。
早上起来啃文档，又是鸟语啊。
窝中一日，世上已千年。哎，跟着爬啊爬，不过这么高端的方案先看看。。。。。。。

我已经用lighthttpd(mod_proxy) + tomcat搭建了一个按照上面部署方案的群集环境，failover已经可以了，但是loadbalance还有问题。还在熟悉lighthttpd中...

我现在是安装tomcat5.5.17，配置apr，然后把配置文件拷贝出来做了两个clone，clone1跑8081端口，clone2跑8082端口。然后lighthttpd跑80端口，配置mod_proxy将请求分发到8081端口和8082端口。测试了一把failover，第一次请求503，再刷新的时候就切换到另外一个clone上面了，balance好像还不行。

感觉lighthttpd速度真的很快啊，明显比apache快很多。

其实，不管使用任何技术，解决web的性能问题有一个方法是最好的，cookie，当然，缺点也不用说了。

做项目，能要求客户环境的，那cookie绝对是最好的方式。
即使是运营网站，我觉得，现在也极少人会不使用cookie——主要是浏览器默认打开了，很少人会刻意去修改这个设置，应该没有太大的问题。

呵呵，我现在设计的网站部署方案几乎就是照抄rails的群集部署方案：

lighthttpd作为web proxy，兼有处理静态资源(js，css，images)，页面cache，和loadbalance/failover的功能(如果不是为了failover，我直接用iptables进行端口转发是速度最快的loadbalance)；

后面n个tomcat clone来处理业务，不使用Hibernat二级缓存，用户ID使用cookie，不在session里面保存和标示状态，因此tomcat clone的数量可以近乎无限扩展。

memcached用来作为全局共享变量的holder，在spring里面配置一个bean去封装对memcached的访问，这样访问memcached的全局共享变量和过去访问JVM内部的全局共享变量的方式从编程接口上来说就根本没有任何区别了，桀桀。

好完美的一个群集部署方案啊，谁来挑挑刺？

文件共享系统和数据库集群没有谈到怎么做...