网站架构调优实_点滴.docVIP

.NET平 台网站架构调优实践点滴 ? 真正的高并发高负载的架构并不是由语言来决定，到了最后都是抽象成简单的结构，最后在各个点之间取得一种平衡。文/张英刚（《程序员》2008年1月刊）《程序员》最近出版的《实战Web2.0》增刊中列出了很多关于高并发高负载的网站架构，让我们对这些知名Web 2.0网站背后神秘的架构得以一窥全豹。我们可以把这些网站（请参阅《实战Web 2.0》增刊中的国外篇）分为几个类型。虽然各个网站有些业务是重叠的，我们还是可以按照所处理的信息重心来考虑分类：视频处理：《YouTube架构》图片处理：《Flickr 架构》交易处理：《eBay网站架构》、《Amazon的体系结构》海量信息处理：《Wikimedia架构》、《Google架构》、《Digg网站架构》、《Wikimedia架构》、《Twitter的增容处理》综合类网站：《MySpace的成功秘密》、《Facebook 详解》掩卷之余，笔者试图模仿其中的结构，分享自己在日常工作中积累的经验点滴。虽然笔者只熟悉微软的.NET开发环境，也只在微软的平台下涉及到了相关的应用，但真正的高并发、高负载的架构并不是由语言来决定，到了最后都是抽象成简单的结构，最后在各个点之间取得一种平衡。本文试图结合笔者遇到的实际情况与问题，探讨如何优化.NET平台下的网站架构。背景大部分网站开发人员在很长的时间中，一直会遇到硬件资源不够，网站负载上升的情况。那么当我们使用微软的整套软件架构，在1台Web服务器、1台数据库服务器的状态下，每天到底可以承载多少页面浏览量？目前可以获得的最大数据是，百合网在系统搭建初期，每天页面浏览量达到1200万。当然，系统负载的功能不同，所能承载的量就会有高有低。根据搜狐博客开发组提供的数据，在单Web服务器单数据库的条件下，最多可以承载每天300万页面浏览量。（当前搜狐的博客流量已经超过了3000万，共有20多台服务器，主服务器有8台）。应用到具体环境中时，如何判断当前的服务器已经满负荷了？在完成下面的所有优化之后（通俗点讲就是所有的应用在单独运行的时候都很快，但是集合在一起以后，当到达最高负载的时候就会使整个系统都变得很慢的情况下），需要增加服务器。这个时候，完全没有必要重写代码，最快解决性能问题的方法就是，购买1组服务器（1台Web服务器，1台数据库服务器），Web前端做负载均衡，这时候流量就会被均匀地分配到两组服务器中，数据库方面做失败转移（fail over），就可以解决当前的性能问题。在燃眉之急解决后，当前情况下，有2种选择方案： 代码重构，拆分数据库，把访问频繁的数据库应用拆分到不同的服务器上，使用静态文件和缓存。 另外一种，既然开发组已经对所需要处理的业务非常了解，问题点也非常了解，或许可以对系统做8到10倍的预期，重新开发一套新代码。那么在这个阶段，如何优化Web服务器、数据库、代码（前端和服务器端代码），以达到能提供较高性能的状态呢?限于篇幅，本文只介绍笔者在Web服务器调优方面的心得体会。Web服务器调优1. 把不同的网站尽量分布在不同的物理磁盘上，充分利用多个磁头进行读写的能力，根据各个网站的访问频度，规划存放文件的目录，使得磁头能最大并发访问。2. 把IIS服务器的页交换文件分布到多个物理磁盘上。3. 应该将IIS服务器，设置为独立的服务器，不要让服务器去做域控制器以及数据库服务器。4. 关于日志的记录，应该采用文件记录而不是记录到ODBC数据源。5. 为了提高性能和节约资源，应该只运行需要的TCP/IPD?议。同时安装有NetBEUI、TCP/IP和IPXD?议会增加系统负担。6. 尽量使用硬件的磁盘镜像或硬件的磁盘带区集可以提高磁盘的读取性能（服务器硬件需支持）。7. 虽然SSL可以提供相当可靠的加密传输。但是所需的额外开销会导致IIS服务器速度下降，尤其是在处理大型文件的时候。所以应该只对确实需要保护的目录进行SSL加密。8. 调整 Web 服务器时应考虑的注册表项。需要重新启动 IIS 才能使新的 WWW 服务设置生效。 MemCacheSize （IIS缓存的大小）注册表路径：HKEY_LOCAL_MACHINESYSTEMCurrentControlSet?ServicesInetInfoParameters数据类型：REG_DWORD默认值：大约为可用物理内存的一半，以兆字节为单位范围：0 - 2500MB目前已经调整为 2500M（2.5G）  MaxPoolThreads （指定为每个处理器创建的 I/O 工作线程的数量，通常，每个处理器最好不要创建超过 20 个线程）注册表路径：HK