淘客熙熙

主题:【建议】谈谈西西河的稳定性问题 -- 兼答雪个 -- Highway

共:💬15
全看树展主题 · 分页首页 上页
/ 1
下页 末页
家园 【建议】谈谈西西河的稳定性问题 -- 兼答雪个

前一段西西河不太稳定,原因现在基本上明白了。那就是服务商给西西河的连接数作了限制。其原因大概是西西河流量过大,可能影响了其他一些网站的运行。

经过铁手的努力,www.cchere.net在另外一处开通了。虽然服务商还没有对我们做出任何限制,但西西河另外一个问题暴露出来了,那就是稳定性。我没有Run 任何Benchmark程序,无法定量的指出问题,但就雪个斑竹以及其他一些朋友的观察,西西河上线人数超过400后,系统就感觉不太Smooth了,严重时西西河还会短时间瘫痪。对于大家来说,这是一个稳定性的问题,但导致西西河不稳定的原因却可能是的可扩充性问题。IT界叫做 Scalability.

今天茶博士在给铁手的建议中提出,把西西河划分成几个部分,让其他人在别处Host西西河的一些版面。茶博士的建议非常好,深合IT界最流行的分布式计算的思想(Distributed Computation)。微软所谓的Web Farm, Web Garden以及Server Cluster就是这么个意思。但是分布式计算并不是可以简单应用到每一个程序上的。比如说茶博士在美东Host性感世界,文化百家,铁手继续Host其它版面。这样的方案面临的问题就是如何Share 数据库。通过Internet Share Database 基本是不太可行的,因为那样速度会很慢;如果每个网站各运行一套数据库,那么西西河的许多功能就不工作了,比如文章查询,用户积分统计等等。甚至于你要在两处分别登陆才行。

Share Nothing的程序是最容易使用分布式计算的。像西西河这样中心数据库驱动的网站就不太容易。可行的方案是使用多台Web Server,让这些Server共同分担负载,或是每一个Server负责一部分版面,这些Server通过高速网络和数据库Server紧密连接,共享一个数据库。

文学城基本上是这种结构。他们有一批Web server,IP 地址从66.166.3.21到66.166.3.34。每一个IP对应的Web Server负责一个或几个板块,后台的数据库和这些Web Server相连。这是一种静态(Static) 的负载分担技术,比较简单,容易操作。但缺点也是明显的,比如有一天“几曾回首”突然人满为患,对应的Web Server忙不过来,而其他的Server却帮不上忙,虽然他们当时无事可做。不管怎么说,这种方法使得文学城还能基本应付现在的荷载。

这种方案的假定是现在的扩充性瓶颈是Web Server,而不是Database Server。如果Database Server成为了扩充性的瓶颈,那么我们可以再讨论如何扩充Database Server的性能(Optimizing Index,Using Stored Procedure, Partition Table and so on)。

以上谈论的Scalability的方案叫做Scale Out。另外一种方案做Scale Up。那就是根据系统瓶颈,升级相应的部分。比如增加Server的CPU,增加内存,升级硬盘子系统等等。

这两种方案对于铁手来说有一定的困难。因为我们请别人Host我们的网站,我们无法在硬件设置上提出要求。直到我们有了自己的Server群,我们才可能实现这些想法。这可能是铁手提出资金问题的最主要原因吧!

除去升级/更改硬件设施外,软件上我们还是有一些潜力可以挖掘的。比如说,

1)使用最新的IIS 6.0来Host我们的网站。IIS 6.0和以前的5.0/4.0相比,在体系结构上有很大的突破。服务更加可靠,跟安全,管理的功能更加丰富,性能上也有较大提到。它可以Host 传统的ASP网页,更可以Host最新的ASP.NET网页。铁手可以努力寻找有这样能力的服务商(Windows 2003 上运行的就是IIS 6.0)

