本文目录一览：
- 1、CMS和Discuz有什么区别？
- 2、phpwind和discuz各自都有什么特点
- 3、ngnix 配置文件 设定timeout时间
CMS和Discuz有什么区别？
CMS是内容管理系统的简称，主要是用于搭建网站，如中国站长站，ADMIN5之类的站点都是使用CMS系统来搭建的。而DISCUZ则是一款论坛软件，是康盛推出的一款论坛程序。像国内目前很多论坛都是使用DISCUZ来实现的。确切的说这两种软件的用途是不一样的。都是供上网人员使用的但类型不同。希望我的回答 对你有些行的帮助。
phpwind和discuz各自都有什么特点
软件PHPWind Forums（中国国家版权局著作权登记号: 2006SR15880）开发至今，是国内最先保持PHP社区软件代码开源的系统，并由此带动了国内开源软件的发展。PHPWind Forums拥有众多原创的核心技术，包括：独创的模版设计体系、数据库的多表散列设计理念、索引数据文件的利用及其算法、文件读写稳定性算法、数据库索引负载均衡算法、安全防护技术等。目前已经成为全国最优秀的PHP社区软件，也是全国使用范围最为广泛的社区软件之一。
Crossday Discuz! Board（以下简称 Discuz!，中国国家版权局著作权登记号 2006SR11895）是康盛创想(北京)科技有限公司（英文简称Comsenz）推出的一套通用的社区论坛软件系统，用户可以在不需要任何编程的基础上，通过简单的设置和安装，在互联网上搭建起具备完善功能、很强负载能力和可高度定制的论坛服务。Discuz! 的基础架构采用世界上最流行的 web 编程组合 PHP+MySQL 实现，是一个经过完善设计，适用于各种服务器环境的高效论坛系统解决方案。
作为国内最大的社区软件及服务提供商，Comsenz旗下的 Discuz! 开发组具有丰富的 web 应用程序设计经验，尤其在论坛产品及相关领域，经过长期创新性开发，掌握了一整套从算法，数据结构到产品安全性方面的领先技术。使得 Discuz! 无论在稳定性，负载能力，安全保障等方面都居于国内外同类产品领先地位。
//个人认为用discuz的客户群体居多,主要是其跨平台及其强大的客服支持,所以建议用后者
ngnix 配置文件 设定timeout时间
nginx常用的超时配置说明
client_header_timeout
语法 client_header_timeout time
默认值 60s
上下文 http server（指可以放在http块和server块）
说明 指定等待client发送一个请求头的超时时间（例如：GET / HTTP/1.1）.仅当在一次read中，没有收到请求头，才会算成超时。如果在超时时间内，client没发送任何东西，nginx返回HTTP状态码408(“Request timed out”)
client_body_timeout
语法 client_body_timeout time
默认值 60s
上下文 http server location
说明 该指令设置请求体（request body）的读超时时间。仅当在一次readstep中，没有得到请求体，就会设为超时。超时后，nginx返回HTTP状态码408(“Request timed out”)
keepalive_timeout （长连接类型）
语法 keepalive_timeout timeout [ header_timeout ]
默认值 75s
上下文 http server location
说明 第一个参数指定了与client的keep-alive连接超时时间。服务器将会在这个时间后关闭连接。可选的第二个参数指定了在响应头Keep-Alive: timeout=time中的time值。这个头能够让一些浏览器主动关闭连接，这样服务器就不必要去关闭连接了。没有这个参数，nginx不会发送Keep-Alive响应头（尽管并不是由这个头来决定连接是否“keep-alive”）（服务器在返回数据给用户时，在头header文件中会添加keepalive字段，75s，浏览器在这个时间后能够主动关闭连接）
两个参数的值可并不相同
注意不同浏览器怎么处理“keep-alive”头
MSIE和Opera忽略掉"Keep-Alive: timeout=N" header.
MSIE保持连接大约60-65秒，然后发送TCP RST
Opera永久保持长连接
Mozilla keeps the connection alive for N plus about 1-10 seconds.
Konqueror保持长连接N秒
lingering_timeout
语法 lingering_timeout time
默认值 5s
上下文 http server location
说明 lingering_close生效后，在关闭连接前，会检测是否有用户发送的数据到达服务器，如果超过lingering_timeout时间后还没有数据可读，就直接关闭连接；否则，必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。
resolver_timeout
语法 resolver_timeout time
默认值 30s
上下文 http server location
说明 该指令设置DNS解析超时时间
proxy转发模块的超时设置：
proxy_connect_timeout
语法 proxy_connect_timeout time
默认值 60s
上下文 http server location
说明 该指令设置与upstream server的连接超时时间，有必要记住，这个超时不能超过75秒。
这个不是等待后端返回页面的时间，那是由proxy_read_timeout声明的。如果你的upstream服务器起来了，但是hanging住了（例如，没有足够的线程处理请求，所以把你的请求放到请求池里稍后处理），那么这个声明是没有用的，因为与upstream服务器的连接已经建立了。
This directive assigns a timeout for the connection to the proxyserver. This is not the time until the server returns the pages, this is the proxy_read_timeout statement. If your proxyserver is up, but hanging (e.g. it does not have enough threads to process your request so it puts you in the pool of connections to deal with later), then this statement will not help as the connection to the server has been made. It is necessary to keep in mind that this time out cannot be more than 75 seconds.
proxy_read_timeout
语法 proxy_read_timeout time
默认值 60s
上下文 http server location
说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间，而是两次reading操作的时间。（？？什么是两次reading操作的时间）
This directive sets the read timeout for the response of the proxied server. It determines how long NGINX will wait to get the response to a request. The timeout is established not for entire response, but only between two operations of reading.
In contrast to proxy_connect_timeout, this timeout will catch a server that puts you in it's connection pool but does not respond to you with anything beyond that. Be careful though not to set this too low, as your proxy server might take a longer time to respond to requests on purpose (e.g. when serving you a report page that takes some time to compute). You are able though to have a different setting per location, which enables you to have a higher proxy_read_timeout for the report page's location.
If the proxied server nothing will communicate after this time, then nginx is shut connection.
proxy_send_timeout
语法 proxy_send_timeout time
默认值 60s
上下文 http server location
说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间，而是在两次write操作期间。如果超时后，upstream没有收到新的数据，nginx会关闭连接
proxy_upstream_fail_timeout（fail_timeout）
语法 server address [fail_timeout=30s]
默认值 10s
上下文 upstream
说明 Upstream模块下 server指令的参数，设置了某一个upstream后端失败了指定次数（max_fails）后，该后端不可操作的时间，默认为10秒
负载均衡配置时的2个参数：fail_timeout和max_fails
这2个参数一起配合，来控制nginx怎样认为upstream中的某个server是失效的当在fail_timeout的时间内，某个server连接失败了max_fails次，则nginx会认为该server不工作了。同时，在接下来的 fail_timeout时间内，nginx不再将请求分发给失效的server。
个人认为，nginx不应该把这2个时间用同一个参数fail_timeout来控制，要是能再增加一个fail_time，来控制接下来的多长时间内，不再使用down掉的server就更好了~
如果不设置这2个参数，fail_timeout默认为10s，max_fails默认为1。就是说，只要某个server失效一次，则在接下来的10s内，就不会分发请求到该server上
send_timeout
默认：send_timeout 60;
send_timeout 指定客户端的响应超时时间。这个设置不会用于整个转发器，而是在两次客户端读取操作之间。如果在这段时间内，客户端没有读取任何数据，nginx就会关闭连接。
Directive assigns response timeout to client. Timeout is established not on entire transfer of answer, but only between two operations of reading, if after this time client will take nothing, then nginx is shutting down the connection.
另一个参考：504 Gateway Time-out问题
常见于使用nginx作为web server的服务器的网站
我遇到这个问题是在升级discuz论坛的时候遇到的
一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out
现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K
默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点
在nginx.conf里, 加入:
fastcgi_buffers 8 128k
这表示设置fastcgi缓冲区为8×128k
当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点, 例如设置成60秒:
send_timeout 60;
调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验累计才有结果。
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 32 4k;
proxy_busy_buffers_size 64k;
