Apache 打开网页的时候等待时间过长的解决方案

服务器搭建后常常在打开页面的时候，等待很长时间，有时候，都超过一分钟了，而后才能打开，可是打开后，速度又很快，休息一会再点击，又会很慢了，遇到了这种问题很头疼，因为不是专业作服务器配置的，因此刚开始没有找到好的解决办法，只能一点点去测试了

首先尝试了，给Apache开启Gzip功能，减小数据的传输，优化网络，可是效果不明显，仍是同样的慢，如何开启GZIP，请查看上一篇日志，Apache开启GZIP。

而后尝试，加入缓存功能，也基本上没有效果，在页面中加入缓存，不在这里进行介绍了，能够查看相关资料。

通过仔细观察，发现是打开网页的时候，一直在等待xxx.xxx.com响应，证实不是GZIP或者是缓存的问题，应该是服务器响应的问题，在这个想到的，第一个是服务器能同时承受的链接数设置的过少，第二个是服务器已有资源已用完，只能等待释放新的资源。

在网上查找资料，开始修改上对于服务器的一些设置，先设置Apache的MPM模块（多路处理模块），设置模块中的相关选项，由于是使用的Windows操做系统，因此设置的模块为：<IfModule mpm_winnt_module>，此模块是在Windows服务器下使用的，该多路处理模块(MPM)是Windows NT上的默认值。它使用一个单独的父进程产生一个单独的子进程，在这个子进程中轮流产生多个线程来处理请求。

在此设置为：

ThreadStackSize 8388608   #用来控制堆栈大小

默认：NetWare上为65536，其余平台上等于操做系统默认值
这个指令用来设置处理客户端链接（包括调用模块以协助处理）的线程容许使用的最大栈尺寸（字节）。
大多数状况下，操做系统默认的栈尺寸很合理。可是在某些状况下，须要调整这个值：
在默认栈尺寸较小的平台上(好比HP-UX)，Apache可能会在使用一些须要较大栈尺寸的第三方模块时崩溃。这样的问题能够经过将ThreadStackSize设置为一个较大的值来解决。这种调整应当仅仅在第三方模块提供者明确要求的状况下才须要，或者是您经过诊断肯定是因为栈空间过小而致使崩溃。
在某些平台上，若是默认的栈空间大于服务器运行所需空间，那么将ThreadStackSize值下降到小于操做系统默认值可让每一个进程中容许生成的最大线程数量增长。这种类型的调整应该仅在测试环境中使用，而且对全部服务器进程进行充分的测试，由于处理某些罕见的请求须要较大的栈空间。一个很小的服务器配置变化就有可能使得当前的ThreadStackSize设置变得不合适。

ThreadsPerChild 350 每一个子进程的服务线程数目

每一个子进程的服务线程数目
MaxConnectionsPerChild 10000 最大链接数的一个服务器进程服务

最大链接数的一个服务器进程服务

一些其它的参数

# StartServers:　　初始数量的服务器进程开始

# MinSpareThreads:　　最小数量的工做线程,保存备用

# MaxSpareThreads:　　最大数量的工做线程,保存备用

# ThreadsPerChild:　　固定数量的工做线程在每一个服务器进程

# MaxRequestWorkers:　　最大数量的工做线程

# MaxConnectionsPerChild:　　最大链接数的一个服务器进程服务

 

因为是在进行测试，因此所设置数量，并不提供准确的值，仅为解决问题页来，具体数值大小，请参考自身设计

 

之后设置完成后，问题依然没有解决，

而后设置服务的链接超超等，在extra/httpd-default.conf 文件，须要在httpd.conf中打开此注释

修改KeepAlive 

KeepAlive指的是保持链接活跃

相似于Mysql的永久链接。若是将KeepAlive设置为On，那么来自同一客户端的请求就不须要再一次链接，避免每次请求都要新建一个链接而加剧服务器的负担。

表示单个进程的最大请求数

MaxKeepAliveRequests 指令限制了当启用KeepAlive时，每一个链接容许的请求数量。若是将此值设为”0″，将不限制请求的数目。咱们建议最好将此值设为一个比较大的值，以确保最优的服务器性能。

KeepAliveTimeout的设置说明：
Apache在关闭持久链接前等待下一个请求的秒数。一旦收到一个请求，超时值将会被设置为Timeout指令指定的秒数。
对于高负荷服务器来讲，KeepAliveTimeout值较大会致使一些性能方面的问题：超时值越大，与空闲客户端保持链接的进程就越多。

MaxRequestsPerChild 表示单个进程的最大请求数

以上设置完成后，重启服务器，测试后状况有所改观，可是仍是常常出现等待响应。

再查找资料，见到有说人到，须要根据协议类型对监听Socket进行优化。

Accept Filter 接收以后对信息进行一个过滤，有介绍说是反向一个代理，具体也不清楚，看到了，果断试一下。

AcceptFilter http none

AcceptFilter https none

 

以后重启服务，而后进行测试，通过差很少4个小时的测试，没有出现正在等待响应的问题，至此问题基本解决，同时也开启了GZIP的功能，而且也进行了一些其它的优化。一直困扰多天的问题，终于烟消云散了，至于其它的问题，只能边发现问题，边解决问题了。