如何提高网页运行性能

从编码方面

一、 缓存

缓存是ASPNET中提高性能的重要手段，缓存一般遵循以下原则：

1） 在页面中将静态内容与动态内容分割开来

考虑将动态内容作成用户控件

2） 缓存合理的数据

一般应当缓存应用程序集的数据、多个用户共同使用的数据、静态数据、生成数据需要很大开销的动态数据、DataSet以及自定义对象等。不要缓存数据库连接对象、DataReader。

3） 选择适当的方式

如可以使用页面缓存指令，API等。

二、 视图状态

视图状态放在页面中名为_VIEWSTATE的表单隐藏域里面，随页面一起被发送到客户端，在用户提交页面时，又被提交到服务器。

1） 如果不需要视图状态，则禁用

视图状态默认是允许的，如果页面不进行PostBack，如果不处理服务器控件的事件，如果服务器控件的数据每次都需要重新计算等

2） 尽量减少视图状态中存放的对象

三、 关于页面处理（减少页面生成的时间和过程）

1） 应尽量减少页面文件的大小

2） 通过检测PageIsPostBack减少代码执行的数量

3） 禁止使用Debug=“true”，减少页面生成过程中生成额外的调试信息

4） 使用ServerTransfer而不使用ResponseRedirect，减少服务器和客户端间的往返

5） 尽量使用客户端验证，减少服务器和客户端间的往返

6） 在适当的场合使用服务器控件

7） 尽量避免嵌套的服务器控件

四、 避免使用PageDataBind和DataBinderEval

五、 关于Application对象和Session对象

1） 使用静态属性存储数据而不使用Application对象，在Application对象里存储只读类型的数据都将回提高性能

2） 尽量使用InProc模式的Session，这个模式是最快的

3） 在Session里存储基本类型的数据减少序列化的所消耗的资源

4） 如果不用Session变量，使用EnvableViewState=“false”禁用

5） 如果不修改Session变量的值，尽量使用ReadOnly属性设置

六、 关于字符串 *** 作

1） 尽量使用ResponseWrite将结果输出到浏览器，这种方法是最快的。不要将字符串连接在一起一次输出。

2） 在字符串短并且少的情况下可以使用StringConcat方法，而在字符串长度未知，并且字符串大的情况下，使用StringBuilder对象

3） 不要使用strVar==“”来判断字符串是否为“”，这样它会创建额外的字符串，请使用strVar==StringEmpty代替或者使用strVarLength==0来判断

4） 请使用StringCompare方法进行字符串的比较

七、 关于数据访问

1） 尽量使用存储过程返回数据，不要直接在代码中进行查询

2） 在数据库中只返回有用的数据结果，不要选择不使用的数据字段

3） 进行使用DataReader进行数据绑定，DataReader是单向只读的

4） 尽量一次返回多个数据集而不是每个记录集分别打开一次数据库连接进行查询

5） 尽量晚的打开数据库，尽量早的关闭数据库

6） 使用连接池提高性能

7） 使用ExecuteNonQuery方法执行不返回数据的 *** 作，使用ExecuteScalar方法返回单个结果的 *** 作，使用CommandBehaviorSequentialaccess返回二进制数据或者大数据

8） 如果多次相同的查询，请使用CommandPrepare方法

9） 使用GetOrdinal方法预先得到索引值，使用索引值比使用字符串的列名查询数据效率更高

八、 关于代码优化

1） 在解析基本数据类型时，使用Try方法如果解析失败，会抛出异常，使用TryParse方法则只执行Else下的语句。

2） 使用AppendAllText、WriteAllBytes等方法读写文件内容可以优化性能

3） 将循环判定条件放在for语句外

4） 避免在循环里创建对象

5） 尽量减少装箱的次数

6） 不要使用例外控制程序的流程

7） 在循环中不要使用不变的对象属性或者字段

8） 使用for循环代替foreach循环遍历结合内容

9） 数组是所有集合中最快的，如果没有特殊需要，尽量使用数组代替集合

