锁定老帖子 主题:关于rails大容量网站部署的性能讨论
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-05-14
单台服务器的性能也不会有太大的问题
我们的单物理CPU服务器一般都配备8GB内存,双路SMP的就有16GB内存,Optron处理器在Linux内核不优化的情况下已经能满足生产系统的要求。 现在的服务器那怕只是PC服务器,性能都已经相当了得。 |
|
返回顶楼 | |
发表时间:2007-05-18
如果早点看到这个帖子就好了,我也不会走了那么多弯路,结果还造成群集经常宕机。我采用的是weblogic群集,session复制,结果太惨了。
|
|
返回顶楼 | |
发表时间:2007-05-24
这个"无共享架构"设计,只能解决中型系统的性能瓶颈.对于大型系统,真正的瓶颈是数据库,如何做好"分库,分表",尤其是"分库",是真正解决大型系统架构设计的核心(无论是性能还是扩展性方面)是重中之重!
|
|
返回顶楼 | |
发表时间:2007-06-24
robbin 能否将你在部署开发中累计的经验写一本书?
|
|
返回顶楼 | |
发表时间:2007-06-28
taobao是完整基于java的,session复制是很不明智的做法,大型站不可能采用软集群的,所以taobao一直是cookie session的;至于序列化SUN做得不是很好,对于Bean的序列化hessian表现要好一些, 但在一些特殊的对象,如String...SUN的表现还是不错的
|
|
返回顶楼 | |
发表时间:2007-06-28
对于taobao这种规模的网站,瓶颈不仅仅是session复制了,还有cache的问题吧?
|
|
返回顶楼 | |
发表时间:2007-06-28
restart 写道 使用JMeter,在Spring+Hibernate+MemCached的框架下粗略测试了一下
硬件: 2台服务器,一台跑Resin,一台跑memcache CPU: Intel(R) Xeon(TM) CPU 2.80GHz * 2 内存: 2G 结果如下(读操作): 300个并发(循环3次): 平均相应时间是5099ms 200个并发(循环3次): 平均相应时间是3542ms 100个并发(循环3次): 平均相应时间是2070ms 测试同样的页面,改为ehcache 300个并发(循环3次): 平均相应时间是2679ms 这个数据有点夸张,不知道是java效率慢还是你的程序有问题 我们有几十G的memcached cache,用来存放文件cache,基本响应速度都是在100ms以内的,单进程连接数是300-400个 不过我们的程序都是c++ |
|
返回顶楼 | |
发表时间:2007-07-19
fustic 写道 restart 写道 使用JMeter,在Spring+Hibernate+MemCached的框架下粗略测试了一下
硬件: 2台服务器,一台跑Resin,一台跑memcache CPU: Intel(R) Xeon(TM) CPU 2.80GHz * 2 内存: 2G 结果如下(读操作): 300个并发(循环3次): 平均相应时间是5099ms 200个并发(循环3次): 平均相应时间是3542ms 100个并发(循环3次): 平均相应时间是2070ms 测试同样的页面,改为ehcache 300个并发(循环3次): 平均相应时间是2679ms 这个数据有点夸张,不知道是java效率慢还是你的程序有问题 我们有几十G的memcached cache,用来存放文件cache,基本响应速度都是在100ms以内的,单进程连接数是300-400个 不过我们的程序都是c++ 引用 没理解。 按照robbin的方案,浏览器端是不知道访问了clone1还是clone2的,而且部署在clone1/clone2上的程序也不知道自己是部属在哪个节点上的,而且,这个程序也不应该为了群集而作特别的处理。 另外,浏览器得到的域名都是前端分发请求的那个服务器的域名。这样,实际上这些cookie都保存在一个cookie文件(文件名应当是域名)里面,而且,因为tomcat的sessionid用的是同一个名字,好像都是jsessionid吧,域名和路径也必然是一样的,按照RFC2109 我弄错了,好像是有问题。 两个tomcat会生成相同的cookie,域名,路径都相同,cookie的名字也一样 |
|
返回顶楼 | |