loadrunner响应时间及Apache 并发数的优化_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
6页免费12页免费11页1下载券4页¥2.005页免费1页免费3页免费3页免费2页免费21页1下载券
喜欢此文档的还喜欢11页1下载券3页1下载券151页免费8页免费16页1下载券
loadrunner响应时间及Apache 并发数的优化|
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢非常急！apache并发连接数如何修改？
[问题点数：100分，无满意结帖，结帖人jetjet_li]
非常急！apache并发连接数如何修改？
[问题点数：100分，无满意结帖，结帖人jetjet_li]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
2012年 总版技术专家分年内排行榜第一2007年 总版技术专家分年内排行榜第二2006年 总版技术专家分年内排行榜第二2004年 总版技术专家分年内排行榜第二
2005年 总版技术专家分年内排行榜第三2003年 总版技术专家分年内排行榜第三2002年 总版技术专家分年内排行榜第三
本帖子已过去太久远了，不再提供回复功能。Tomcat并发数优化的方法总结 - jsczxy2 - ITeye技术网站
博客分类：
web应用的并发提升，除了负载均衡。在小企业中也可以通过一些软件的上的设置来进行一些优化。下面是一些在服务器上修改tomcat参数的优化方法，非常简单实用！（这些方法通过网络整理的） 1，让Tomcat6 中支持Java语言的特性 NIO( New I/O)
使用NIO在服务器端会有更好的性能，加强服务器端对并发处理的性能。
请注意：很抱歉，在tomcat6在默认的配置选项中是没有把NIO功能打开。所以很多正在使用Tomcat6的朋友们本以为能快活的使用上NIO。 而NIO则是使用单线程(单个CPU)或者只使用少量的多线程(多CPU)来接受Socket，而由线程池来处理堵塞在pipe或者队列里的请求.这样的话，只要OS可以接受TCP的连接，web服务器就可以处理该请求。大大提高了web服务器的可伸缩性。
可以在控制台的启动信息里看见，默认状态下没有被打开nio配置，启动时的信息,如下：
12:59:40 org.apache.coyote.http11.Http11Protocol init 信息: Initializing Coyote HTTP/1.1 on http-8080
12:59:40 org.apache.catalina.startup.Catalina load 修改成支持NIO的类型，配置如下：
&Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" /&
进行测试，被打开nio配置，启动时的信息，如下：
13:01:01 org.apache.tomcat.util.net.NioSelectorPool getSharedSelector 信息: Using a shared selector for servlet write/read
13:01:01 org.apache.coyote.http11.Http11NioProtocol init 信息: Initializing Coyote HTTP/1.1 on http-8080 这样才能让你真正体验到Tomcat6下NIO给你的系统带来的快感。 2，修改Tomcat 6默认的maxThread
打开server.xml可以看到如下配置： &Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" /& 官方文档默认说支持200但似乎超过40就不行了
修改方法 :
&Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" maxThreads="150"/&
在tomcat配置文件server.xml中的&Connector ... /&配置中，和连接数相关的参数有： minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10 maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75 acceptCount：允许的最大连接数，应大于等于maxProcessors，默认值为100 enableLookups：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。 其中和最大连接数相关的参数为maxProcessors和acceptCount。如果要加大并发连接数，应同时加大这两个参数。
3,大量的并发也意味着大量的服务器资源，所以修改一下tomcat的JVM参数也是必要的 错误提示：java.lang.OutOfMemoryError: Java heap space
Windows环境下修改“%TOMCAT_HOME%\bin\catalina.bat”文件，在文件开头增加如下设置：set JAVA_OPTS=-Xms256m -Xmx512m Linux环境下修改“%TOMCAT_HOME%\bin\catalina.sh”文件，在文件开头增加如下设置：JAVA_OPTS=’-Xms256m -Xmx512m’
JVM设置 堆的尺寸 -Xmssize in bytes
设定Java堆的初始尺寸，缺省尺寸是MB)。这个值必须是1024个字节（1KB）的倍数，且比它大。（-server选项把缺省尺寸增加到32M。） -Xmnsize in bytes
为Eden对象设定初始Java堆的大小，缺省值为640K。（-server选项把缺省尺寸增加到2M。) -Xmxsize in bytes
设定Java堆的最大尺寸，缺省值为64M，（-server选项把缺省尺寸增加到128M。） 最大的堆尺寸达到将近2GB（2048MB）。 请注意：很多垃圾收集器的选项依赖于堆大小的设定。请在微调垃圾收集器使用内存空间的方式之前，确认是否已经正确设定了堆的尺寸。 垃圾收集:内存的使用 -XX:MinHeapFreeRatio=percentage as a whole number
修改垃圾回收之后堆中可用内存的最小百分比，缺省值是40。如果垃圾回收后至少还有40%的堆内存没有被释放，则系统将增加堆的尺寸。 -XX:MaxHeapFreeRatio=percentage as a whole number
改变垃圾回收之后和堆内存缩小之前可用堆内存的最大百分比，缺省值为70。这意味着如果在垃圾回收之后还有大于70%的堆内存，则系统就会减少堆的尺寸。 -XX:NewSize=size in bytes
为已分配内存的对象中的Eden代设置缺省的内存尺寸。它的缺省值是640K。（-server选项把缺省尺寸增加到2M。） -XX:MaxNewSize=size in bytes
允许您改变初期对象空间的上限，新建对象所需的内存就是从这个空间中分配来的，这个选项的缺省值是640K。（-server选项把缺省尺寸增加到2M。） -XX:NewRatio=value
改变新旧空间的尺寸比例，这个比例的缺省值是8，意思是新空间的尺寸是旧空间的1/8。 -XX:SurvivorRatio=number
改变Eden对象空间和残存空间的尺寸比例，这个比例的缺省值是10，意思是Eden对象空间的尺寸比残存空间大survivorRatio+2倍。 -XX:TargetSurvivorRatio=percentage
设定您所期望的空间提取后被使用的残存空间的百分比，缺省值是50。 -XX:MaxPermSize=size in MB
长久代（permanent generation）的尺寸，缺省值为32（32MB）。
有关JVM的参数设置可参考这个地址：/blog/893844 web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。Unix中如何设置这些参数，请参阅Unix常用监控和管理命令
浏览: 333044 次
来自: 常州
${escape:a b c}
拷贝googlemap的代码，看效果时，报google未定义， ...
你好，有完整代码？parseJSoupDocumentFrom ...
你好。你的例子很好。但是当我重启服务器的时候，服务器关闭这段时 ...Apache配置压缩优化时报错——undefined symbol: inflateEnd_服务器应用_Linux公社-Linux系统门户网站
你好，游客
Apache配置压缩优化时报错——undefined symbol: inflateEnd
来源：Linux社区&
作者：sunsky
Apache配置压缩优化时报错&&undefined symbol: inflateEnd
环境： 6.4& & 软件版本：httpd-2.4.6 apr-1.4.8 apr-util-1.5.2 pcre-8.33 其他的软件和库文件： yum -y groupinstall "Development tools" "Server Platform Development"yum -y install pcre-devel
问题描述：在apache上做压缩优化的时候，当我DSO方式添加完mod_deflate，并且配置好压缩参数之后，检查语法的是否出现如下报错：httpd: Syntax error on line 102 of /application/apache2.4.6/conf/httpd.conf: Cannot load modules/mod_deflate.so into server: /application/apache2.4.6/modules/mod_deflate.so: undefined symbol: inflateEnd未定义的符号：inflateEnd
问题处理办法：1、首先检查了httpd.conf和httpd-vhosts.conf里面的配置，均无错误；然后又查看了编译mod_deflate时的输出信息，也没有提示错误。2、我百度了inflateEnd，第一个就是搜索条目就是zlib的百度百科，然后我就去google搜索inflateEnd，搜索条目告诉我inflateEnd是属于zlib.lib库文件里面的。3、接着我在google下面找到了以前也遇到过相似问题的人，他们是在apr的主配置文件apr-1-config（老版本可能是apr-conf）里面将LDFLAGS="" 修改为 LDFLAGS="-lz"，然后用apxs从新编译mod_deflate.c后，apache服务就正常了，并且也可以正常压缩文件了。该问题的另一种解决办法：需要在 LoadModule deflate_module& modules/mod_deflate.so 的前面加载zlib.so如果是32操作系统就在LoadModule deflate_module& &
modules/mod_deflate.so这行的上一行添加LoadFile /usr/lib/libz.so即可。如果是64操作系统就在LoadModule deflate_module& &
modules/mod_deflate.so这行的上一行添加LoadFile /usr/lib64/libz.so即可。
下面是一些LDFLAGS和lz的相关信息：一、gcc 一些应用-shared生成一个共享目标文件,他可以和其他目标文件连接产生可执行文件.只有部分系统支持该选项.-Wl,option把选项option传递给连接器.如果option中含有逗号,就在逗号处分割成多个选项.-w 不生成任何警告信息。 -Wall 生成所有警告信息。lc 是link libclm 是link libmlz 是link libz-l指定程序要链接的库文件，假设库文件名为libxxx.so，链接命令为-放在/lib和/usr/lib和/usr/local/lib里的库直接用-l参数就能链接了-L指定库文件所在目录
二、Makefile选项讲解CFLAGS 表示用于 C 编译器的选项。CXXFLAGS 表示用于 C++ 编译器的选项。这两个变量实际上涵盖了编译和汇编两个步骤。
CFLAGS： 指定头文件（.h文件）的路径，如：CFLAGS=-I/usr/include -I/path/include。同样地，安装一个包时会在安装路径下建立一个include目录，当安装过程中出现问题时，试着把以前安装的包的include目录加入到该变量中来。LDFLAGS：gcc 等编译器会用到的一些优化参数，也可以在里面指定库文件的位置。用法：LDFLAGS=-L/usr/lib -L/path/to/your/lib。每安装一个包都几乎一定的会在安装目录里建立一个lib目录。如果明明安装了某个包，而安装另一个包时，它愣是说找不到，可以抒那个包的lib路径加入的LDFALGS中试一下。LIBS：告诉链接器要链接哪些库文件，如LIBS = -lpthread -liconv简单地说，LDFLAGS是告诉链接器从哪里寻找库文件，而LIBS是告诉链接器要链接哪些库文件。不过使用时链接阶段这两个参数都会加上，所以你即使将这两个的值互换，也没有问题。有时候LDFLAGS指定-L虽然能让链接器找到库进行链接，但是运行时链接器却找不到这个库，如果要让软件运行时库文件的路径也得到扩展，那么我们需要增加这两个库给"-Wl,R"：LDFLAGS = -L/var/xxx/lib -L/opt/mysql/lib -Wl,R/var/xxx/lib -Wl,R/opt/mysql/lib如果在执行./configure以前设置环境变量export LDFLAGS="-L/var/xxx/lib -L/opt/mysql/lib -Wl,R/var/xxx/lib -Wl,R/opt/mysql/lib" ，注意设置环境变量等号两边不可以有空格，而且要加上引号（shell的用法）。那么执行configure以后，Makefile将会设置这个选项，链接时会有这个参数，编译出来的可执行程序的库文件搜索路径就得到扩展了。
推荐阅读：
Linux中Subversion配置实例
CentOS 6.2 SVN搭建 (YUM安装)
Apache+SVN搭建SVN服务器
Windows下SVN服务器搭建和使用 + 客户端重新设置密码
Server 12.04 安装 SVN 并迁移 Virtual SVN数据
Ubuntu Server搭建svn服务以及迁移方法
借助网盘搭建SVN服务器
CentOS 6.3下Apache+SVN部署Web版本同步
相关资讯 & & &
& (05月20日)
图片资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款高并发上的 Nginx 优化方案_系统运维大全_优良自学吧 |
当前位置： >
> 高并发上的 Nginx 优化方案优良自学吧提供高并发上的 Nginx 优化方案,高并发下的 Nginx 优化方案 我已经谈过一些关于Nginx的常见问题，其中有一些是关于如何优化Nginx，很多Nginx新用户是从Apache迁移过来的，因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行。 我有一些坏消息要告诉你，你不能像Apache一样优化Nginx。它没有魔高并发下的 Nginx 优化方案
我已经谈过一些关于Nginx的常见问题，其中有一些是关于如何优化Nginx，很多Nginx新用户是从Apache迁移过来的，因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行。
我有一些坏消息要告诉你，你不能像Apache一样优化Nginx。它没有魔术配置来减半负载或是让PHP运行速度加快一倍。高兴的是，Nginx已经优化的非常好了，当你决定使用Nginx并用apt-get，yum或是make命令安装的时候它就已经进行了最佳优化。
(注意那些库经常过期，Wiki的安装页面上通常有最新的库)
就是说，很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况。我们也要考虑Nginx运行所在的平台，优化我们的操作系统当有一些限制的时候。
总的来说，我们无法优化单个连接的负载时间，但是我们可以确保Nginx的高并发处理环境。当然， 对于高并发我指的是每秒数百个请求连接，大多数人不需要了解这些。假如你太好奇或是想知道那就继续读吧。
首先，我们需要认识到Nginx几乎可能需要在所有的平台上使用，MacOS，Linux，FreeBSD，Solaris，Windows甚至一些更深奥的系统。他们大部分(这么翻译好些)实现了高性能的基于事件的polling方法，不幸的是Nginx的只支持其中4个系统。在四个系统中我倾向于FreeBSD，但你不会看到太大的性能差异，所以选择的操作系统让你用起来顺手，比选择最优化的操作系统更重要。
我想你一定猜到了windows不在其中。 Windows上的nginx确实没有什么理由让你值得使用。 Windows有自己的一套处理事件polling。 所以nginx的作者选择了不支持。 因此默认的还是使用select() 这种不是很高效而且性能会下降很多的方式。(初次翻译不是很好希望多多指教)
第二个最大的限制， 也是大多数人会遇到的问题是和操作系统相关的。 打开一个Shell窗口，
使用su命令切换到Nginx的运行用户， 运行命令`ulimit
-a`。 这些值也会在Nginx在运行中对它进行限制。 在许多操作系统中，&&open
files&的值是相当有限的， 在我使用的操作系统中， 它的值是 1024。 如果Nginx在运行中操作了这个限制他会记录error
log(24： Too many open files)&接着返回一个操作给客户端。 当然Nginx可以处理的文件数可以更大你也可以针对操作系统做一些改动， 你可以放心的去增加这个值。
两种方式可以实现， 你可以通过ulimit设置os的：&open
files&， 你还可以通过(nginx)配置worker_rlimit_nofile&来申明你期望的值。
Nginx 限制
除了注意操作系统的限制， 现在我来深入到Nginx本身，看看一些指令和方法，我们可以用它来调整Nginx。
Worker Processes(用英文会更好一些)
worker_process&是Nginx的主干，
一旦主进程绑定到指定的IP和端口，就会使用nginx指定的用户孵化出子进程， 之后他们会处理所有的工作。 Workers 不是多线程的， 所以不能扩展它超过CPU的核数。 所以我们应该理解设置多个(&1)workers的原理， 通常一个CPU核对应一个worker。 过犹不及，2-4个workers会伤害CPU， 在CPU成为问题之前Nginx会遇到其他的瓶颈。而通常你只是看到了空闲的进程。(这段翻的太烂了希望大家多多改进)
当你正在处理下面这种情况， 你有很多的阻塞(blocking)磁盘IO，这是你可以适当增加worker_process的值。 你需要针您的配置进行测试，检查静态文件的等待时间(waiting time)， 如果值比较大，可以适当的增加worker_process。(这段翻译完有想哭的感觉)
Worker Connections
worker_connections&是个稍稍有点怪的概念。
我不是很了解这个指令的目的， 但是它有效的限制了在同一时间内每个worker可以维护的连接数。 如果我没猜错的话， 这个配置是为了确保在keep-alive配置不正确的情况下， 当你使用的端口将要耗尽之时，增加连接数。(这个翻译的好难不知道是否正确因为作者也是forced to guess 我也只能被逼去猜了望指正)
默认的值是1024。 我们假设一个李兰奇一般情况下打开2个连接来通过管道获取网站资源，也就是最多可以同时处理512个用户的请求。听起来实在是太少了，但是我们在想一下默认的keepalive-timeout是65(在默认配置文件里面提供了65这个值，
如果没有设置该值，默认值是75，请参考wiki&keepalive_timeout)，也就是说我们实际上每秒只能处理8个连接。
显然这个值高于许多人期望的(我没觉得高呵呵)， 尤其是考虑到我们通常会设置2-4个workers。 但是对于流量较大的网站 使用keep-alive是值得的。(翻译完了又想哭了)
此外，我们还必须考虑反向代理， 这将打开一个额外的连接到后台，但是，自Nginx的不支持持久连接到后台，这不是太大的问题，除非你有长时间运行的后台进程。
所有关于worker连接的配置应该是相当清楚的，如果你流量增加了，你要相应的增加worker连接的数量。
2048对于大多数人来说应该是满足了，但老实说，如果你的流量增长了，那么对于workers的数量值应该是多少应该是很清楚的。
CPU 亲和力
设置CPU的亲和力，基本上意味着你告诉每个程序使用的CPU核心，而他们将只使用这个CPU核心。关于这一条，我不想说很多，但你要知道，如果你准备这样做，则必须非常小心。 要知道，你操作系统的 CPU 调度器处理负载均衡的能力要远远超过你。当然，如果你认为你的
CPU 负载均衡有问题，在调度层面上优化它，可能的话找一个替代的调度器。除非你知道你在做什么，否则不要碰这个。
Keep Alive
keep_alive&是
HTTP的一个特性， 它允许客户端维护与服务器已经创建的连接进行一批请求的处理直到指定的超时时间到达。 这个实际上不会在很大程度上改变我们的Nginxserver的性能， 因为Nginx能够很好的处理空闲的连接。 Nginx的作者声称10，000个空闲的连接智慧使用2。5兆内存(unbelievable)， 我个人的使用来说这个值也是靠谱的。
我在这篇性能文章里面提到这个原因非常简单。 对于最终用户来说keep alive对加载时间有着巨大的影响。 这是最重要的指标之一也是我们不断优化的原因。如果你的网站对用户来说感觉加载起来很快，他们就会很开心。 Amazon和一些其他的大型在线零售商做过许多类似的研究表明， 网站的加载时间和网站订单的完成有着直接的关系。
为什么keep
alive有着如此巨大的影响， 应该是显而易见的， 那就是你避免为所有的HTTP请求创建各自的连接， 这是非常低效的。 也许你不需要把keepalive-timeout设置为65，
但是10-20应该是比较通用的选择，正如上面一段所说， Nginx会很好的处理这方面。
tcp_nodelay 和 tcp_nopush
这两个指令也许是最难理解的nginx配置， 他们对于nginx的影响在网络的较低层。 你可以简单的认为这些指令决定了操作系统如何处理网络缓存和他们何时将这些缓存输出到最终用户(客户端)。 我只能建议大家如果你之前不了解这些概念你最好不要动它。 他们不会显著的改善或者改变性能， 所以最好使用他们的默认值。
因为我们要处理nginx带来的所有可能的限制， 所以我们现在需要弄清楚如何有效的利用我们的服务器。为了做到这点我们需要看一下硬件层面的东西，由于大部分服务器瓶颈都会发生在这里。
一般服务器主要还有3个方面的瓶颈。 CPU，内存和IO。 Nginx在CPU的利用方面是非常高效的， 所以我会坦白的告诉你这不会成为瓶颈。 同样nginx在使用内存方面也是很高效的，这也不会成为瓶颈。 现在只剩下IO这个服务器瓶颈的罪魁祸首了。(搞得像找罪犯一样)
如果你经常使用服务器，那么你可能经历过这样认识。硬盘驱动器是真的，真的很慢。从硬盘驱动器读取可能是对服务器最昂贵的操作。 所以自然得出的结论是，为了避免IO瓶颈， 我们需要大量的减少nginx对硬盘驱动器的读写。
要做到这一点，我们可以通过修改Nginx的行为，以减少磁盘写操作，以及确保对nginx的内存限制，允许它避免磁盘访问。
Access Logs
默认情况下，Nginx的每个请求都会记录在磁盘上的日志文件中，你可以使用这个方法进行统计，安全问题检查等， 带着这会在一定程度上带来IO使用成本。 如果你不打算用这些访问日志来做一些检查或其他用途， 你可以直接关闭它以避免对磁盘写操作， 但是如果你需要访问日志，你可以考虑保存日志到内存中。这将会比直接写到磁盘上快很多，并且明显减少IO的使用。
如果你只打算使用访问日志进行统计，你可以考虑使用其他的比如Google&analytics来取代(ga和access
log还是有区别的 不能简单的取代哦)，或者你只记录访问请求的部分信息而不是全部。
Error Logs
我内心小小的挣扎了一把，我是否要在这里阐述这个error
log&指令呢，因为也许你根本不希望关闭error
log， 特别是考虑到实际应用中错误日志的量会很少。 但是考虑到这里指令有一个小小的地方需要引起大家注意， 错误日志的等级参数你是可以指定的， 如果你指定的太低了他会记录404错误甚至是debug信息。 在实际的应用中可以将它设置为warn级别，将会是绰绰有余的并且能降低IO。
Open File Cache
从文件系统中读取文件由2部分组成，打开和关闭文件。
考虑到这是一个有阻塞的操作，因此不要忽略这部分。 因此， 对于我们来说缓存打开文件的描述符是非常好的，这就是open_file_cache指令的由来。
链接的wiki地址里对于使用和配置它有着非常好的说明， 所以我建议你去拜读一下。
配置Nginx缓存的大小是一个非常重要的事情。 如果缓存大小设置的太小， Nginx将不得不把上游(用英文upsteams会更好)的相应结果存放到临时的缓存文件里面，这将会同时增加IO的读写操作，
而且流量越大问题越多。
client_body_buffer_size指令用来指定处理客户端请求的缓冲区大小，
这个代表了访问请求的body。 这是用来处理POST的数据，也就是通过提交表单，文件上传等请求的数据。 如果你需要处理很多大的POST请求的，你必须确保缓存区要设置的足够大。
fastcgi_buffers&和&proxy_buffers&指令用来处理上流(upstream)的响应结果，
也就是PHP Apache等。它的概念其实和上面提到的差不多， 如果缓冲区不足够大数据将在返回给用户使用之前被保存到磁盘上。 注意Nginx将这个buffer数据同步的传输给客户端之前，有一个缓存上限， 保存到磁盘也同样受限。 这个上线是通过fastcgi_max_temp_file_size和proxy_max_temp_file_size来设置的。
另外对于代理的连接你也可以通过把proxy_buffering设置成off来彻底的关闭缓存。(通常这不是一个好办法)。
彻底移除磁盘IO
最好的减少磁盘IO的方法无疑是不使用磁盘， 如果你的的应用只有少量的数据传输，你可以将数据都放入内存，这样就可以彻底不用考虑磁盘IO的阻塞了。 当然默认情况下你的操作系统也会缓存频繁访问的磁盘扇区， 所以内存越大磁盘的IO就会用到的越少。 这就意味着你可以通过增加内存来解决IO的瓶颈。 数据量越多，需要的内存越大。
为了好玩，我们假设你有了足够大的内存来缓存你的所有数据。 这意味着理论上你的IO读速度达到了3-6gbps。 但是你没有那么快的网络通道。 不幸的是，我们可以优化的网络IO是有限的，我们要通过网络传输数据，所以还将受制于网络IO。 唯一真正有效的方法是尽量减少数据量或压缩。
幸运的是Nginx提供了gzip模块， 它可以使我们在将数据传输给客户端之前压缩它， 这将大大减少数据的大小。 一般来说gzip_comp_level的值不会在性能方面有多大的差别，设为为4-5即可。
一味的增加它是没有意义的只是浪费的CPU的周期。
你也可以通过一些javascript和css缩小工具来减少传输文件大小。 但这些不是和Nginx很相关所以我相信你通过google可以获取更多的相关信息。
翻译来源：/2011/04/optimizing-nginx-for-high-traffic-loads/
（本文来自互联网，不代表搜站(/)的观点和立场）编辑推荐最近更新