10） 了解各个集合类型的特性，选择合适的类型

11） 使用泛型避免减少装箱、拆箱

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的服务器，甚至很多台服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃，在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，net不是很熟悉，相信也肯定有。

镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，其中有两个架构可以参考。

硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有>

首先大数据挑战的就是企业的存储系统，大数据爆炸式的增长使得存储系统的容量、扩展能力、传输瓶颈等方面都面临着挑战。与之相连的还有服务器的计算能力，内存的存储能力等等都面临着新的技术攻关。目前闪存技术的发展以及英特尔、IBM等公司在大数据方面都已经投入相当大的资金进行研发，主要也是为了解决大数据对基础平台所带来的挑战。

同样，大数据分析同样面临着软件方面的挑战，同时也引发数据库、数据仓库、数据挖掘、商业智能、人工智能、内容/知识管理等领域的技术变革。Hadoop是近年大家经常提到了一个能够对大量数据进行分布式处理的软件框架，用户可以轻松地在Hadoop上开发和运行处理海量数据的应用程序。

2、商业模式的挑战

大数据具有强大的数据价值，当我们可以利用大数据挖掘到需要信息的时候，则需要我们根据得到的信息对企业的商业模型、产品和服务等方面进行创新，这样才能够真正的让大数据的价值得到体现。

一：传统数据库

