网站性能优化 - 数据库及服务器架构篇

我先前曾写过三篇有关网站系统、https://www.360docs.net/doc/0c15564116.html, 性能优化的文章，分别从 SQL 语句、数据库设计、https://www.360docs.net/doc/0c15564116.html, 功能、IIS 7 的套件，来探讨此一性能议题。本帖算是系列作的第四篇，整理了一些我看过的书籍和文章，改从「负载均衡、服务器架构、数据库扩展」的角度，提出一些性能优化的建议，以供有建设中大型网站需求的网友们作为参考。

小弟我先前写过的三篇帖子：

(一) 30 分钟快快乐乐学 SQL Performance Tuning

https://www.360docs.net/doc/0c15564116.html,/WizardWu/archive/2008/10/27/1320055.html

(二) 网站性能越来越差怎么办？

https://www.360docs.net/doc/0c15564116.html,/WizardWu/archive/2009/01/03/1367527.html

(三) 用 IIS 7、ARR 與 Velocity 建设高性能的大型网站

https://www.360docs.net/doc/0c15564116.html,/WizardWu/archive/2009/05/16/1458108.html

-----------------------------------------------------

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（部署规划）：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms978676.aspx

Three-Tiered Distribution（三级分布）(硬件、不同主机的物理级分层)：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms978694.aspx

Three-Layered Services Application（三层服务应用程序）(软件、代码上的分层)：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms978689.aspx

Tiered Distribution（分级分布）：

https://www.360docs.net/doc/0c15564116.html,/en-gb/library/ms978701(zh-cn).aspx

Deployment Patterns：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms998478.aspx

https://www.360docs.net/doc/0c15564116.html,/en-us/library/ms998478.aspx

-----------------------------------------------------

2、负载均衡 (Load Balance)

负载均衡技术发展了多年，有很多专业的服务提供商和产品可选择，基本上又可分为「软件」和「硬件」的解决方案：

(1) 硬件：

硬件的解决方案称作 Layer 4 Switch (第 4 层交换)，可将业务流分配到合适的 AP Server 进行处理，知名产品如 Alteon、F5 等。这些硬件产品虽比软件的解决方案要贵得多，但是物有所值，通常能提供远比软件优秀的性能，和方便、易于管理的 UI 界面，供管理人员快速配置。据说 Yahoo 中国当初接近 2000 台服务器时，只用三台 Alteon 就搞定了 [1]。

(2) 软件：

Apache 这一款众所皆知的 HTTP Server，其双向 Proxy / Reverse Proxy 功能，亦可达成 HTTP 负载均衡功能，但其效率算不上特别好。而另一款 HAProxy 就是纯粹用来处理负载均衡的，且具有简单的缓存功能。

以操作系统内置的负载均衡功能来讲，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 集群和云计算的概念)。

图 1　分布

式用户 vs

服务器农场

(Web

Server

farm)

图 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，且要执行 https://www.360docs.net/doc/0c15564116.html, 程序，就要注意一个问题，就是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 人员应视公司的硬件资源、成本和预算，考量是否两者都要做。

Load-Balanced Cluster（负载平衡群集）：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms978730.aspx

https://www.360docs.net/doc/0c15564116.html,/en-us/library/ms978730.aspx

Server Clustering（服务器群集）：

https://www.360docs.net/doc/0c15564116.html,/en-gb/library/ms998414(zh-cn).aspx

Installing Network Load Balancing (NLB) on Windows Server 2008：

https://www.360docs.net/doc/0c15564116.html,/clustering/archive/2008/01/08/7024154.aspx

Linux load balancing support & consulting：

https://www.360docs.net/doc/0c15564116.html,/linux-loadbalancing.php

Load Balancing (WCF, 与本文无直接关系)：

https://www.360docs.net/doc/0c15564116.html,/zh-cn/library/ms730128.aspx

https://www.360docs.net/doc/0c15564116.html,/en-us/library/ms730128.aspx

-----------------------------------------------------

3、展示和功能的分层

