WEB服务器的优化方法简介

WEB服务器的优化方法简介

在对Web服务器进行优化时要根据真实的Web应用系统的情况和特征来采取有针对性地优化方案。首先根据不同的网络特性来看：在局域网中，降低M T U (最大传输单位)值对可以避免复制数据和求校验，而通过优化select系统调用或在Socket事件处理器中执行计算可以优化请求并发管理，利用>服务器优化可以分为阶段性完成从硬件到软件的优化或者从软件到硬件的优化 要跟公司或者个人目的及意图而定
阶段性的工作是,明确你要实现的优化目的,服务器方案切割的备份以及了解服务器内部数据结构和优化的部分
对于,数据库内容以及结构引擎是要非常细腻的排列优化的 有关服务器优化方案的文章不少,你可以多了解一下,有什么问题尽管问我

数据和日志文件分开存放在不同磁盘上

数据文件和日志文件的 *** 作会产生大量的I/O 在可能的条件下 日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O 同时还有利于数据库的灾难恢复

tempdb数据库单独存放在不同磁盘上

tempdb数据库是其他所有数据库都有可能使用的临时数据库 当使用select into 在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据 由于建立和填充临时表会严重降低系统性能 所以在尽可能的情况下应该为要排序的列建立索引 同时 tempdb数据库是为所有的用户和应用程序共享 所以如果一个用户占据了tempdb数据库的所有空间 则其他数据库将不能再使用 在可能的情况下 tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上 分离tempdb数据库的I/O *** 作以加快性能 tempdb数据库应该有适当的容量 以满足用户的需要 应该允许tempdb数据库的空间自动增长 如果设置为不允许自动增长 当查询 *** 作建立了超过tempdb数据库容量的临时表时 *** 作将无法完成

适当设置tempdb数据库的增长幅度 过小的增长幅度会产生更多的外部碎片 会占用更多的资源

避免热点数据的发生

在SQLServer 之前 对于没有聚集索引的表（堆集表） 新插入的数据行总是放置在磁盘中表的物理结尾处 如果并发的用户很多 同时在对表执行插入或者更新数据的 *** 作 这将使得十分繁忙的表的末尾有可能产生数据热点 并发的I/O *** 作集中对少数页面进行 *** 作 将导致数据库性能的下降

在SQLServer中 新的数据行的物理存储空间的分配是通过PFS页面来进行的 PFS页面的管理算法将插入 *** 作进行分散来尽量避免产生数据热点

在设计应用系统和数据库时 要避免在自然增长的列上建立主键 这样有可能导致热点数据的发生

数据类型要少

在设计表时 尽可能少用数据类型 这样一个数据页面上可以保存最多的信息 数据页面就少 检索数据页面的I/O *** 作就少 所以效率会高

监控和整理空间碎片

文件空间的自动增长提高了自动管理性 但可能导致空间碎片 物理空间与数据的逻辑空间不再连续 定期的监控和空间碎片整理有利于提高I/O性能

使用主数据文件和次要数据文件

每个数据库的一个主数据文件属于主文件组 对于 GB左右规模的数据库 一个数据文件就够了 如果有次要数据文件 主数据文件中有管理次要数据文件的指针

采用多个数据文件时 主数据文件用于存储系统对象和表 次要数据文件用于存储用户数据和索引 在可能的情况下 主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O

如果采用多个数据文件 推荐主数据文件存储系统数据 次要数据文件存放用户数据和索引 这样会有助于提高I/O性能

利用文件组改善性能

在大型数据库系统中 可以考虑建立文件组来管理数据文件 将表和索引通过存放在不同的物理磁盘上进行性能监控比较 最后得出优化的存储方案

重视自动增长和自动收缩可能导致的性能问题

数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用 但可能导致大型数据库的性能问题 因为文件的自然增长的同时会导致存储碎片的发生 当文件空间变大时 新分配的空间不一定和原来的空间连续 当文件空间收缩时 释放了部分空间 然而当文件又需要增长存储空间却不能利用原先释放的空间 也会导致碎片的发生

分离系统数据和用户数据

将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能 有助于数据库备份和恢复

优化索引设计

索引的设计对数据库的性能十分重要 具体不再阐述 可参见本博相关文章

定期更新统计信息

SQLServer默认使用基于代价的优化 所以统计信息的及时更新对于查询优化十分重要

定期的一致性检查

lishixinzhi/Article/program/SQLServer/201311/22434

这个问题有点搞笑！！！

