转http://www.cnblogs.com/WizardWu/archive/2009/09/22/1571499.html 我先前曾写过三篇有关网站系统、ASP.NET 性能优化的文章,分别从 SQL 语句、数据库设计、ASP.NET 功能、IIS 7 的套件,来探讨此一性能议题。本帖算是系列作的第四篇,整理了一些我看过的书籍和文章,改从「负载均衡、服务器架构、数据库扩展」的角度,提出一些性能优化的建议,以供有建设中大型网站需求的网友们作为参考。 小弟我先前写过的三篇帖子: (一) 30 分钟快快乐乐学 SQL Performance Tuning (二) 网站性能越来越差怎么办? (三) 用 IIS 7、ARR 與 Velocity 建设高性能的大型网站 ----------------------------------------------------- 1、Web Server 与 DB Server 分离 小型网站或 B/S 项目,因同时在线人数不多,尚可让同一台物理主机,既做 Web Server,又做 DB Server。但此二者皆会占用大量的 CPU、内存、磁盘 I/O,最好让二者分别用不同的服务器主机来提供服务,以分散压力、提高负载承受能力。此外,二者若在同一网段,应尽量用内网 Private IP 进行访问,而不要用 Public IP 或主机名称。 基本上跑 Web 上的应用程序,不管用什么软、硬件,同时处理多个用户的 request,通常都比较消耗 CPU;但对数据库而言,CPU 就不见得会大量消耗,而是内存和磁盘 I/O 用得比 Web Server 多。因此一般建议 Web Server 用普通的 PC 即可,但要用好一点的 CPU;而 DB Server 就不能草率,应尽量买高级的服务器,并要有 RAID 5 或 6 的磁盘阵列 (硬件的 RAID,性能远比操作系统或软件做的 RAID 要好),并有 4 GB 以上的内存。当然如果操作系统、数据库都用 64 位版本的最好,例如升级到 64 位的 SQL Server 和 64 位的 Windows Server,这样内存都可配置到 64 GB;不过要记得,太旧的 PC,一些周边硬件的 driver 可能不支持 64 位的操作系统和软件。 如果在线人数持续增加,则可增加多台 Web Server 和 DB Server,用「服务器集群 (cluster)」、「负载均衡 (Load balancing) 集群」、「高可用性集群 High-availability (HA)」、数据库集群,以实现更大规模的分布式布署。 Deployment Plan(部署规划): Three-Tiered Distribution(三级分布)(硬件、不同主机的物理级分层): Three-Layered Services Application(三层服务应用程序)(软件、代码上的分层): Tiered Distribution(分级分布): Deployment Patterns: ----------------------------------------------------- 2、负载均衡 (Load Balance) 负载均衡技术发展了多年,有很多专业的服务提供商和产品可选择,基本上又可分为「软件」和「硬件」的解决方案: (1) 硬件: (2) 软件: 以操作系统内置的负载均衡功能来讲,Unix 如 Sun 的 Solaris 有支持,Linux 上则有常用的 LVS (Linux Virtual Server),而微软的 Windows Server 2003 / 2008 则有 NLB (Network LoadBalance)。 LVS 是利用 ipvsadm 这一个以 IP 为主的负载均衡程序,来达到让所有 TCP/IP 的通讯协议都可以进行负载均衡。由于它是 Linux Kernel 所支持,因此效率相当好,占用的 CPU 资源相当低,但缺点是 ipvsadm 无法针对 Layer 4 以上的网络 packet 数据进行分析。 至于 Windows Server 的 NLB,其原理是不论有多少台服务器,都全部共用一个「集群的 IP」,如下图 1 的 Active Load balancer,和下图 2 的 Virtual Server 1 (Web Server),以及 Virtual DB Server,依照负载均衡的类型来做分配 (Active/Active、Active/Standby、...),而用户在外面只会看到单一个 IP,至于背后有多少台服务器,用户并不需要知道 (如同 Cluster 集群和云计算的概念)。
图 2 红色箭头为 Failover 架构 (HA),其功能与 Load Balance 不同 上图 2 中,有四台 Real Server (Web Server),以及三台 Real DB Server,形成 Web 及 DB 的服务器集群 (Cluster)。我们看到最上方的 Virtual Server 1 本身不具备任何的数据服务 (如:.NET 代码、图片...等),只有一个功能,就是将用户的连线 request 请求,重新导向下方的四台 Real Server。这种利用重新导向 (director) 的方式,将服务负载分布给 Real Server 的方式,就称作 Load Balance。 现在似乎还没有一种做法,能自动计算主机的「负载」情形,例如计算 CPU 已使用多少百分比,以决定要把 request 丢向哪一台 Real Server;现在一般都还是按照轮替 (Round-robin) 的方式,或加上一些权重的设置而已。 若我们在 Server 上设置 Load Balance,且要执行 ASP.NET 程序,就要注意一个问题,就是 Session 的存储位置是在哪一台 Web Server 的内存上,以避免发生有用户表单填写得比较久,等到他提交时,已经被 Windows Server 的 NLB 将工作阶段切换到另一台 Web Server 主机上了。此时就可考虑将 Session State,改存储在 SQL Server 里。 至于用软件做的 Load Balance 其性能如何呢?基本上用软件做的,性能一定不会是 1 + 1 = 2,但通常能提高 Availability,亦即常听到的 HA (高可用性集群 High-availability),即 Failover 方式,如上图 2 的最上方,红色箭头左侧的 Virtual Server 2,是能够侦测 Virtual Server 1 宕机或无法提供服务时,自动将自己的 IP address 取代 Virtual Server1。因此 HA 是指提供「不会中断的服务」,而本帖讨论的 Load Balance 是指提供「能承受高度负载的服务」,两者指的不是同一件事。MIS 人员应视公司的硬件资源、成本和预算,考量是否两者都要做。
Server Clustering(服务器群集): Installing Network Load Balancing (NLB) on Windows Server 2008: Linux load balancing support & consulting: Load Balancing (WCF, 与本文无直接关系): ----------------------------------------------------- 3、展示和功能的分层 大型网站中,常会为了将来的可扩展性、源代码维护方便,而将前台的展示 (HTML、Script),和后台的商业逻辑、数据库访问 (.NET/C#、SQL),切成多层。 根据 Martin Fowler 在 P of EAA 里的說法:Layer 是指「逻辑」上的分层 (logical separation),Tier 是指「物理」上的分层 (physical separation)。若我们的 ASP.NET 站台,是用「虚拟」的分层 (N-Layer),来切开 UI - BLL - DAL,通常不会有性能上的问题;但若是用「物理」的分层 (N-Tier),亦即如上图 2 和下图 3,可能每一台 AP Server 都负责不同的商业逻辑 (销售、库存、物流、制造、会计、...),各自的源代码都存放在不同的物理主机上,且可各自独立运作,此时就要考虑到每一台 AP Server 在彼此协调合作,以及调用 Web Service (XML 的性能不佳)、执行分布式事务上的性能问题。
谈到「物理」分层上的分布式事务 (Distributed Transaction),微软的 Enterprise Services、COM+、WCF、WF 用到操作系统上的 MS DTC 来协调事务,由于 MS DTC 和这些应用程序各自处于不同的 Process,在沟通上会遇到序列化、反序列化的动作,还要整合事务中所有的 AppDomain 和不同主机上的资源,无可避免地一定会拖累性能。 Web Applications: N-Tier vs. N-Layer : ----------------------------------------------------- 4、数据大表拆分 对比较大的数据表,或历史数据比较多的数据表,可根据一定的逻辑进行拆分。若每天的数据量非常大,则可采用按日存放,再用一个「汇总表」来记录当天的一个汇总值;也可先将比较大的表拆分成多个表,再通过「索引表」进行关联处理,以避免查询大表造成的性能问题 [1]。 另也可用「表分区」的方式,将数据存储在不同的文件上,然后再部署到独立的物理服务器,以增加 I/O 吞吐,改善读写的性能。 此外,在本文的系列作「30 分钟快快乐乐学 SQL Performance Tuning」曾提过,若一个数据表的字段过多 (与刚才提的记录量过多不同),应垂直切割成两个以上的数据表,并可用同名的 Primary Key 一对多连结起来,如:Northwind 的 Orders、Order Details 数据表。以避免在访问数据时,以「集簇引 (clustered index)」扫描时会加载过多的数据,或修改数据时造成互相锁定或锁定过久。 ----------------------------------------------------- 5、图片服务器分离 对于 Web Server 来说,用户对图片的请求是最消耗系统资源的,因此可视网站的规模和项目的特性,部署独立的图片服务器,甚至多台图片服务器。 ----------------------------------------------------- 6、读写分离 同时对数据库进行「读」和「写」的操作,是非常没效率的一种访问方式。比较好的做法,是根据读、写的压力和需求,分别建立两台结构完全相同的数据库服务器,将负责「写」的那台服务器的数据,定时复制给负责「读」的服务器。 ----------------------------------------------------- 7、扩容性应对突增流量 大型网站在设计架构的时候,必须考虑到以后的容量扩充 [1]。对于活动类的网站来说,不定时的突增流量是巨大的。在网站主存储服务器上,采用配置文件形式,指定每一个存储盘柜上存储的数据文件的 ID 范围。当前台服务器需要读取一个数据的时候,首先通过询问主存储服务器上的接口,获得该数据所在的盘柜及目录地址,然后再去该盘柜读取实际的数据文件。如果需要增加盘柜,则只要修改配置文件即可,前台程序完全不受影响。 ----------------------------------------------------- 8、缓存 缓存 (Cache) 是数据库或对象在内存中的临时容器,使用缓存可大幅减少数据库的读取,改由内存来提供数据。例如我们可以在 Web Server、DB Server 之间增加一层「数据缓存层」,在内存中建立被频繁请求对象的副本,如此一来,不访问数据库也可供给数据。例如,有 100 个用户请求同一份资料,以前需要查询数据库 100 次,现在则只需要 1 次,其余都可从缓存数据中获得,而且读取速度、网页反应速度会大幅提升。 提供缓存的产品有很多种,还可分为用硬件或软件所做的缓存,如:ASP.NET 内置的缓存功能、第三方厂商的缓存套件、Hibernate 和 NHibernate 里也有 Session 和 SessionFactory 的缓存机制、Oracle 的 cache group 技术,还有我先前在「用 IIS 7、ARR 與 Velocity 建设高性能的大型网站」这篇文章介绍的,微软官方新一代的分布式缓存技术 Velocity,另外像 Proxy Server (代理服务器) 也可以作为网页的缓存: 客户端 <----> 代理服务器 <----> 目的服务器
ASP.NET 2.0 以后的缓存,最大的改变在于 CacheDependency 类已经被微软重新改写过,我们也可透过自定义类去继承它后再改写,以达成以下功能:
(4) 用程序或软件做缓存 (5) 用硬件做快取或缓冲、砸钱加装 AP Server (6) 用硬件做缓存 (cache) 回复:
----------------------------------------------------- 9、分布式系统数据结构 - 以 MySpace 为例 在网络上流传一篇很火红的文章「从 MySpace 数据库看分布式系统数据结构变迁」,内容提到 MySpace 这个大型的社区网站,使用微软平台的 Windows Server、SQL Server、ASP.NET 技术,如今每个月的用户访问量高达 500 亿,且已有 2 亿个以上的用户注册。以下仅节录该文的重点: 第一代架构 - 添置更多的 Web 服务器 从 MySpace 数据库看分布式系统数据结构变迁: ----------------------------------------------------- 参考资料: [1] 亮剑 .NET : .NET 深入体验与实战精要,第 15 章,作者: 李天平 [2] 走出软件作坊,作者: 阿朱 [3] 多本书籍、网络文件、msdn -----------------------------------------------------
|
|