大型网站中，常会为了将来的可扩展性、源代码维护方便，而将前台的展示 (HTML、Script)，和后台的商业逻辑、数据库访问 (.NET/C#、SQL)，切成多层。

根据Martin Fowler在P of EAA里的說法：Layer 是指「逻辑」上的分层 (logical separation)，Tier 是指「物理」上的分层 (physical separation)。若我们的 https://www.360docs.net/doc/0c15564116.html, 站台，是用「虚拟」的分层 (N-Layer)，来切开 UI - BLL - DAL，通常不会有性能上的问题；但若是用「物理」的分层 (N-Tier)，亦即如上图 2 和下图 3，可能每一台 AP Server 都负责不同的商业逻辑 (销售、库存、物流、制造、会计、...)，各自的源代码都存放在不同的物理主机上，且可各自独立运作，此时就要考虑到每一台 AP Server 在彼此协调合作，以及调用 Web Service (XML 的性能不佳)、执行分布式事务上的性能问题。

图 3　「物理」上的分层，各种商业逻辑可能存在多台物理主机上

谈到「物理」分层上的分布式事务 (Distributed Transaction)，微软的 Enterprise Services、COM+、WCF、WF 用到操作系统上的 MS DTC 来协调事务，由于 MS DTC 和这些应用程序各自处于不同的 Process，在沟通上会遇到序列化、反序列化的动作，还要整合事务中所有的 AppDomain 和不同主机上的资源，无可避免地一定会拖累性能。

Web Applications: N-Tier vs. N-Layer ：

https://www.360docs.net/doc/0c15564116.html,/blogs/david.hayden/archive/2005/07/23/129745.aspx

-----------------------------------------------------

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 次，其余都可从缓存数据中获得，而且读取速度、网页反应速度会大幅提升。

提供缓存的产品有很多种，还可分为用硬件或软件所做的缓存，如：https://www.360docs.net/doc/0c15564116.html, 内置的缓存功能、第三方厂商的缓存套件、Hibernate 和 NHibernate 里也有 Session 和 SessionFactory 的缓存机制、Oracle 的 cache group 技术，还有我先前在「用 IIS 7、ARR 與 Velocity 建设高性能的大型网站」这篇文章介绍的，微软官方新一代的分布式缓存技术 Velocity，另外像 Proxy Server (代理服务器) 也可以作为网页的缓存：

客户端 <---->代理服务器<---->目的服务器

在 .NET 的类库中，有提供 CacheDependency 和 AggregateCacheDependency 这两个类，可用来将 https://www.360docs.net/doc/0c15564116.html, 中缓存的对象 (如：DataSet)，和一或多个物理文件 (如：XML 文件) 或数据库中的表，去建立一种关联。当其中任一个 XML 文件被修改或移除时，与其关联的 DataSet 也会一并从内存里移除；当然，也可透过您程序中设定的时间自动移除。

https://www.360docs.net/doc/0c15564116.html, 2.0 以后的缓存，最大的改变在于 CacheDependency 类已经被微软重新改写过，我们也

可透过自定义类去继承它后再改写，以达成以下功能：

? 从 Active Directory 中的请求，让缓存失效 (缓存被自动移除)

? 从 MSMQ 或 MQSeries 中的请求，让缓存失效

? 从 Web Service 中的请求，让缓存失效

? 创建用于 Oracle 的 CacheDependency

? 其他

此外，SQL Server 中还有一种 SqlCacheDependency (缓存相依性)，可监听数据表中的数据是否曾经改变，亦即避免用户在缓存期间查到的数据是旧的，达到如果数据不变化，用户就一直从缓存中取得数据；一旦数据有变化，就自动更新缓存中的数据。启用 SqlCacheDependency 的方式，只要透过 aspnet_regsql.exe 这个工具，搭配参数输入命令，就会在 SQL Server 中产生一个新的AspNet_SqlCacheTablesForChangeNotification 表，如下图 4 所示，这张表的的每一条记录，都代表您要监听的其中一个表；最右侧的 changeId 字段，其值为供系统判断，用户对 https://www.360docs.net/doc/0c15564116.html, 中的请求，应由内存中的缓存来提供，抑或要至数据库重新做查询。

图 4　启用 SqlCacheDependency 后，自动添加用来监听的表

另外再谈到，我在「网站性能越来越差怎么办？」这篇文章，也有提过下面的内容：

(4) 用程序或软件做缓存

用程序做缓存，如 https://www.360docs.net/doc/0c15564116.html, 从 1.x 时代，就已内建的 Cache (缓存) 机制；或用一些第三方的辅助软件、Framework。

(5) 用硬件做快取或缓冲、砸钱加装 AP Server

他还在原本的网页服务器，与数据库服务器的架构中，加入一组应用程序服务器，作为网页服务器cache 数据的来源。

改版之后的新网站，搜寻速度提升许多，先前每日的统计数据中，处理速度超过 3 秒的数据超过 50万笔；而改版后，每星期超过 3 秒的查询不到 10 笔。

(6) 用硬件做缓存 (cache)

全盛时期，来自美国 blog 的流量每天达 80 万次。这个数字其实不高，对程序高手来说是小菜一碟，但笔者是半吊子工程师，知识有限也因此可能程序写得不好，频频被主机供货商发信警告，要求改善网站系统性能。最后，我决定开发 cache system。cache system 缓存系统上线后，将数据库读写，从每天 80 万次降低到每天 16 万次。

回复：

Peter.z.lu

中间件可以有很多选择：

Ncache, Coherence, Velocity, MemCache...

另外，还有像是 Memcached、Cacheman 这种分布式缓存的系统。前者可基于 Linux 和 Win32 平台使用，通过在内存里维护一个巨大的 hash 表，可存储图像、视频、文件及数据库检索的结果，并且支持多服务器，可解决 https://www.360docs.net/doc/0c15564116.html, 内置的缓存机制仅适用于单独的服务器；后者据说是微软旗下Popfly 项目组成员 Sriram Krishnan 的作品，将来也有可能成为微软的正式产品。

-----------------------------------------------------

9、分布式系统数据结构 - 以 MySpace 为例

在网络上流传一篇很火红的文章「从 MySpace 数据库看分布式系统数据结构变迁」，内容提到MySpace 这个大型的社区网站，使用微软平台的 Windows Server、SQL Server、https://www.360docs.net/doc/0c15564116.html, 技术，如今每个月的用户访问量高达 500 亿，且已有 2 亿个以上的用户注册。以下仅节录该文的重点：?第一代架构 - 添置更多的 Web 服务器

在 MySpace 有 50 万个注册用户的时候，网站只用了两台 Dell 双 CPU、4 GB 内存的

Web Server (分散用户的请求)、一台 DB Server (所有数据都存储在这)。

?第二代架构 - 增加数据库服务器

运行在三台数据库服务器上，一台用于更新数据 (由它复制到其他两个)、另两台用于读取数

据，因为看网页的人多，而需要写入的人少。等到用户数和访问量增加了，就再加装硬盘。

后来数据库服务器的 I/O 成了瓶颈，就按照垂直分割模式设计，把网站里的不同功能，如：

当注册用户达到 200 万后，还从存储设备与数据库服务器直接交互的方式，切换到 SAN (存储区域网络)，一种高带宽、专门设计的网络系统，可将大量磁盘存储设备连接在一起。

MySpace 让数据库连接到 SAN。但是当用户增加到 300 万人后，垂直分割策略也变得难以维持下去，后来架构师后来将主机升级成 34 个 CPU 的昂贵服务器，却也无法负荷。

?第三代架构 - 转到分布式计算架构

架构师将 MySpace 移到分布式计算架构，它在物理上分布的众多服务器，整体必须逻辑上

等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支

持，而必须将整个站点看作一个应用。这次，不再按站点功能和应用分割数据库，MySpace

开始将它的用户按每 100 万一组分割，然后将各组的全部数据分别存入独立的 SQL Server 实例。后来 MySpace 的每台数据库服务器实际运行两个 SQL Server 实例，也就是说每台

服务器会服务大约 200 万用户。

?第四代架构 - 增加数据缓存层

当用户达到 900-1000 万时，MySpace再次遭遇存储瓶颈问题，后来引用了新的 SAN 产

品，但站点目前的要求，已经超越 SAN 的 I/O 磁盘存储系统、及其读写数据的极限速度。

当用户达到 1700 万时，增加了一个数据缓存层，其位于 Web 服务器和数据库服务器之

间，其唯一职能是在内存中建立被频繁请求数据对象的副本。以前每一位用户查询一个信息，就请求一次数据库；现在当任一个用户请求数据库后，缓存层就会保留一个副本，当其他用户再访问时就不需要再请求数据库了，如此一来，不访问数据库也可以供给数据。

?第五代架构 - 转到支持 64 位处理器的操作系统和数据库软件

当用户数达到 2600 万时，转到了还处于 Beta 版、但支持 64 位处理器的 SQL Server 2005。在升级到 64 位的 SQL Server 2005 和 Windows Server 2003 后，MySpace 每台服务器配备了 32 GB 内存，后来又提升到了 64 GB。

如何优化数据库,提高查询效率

龙源期刊网 https://www.360docs.net/doc/0c15564116.html, 如何优化数据库，提高查询效率作者：代鸿彬来源：《学习与科普》2019年第10期摘要：随着信息时代的到来，生活和工作当中已经无法避免的需要和计算机打交道，和计算机打交道的同时就必须要用到数据库。数据库系统是计算机当中的一项重要系统，储存在用户的关键信息，不仅对个人影响很大，同时对企事业单位也有着重要影响。关键词：信息时代；数据库；索引数据库是信息的载体也是数据的最佳表现形式，它的共享性导致了数据会被大量的搜索查询，为了提高查询的效率，就不得不对数据库进行优化。一、利用索引进行优化。索引是数据库的重要组成部分，也是使用者根据需要进行查询最直接的方法，优化索引可以提高查询的效率。当前的数据库当中大部分还是使用国际商业机器公司以前的索引顺序存取方法，对于用户来说肯定会选择方便、快捷的索引方式，怎么方便怎么来。在建立索引的时候针对不同的内容，需要建立不同的连接方式，但是随着用户的增多，查询内容和方向的多元化，这就造成了在实际工作当中经常会有使用频率很少的索引出现，甚至也会出现没有查询所需的索引，这种情况可以通过查询优化器进行自动生成的索引进行查询。对于使用频率较为频繁的列，需要对其进行排序或者分组的列上建立索引时，要优化索引提高效率，对于使用频率很少的列可以不建立索引。二、简化排序进行优化。对于部分企事业单位需要排序的内容很多时，就要使用大型数据表来满足查询需求，但是大型数据表涉及的内容很多，为了避免出现重复排序的现象需要对数据表进行简化。在大型数据表当中有一部分的内容可以自动进行排序的次序输出，这时就可以直接利用查询优化器进行优化，将复杂的排序简单化，从而提高索引查询效率。需要排序的列对索引优化影响较大，就像语言当中的ORDER BY 或者GROUP BY句子当中的列次序和索引当中的列次序基本是不同的，但是排序的列可通过表的不同形式表现出来。通过简化排序避免了重复的排序，并且将数据库进行了合理的合并。如果不进行简化排序，就需要将排序的范围进行缩小简化，从而提高查询使用的效率。三、大型表行数据库存取的合理消除。数据库系统的存储量是有上限的，所有的索引内容都占有数据库空间，尤其是大型数据表占有的空间更大，将会造成索引时间变长。但是大型表行数据有些内容是不必要的，在进行索引查詢时，数据表当中的存取顺序对查询的效率有直接的影响。例如需要采用存取策略时，通

C# 数据库体系结构

数据库体系结构数据库如何处理一个查询当应用程序向PostgreSQL系统提交一个查询时，一般要经过五个阶段：

联接阶段一旦建立起来一个联接，客户端进程就可以向后端服务器进程发送查询了。查询是通过纯文本传输的，也就是说在前端不做任何分析处理。服务器分析查询，创建执行规划，执行该规划并且通过已经建立起来的联接把检索出来的记录返回给客户端。分析阶段解析器的功能就其目的性来说，就是检查从应用程序（客户端）发送过来的查询，核对语法并创建一个查询分析树（querytree）。重写阶段重写系统是一个位于分析器阶段和规划器/优化器之间的模块。它接收分析阶段来的查询树且搜索任何应用到查询树上的规则，（规则存储在系统表里）并根据给出的规则体进行转换。重写系统的一个应用就是实现视图。当一个查询访问一个视图时（也就是说，一个虚拟表），重写系统改写用户的查询，使之成为一个访问在视图定义里给出的基本表的查询。优化阶段规划器/优化器的任务是创建一个优化了的执行规划。它首先合并对出现在查询里的关系进行扫描和连接所有可能的方法。这样创建的所有路径都导致相同结果，而优化器的任务就是计算每个路径的开销并且找出开销最小的那条路径。

执行阶段接受规划器/优化器传过来地查询规划然后递归地处理它，抽取所需要的行集合。执行器就是对应于上面所提到的查询引擎中的执行处理客户端发来的请求（Executor），它是查询引擎的核心模块。执行器实际上是一个需求－拉动地流水线机制。每次调用一个规划节点地时候，它都必须给出更多的一个行，或者汇报它已经完成行的传递。针对不同的SQL查询类型，执行器会有不同的执行方案，而这些方案的选择是按照执行器机制进行的。

web性能优化(服务器优化)

Web网站性能优化的相关技术来源：站长网 https://www.360docs.net/doc/0c15564116.html, 2011-03-04 06:50:47 Web站点性能问题吸引或者迫使越来越多的人投入到这个问题的研究中来，产生了很多解决方案。下面是我根据自身的理解对这些技术进行了归类总结，如有不足之处欢迎拍砖。一、提高服务器并发处理能力我们总是希望一台服务器在单位时间内能处理的请求越多越好，这也成了web 服务器的能力高低的关键所在。服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计，使得多个任务可以轮流使用系统资源，这些资源包括CPU、内存以及I/O等。这就需要选择一个合适的并发策略来合理利用这些资源，从而提高服务器的并发处理能力。这些并发策略更多的应用在apache、nginx、lighttpd等底层web server软件中。二、Web组件分离这里所说的web组件是指web服务器提供的所有基于URL访问的资源，包括动态内容，静态网页，图片，样式表，脚本，视频等等。这些资源在文件大小，文件数量，内容更新频率，预计并发用户数，是否需要脚本解释器等方面有着很大的差异，对不同特性资源采用能充分发挥其潜力的优化策略，能极大的提高web 站点的性能。例如：将图片部署在独立的服务器上并为其分配独立的新域名，对静态网页使用epoll模型可以在大并发数情况下吞吐率保持稳定。三、数据库性能优化和扩展。 Web服务器软件在数据库方面做的优化主要是减少访问数据库的次数，具体做法就是使用各种缓存方法。也可以从数据库本身入手提高其查询性能，这涉及到数据库性能优化方面的知识本文不作讨论。另外也可以通过主从复制，读写分离，使用反向代理，写操作分离等方式来扩展数据库规模，提升数据库服务能力。四、Web负载均衡及相关技术负载均衡是web站点规模水平扩展的一种手段，实现负载均衡的方法有好几种包括基于HTTP重定向的负载均衡，DNS负载均衡，反向代理负载均衡，四层负载均衡等等。对这些负载均衡方法做简单的介绍：基于HTTP重定向的负载均衡利用了HTTP 重定向的请求转移和自动跳转功能来实现负载均衡，我们熟悉的镜像下载就使用这种负载均衡。DNS负载均衡是指在一个DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时返回不同的解析结果将客户端的访问引到不同的机

大数据库优化(SQLServer)

SQL SERVER性能优化综述近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以前的经验和测试结果进行总结了。我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。一、分析阶段一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。二、设计阶段设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三

服务端性能优化参考指南

服务端性能优化参考指南 1、代码优化通过JPROFIRE等第三方工具分析判读代码运行耗时长、性能瓶颈部分，重新审视自己写的代码，逐条逐句，主要注意一下几点：对象的生成和大小的调整 JAVA程序设计中一个普遍的问题就是没有好好的利用JAVA语言本身提供的函数，从而常常会生成大量的对象（或实例）。由于系统不仅要花时间生成对象，以后可能还需花时间对这些对象进行垃圾回收和处理。因此，生成过多的对象将会给程序的性能带来很大的影响。杜绝不必要的对象产生，减少可调整的生成对象。代码举例： String name=new String("HuangWeiFeng"); System.out.println(name+"is my name"); (1) 生成新的字符串new String（STR_1); (2) 复制该字符串; (3) 加载字符串常量"HuangWeiFeng"（STR_2); (4) 调用字符串的构架器（Constructor）; (5) 保存该字符串到数组中（从位置0开始）; (6) 从java.io.PrintStream类中得到静态的out变量; (7) 生成新的字符串缓冲变量new StringBuffer(STR_BUF_1); (8) 复制该字符串缓冲变量; (9) 调用字符串缓冲的构架器（Constructor）; (10) 保存该字符串缓冲到数组中（从位置1开始）; (11) 以STR_1为参数，调用字符串缓冲(StringBuffer)类中的append方法; (12) 加载字符串常量"is my name"(STR_3); (13) 以STR_3为参数，调用字符串缓冲(StringBuffer)类中的append方法; (14) 对于STR_BUF_1执行toString命令; (15) 调用out变量中的println方法，输出结果。上面两行代码生成了STR_1,STR_2,STR_3,STR_4和STR_BUF_1五个对象变量。这些生成的类的实例一般都存放在堆中。堆要对所有类的超类，类的实例进行初始化，同时还要调用类极其每个超类的构架器。而这些操作都是非常消耗系统资源的。因此，对对象的生成进行限制，是完全有必要的。经修改，上面的代码可以用如下的代码来替换。