用户多，不代表你服务器访问量大，访问量大不一定你服务器压力大！我们换成专业点的问题，高并发下怎么优化能避免服务器压力过大？

1，整个架构:可采用分布式架构，利用微服务架构拆分服务部署在不同的服务节点，避免单节点宕机引起的服务不可用！

2，数据库:采用主从复制，读写分离，甚至是分库分表，表数据根据查询方式的不同采用不同的索引比如btree，hash，关键字段加索引，sql避免复合函数，避免组合排序等，避免使用非索引字段作为条件分组，排序等！减少交互次数，一定不要用select！

3，加缓存:使用诸如memcache，redis，ehcache等缓存数据库定义表，结果表等等，数据库的中间数据放缓存，避免多次访问修改表数据！登录信息session等放缓存实现共享！诸如商品分类，省市区，年龄分类等不常改变的数据，放缓存，不要放数据库！

同时要避免缓存雪崩和穿透等问题的出现导致缓存崩溃！

4，增量统计:不要实时统计大量的数据，应该采用晚间定时任务统计，增量统计等方式提前进行统计，避免实时统计的内存，CPU压力！

5，加服务器:等大文件，一定要单独经过文件服务器，避免IO速度对动态数据的影响！保证系统不会因为文件而崩溃！

6，HTML文件，枚举，静态的方法返回值等静态化处理，放入缓存！

7，负载均衡:使用nginx等对访问量过大的服务采用负载均衡，实现服务集群，提高服务的最大并发数，防止压力过大导致单个服务的崩溃！

8，加入搜索引擎:对于sql中常出现的like，in等语句，使用lucence或者solr中间件，将必要的，依赖模糊搜索的字段和数据使用搜索引擎进行存储，提升搜索速度！#注意:全量数据和增量数据进行定时任务更新！

9，使用消息中间件:对服务之间的数据传输，使用诸如rabbitmq，kafka等等分布式消息队列异步传输，防止同步传输数据的阻塞和数据丢失！

10，抛弃tomcat:做web开发，接触最早的应用服务器就是tomcat了，但是tomcat的单个最大并发量只能不到1w！采取netty等actor模型的高性能应用服务器！

11，多线程:现在的服务器都是多核心处理模式，如果代码采用单线程，同步方式处理，极大的浪费了CPU使用效率和执行时间！

12，避免阻塞:避免bio，blockingqueue等常常引起长久阻塞的技术，而改为nio等异步处理机制！

13，CDN加速:如果访问量实在过大，可根据请求来源采用CDN分流技术，避免大流量完成系统崩溃！

14，避免低效代码:不要频繁创建对象，引用，少用同步锁，不要创建大量线程，不要多层for循环！

还有更多的细节优化技术，暂时想不起来了！

先阅读apache配置优化建议如下，再对相关参数进行调整，观察服务器状况
Apache配置优化建议:
进入/usr/local/apache2/conf/extra目录下
Apache优化,
经过上述 *** 作后，Apache已经能够正常运行。但是，对于访问量稍大的站点，Apache的这些默认配置是无法满足需求的，我们仍需调整Apache的一些参数，使Apache能够在大访问量环境下发挥出更好的性能。以下我们对Apache配置文件>

1带宽和吞吐量

带宽是指通信通道的大小，吞吐量是指处理系统发送和接收数据的能力。因此，您的硬件可能无法使用您的最大带宽，因此我们可以相应地升级服务器配置，以确保网站正常运行。

2衡量您的性能

网络带宽不足往往不会导致性能下降。跟踪链接的繁忙度可以帮助您更好地了解带宽与性能之间的关系。例如，黑客可能会使用过多的带宽来耗尽带宽资源。此时，服务器可能会负载下降，因此我们需要第三方CDN产品或负载平衡来解决它。

3选择正确监控工具

使用网站监视工具来帮助我们准确地了解服务器资源的分配方式。分析长期趋势并不总是有用的，因为它们会掩盖峰值利用率。同样，仅查看峰值只会告诉您哪个链接最繁忙。好的监控软件可以为您提供完整的，以指导您的优化工作。

4确保带宽使用目的

如果您购买的服务器是共享带宽，那么运行服务器的网站可能会降低所有人的速度，包括最终用户。如果是平台型网站，为了确保企业的网络是处于足够快的速度的那么建议您使用独占带宽，当然带来的成本也会随之变高。如果业务应用程序引起很多拥塞，请升级服务器带宽以优化服务器进程，或者是否应将其从网络中删除。

---