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的功能，并且也进行了一些其它的优化。一直困扰多天的问题，终于烟消云散了，至于其它的问题，只能边发现问题，边解决问题了。