通向FPGA之路---七天玩转Altera之基础篇V1.00

通向FPGA之路---七天玩转Altera 之基础篇V1.0

目录： 1. Altera基础 (4) 1.1 典型设计流程 (4) 1.2 QuartusII 编译流程 (4) 1.3 管理QuartusII工程 (5) 1.4 设计输入 (7) 1.5 优化向导 (9) 2. Assignment Editor (11) 2.1 介绍 (11) 2.2 优化实例 (14) 2.2.1 PCI I/O及乘法器 (14) 2.2.2 弱上拉 (15) 2.2.3 设置输出管脚驱动电流 (16) 3. I/O设计 (20) 3.1 I/O系统 (20) 3.1.1 早期I/O规划 (20) 3.1.2 引脚分配 (27) 3.1.3 验证并使能I/O设置 (37) 3.2 高级I/O系统 (40) 3.2.1 信号完整性仿真和分析需求 (41) 3.2.2 SSN分析和减小措施 (41) 3.2.3 QuartusII软件中的三类分析 (50) 3.2.4 第三类：IBIS & HSPICE模型 (60) 4. Netlist Viewers (68) 4.1 界面介绍 (71) 4.1.1 图标 (71) 4.1.2 视图 (75) 4.2 浏览 (76) 4.3 过滤 (80) 4.3.1 类型 (81) 4.3.2 层次化过滤 (82) 4.4 Tooltips (83) 5. MegaWizard Plug-In Manager（暂无） (85)