2)逐渐从ASP向ASP.NET转移。现在的网页是内嵌VBScript /Jscript的ASP Page,已经是比较过时的技术。如果可能的话,今后要向.NET转移。和ASP相比,ASP.NET的优势是压倒性的。Full-Blown的OO开发语言,强大的开发调试环境,服务完善的Runtime,强大而且灵活的Page Cache能力。。。如果铁手对西西河有长远打算的话,升级到ASP.NET是早晚的事。新的ASP.NET 2.0支持用户端自定义Skin和Theme,那就是说每个西西河的朋友可以按照自己的口味设计自己的西西河,就像现在每个人可以自由变更自己的Windows的Theme一样。

3)如果可能的话(眼下的权宜之计),可以把VBScript里面的一些费时的操作拿出来放到VB里,编译成COM Object。然后在VBScript里面调用 COM。这样做的性能要比纯ASP好不少。如果愿意的话,可以进一步把它写成COM+ Object,这样管理和发布起来会更方便一些,资源的利用上也会更好一些。

我这里已经是半夜2点了,就先写到这里了。如果明天想起来什么再补充!


本帖一共被 2 帖 引用 (帖内工具实现)
家园 向highway致敬!
家园 老轧和老铁,请估计一下配置以后发展也可以SCALABLE的硬件软件的费用,

还有日常维护需要的人员配备。俺们好计算资金流。

家园 你说和数据库有没有直接的关系呢?

我看了错误信息,好像是超过了MYSQL的最大值。MYSQL应该是承受不了太大的负荷的,换上SQL SEVER or ORACLE会不会好一点。或者这个最大值是由ISP设定的?

家园 数据库可能是一个问题。

理论上讲,MySQL不应该设定最大连接数量(SQL, Oravle等可能受购买的License的限制)。并且ASP的程序在读写完数据库后,马上关掉了接数,而IIS Web Server又采用了Thread Pool,在每个时间内不会有很多的Working Thread(缺省好像是5)在运行,那就是说每个时间内不会有超过5个的数据库连接。当然这是理想情况,实际上可能要有一些不同。

MySQL我没有用过,不知道它在这种负荷下的可靠性和性能如何。另外,ASP访问MySQL的ODBC或是OLE DB的驱动程序也可能造成一些问题。第三方的产品总是或多或少的和微软的东西有兼容性的问题。我建议使用 MS SQL 2000,如果可能的话。

家园 容我想想!
家园 虽然我看的似懂非懂,还是要向你致敬!!
家园 救星啊。不懂ASP.NET。转换起来不知道难不难?

数据库的链接方面应该不是个大问题。昨天的情况是服务器上的数据库有些问题,后来服务商重起了系统,就好了。

问题好像是在于ASP的效率。估计直接用HTML应该会好些。现在正在考虑把帖子内容放到HTML里去,看贴的时候,ASP,MYSQL相对的负担可能要小一些。

同意关于分布式数据库的问题。除非是有自己的专门服务器的话,可以考虑,否则的话,太动干戈,就目前看,意义不大。

我最近在想php+mysql的方式。不熟悉。不知道可行不可行?听人说好像PHP+MYSQL应该是不错的组合,而且,LINUX的空间相对要便宜很多:)

家园 向我致敬?Are you kidding me?
家园 php+mysql+Linux+Apache是比较流行的一种组合,优点是便宜,有不少现成的Code可以使用

缺点是你要熟悉这些技术。

熟悉ASP的程序员过渡到ASP.NET不是一个太大的问题。你可以到WWW.ASP.NET去看看。那里有不少免费的东西可以下载(包括Souce Code和文档介绍)

ASP.NET 2.0刚刚出炉,你可以上网看些介绍,结合西西河的具体情况,看看是否有启发!

家园 你分析的精彩啊,佩服

我是半瓶醋瞎建议,你是真懂,好啊。

家园 后悔没学计算机!每个字都看懂了,每句话都是天书啊
家园 【建议】Hightway 同学担任西西河CTO

写得清楚。

家园 嘿嘿,网管的救星,你真牛啊。

你还不借机向铁手要个认证会员?

顺便把我也带进义事厅。

家园 No. I am serious..
全看树展主题 · 分页首页 上页
/ 1
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河