主题：【建议】谈谈西西河的稳定性问题 -- 兼答雪个 -- Highway
家园 【建议】谈谈西西河的稳定性问题 -- 兼答雪个 前一段西西河不太稳定，原因现在基本上明白了。那就是服务商给西西河的连接数作了限制。其原因大概是西西河流量过大，可能影响了其他一些网站的运行。
经过铁手的努力，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 帖 引用 (帖内工具实现)家园 【建议】Hightway 同学担任西西河CTO 写得清楚。
家园 后悔没学计算机！每个字都看懂了，每句话都是天书啊 家园 救星啊。不懂ASP.NET。转换起来不知道难不难？ 数据库的链接方面应该不是个大问题。昨天的情况是服务器上的数据库有些问题，后来服务商重起了系统，就好了。
问题好像是在于ASP的效率。估计直接用HTML应该会好些。现在正在考虑把帖子内容放到HTML里去，看贴的时候，ASP，MYSQL相对的负担可能要小一些。
同意关于分布式数据库的问题。除非是有自己的专门服务器的话，可以考虑，否则的话，太动干戈，就目前看，意义不大。
我最近在想php+mysql的方式。不熟悉。不知道可行不可行？听人说好像PHP+MYSQL应该是不错的组合，而且，LINUX的空间相对要便宜很多：）
家园 虽然我看的似懂非懂，还是要向你致敬！! 家园 你说和数据库有没有直接的关系呢？ 我看了错误信息，好像是超过了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,如果可能的话。
家园 老轧和老铁，请估计一下配置以后发展也可以SCALABLE的硬件软件的费用， 还有日常维护需要的人员配备。俺们好计算资金流。
家园 容我想想！
家园 向highway致敬！