前言：网上关于Altera的教程很多，可谓浩如烟海。大体来说有两类：一是，step by step的指导如何操作Quartus软件，这类方法的优点是上手快，但却有知其然不知其所以然之惑；二是，从一个很高的起点分析一些具体问题，优点是有深度，但也把大部分初学者拒之门外，不知路在何方。本系列教程的宗旨是在力求全面介绍Altera及其QuartusII软件原理的基础上，对何如使用Altera FPGA进行基础设计、时序分析、验证、优化四大方面进行讲解。本篇为基础篇，推荐用一天时间掌握。还有三大类各需两天，一共七天。本教程大部分内容参考翻译altera官方handbook和对应的paper等资料，也有部分章节系热心网友所创，笔者基本原文引用，只为阅读流畅性做了少许改动，如造成原作者的不适，可联系笔者删除之。后续教程视读者反映情况进行适当调整和发布。 2011.3.18 上海foreveryoung 交流QQ群：123035845/91968656 笔者QQ：298467204

分布式服务架构方案

高并发分布式服务架构方案下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。数据的存储和读取分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格，适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案，但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对

于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。基础服务基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。应用层应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群，可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。

数据库性能优化基础步骤

1性能优化基本步骤 1.1定位跟踪耗费资源较多的SQL语句步骤 1.1.1 通过SQL查询 (1): 查询出最耗费资源的SQL语句 select t1.SID, t1.SERIAL#, tt.HASH_VALUE, tt.ADDRESS, tt.BUFFER_GETS, --读内存次数 tt.DISK_READS, --磁盘物理读次数 tt.EXECUTIONS, --语句的执行次数 tt.BUFFER_GETS / tt.EXECUTIONS, --平均读内存次数 tt.SQL_FULLTEXT from v$sqlareatt, v$session t1 where (tt.BUFFER_GETS>100000 or tt.DISK_READS>100000) and tt.HASH_VALUE = t1.SQL_HASH_VALUE and tt.ADDRESS = t1.SQL_ADDRESS and t1.STATUS = 'ACTIVE' orderby tt.BUFFER_GETS desc (2)：根据客户端程序发出的SQL来定位需要跟踪的session select s.sid sid, s.SERIAL# "serial#", https://www.360docs.net/doc/0c15564116.html,ername, s.machine, s.program, s.server, s.LOGON_TIME from v$session s 1.1.2 通过Oracle提供的SQL TRACE进行SQL跟踪 (1)：跟踪前设定相应参数 1．查询得到需要跟踪的session 2．打开时间开关