(1）传统索引不适于海量数据    

传统行存数据库索引需要手工设定，对应用不完全透明，随场景和需求的变化需要不断调整，人工维护成本很高。并且传统索引占用存储空间很大，甚至高于数据本身，造成查询效率的下降。

（2）数据装载速度慢

因为索引需要重新创建，加载性能会变的很糟糕。分析型架构系统要解决这些个问题，必须最大限度地减少磁盘 I/O ，提升查询效率，减小人工维护成本。南大通用分析型数据库GBase8a (以下简称GBase 8a)通过列存储模式、数据压缩、智能化的索引、并行处理、并发控制、高效的查询优化器等技术，使得上述问题得到有效解决。以下各节将描述 GBase 8a 的创新架构如何实现这些目标。

二：新型数据库

新型数据库采用分布式并行计算架构，部署于X86通用服务器，满足大数据实时交易需求，成本低、扩展性高，突破了传统数据库性能瓶颈。

分布式非关系型数据库技术创新

非关系型数据库即NoSQL，抛弃了关系数据库复杂的关系 *** 作、事务处理等功能，仅提供简单的键值对(Key, Value)数据的存储与查询，换取高扩展性和高性能，满足论坛、博客、SNS、微博等互联网类应用场景下针对海量数据的简单 *** 作需求。主要技术创新为:

(1) 简单的数据 *** 作换取高效响应。NoSQL仅支持按照Key(关键字)来存储和查询Value(数据)，不支持对非关键字数据列的高效查询;因数据 *** 作简单、数据间一般不需要关联 *** 作，故系统可支持高并发和较快的响应速度。

(2) 多种一致性策略满足业务需求。不同于传统关系型数据库仅支持强一致性策略，NoSQL还支持弱一致性和最终一致性等多种策略，可根据应用场景进行对应配置。例如，对写入 *** 作频繁，但数据读取最新版本要求并不严格的应用，如互联网网页数据的存储和分析应用，可以采用最终一致性策略;而对订购关系存储的应用，则必须用强一致性策略，保证总是读取最新版本数据

统企业的OLAP几乎都是基于关系型数据库，在面临“大数据”分析瓶颈，甚至实时数据分析的挑战时，在架构上如何应对本文试拟出几个大数据OLAP平台的设计要点，意在抛砖引玉。

突破设计原则

建设企业的大数据管理平台(Big Data Management Platform)，第一个面临的挑战来自历史数据结构，以及企业现有的数据库设计人员的观念、原则。数据关系、ACID在关系数据库几十年的统治时期是久得人心，不少开发人员都有过为文档、设计数据表，或将文档、序列化为二进制文件存入关系数据库的经历。在BDMP之上，我们需要对多种不同的格式的数据进行混合存储，这就必须意识到曾经的原则已经不再适用——One size dosen’t fit all，新的原则——One size fits a bunch

以下是我列出的一些NoSQL数据库在设计上的模式：

文档数据库：数据结构是类JSON，可以使用嵌入(Embed)或文档引用(Reference)的方式来为两个不同的文档对象建立关系;

列簇数据库：基于查询进行设计，有宽行(Wild Rows)和窄行(Skinny Rows)的设计决策;

索引数据库：基于搜索进行设计，在设计时需要考虑对对每个字段内容的处理(Analysis)。

搜索和查询的区别在于，对返回内容的排序，搜索引擎侧重于文本分析和关键字权重的处理上，而查询通常只是对数据进行单列或多列排序返回即可。

数据存储的二八原则

不少企业在解决海量数据存储的问题上，要么是把关系数据库全部往Hadoop上一导入，要么是把以前的非结构化数据如日志、点击流往NoSQL数据库中写入，但最后往往发现前者还是无法解决大数据分析的性能瓶颈，后者也无法回答数据如何发挥业务价值的问题。

在数据的价值和使用上，其实也存在着二八原则：

20%的数据发挥着80%的业务价值;

80%的数据请求只针对20%的数据。

目前来看，不管是数据存储处理、分析还是挖掘，最完整和成熟的生态圈还是基于关系型数据库，比如报表、联机分析等工具;另外就是数据分析人员更偏重于查询分析语言如SQL、R、Python数据分析包而不是编程语言。

企业大数据平台建设的二八原则是，将20%最有价值的数据——以结构化的形式存储在关系型数据库中供业务人员进行查询和分析;而将80%的数据——以非结构化、原始形式存储在相对廉价的Hadoop等平台上，供有一定数据挖掘技术的数据分析师或数据工程师进行下一步数据处理。经过加工的数据可以以数据集市或数据模型的形式存储在NoSQL数据库中，这也是后面要讲到的“离线”与“在线”数据。

理解企业的数据处理需求

数据库到数据仓库，是事务型数据到分析型数据的转变，分析型数据需要包括的是：分析的主题、数据的维度和层次，以及数据的历史变化等等。而对大数据平台来说，对分析的需求会更细，包括：

查询：快速响应组合条件查询、模糊查询、标签

搜索：包括对非结构化文档的搜索、返回结果的排序

统计：实时反映变化，如电商平台的在线销售订单与发货计算出的库存显示

挖掘：支持挖掘算法、机器学习的训练集

针对不同的数据处理需求，可能需要设计不同的数据存储，还需要考虑如何快速地将数据复制到对应的存储点并进行合适的结构转换，以供分析人员快速响应业务的需求。

离线数据与在线数据

根据不同的企业业务，对“离线”的定义其实不一样，在这里离线数据特指在业务场景中适用于“历史数据”的部分。常见的历史数据查询分析一般来自于特定时间段，设计上需要考虑的是将数据存入历史库中时，建立时间索引。另一种情况是某种业务问题的定位或分析，在数据量巨大的情况下，基于Hadoop或Spark等框架编写分析算法并直接在平台上运行，可以大大节约数据导出导入、格式转换与各种分析工具对接的时间。

在线数据处理按照存储和分析的先后顺序，可分为批处理(先存储后分析)和流处理(先分析后存储)两类。Cassandra数据库的设计采用上数据追加写入模式，可以支持实时批处理;流式计算平台则有Apache Storm、Yahoo S4等开源框架，商业平台有Amazon Kenisis(部署在云端)。企业的实时分析需求往往有特定的应用场景，需要对业务和现行系统有深入的理解才能设计出一个合理的架构。

以上就是关于如何提高网页运行性能全部的内容，包括:如何提高网页运行性能、大数据工程未来有哪些挑战、传统数据库与新型数据库的优缺点等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！