Show parameter timed_statistics alter session set timed_statistics=true; execsys.dbms_system.set_bool_param_in_session(sid => 8,serial# => 3,parnam => 'timed_statistics',bval => true); 3．设置跟踪文件存放位置 Show parameter user_dump_dest alter system set user_dump_dest='c:\temp'; (2)：启动跟踪功能并让系统运行一段时间 alter session set sql_trace=true; execsys.dbms_system.set_sql_trace_in_session(8, 3, true); (3)：关闭跟踪功能 alter session set sql_trace=false; execsys.dbms_system.set_sql_trace_in_session(8, 3, false); (4)：格式化跟踪数据文件，并分析跟踪结果文件 tkprof dsdb2_ora_18468.trc dsdb2_trace.txt EXPLAIN=SCOTT/TIGER tkprof各参数含义： ' traced_file ' 指定输入文件，即oracle产生的trace文件 'formatted_file'指定输出文件，即我们想得到的易于理解的格式化文件 'EXPLAIN' 利用哪个用户对trace文件中的sql进行分析得到该sql语句的执行计划1.2查看分析执行计划 1.2.1查看执行计划 (1)：Sqlplus中可按F5查看执行计划 (2)：使用执行计划表进行查看使用语句将SQL语句的执行计划装入plan_table表，然后进行分析查看explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value (3)：示例演示 1．让ORALCE自动选择最优的执行计划，不人为干预 explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value

Tomcat服务器性能调优几个方面

Tomcat性能调优几个方面一、操作系统调优对于操作系统优化来说，是尽可能的增大可使用的内存容量、提高CPU的频率，保证文件系统的读写速率等。经过压力测试验证，在并发连接很多的情况下，CPU的处理能力越强，系统运行速度越快。。【适用场景】任何项目。二、Java虚拟机调优应该选择SUN的JVM，在满足项目需要的前提下，尽量选用版本较高的JVM，一般来说高版本产品在速度和效率上比低版本会有改进。 JDK1.4比JDK1.3性能提高了近10%-20%，JDK1.5比JDK1.4性能提高25%-75%。因此对性能要求较高的情况推荐使用 JDK1.6。【适用场景】任何项目。三、Apache集成Tomcat Web服务器专门处理HTTP请求，应用服务器是通过很多协议为应用提供商业逻辑。虽然Tomcat也可以作web服务器，但其处理静态html的速度比不上Apache，且其作为web服务器的功能远不如Apache，因此把Apache和Tomcat集成起来，将html和Jsp的功能部分进行明确分工，让Tomcat只处理Jsp部分，其他的由Apache，IIS等web服务器去处理，由此大大提高Tomcat的运行效率。如果一个项目中大量使用了静态页面、大量的图片等，并有有较大的访问量，推荐使用Apache集成Tomcat的方式来提高系统的整体性能。 Apache和Tomcat的整合有三种方式，分别是JK、http_proxy和ajp_proxy.其中JK方式是最常见的方式，JK本身有两个版本分别是1和2，目前1最新版本是1.2.8，而版本2早已经废弃了。http_proxy是利用Apache自带的mod_proxy 模块使用代理技术来连接Tomcat。Ajp_proxy连接方式其实跟http_proxy方式一样，都是由mod_proxy所提供的功能。只需要把配置中的http://换成ajp://,同时连接的是Tomcat的AJP Connector所在的端口。相对于JK的连接方式，后两种在配置上比较简单的，灵活性方面也一点都不逊色。但就稳定性而言不像JK这样久经考验，所以建议采用JK的连接方式。Apache+JK+Tomcat配置：

数据库查询优化实验报告_SQLServer2008

SQL Server 2008数据查询的优化方法研究摘要随着数据存储需求的日益增长，对关系数据的管理和访问就成为数据库技术必须解决的问题。本文主要论述关系数据库查询优化技术，并从它的优化技术进行深入探讨，对系统实现做了一定的论述，并进行了部分的程序实现。关键词：数据库查询系统优化引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种： 1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 SQLServer数据查询优化方法 1、避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary 是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: select name from employee where salary ＞60000

web服务器性能优化

web服务器性能优化导读：本文web服务器性能优化，仅供参考，如果觉得很不错，欢迎点评和分享。作为一种资源的组织和表达机制，Web已成为Internet最主要的信息传送媒介。因此Web的性能已经成为判断一个网站成功与否的一个重要评估标准。而Web服务器则是决定Web性能的重要环节。 Web服务器性能就是指一个Web服务器响应用户请求的能力。为了提高Web服务器的性能人们进行了诸多尝试，已经取得了可喜的成果。本文通过对前人研究结果的分析，提出了在具体应用环境中优化Web服务器的方法和策略。 Web服务器概述 Web系统在现在网络中广泛使用，而Web服务器则是Web系统的一个重要组成部分。完整的Web结构应包括:HTTP协议，Web 服务器，通用网关接口CGI、Web应用程序接口、Web浏览器。 Web服务器是指驻留在因特网上某种类型计算机的程序。它是在网络中信息提供者基干HTTP的为实现信息发布、资料查询、数据处理等诸多应用搭建基本平台的服务器，其主要功能是提供网上信息浏览服务。当Web浏览器(客户端)连到服务器并请求文件时，服务器将处理该请求并将文件发送到该浏览器上，附带的信息会告诉浏览器如何查看该文件(即文件类型)。

Web服务器在web页面处理中大致可分为三个步骤:第一步，web浏览器向一个特定的服务器发出Web页面请求;第二步，Web 服务器接收到web页面请求后，寻找所请求的web页面，并将所请求的Web页面传送给Web浏览器;第三步，Web服务器接收到所请求的web页面，并将它显示出来。 web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。在Web上，常见的大多数表单核搜索引擎上都是用的是CGI脚本。影响web应用服务器性能的因素 Web服务器的性能就是指一个Web服务器响应用户请求的能力，服务器的性能对于一个Web系统来说至关重要。为了提高Web 服务器的性能人们进行了许多尝试，也采用了许多技术和方法，但是这些技术和方法往往缺乏适用性。通过对前人的研究分析可以发现，在web服务器的优化方而存在这种问题的原因主要有两个:一方面是服务器性能评测造成的，一方面是选用优化方案时考虑不全面造成的。现行的服务器性能评测工具在对Web服务器进行评测时，其实是由一台或几台计算机模拟客户机，与被测的Web服务器进行通信，它们其实组成的只是一个局域网的环境，这与真正的广域网的环境有一定的差别。另外，评测工具在选择网络负载时，虽然已经尽可能的接近真实负载，但是与持续的高频率负载要求仍有差距;再者，在性能测试指

数据库的体系结构

数据库基础（视频讲解：25分钟）本章主要介绍数据库的相关概念，包括数据库系统的简介、数据库的体系结构、数据模型、常见关系数据库。通过本章的学习，读者应该掌握数据库系统、数据模型、数据库三级模式结构以及数据库规范化等概念，掌握常见的关系数据库。通过阅读本章，您可以：了解数据库技术的发展掌握数据库系统的组成掌握数据库的体系结构熟悉数据模型掌握常见的关系数据库 1 第章

1.1 数据库系统简介视频讲解：光盘\TM\lx\1\数据库系统简介.exe 数据库系统（DataBase System，DBS）是由数据库及其管理软件组成的系统，人们常把与数据库有关的硬件和软件系统称为数据库系统。 1.1.1 数据库技术的发展数据库技术是应数据管理任务的需求而产生的，随着计算机技术的发展，对数据管理技术也不断地提出更高的要求，其先后经历了人工管理、文件系统、数据库系统等3个阶段，这3个阶段的特点分别如下所述。（1）人工管理阶段 20世纪50年代中期以前，计算机主要用于科学计算。当时硬件和软件设备都很落后，数据基本依赖于人工管理，人工管理数据具有如下特点： ?数据不保存。 ?使用应用程序管理数据。 ?数据不共享。 ?数据不具有独立性。（2）文件系统阶段 20世纪50年代后期到60年代中期，硬件和软件技术都有了进一步发展，出现了磁盘等存储设备和专门的数据管理软件即文件系统，文件系统具有如下特点： ?数据可以长期保存。 ?由文件系统管理数据。 ?共享性差，数据冗余大。 ?数据独立性差。（3）数据库系统阶段 20世纪60年代后期以来，计算机应用于管理系统，而且规模越来越大，应用越来越广泛，数据量急剧增长，对共享功能的要求越来越强烈。这样使用文件系统管理数据已经不能满足要求，于是为了解决一系列问题，出现了数据库系统来统一管理数据。数据库系统满足了多用户、多应用共享数据的需求，它比文件系统具有明显的优点，标志着管理技术的飞跃。 1.1.2 数据库系统的组成数据库系统是采用数据库技术的计算机系统，是由数据库（数据）、数据库管理系统（软件）、数

服务器性能优化配置建议

目录一、服务配置建议二、MySQL性能分析及建议三、系统性能分析很久以前在前公司给中企动力那边写的服务器分析建议，其实出就是一些简单参数调整仍后利用vmstat,top这些工具对系统性能做初步分析。贴出来希望对朋友们学习有帮助，同时也欢迎朋友们补充！[此文档仅作参考和学习，具体优化比较复杂欢迎朋友们探讨！] 一、服务器配置先阅读apache配置优化建议如下，再对相关参数进行调整，观察服务器状况. Apache配置优化建议: 进入/usr/local/apache2/conf/extra 目录下 Apache优化, 经过上述操作后，Apache已经能够正常运行。但是，对于访问量稍大的站点，Apache的这些默认配置是无法满足需求的，我们仍需调整Apache的一些参数，使Apache能够在大访问量环境下发挥出更好的性能。以下我们对Apache配置文件httpd.conf中对性能影响较大的参数进行一些说明。 (1) Timeout 该参数指定Apache在接收请求或发送所请求内容之前的最长等待时间（秒），若超过该时间Apache则放弃处理该请求，并释放连接。该参数默认值为120，推荐设置为60，对于访问量较大的网站可以设置为30或15。 (2) KeepAlive 该参数控制Apache是否允许在一个连接中有多个请求，默认打开。但对于大多数论坛类型站点来说，通常设置为off以关闭该支持。 (3) MPM - prefork.c 在默认情况下Apache使用Prefork（进程）工作模式，可以说这部分的参数设置是对Apache性能影响的核心和关键。用户可以在配置文档中找到以下配置段： ? StartServers 5 ? MinSpareServers 5 ? MaxSpareServers 10 ? MaxClients 15 ? MaxRequestsPerChild 0 ?

MS_SQL_Server_数据库性能优化方法总结

1.列出数据库服务器、Web服务器的基本的硬件配置，如CPU、内存等。 2.检查数据库服务器是否真正启用了AWE内存。 (1) 启用AWE：数据库服务器检查C:\boot.ini文件,需要配置"/PAE"(*重启电脑才能生效),如下： [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE (2) 开启sql server 服务用户的，内存中锁定页面权限 (*重启电脑才能生效)在“服务管理”中查看 SQL SERVER 服务登录账户，默认是本地系统帐户（System）。然后在运行 gpedit.msc ，选择计算机配置->windows 设置->安全设置->本地策略->用户权限分配->内存中锁定页面。添加SQL SERVER服务的登录用户到里面去。 (3)启用数据库AWE内存，以服务器8G内存为例，一般设置如下，最小2G，最大6G(重启SQL SERVER服务即可)： (4)跟踪数据库性能“Total Server Memory ”的使用情况，看看数据库真正使用的内存，越接近为数据库分配的最大内存越好。或使用如下语句，查询数据库的内存使用情况： use master go select * from sysperfinfo where counter_name like '%Total Server Memory(KB)%' go 3.Web服务器监控项：

数据库优化

关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。一、分析阶段一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。二、设计阶段设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。 3、主键的设计主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前

大型网站架构技术方案集锦

大型网站架构技术方案集锦-具体内容 PlentyOfFish 网站架构学习采取Windows 技术路线的Web 2.0 站点并不多，除了MySpace ，另外就是这个PlentyOfFish。这个站点提供"Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值10 亿，估计要让很多人眼热，更何况Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。之所以选择Windows .NET 的技术路线是因为Markus Frind 不懂LAMP 那一套东西，会啥用啥。就这样，也能支撑超过3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于PlentyOfFish 架构的细节。记录一下感兴趣的部分。带宽与CPU PlentyOfFish 比较特殊的一个地方是几乎不需要Cache，因为数据变化过快，很快就过期。我不知道这是因为https://www.360docs.net/doc/0c15564116.html, 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了30% 的CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。负载均衡微软Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对Windows 架构的站点又是必须--IIS 的总连接数是有限制的。PlentyOfFish 用的是ServerIron (Conf Refer)，ServerIron 使用简单，而且功能比NLB 更丰富。数据库一共三台SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器"。因为Cache没啥用，所以要花大力气优化DB。每个页面上调用DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。微软好不容易找到了一个宣传案例，所以在Channel 9 上有一个PlentyOfFish 的访谈。 PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。 --EOF-- YouTube 的架构扩展

优化数据库性能

查询速度慢如何解决 ------主要针对SQL 2005 为例引起查询或更新的执行时间超过预期时间的原因有多种。查询运行慢，可能是由与运行 SQL Server 的网络或计算机相关的性能问题引起的，也可能是由物理数据库设计问题引起的。查询和更新运行慢的最常见原因有： ?网络通讯速度慢。 ?服务器的内存不足，或者没有足够的内存供 SQL Server 使用。 ?索引列上缺少有用的统计信息。 ?索引列上的统计信息过期。 ?缺少有用的索引。 ?缺少有用的索引视图。 ?缺少有用的数据条带化。 ?缺少有用的分区。 1、用于对运行慢的查询进行故障排除的清单当查询或更新花费的时间比预期时间长时，请考虑以下问题，找到可解答前一节中列出的查询运行慢的原因： ①. 是与组件而不是与查询相关的性能问题吗？例如，是网络性能低的问题吗？有其他可能引起或造成性能降低的组件吗？ Windows 系统监视器可用于监视与 SQL Server 和非 SQL Server 相关的组件的性能。有关详细信息，请参阅监视资源使用情况（系统监视器）。 ②. 如果性能问题与查询相关，那么涉及到的是哪个或哪组查询？首先使用 SQL Server Profiler来帮助找出运行慢的查询。有关详细信息，请参阅使用 SQL Server Profiler。在找出运行慢的查询后，可以使用 SET 语句启用 SHOWPLAN、STATISTICS IO、STATISTICS TIME 和 STATISTICS PROFILE 选项，进一步分析查询的性能，相关描述如下： ?SET SHOWPLAN_XML ON 描述 SQL Server 查询优化器选择用来检索完善的 XML 文档数据的方法。有关详细信息，请参阅 SET SHOWPLAN_XML (Transact-SQL)。在 Microsoft SQL Server 2005 中，建议使用这种方法。此 SET 选项生成的信息比 SHOWPLAN_ALL 和 SHOWPLAN_TEXT SET 选项生成的信息详细。 ?SET SHOWPLAN_ALL ON 描述 SQL Server 查询优化器选择的数据检索方法。有关详细信息，请参阅 SET SHOWPLAN_ALL (Transact-SQL)。此 SET 选项生成的信息比 SHOWPLAN_TEXT SET 选项生成的信息详细。 ?SET SHOWPLAN_TEXT ON 返回每条 Transact-SQL 语句的执行信息，但不执行它们。有关详细信息，请参阅SET SHOWPLAN_TEXT (Transact-SQL)。