通知设置 新通知
linux开启nscd服务缓存加速
zkbhj 发表了文章 • 0 个评论 • 1274 次浏览 • 2017-03-01 17:51
在我使用的阿里云主机上有观察到开启了一个服务nscd ，后来谷哥了下该服务的作用。了解到nscd会缓存三种服务passwd group hosts，所以它会记录三个库，分别对应源/etc/passwd, /etc/hosts 和 /etc/resolv.conf每个库保存两份缓存，一份是找到记录的，一份是没有找到记录的。每一种缓存都保存有生存时间（TTL）。其作用就是在本当中增加cache ，加快如DNS的解析等的速度。
一、nscd的配置
通过编辑/etc/nscd.conf文件，在其中增加如下一行可以开启本地DNS cache：
enable-cache hosts yes阿里云主机上的配置如下：
[root@361way ~]# cat /etc/nscd.conf
#logfile /var/log/nscd.log
threads 6
max-threads 128
server-user nscd
debug-level 5
paranoia no
enable-cache passwd no
enable-cache group no
enable-cache hosts yes
positive-time-to-live hosts 5
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432相关参数的解释如下：
logfile debug-file-name
指定调试信息写入的文件名。
debug-level value
设置希望的调试级别。
threads number
这是启动的等待请求的线程数。最少将创建5个线程。
server-user user
如果设置了该选项，nscd将作为该用户运行，而不是作为root。如果每个用户都使用一个单独的缓存（-S参数），将忽略该选项。
enable-cache service <yes|no>
启用或禁用制定的 服务 缓存。
positive-time-to-live service value
设置 service 在指定缓存中正的项目（成功的请求）的TTL（存活时间）。 Value 以秒为单位。较大的值将增加缓存命中率从而减低平均响应时间，但是将增加缓存的一致性问题。
negative-time-to-live service value
设置 service 在指定缓存中负的项目（失败的请求）的TTL（存活时间）。 Value 以秒为单位。如果存在由不在系统数据库中的uid（用户ID）（例如在以root身份解包linux 内核源代码时）所拥有的文件将明显改善性能；应该维持较小的值以降低缓存一致性问题。
suggested-size service value
这是内部散列表的大小， value 应该保持一个素数以达到优化效果。
check-files service <yes|no>
启用或禁用检查属于指定 服务 的文件的改变。这些文件是 /etc/passwd， /etc/group， 以及/etc/hosts。
二、nscd 服务查看和清除
默认该服务在redhat或centos下是关闭的，可以通过services nscd start开启。缓存DB文件在/var/db/nscd下。可以通过nscd -g查看统计的信息，这里列出部分：
[root@361way ~]# nscd -g
nscd configuration:
5 server debug level
34d 23h 14m 18s server runtime
6 current number of threads
128 maximum number of threads
0 number of times clients had to wait
no paranoia mode enabled
3600 restart internal
5 reload count
passwd cache:
no cache is enabled
no cache is persistent
no cache is shared
0 suggested size
0 total data pool size
0 used data pool size
3600 seconds time to live for positive entries
20 seconds time to live for negative entries
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 current number of cached values
0 maximum number of cached values
0 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/passwd for changes清除缓存
nscd -i passwd
nscd -i group
nscd -i hosts除了上面的方法，重启nscd服务同样可以达到清理cache的目的。
三、nscd的效果
首先要看网络和dns服务器的能力,dns解析越慢,dns缓存的优势就越大.比如我们在北京用的dns服务器202.106.0.20和google的dns服务器8.8.8.8速度会差不少.
如果dns服务器比较稳定,那它对效率的影响就是一个常数.这个常数有多大呢?
我简单试了一下.在局域网内进行压力测试,压一个nginx下的静态页面,使用202.106.0.20这个dns服务器,不用dns缓存.平均一分钟可以访问27万次.压一个简单的php页面,平均一分钟可以访问22万次.加上nscd服务后,静态页面平均一分钟可以访问120万次,要快4倍多.php页面平均一分钟可以访问50万次,快一倍多.
如果是做搜索引擎或是一些代理服务类的项目,比如短信通道,数据推送服务,这个性能提升还是比较可观的.但在一般的项目中,一台服务器每分钟发22万次请求的情况是很少见的,所以这个性能提升也微呼其微.
但在追求极限的道路上,每一小步都至关重要噢~
原文链接：http://www.361way.com/linux-ns ... .html
查看全部
一、nscd的配置
通过编辑/etc/nscd.conf文件，在其中增加如下一行可以开启本地DNS cache：
enable-cache hosts yes阿里云主机上的配置如下：
[root@361way ~]# cat /etc/nscd.conf
#logfile /var/log/nscd.log
threads 6
max-threads 128
server-user nscd
debug-level 5
paranoia no
enable-cache passwd no
enable-cache group no
enable-cache hosts yes
positive-time-to-live hosts 5
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432相关参数的解释如下：
logfile debug-file-name
指定调试信息写入的文件名。
debug-level value
设置希望的调试级别。
threads number
这是启动的等待请求的线程数。最少将创建5个线程。
server-user user
如果设置了该选项，nscd将作为该用户运行，而不是作为root。如果每个用户都使用一个单独的缓存（-S参数），将忽略该选项。
enable-cache service <yes|no>
启用或禁用制定的 服务 缓存。
positive-time-to-live service value
设置 service 在指定缓存中正的项目（成功的请求）的TTL（存活时间）。 Value 以秒为单位。较大的值将增加缓存命中率从而减低平均响应时间，但是将增加缓存的一致性问题。
negative-time-to-live service value
设置 service 在指定缓存中负的项目（失败的请求）的TTL（存活时间）。 Value 以秒为单位。如果存在由不在系统数据库中的uid（用户ID）（例如在以root身份解包linux 内核源代码时）所拥有的文件将明显改善性能；应该维持较小的值以降低缓存一致性问题。
suggested-size service value
这是内部散列表的大小， value 应该保持一个素数以达到优化效果。
check-files service <yes|no>
启用或禁用检查属于指定 服务 的文件的改变。这些文件是 /etc/passwd， /etc/group， 以及/etc/hosts。
二、nscd 服务查看和清除
默认该服务在redhat或centos下是关闭的，可以通过services nscd start开启。缓存DB文件在/var/db/nscd下。可以通过nscd -g查看统计的信息，这里列出部分：
[root@361way ~]# nscd -g
nscd configuration:
5 server debug level
34d 23h 14m 18s server runtime
6 current number of threads
128 maximum number of threads
0 number of times clients had to wait
no paranoia mode enabled
3600 restart internal
5 reload count
passwd cache:
no cache is enabled
no cache is persistent
no cache is shared
0 suggested size
0 total data pool size
0 used data pool size
3600 seconds time to live for positive entries
20 seconds time to live for negative entries
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 current number of cached values
0 maximum number of cached values
0 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/passwd for changes清除缓存
nscd -i passwd
nscd -i group
nscd -i hosts除了上面的方法，重启nscd服务同样可以达到清理cache的目的。
三、nscd的效果
首先要看网络和dns服务器的能力,dns解析越慢,dns缓存的优势就越大.比如我们在北京用的dns服务器202.106.0.20和google的dns服务器8.8.8.8速度会差不少.
如果dns服务器比较稳定,那它对效率的影响就是一个常数.这个常数有多大呢?
我简单试了一下.在局域网内进行压力测试,压一个nginx下的静态页面,使用202.106.0.20这个dns服务器,不用dns缓存.平均一分钟可以访问27万次.压一个简单的php页面,平均一分钟可以访问22万次.加上nscd服务后,静态页面平均一分钟可以访问120万次,要快4倍多.php页面平均一分钟可以访问50万次,快一倍多.
如果是做搜索引擎或是一些代理服务类的项目,比如短信通道,数据推送服务,这个性能提升还是比较可观的.但在一般的项目中,一台服务器每分钟发22万次请求的情况是很少见的,所以这个性能提升也微呼其微.
但在追求极限的道路上,每一小步都至关重要噢~
原文链接：http://www.361way.com/linux-ns ... .html
查看全部
在我使用的阿里云主机上有观察到开启了一个服务nscd ，后来谷哥了下该服务的作用。了解到nscd会缓存三种服务passwd group hosts，所以它会记录三个库，分别对应源/etc/passwd, /etc/hosts 和 /etc/resolv.conf每个库保存两份缓存，一份是找到记录的，一份是没有找到记录的。每一种缓存都保存有生存时间（TTL）。其作用就是在本当中增加cache ，加快如DNS的解析等的速度。
一、nscd的配置
通过编辑/etc/nscd.conf文件，在其中增加如下一行可以开启本地DNS cache：
logfile debug-file-name
指定调试信息写入的文件名。
debug-level value
设置希望的调试级别。
threads number
这是启动的等待请求的线程数。最少将创建5个线程。
server-user user
如果设置了该选项，nscd将作为该用户运行，而不是作为root。如果每个用户都使用一个单独的缓存（-S参数），将忽略该选项。
enable-cache service <yes|no>
启用或禁用制定的 服务 缓存。
positive-time-to-live service value
设置 service 在指定缓存中正的项目（成功的请求）的TTL（存活时间）。 Value 以秒为单位。较大的值将增加缓存命中率从而减低平均响应时间，但是将增加缓存的一致性问题。
negative-time-to-live service value
设置 service 在指定缓存中负的项目（失败的请求）的TTL（存活时间）。 Value 以秒为单位。如果存在由不在系统数据库中的uid（用户ID）（例如在以root身份解包linux 内核源代码时）所拥有的文件将明显改善性能；应该维持较小的值以降低缓存一致性问题。
suggested-size service value
这是内部散列表的大小， value 应该保持一个素数以达到优化效果。
check-files service <yes|no>
启用或禁用检查属于指定 服务 的文件的改变。这些文件是 /etc/passwd， /etc/group， 以及/etc/hosts。
二、nscd 服务查看和清除
默认该服务在redhat或centos下是关闭的，可以通过services nscd start开启。缓存DB文件在/var/db/nscd下。可以通过nscd -g查看统计的信息，这里列出部分：
三、nscd的效果
首先要看网络和dns服务器的能力,dns解析越慢,dns缓存的优势就越大.比如我们在北京用的dns服务器202.106.0.20和google的dns服务器8.8.8.8速度会差不少.
如果dns服务器比较稳定,那它对效率的影响就是一个常数.这个常数有多大呢?
我简单试了一下.在局域网内进行压力测试,压一个nginx下的静态页面,使用202.106.0.20这个dns服务器,不用dns缓存.平均一分钟可以访问27万次.压一个简单的php页面,平均一分钟可以访问22万次.加上nscd服务后,静态页面平均一分钟可以访问120万次,要快4倍多.php页面平均一分钟可以访问50万次,快一倍多.
如果是做搜索引擎或是一些代理服务类的项目,比如短信通道,数据推送服务,这个性能提升还是比较可观的.但在一般的项目中,一台服务器每分钟发22万次请求的情况是很少见的,所以这个性能提升也微呼其微.
但在追求极限的道路上,每一小步都至关重要噢~
原文链接：http://www.361way.com/linux-ns ... .html
一、nscd的配置
通过编辑/etc/nscd.conf文件，在其中增加如下一行可以开启本地DNS cache：
enable-cache hosts yes阿里云主机上的配置如下：
[root@361way ~]# cat /etc/nscd.conf相关参数的解释如下：
#logfile /var/log/nscd.log
threads 6
max-threads 128
server-user nscd
debug-level 5
paranoia no
enable-cache passwd no
enable-cache group no
enable-cache hosts yes
positive-time-to-live hosts 5
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
logfile debug-file-name
指定调试信息写入的文件名。
debug-level value
设置希望的调试级别。
threads number
这是启动的等待请求的线程数。最少将创建5个线程。
server-user user
如果设置了该选项，nscd将作为该用户运行，而不是作为root。如果每个用户都使用一个单独的缓存（-S参数），将忽略该选项。
enable-cache service <yes|no>
启用或禁用制定的 服务 缓存。
positive-time-to-live service value
设置 service 在指定缓存中正的项目（成功的请求）的TTL（存活时间）。 Value 以秒为单位。较大的值将增加缓存命中率从而减低平均响应时间，但是将增加缓存的一致性问题。
negative-time-to-live service value
设置 service 在指定缓存中负的项目（失败的请求）的TTL（存活时间）。 Value 以秒为单位。如果存在由不在系统数据库中的uid（用户ID）（例如在以root身份解包linux 内核源代码时）所拥有的文件将明显改善性能；应该维持较小的值以降低缓存一致性问题。
suggested-size service value
这是内部散列表的大小， value 应该保持一个素数以达到优化效果。
check-files service <yes|no>
启用或禁用检查属于指定 服务 的文件的改变。这些文件是 /etc/passwd， /etc/group， 以及/etc/hosts。
二、nscd 服务查看和清除
默认该服务在redhat或centos下是关闭的，可以通过services nscd start开启。缓存DB文件在/var/db/nscd下。可以通过nscd -g查看统计的信息，这里列出部分：
[root@361way ~]# nscd -g清除缓存
nscd configuration:
5 server debug level
34d 23h 14m 18s server runtime
6 current number of threads
128 maximum number of threads
0 number of times clients had to wait
no paranoia mode enabled
3600 restart internal
5 reload count
passwd cache:
no cache is enabled
no cache is persistent
no cache is shared
0 suggested size
0 total data pool size
0 used data pool size
3600 seconds time to live for positive entries
20 seconds time to live for negative entries
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 current number of cached values
0 maximum number of cached values
0 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/passwd for changes
nscd -i passwd除了上面的方法，重启nscd服务同样可以达到清理cache的目的。
nscd -i group
nscd -i hosts
三、nscd的效果
首先要看网络和dns服务器的能力,dns解析越慢,dns缓存的优势就越大.比如我们在北京用的dns服务器202.106.0.20和google的dns服务器8.8.8.8速度会差不少.
如果dns服务器比较稳定,那它对效率的影响就是一个常数.这个常数有多大呢?
我简单试了一下.在局域网内进行压力测试,压一个nginx下的静态页面,使用202.106.0.20这个dns服务器,不用dns缓存.平均一分钟可以访问27万次.压一个简单的php页面,平均一分钟可以访问22万次.加上nscd服务后,静态页面平均一分钟可以访问120万次,要快4倍多.php页面平均一分钟可以访问50万次,快一倍多.
如果是做搜索引擎或是一些代理服务类的项目,比如短信通道,数据推送服务,这个性能提升还是比较可观的.但在一般的项目中,一台服务器每分钟发22万次请求的情况是很少见的,所以这个性能提升也微呼其微.
但在追求极限的道路上,每一小步都至关重要噢~
原文链接：http://www.361way.com/linux-ns ... .html
吞吐量（Throughput）、QPS、并发数、响应时间（RT）对系统性能的影响
zkbhj 发表了文章 • 0 个评论 • 2252 次浏览 • 2017-02-23 19:13
首先对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念一直比较模糊，也不知道哪些指标可以较好的衡量系统的性能。今天特意查了些资料做一些记录：首先看一些概念（来自百度百科）
1. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量，QPS更关心处理笔数。
QPS提升带来什么？QPS提升说明单台服务器处理能力提升，如果QPS提升1倍，服务器资源减少1半，或者说服务器不变可以支撑2倍的请求量。
如何提升QPS？
1）减少CPU的使用时间（哪些代码会消耗CPU：循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩）
2）增加CPU的数量
3）减少同步锁
（如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
RT提升带来什么？
响应速度提升说明单次请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。
如何提升RT？
1）减少I/O的响应时间
2）减少I/O的调用次数
3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）
QPS和TPS的区别
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
吞吐量和TPS不是同一个概念，给你举个例子吧，比如一个水龙头开一晚上出水10t，而10个水龙头开1s中出水0.1t，你能说一个水龙头的出水能力比10个水龙头的强么？所以，我们要加个单位时间，看谁1s的出水量大，这就是吞吐率，即TPS。明白了吧。吞吐量中的那个单位时间我们通常是以系统运行的时间为单位比如10分钟。而TPS中的单位时间通常是s。
追问:
我是否可以这样理解：
1、TPS就是通过的事务数\时间
2、吞吐量是和请求数量相关的
-------------------------------------华丽丽的分割线-------------------------------------------------
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。
單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鐘request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
查看全部
1. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量，QPS更关心处理笔数。
QPS提升带来什么？QPS提升说明单台服务器处理能力提升，如果QPS提升1倍，服务器资源减少1半，或者说服务器不变可以支撑2倍的请求量。
如何提升QPS？
1）减少CPU的使用时间（哪些代码会消耗CPU：循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩）
2）增加CPU的数量
3）减少同步锁
（如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
RT提升带来什么？
响应速度提升说明单次请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。
如何提升RT？
1）减少I/O的响应时间
2）减少I/O的调用次数
3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）
QPS和TPS的区别
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
吞吐量和TPS不是同一个概念，给你举个例子吧，比如一个水龙头开一晚上出水10t，而10个水龙头开1s中出水0.1t，你能说一个水龙头的出水能力比10个水龙头的强么？所以，我们要加个单位时间，看谁1s的出水量大，这就是吞吐率，即TPS。明白了吧。吞吐量中的那个单位时间我们通常是以系统运行的时间为单位比如10分钟。而TPS中的单位时间通常是s。
追问:
我是否可以这样理解：
1、TPS就是通过的事务数\时间
2、吞吐量是和请求数量相关的
-------------------------------------华丽丽的分割线-------------------------------------------------
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。
單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鐘request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
查看全部
首先对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念一直比较模糊，也不知道哪些指标可以较好的衡量系统的性能。今天特意查了些资料做一些记录：首先看一些概念（来自百度百科）
1. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量，QPS更关心处理笔数。
QPS提升带来什么？QPS提升说明单台服务器处理能力提升，如果QPS提升1倍，服务器资源减少1半，或者说服务器不变可以支撑2倍的请求量。
如何提升QPS？
1）减少CPU的使用时间（哪些代码会消耗CPU：循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩）
2）增加CPU的数量
3）减少同步锁
（如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
RT提升带来什么？
响应速度提升说明单次请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。
如何提升RT？
1）减少I/O的响应时间
2）减少I/O的调用次数
3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）
QPS和TPS的区别
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
吞吐量和TPS不是同一个概念，给你举个例子吧，比如一个水龙头开一晚上出水10t，而10个水龙头开1s中出水0.1t，你能说一个水龙头的出水能力比10个水龙头的强么？所以，我们要加个单位时间，看谁1s的出水量大，这就是吞吐率，即TPS。明白了吧。吞吐量中的那个单位时间我们通常是以系统运行的时间为单位比如10分钟。而TPS中的单位时间通常是s。
追问:
我是否可以这样理解：
1、TPS就是通过的事务数\时间
2、吞吐量是和请求数量相关的
-------------------------------------华丽丽的分割线-------------------------------------------------
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。
單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鐘request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
1. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
从以上概念来看吞吐量和响应时间是衡量系统性能的重要指标，QPS虽然和吞吐量的计量单位不同，但应该是成正比的，任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量，QPS更关心处理笔数。
QPS提升带来什么？QPS提升说明单台服务器处理能力提升，如果QPS提升1倍，服务器资源减少1半，或者说服务器不变可以支撑2倍的请求量。
如何提升QPS？
1）减少CPU的使用时间（哪些代码会消耗CPU：循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩）
2）增加CPU的数量
3）减少同步锁
（如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）
RT提升带来什么？
响应速度提升说明单次请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。
如何提升RT？
1）减少I/O的响应时间
2）减少I/O的调用次数
3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）
QPS和TPS的区别
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
吞吐量和TPS不是同一个概念，给你举个例子吧，比如一个水龙头开一晚上出水10t，而10个水龙头开1s中出水0.1t，你能说一个水龙头的出水能力比10个水龙头的强么？所以，我们要加个单位时间，看谁1s的出水量大，这就是吞吐率，即TPS。明白了吧。吞吐量中的那个单位时间我们通常是以系统运行的时间为单位比如10分钟。而TPS中的单位时间通常是s。
追问:
我是否可以这样理解：
1、TPS就是通过的事务数\时间
2、吞吐量是和请求数量相关的
-------------------------------------华丽丽的分割线-------------------------------------------------
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。
單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鐘request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
502 Bad Gateway出现的原因以及解决办法
zkbhj 发表了文章 • 0 个评论 • 1764 次浏览 • 2017-02-20 10:31
502 bad gateway通常出现在Nginx服务器中，其中造成的原因也比较多样性，其中对用户访问请求的响应超时造成的情况最为常见，那么502 Bad Gateway该怎么解决呢，下面我们就分情况介绍一下502 Bad Gateway的主要原因与解决方法。
什么是502 bad gateway 报错
简单来说 502 是报错类型代码 bad gateway 错误的网关。是Web服务器作为网关或代理服务器时收到无效的响应。 用我们的口语说就是运行网站的服务器暂时挂了(不响应)。
产生错误的原因
1.连接超时 我们向服务器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应,产生此类报错
2.Nginx本身设置等cgi接口返回的数据延时太短，要延长这个时间。如同前面说的，很多情况下并非Nginx本身的问题，这样操作后常常并不能缓解问题。
此时，就要考虑对应cgi接口的配置，比如 php-fpm.conf 的配置，脚本执行时间的超时情况限制。这可以通过跟踪php-fpm的 slow log 来排查，对相关代码优化，减少延时。
3.另外很大的问题在MySQL数据库这一块，如果数据库执行命令超时也会大延长php脚本的执行时间，导致 Nginx 等待超时。可以my.cnf的 slow log进行确认效能低下的sql语句是哪些，进行优化配置。
502 bad gateway解决方法
普通访客
一般情况下稍候访问或者按下快捷键 ctrl+F5强制刷新一下，这样就是重新向服务器发送请求了。再或者清理一下电脑的缓冲文件.(如果一直都是这样，我们就只能等管理员来解决)
管理员
1.查看当前的PHP FastCGI进程数是否够用
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的"FastCGI进程数"接近预设的"FastCGI进程数"，那么，说明"FastCGI进程数"不够用，需要增大。
2.部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间。
其他方法：
1.提高 Web 服务器的响应速度，也即减少内部的调用关系，可以把需要的页面、素材或数据，缓存在内存中，可以是专门的缓存服务器 ，也可以Web服务器自身的缓存，提高响应速度;
2.网络带宽的问题，则对传输的数据包进行压缩处理，或者向IDC申请增加带宽;
3.属于内部网络的故障或设置问题，也即内部网络拥塞，可能内部存在大量的数据调用或交互造成的，则需要优化内部网络传输或协议;
4.数据库的数据读取造成前端服务器 ，响应用户的请求变慢，那么必须提高数据库的处理能力，若是只读业务可以增加数据缓存的模式 或者增加数据库备机，分散读压力;
参考文档：
http://mt.sohu.com/20161223/n476739428.shtml
http://www.linuxidc.com/Linux/2016-03/128812.htm
http://www.cnblogs.com/siqi/p/3658771.html
查看全部
什么是502 bad gateway 报错
简单来说 502 是报错类型代码 bad gateway 错误的网关。是Web服务器作为网关或代理服务器时收到无效的响应。 用我们的口语说就是运行网站的服务器暂时挂了(不响应)。
产生错误的原因
1.连接超时 我们向服务器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应,产生此类报错
2.Nginx本身设置等cgi接口返回的数据延时太短，要延长这个时间。如同前面说的，很多情况下并非Nginx本身的问题，这样操作后常常并不能缓解问题。
此时，就要考虑对应cgi接口的配置，比如 php-fpm.conf 的配置，脚本执行时间的超时情况限制。这可以通过跟踪php-fpm的 slow log 来排查，对相关代码优化，减少延时。
3.另外很大的问题在MySQL数据库这一块，如果数据库执行命令超时也会大延长php脚本的执行时间，导致 Nginx 等待超时。可以my.cnf的 slow log进行确认效能低下的sql语句是哪些，进行优化配置。
502 bad gateway解决方法
普通访客
一般情况下稍候访问或者按下快捷键 ctrl+F5强制刷新一下，这样就是重新向服务器发送请求了。再或者清理一下电脑的缓冲文件.(如果一直都是这样，我们就只能等管理员来解决)
管理员
1.查看当前的PHP FastCGI进程数是否够用
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的"FastCGI进程数"接近预设的"FastCGI进程数"，那么，说明"FastCGI进程数"不够用，需要增大。
2.部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间。
其他方法：
1.提高 Web 服务器的响应速度，也即减少内部的调用关系，可以把需要的页面、素材或数据，缓存在内存中，可以是专门的缓存服务器 ，也可以Web服务器自身的缓存，提高响应速度;
2.网络带宽的问题，则对传输的数据包进行压缩处理，或者向IDC申请增加带宽;
3.属于内部网络的故障或设置问题，也即内部网络拥塞，可能内部存在大量的数据调用或交互造成的，则需要优化内部网络传输或协议;
4.数据库的数据读取造成前端服务器 ，响应用户的请求变慢，那么必须提高数据库的处理能力，若是只读业务可以增加数据缓存的模式 或者增加数据库备机，分散读压力;
参考文档：
http://mt.sohu.com/20161223/n476739428.shtml
http://www.linuxidc.com/Linux/2016-03/128812.htm
http://www.cnblogs.com/siqi/p/3658771.html
查看全部
502 bad gateway通常出现在Nginx服务器中，其中造成的原因也比较多样性，其中对用户访问请求的响应超时造成的情况最为常见，那么502 Bad Gateway该怎么解决呢，下面我们就分情况介绍一下502 Bad Gateway的主要原因与解决方法。
什么是502 bad gateway 报错
简单来说 502 是报错类型代码 bad gateway 错误的网关。是Web服务器作为网关或代理服务器时收到无效的响应。 用我们的口语说就是运行网站的服务器暂时挂了(不响应)。
产生错误的原因
1.连接超时 我们向服务器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应,产生此类报错
2.Nginx本身设置等cgi接口返回的数据延时太短，要延长这个时间。如同前面说的，很多情况下并非Nginx本身的问题，这样操作后常常并不能缓解问题。
此时，就要考虑对应cgi接口的配置，比如 php-fpm.conf 的配置，脚本执行时间的超时情况限制。这可以通过跟踪php-fpm的 slow log 来排查，对相关代码优化，减少延时。
3.另外很大的问题在MySQL数据库这一块，如果数据库执行命令超时也会大延长php脚本的执行时间，导致 Nginx 等待超时。可以my.cnf的 slow log进行确认效能低下的sql语句是哪些，进行优化配置。
502 bad gateway解决方法
普通访客
一般情况下稍候访问或者按下快捷键 ctrl+F5强制刷新一下，这样就是重新向服务器发送请求了。再或者清理一下电脑的缓冲文件.(如果一直都是这样，我们就只能等管理员来解决)
管理员
1.查看当前的PHP FastCGI进程数是否够用
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的"FastCGI进程数"接近预设的"FastCGI进程数"，那么，说明"FastCGI进程数"不够用，需要增大。
2.部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间。
其他方法：
1.提高 Web 服务器的响应速度，也即减少内部的调用关系，可以把需要的页面、素材或数据，缓存在内存中，可以是专门的缓存服务器 ，也可以Web服务器自身的缓存，提高响应速度;
2.网络带宽的问题，则对传输的数据包进行压缩处理，或者向IDC申请增加带宽;
3.属于内部网络的故障或设置问题，也即内部网络拥塞，可能内部存在大量的数据调用或交互造成的，则需要优化内部网络传输或协议;
4.数据库的数据读取造成前端服务器 ，响应用户的请求变慢，那么必须提高数据库的处理能力，若是只读业务可以增加数据缓存的模式 或者增加数据库备机，分散读压力;
参考文档：
http://mt.sohu.com/20161223/n476739428.shtml
http://www.linuxidc.com/Linux/2016-03/128812.htm
http://www.cnblogs.com/siqi/p/3658771.html
什么是502 bad gateway 报错
简单来说 502 是报错类型代码 bad gateway 错误的网关。是Web服务器作为网关或代理服务器时收到无效的响应。 用我们的口语说就是运行网站的服务器暂时挂了(不响应)。
产生错误的原因
1.连接超时 我们向服务器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应,产生此类报错
2.Nginx本身设置等cgi接口返回的数据延时太短，要延长这个时间。如同前面说的，很多情况下并非Nginx本身的问题，这样操作后常常并不能缓解问题。
此时，就要考虑对应cgi接口的配置，比如 php-fpm.conf 的配置，脚本执行时间的超时情况限制。这可以通过跟踪php-fpm的 slow log 来排查，对相关代码优化，减少延时。
3.另外很大的问题在MySQL数据库这一块，如果数据库执行命令超时也会大延长php脚本的执行时间，导致 Nginx 等待超时。可以my.cnf的 slow log进行确认效能低下的sql语句是哪些，进行优化配置。
502 bad gateway解决方法
普通访客
一般情况下稍候访问或者按下快捷键 ctrl+F5强制刷新一下，这样就是重新向服务器发送请求了。再或者清理一下电脑的缓冲文件.(如果一直都是这样，我们就只能等管理员来解决)
管理员
1.查看当前的PHP FastCGI进程数是否够用
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的"FastCGI进程数"接近预设的"FastCGI进程数"，那么，说明"FastCGI进程数"不够用，需要增大。
2.部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间。
其他方法：
1.提高 Web 服务器的响应速度，也即减少内部的调用关系，可以把需要的页面、素材或数据，缓存在内存中，可以是专门的缓存服务器 ，也可以Web服务器自身的缓存，提高响应速度;
2.网络带宽的问题，则对传输的数据包进行压缩处理，或者向IDC申请增加带宽;
3.属于内部网络的故障或设置问题，也即内部网络拥塞，可能内部存在大量的数据调用或交互造成的，则需要优化内部网络传输或协议;
4.数据库的数据读取造成前端服务器 ，响应用户的请求变慢，那么必须提高数据库的处理能力，若是只读业务可以增加数据缓存的模式 或者增加数据库备机，分散读压力;
参考文档：
http://mt.sohu.com/20161223/n476739428.shtml
http://www.linuxidc.com/Linux/2016-03/128812.htm
http://www.cnblogs.com/siqi/p/3658771.html
Nginx+FPM结构模型剖析及优化
zkbhj 发表了文章 • 0 个评论 • 1583 次浏览 • 2016-12-20 10:28
随着php脚本语言使用的普及，目前webserice服务大部分都在用nginx+(php-fpm)的结构，了解了其工作过程后才可以在各个方面想办法做调整优化和故障排查，从以下几点总结一下这种模型。
一、nginx和php-fpm的关系和分工
nginx是web服务器，php-fpm是一个PHPFastCGI进程管理器，两者遵循fastcgi的协议进行通信，nginx负责静态类似html文件的处理，php-fpm负责php脚本语言的执行，这么设计的目的是为了解耦前端nginx和后端的php，不至于让容易出问题的php脚本堵塞整个nginx的业务处理，影响用户体验，因为php脚本语言的执行是会比较容易出问题的。nginx之所以能处理成千上万高并发业务，除其本身的异步非阻塞模式，在与和其他模块的耦合扩展方法也是分不开的，在nginx的设计里不能接受的就是阻塞，不过并非完全没有梗，比如说用到的最多的多进程单线程的模式，由于nginx日志没有单独的处理进程，如果收集日志时处理不当就会把worker进程堵死。
对应nginx+php-fpm的模型结构图如下：
1、nginx的工作简介
接到php的脚本请求后，nginx通过fastcgi_pass指令将请求传递给后端php-fpm的worker进程处理，在此过程中，nginx做了各种超时机制、缓存机制、buffer机制和长连接机制等来保障与后端的php-fpm能够良性高效的合作。
在超时机制方面控制nginx对后端php的等待时间，通过各种timeout指令进行控制，例如：
fastcgi_connect_timeout ： 后端链接时间
fastcgi_send_timeout ： 数据发送时间，两次成功发送时间差，不是整个发送时间
fastcgi_read_timeout ： 数据接收时间，两次成功接收时间差，不是整个接收时间
当超时后会返回504超时的状态码，在buffer机制指令也有很多，例如：
fastcgi_buffer_size 存放fastcgi传过来的响应头，一般设置为分页大小
fastcgi_buffers 存放fastcgi传过来的相应内容，一般设置分页的倍数，格式例如 8 4k|8k另外还有一些其它的缓存、长连接机制不做介绍，当设置不合理时也会出现5XX错误，nginx的文章介绍写了有很多的，不再做过多的说明。
2、php-fpm工作介绍
Php-fpm是一个PHPfastcgi进程管理器，在启动后会有master和worker两种进程，master负责接收外部信号和管理worker进程，worker进程是负责干活的，处理nginx传过来的任务。
master进程只有一个，负责监听端口和管理worker进程，每次传来任务，与前端的nginx建立3次握手后放入连接队列，供worker进程进行accept，当worker进程出现错误或执行超时时，负责将worker进程重启或者杀掉，是php-fpm模型中的大内总管。
Worker进程是工作进程，每个worker进程都独立的执行php程序脚本，然后把执行的结果通过fastcgi协议交给nginx，执行过程中受master的管理。在工作中，worker进程去竞争accept管理进程master的链接队列，accept函数将从连接请求队列中获得连接信息，创建新的socket，并返回该套接字的fd，新创建的socket用于服务器与nginx的通信，而原来的套接字仍然处于监听状态。
php-fpm可以配置多个pool，所有pool由master统一管理监听不同端口并分配不同worker进程池，worker进程池支持动态prefork同时也支持静态开启，服务器内存较大时建议直接计算后配置静态资源池，可以减少频繁prefork进程所带来的开销，提高服务质量，由于进程模型越跑程序耗费越大，因为每个worker进程可以配置执行多少个请求后进行重启，对应的池子的指令和执行多少个请求的指令如下：
pm = static | dynamic | ondemand ：静态池、服务优先、内存优先
pm.max_children = 256 ： 开启的最大php进程数
pm.max_requests = 1024 ： 在执行了1024个请求后重启worker进程
这也是我们线上服务器的配置，我们线上用的web服务的机器是12核cpu、16G内存，nginx开启12个worker进程，php开启256个进程，跑起来后每个进程大概占用30M内存，也就是（256+12）*30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置**减少了prefork进程带来的开销，RT时间100ms以内的占到90%以上（这个与程序写的如何有关），运行一段时间后的开销截图如下：
二、此模型结构常见的5XX服务器端错误及优化
1、nginx日志里产生502错误
第一种情况，php-fpm的worker进程执行php程序脚本时，超过了配置的最长执行时间，master进程将worker进程杀掉，直接返回502。返回502后nginx对应的error日志是104: Connection reset by peer,对应的php执行时间的配置如下，一些版本中php-fpm的配置会覆盖php.ini的配置，使php.ini的配置不起作用：php.ini中默认30s：max_execution_time =
php-fpm中：request_terminate_timeout =
第二种情况，连接请求数（accpet之前）超出了端口所能监听的tcp连接的最大值（backlog的值），进不了fpm等待accept的链接队列，直接返回502，这里可能会产生tcp重传；返回502后nginx对应的error日志是111: Connection refused, backlog的值是半连接和全连接的总和，他的存在也有短时间缓冲解耦nginx请求与fpm处理的作用，半连接指收到了syn请求，3次握手尚未建立，全连接指的是3次握手已经成功，不过尚未被accpet的请求，fpm里面有调节的参数，如果fpm的参数设置为-1，则默认走的是系统内核参数net.core.somaxconn的设置值，如果不设置可以在/proc/sys/net/core/somaxconn里查看，默认值是128，所以在连接请求较高的业务里要增大这个值。
第三种情况，网络卡时，客户端断开连接，nginx处显示499，然后php检查到前端nginx产生abort后，又master结束此条任务的继而产生502，一般此种情况的报警，先是499，过会儿变成502，再过一会变成504.
减少避免502报错优化建议
502主要从php-fpm的配置方考虑，根据服务器情况，适量增大php-fpm的工作进程数，适当增加php的执行时间，适当增加backlog值。
php的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个php进程是占到30M左右的内存，开多少合适自己算吧，nginx的worker进程一般也能跑到30M的内存，综合计算一下；php的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是502错误，这个按照实际的情况处理吧，反正我是觉得执行的慢有返回结果总比直接返回502错误的强；至于backlog值，当程序写的比较好时，建议设置其数量为php工作进程的1到2倍。
2、nginx日志里产生504错误
第一种情况，php的worker进程池处理慢，无法尽快处理等待accept的链接队列，导致3次握手后的链接队列长时间没有被accept，nginx链接等待超时；返回504后nginx对应的error日志是110: Connection timed out
第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制，这个时候也是会报出504错误的。
第三种情况，客户端的网络及其差，php将请求处理完交给nginx后，nginx没能在超时时间内将内容全部吐给用户，这时也会超时，只有504而没有502。
减少避免504报错的优化建议
504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
另外：在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。 查看全部
一、nginx和php-fpm的关系和分工
nginx是web服务器，php-fpm是一个PHPFastCGI进程管理器，两者遵循fastcgi的协议进行通信，nginx负责静态类似html文件的处理，php-fpm负责php脚本语言的执行，这么设计的目的是为了解耦前端nginx和后端的php，不至于让容易出问题的php脚本堵塞整个nginx的业务处理，影响用户体验，因为php脚本语言的执行是会比较容易出问题的。nginx之所以能处理成千上万高并发业务，除其本身的异步非阻塞模式，在与和其他模块的耦合扩展方法也是分不开的，在nginx的设计里不能接受的就是阻塞，不过并非完全没有梗，比如说用到的最多的多进程单线程的模式，由于nginx日志没有单独的处理进程，如果收集日志时处理不当就会把worker进程堵死。
对应nginx+php-fpm的模型结构图如下：
1、nginx的工作简介
接到php的脚本请求后，nginx通过fastcgi_pass指令将请求传递给后端php-fpm的worker进程处理，在此过程中，nginx做了各种超时机制、缓存机制、buffer机制和长连接机制等来保障与后端的php-fpm能够良性高效的合作。
在超时机制方面控制nginx对后端php的等待时间，通过各种timeout指令进行控制，例如：
fastcgi_connect_timeout ： 后端链接时间
fastcgi_send_timeout ： 数据发送时间，两次成功发送时间差，不是整个发送时间
fastcgi_read_timeout ： 数据接收时间，两次成功接收时间差，不是整个接收时间
当超时后会返回504超时的状态码，在buffer机制指令也有很多，例如：
fastcgi_buffer_size 存放fastcgi传过来的响应头，一般设置为分页大小
fastcgi_buffers 存放fastcgi传过来的相应内容，一般设置分页的倍数，格式例如 8 4k|8k另外还有一些其它的缓存、长连接机制不做介绍，当设置不合理时也会出现5XX错误，nginx的文章介绍写了有很多的，不再做过多的说明。
2、php-fpm工作介绍
Php-fpm是一个PHPfastcgi进程管理器，在启动后会有master和worker两种进程，master负责接收外部信号和管理worker进程，worker进程是负责干活的，处理nginx传过来的任务。
master进程只有一个，负责监听端口和管理worker进程，每次传来任务，与前端的nginx建立3次握手后放入连接队列，供worker进程进行accept，当worker进程出现错误或执行超时时，负责将worker进程重启或者杀掉，是php-fpm模型中的大内总管。
Worker进程是工作进程，每个worker进程都独立的执行php程序脚本，然后把执行的结果通过fastcgi协议交给nginx，执行过程中受master的管理。在工作中，worker进程去竞争accept管理进程master的链接队列，accept函数将从连接请求队列中获得连接信息，创建新的socket，并返回该套接字的fd，新创建的socket用于服务器与nginx的通信，而原来的套接字仍然处于监听状态。
php-fpm可以配置多个pool，所有pool由master统一管理监听不同端口并分配不同worker进程池，worker进程池支持动态prefork同时也支持静态开启，服务器内存较大时建议直接计算后配置静态资源池，可以减少频繁prefork进程所带来的开销，提高服务质量，由于进程模型越跑程序耗费越大，因为每个worker进程可以配置执行多少个请求后进行重启，对应的池子的指令和执行多少个请求的指令如下：
pm = static | dynamic | ondemand ：静态池、服务优先、内存优先
pm.max_children = 256 ： 开启的最大php进程数
pm.max_requests = 1024 ： 在执行了1024个请求后重启worker进程
这也是我们线上服务器的配置，我们线上用的web服务的机器是12核cpu、16G内存，nginx开启12个worker进程，php开启256个进程，跑起来后每个进程大概占用30M内存，也就是（256+12）*30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置**减少了prefork进程带来的开销，RT时间100ms以内的占到90%以上（这个与程序写的如何有关），运行一段时间后的开销截图如下：
二、此模型结构常见的5XX服务器端错误及优化
1、nginx日志里产生502错误
第一种情况，php-fpm的worker进程执行php程序脚本时，超过了配置的最长执行时间，master进程将worker进程杀掉，直接返回502。返回502后nginx对应的error日志是104: Connection reset by peer,对应的php执行时间的配置如下，一些版本中php-fpm的配置会覆盖php.ini的配置，使php.ini的配置不起作用：php.ini中默认30s：max_execution_time =
php-fpm中：request_terminate_timeout =
第二种情况，连接请求数（accpet之前）超出了端口所能监听的tcp连接的最大值（backlog的值），进不了fpm等待accept的链接队列，直接返回502，这里可能会产生tcp重传；返回502后nginx对应的error日志是111: Connection refused, backlog的值是半连接和全连接的总和，他的存在也有短时间缓冲解耦nginx请求与fpm处理的作用，半连接指收到了syn请求，3次握手尚未建立，全连接指的是3次握手已经成功，不过尚未被accpet的请求，fpm里面有调节的参数，如果fpm的参数设置为-1，则默认走的是系统内核参数net.core.somaxconn的设置值，如果不设置可以在/proc/sys/net/core/somaxconn里查看，默认值是128，所以在连接请求较高的业务里要增大这个值。
第三种情况，网络卡时，客户端断开连接，nginx处显示499，然后php检查到前端nginx产生abort后，又master结束此条任务的继而产生502，一般此种情况的报警，先是499，过会儿变成502，再过一会变成504.
减少避免502报错优化建议
502主要从php-fpm的配置方考虑，根据服务器情况，适量增大php-fpm的工作进程数，适当增加php的执行时间，适当增加backlog值。
php的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个php进程是占到30M左右的内存，开多少合适自己算吧，nginx的worker进程一般也能跑到30M的内存，综合计算一下；php的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是502错误，这个按照实际的情况处理吧，反正我是觉得执行的慢有返回结果总比直接返回502错误的强；至于backlog值，当程序写的比较好时，建议设置其数量为php工作进程的1到2倍。
2、nginx日志里产生504错误
第一种情况，php的worker进程池处理慢，无法尽快处理等待accept的链接队列，导致3次握手后的链接队列长时间没有被accept，nginx链接等待超时；返回504后nginx对应的error日志是110: Connection timed out
第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制，这个时候也是会报出504错误的。
第三种情况，客户端的网络及其差，php将请求处理完交给nginx后，nginx没能在超时时间内将内容全部吐给用户，这时也会超时，只有504而没有502。
减少避免504报错的优化建议
504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
另外：在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。 查看全部
随着php脚本语言使用的普及，目前webserice服务大部分都在用nginx+(php-fpm)的结构，了解了其工作过程后才可以在各个方面想办法做调整优化和故障排查，从以下几点总结一下这种模型。
一、nginx和php-fpm的关系和分工
nginx是web服务器，php-fpm是一个PHPFastCGI进程管理器，两者遵循fastcgi的协议进行通信，nginx负责静态类似html文件的处理，php-fpm负责php脚本语言的执行，这么设计的目的是为了解耦前端nginx和后端的php，不至于让容易出问题的php脚本堵塞整个nginx的业务处理，影响用户体验，因为php脚本语言的执行是会比较容易出问题的。nginx之所以能处理成千上万高并发业务，除其本身的异步非阻塞模式，在与和其他模块的耦合扩展方法也是分不开的，在nginx的设计里不能接受的就是阻塞，不过并非完全没有梗，比如说用到的最多的多进程单线程的模式，由于nginx日志没有单独的处理进程，如果收集日志时处理不当就会把worker进程堵死。
对应nginx+php-fpm的模型结构图如下：
1、nginx的工作简介
接到php的脚本请求后，nginx通过fastcgi_pass指令将请求传递给后端php-fpm的worker进程处理，在此过程中，nginx做了各种超时机制、缓存机制、buffer机制和长连接机制等来保障与后端的php-fpm能够良性高效的合作。
在超时机制方面控制nginx对后端php的等待时间，通过各种timeout指令进行控制，例如：
当超时后会返回504超时的状态码，在buffer机制指令也有很多，例如：
2、php-fpm工作介绍
Php-fpm是一个PHPfastcgi进程管理器，在启动后会有master和worker两种进程，master负责接收外部信号和管理worker进程，worker进程是负责干活的，处理nginx传过来的任务。
master进程只有一个，负责监听端口和管理worker进程，每次传来任务，与前端的nginx建立3次握手后放入连接队列，供worker进程进行accept，当worker进程出现错误或执行超时时，负责将worker进程重启或者杀掉，是php-fpm模型中的大内总管。
Worker进程是工作进程，每个worker进程都独立的执行php程序脚本，然后把执行的结果通过fastcgi协议交给nginx，执行过程中受master的管理。在工作中，worker进程去竞争accept管理进程master的链接队列，accept函数将从连接请求队列中获得连接信息，创建新的socket，并返回该套接字的fd，新创建的socket用于服务器与nginx的通信，而原来的套接字仍然处于监听状态。
php-fpm可以配置多个pool，所有pool由master统一管理监听不同端口并分配不同worker进程池，worker进程池支持动态prefork同时也支持静态开启，服务器内存较大时建议直接计算后配置静态资源池，可以减少频繁prefork进程所带来的开销，提高服务质量，由于进程模型越跑程序耗费越大，因为每个worker进程可以配置执行多少个请求后进行重启，对应的池子的指令和执行多少个请求的指令如下：
这也是我们线上服务器的配置，我们线上用的web服务的机器是12核cpu、16G内存，nginx开启12个worker进程，php开启256个进程，跑起来后每个进程大概占用30M内存，也就是（256+12）*30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置**减少了prefork进程带来的开销，RT时间100ms以内的占到90%以上（这个与程序写的如何有关），运行一段时间后的开销截图如下：
二、此模型结构常见的5XX服务器端错误及优化
1、nginx日志里产生502错误
第一种情况，php-fpm的worker进程执行php程序脚本时，超过了配置的最长执行时间，master进程将worker进程杀掉，直接返回502。返回502后nginx对应的error日志是104: Connection reset by peer,对应的php执行时间的配置如下，一些版本中php-fpm的配置会覆盖php.ini的配置，使php.ini的配置不起作用：
第二种情况，连接请求数（accpet之前）超出了端口所能监听的tcp连接的最大值（backlog的值），进不了fpm等待accept的链接队列，直接返回502，这里可能会产生tcp重传；返回502后nginx对应的error日志是111: Connection refused, backlog的值是半连接和全连接的总和，他的存在也有短时间缓冲解耦nginx请求与fpm处理的作用，半连接指收到了syn请求，3次握手尚未建立，全连接指的是3次握手已经成功，不过尚未被accpet的请求，fpm里面有调节的参数，如果fpm的参数设置为-1，则默认走的是系统内核参数net.core.somaxconn的设置值，如果不设置可以在/proc/sys/net/core/somaxconn里查看，默认值是128，所以在连接请求较高的业务里要增大这个值。
第三种情况，网络卡时，客户端断开连接，nginx处显示499，然后php检查到前端nginx产生abort后，又master结束此条任务的继而产生502，一般此种情况的报警，先是499，过会儿变成502，再过一会变成504.
减少避免502报错优化建议
502主要从php-fpm的配置方考虑，根据服务器情况，适量增大php-fpm的工作进程数，适当增加php的执行时间，适当增加backlog值。
php的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个php进程是占到30M左右的内存，开多少合适自己算吧，nginx的worker进程一般也能跑到30M的内存，综合计算一下；php的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是502错误，这个按照实际的情况处理吧，反正我是觉得执行的慢有返回结果总比直接返回502错误的强；至于backlog值，当程序写的比较好时，建议设置其数量为php工作进程的1到2倍。
2、nginx日志里产生504错误
第一种情况，php的worker进程池处理慢，无法尽快处理等待accept的链接队列，导致3次握手后的链接队列长时间没有被accept，nginx链接等待超时；返回504后nginx对应的error日志是110: Connection timed out
第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制，这个时候也是会报出504错误的。
第三种情况，客户端的网络及其差，php将请求处理完交给nginx后，nginx没能在超时时间内将内容全部吐给用户，这时也会超时，只有504而没有502。
减少避免504报错的优化建议
504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：
另外：在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。
一、nginx和php-fpm的关系和分工
nginx是web服务器，php-fpm是一个PHPFastCGI进程管理器，两者遵循fastcgi的协议进行通信，nginx负责静态类似html文件的处理，php-fpm负责php脚本语言的执行，这么设计的目的是为了解耦前端nginx和后端的php，不至于让容易出问题的php脚本堵塞整个nginx的业务处理，影响用户体验，因为php脚本语言的执行是会比较容易出问题的。nginx之所以能处理成千上万高并发业务，除其本身的异步非阻塞模式，在与和其他模块的耦合扩展方法也是分不开的，在nginx的设计里不能接受的就是阻塞，不过并非完全没有梗，比如说用到的最多的多进程单线程的模式，由于nginx日志没有单独的处理进程，如果收集日志时处理不当就会把worker进程堵死。
对应nginx+php-fpm的模型结构图如下：
1、nginx的工作简介
接到php的脚本请求后，nginx通过fastcgi_pass指令将请求传递给后端php-fpm的worker进程处理，在此过程中，nginx做了各种超时机制、缓存机制、buffer机制和长连接机制等来保障与后端的php-fpm能够良性高效的合作。
在超时机制方面控制nginx对后端php的等待时间，通过各种timeout指令进行控制，例如：
fastcgi_connect_timeout ： 后端链接时间
fastcgi_send_timeout ： 数据发送时间，两次成功发送时间差，不是整个发送时间
fastcgi_read_timeout ： 数据接收时间，两次成功接收时间差，不是整个接收时间
当超时后会返回504超时的状态码，在buffer机制指令也有很多，例如：
fastcgi_buffer_size 存放fastcgi传过来的响应头，一般设置为分页大小另外还有一些其它的缓存、长连接机制不做介绍，当设置不合理时也会出现5XX错误，nginx的文章介绍写了有很多的，不再做过多的说明。
fastcgi_buffers 存放fastcgi传过来的相应内容，一般设置分页的倍数，格式例如 8 4k|8k
2、php-fpm工作介绍
Php-fpm是一个PHPfastcgi进程管理器，在启动后会有master和worker两种进程，master负责接收外部信号和管理worker进程，worker进程是负责干活的，处理nginx传过来的任务。
master进程只有一个，负责监听端口和管理worker进程，每次传来任务，与前端的nginx建立3次握手后放入连接队列，供worker进程进行accept，当worker进程出现错误或执行超时时，负责将worker进程重启或者杀掉，是php-fpm模型中的大内总管。
Worker进程是工作进程，每个worker进程都独立的执行php程序脚本，然后把执行的结果通过fastcgi协议交给nginx，执行过程中受master的管理。在工作中，worker进程去竞争accept管理进程master的链接队列，accept函数将从连接请求队列中获得连接信息，创建新的socket，并返回该套接字的fd，新创建的socket用于服务器与nginx的通信，而原来的套接字仍然处于监听状态。
php-fpm可以配置多个pool，所有pool由master统一管理监听不同端口并分配不同worker进程池，worker进程池支持动态prefork同时也支持静态开启，服务器内存较大时建议直接计算后配置静态资源池，可以减少频繁prefork进程所带来的开销，提高服务质量，由于进程模型越跑程序耗费越大，因为每个worker进程可以配置执行多少个请求后进行重启，对应的池子的指令和执行多少个请求的指令如下：
pm = static | dynamic | ondemand ：静态池、服务优先、内存优先
pm.max_children = 256 ： 开启的最大php进程数
pm.max_requests = 1024 ： 在执行了1024个请求后重启worker进程
这也是我们线上服务器的配置，我们线上用的web服务的机器是12核cpu、16G内存，nginx开启12个worker进程，php开启256个进程，跑起来后每个进程大概占用30M内存，也就是（256+12）*30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置**减少了prefork进程带来的开销，RT时间100ms以内的占到90%以上（这个与程序写的如何有关），运行一段时间后的开销截图如下：
二、此模型结构常见的5XX服务器端错误及优化
1、nginx日志里产生502错误
第一种情况，php-fpm的worker进程执行php程序脚本时，超过了配置的最长执行时间，master进程将worker进程杀掉，直接返回502。返回502后nginx对应的error日志是104: Connection reset by peer,对应的php执行时间的配置如下，一些版本中php-fpm的配置会覆盖php.ini的配置，使php.ini的配置不起作用：
php.ini中默认30s：max_execution_time =
php-fpm中：request_terminate_timeout =
第二种情况，连接请求数（accpet之前）超出了端口所能监听的tcp连接的最大值（backlog的值），进不了fpm等待accept的链接队列，直接返回502，这里可能会产生tcp重传；返回502后nginx对应的error日志是111: Connection refused, backlog的值是半连接和全连接的总和，他的存在也有短时间缓冲解耦nginx请求与fpm处理的作用，半连接指收到了syn请求，3次握手尚未建立，全连接指的是3次握手已经成功，不过尚未被accpet的请求，fpm里面有调节的参数，如果fpm的参数设置为-1，则默认走的是系统内核参数net.core.somaxconn的设置值，如果不设置可以在/proc/sys/net/core/somaxconn里查看，默认值是128，所以在连接请求较高的业务里要增大这个值。
第三种情况，网络卡时，客户端断开连接，nginx处显示499，然后php检查到前端nginx产生abort后，又master结束此条任务的继而产生502，一般此种情况的报警，先是499，过会儿变成502，再过一会变成504.
减少避免502报错优化建议
502主要从php-fpm的配置方考虑，根据服务器情况，适量增大php-fpm的工作进程数，适当增加php的执行时间，适当增加backlog值。
php的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个php进程是占到30M左右的内存，开多少合适自己算吧，nginx的worker进程一般也能跑到30M的内存，综合计算一下；php的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是502错误，这个按照实际的情况处理吧，反正我是觉得执行的慢有返回结果总比直接返回502错误的强；至于backlog值，当程序写的比较好时，建议设置其数量为php工作进程的1到2倍。
2、nginx日志里产生504错误
第一种情况，php的worker进程池处理慢，无法尽快处理等待accept的链接队列，导致3次握手后的链接队列长时间没有被accept，nginx链接等待超时；返回504后nginx对应的error日志是110: Connection timed out
第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制，这个时候也是会报出504错误的。
第三种情况，客户端的网络及其差，php将请求处理完交给nginx后，nginx没能在超时时间内将内容全部吐给用户，这时也会超时，只有504而没有502。
减少避免504报错的优化建议
504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
另外：在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。
docker的常用命令
zkbhj 发表了文章 • 0 个评论 • 1378 次浏览 • 2016-12-06 11:35
1、查看当前的Docker虚拟机的状态：docker-machine ls
2、创建一个Docker虚拟机：docker-machine create --driver=virtualbox default
3、获得虚拟机的环境变量：docker-machine env default
4、把当前的PowerShell和虚拟机里面的Docker Linux建立连接，可以在PowerShell中使用docker命令：docker-machine env default | Invoke-Expression
5、查看虚拟机的ip地址：docker-machine ip6、查看当前有哪些镜像：docker images7、当前有哪些容器：docker ps –a8、查看docker所有容器和镜像的数量、docker使用的执行驱动和存储驱动，以及docker的基本配置：docker info9、创建容器：docker run -i -t ubuntu /bin/bash
-i标志保证容器中STDIN是开启的 -t告诉docker为创建的容器分配一个伪tty终端，进而该容器才能提供一个交互式的shell Ubuntu 是一个基础镜像，指定该容器基于那哥基础镜像为基础 仅启动了一个容器，未向容器内添加任何东西/bin/bash 命令告诉docker在新容器中要运行什么命令
10、给容器命名：--namedocker run --name mydockername -i -t ubuntu /bin/bash
11、容器的启动、重新启动和创建（不运行）：docker start mydockername
docker restart mydockername
docker create mydockername
12、附着到正在运行的容器上：docker attach mydockername/mydockerid13、创建守护式容器：-ddocker run --name mydockername -d centos /bin/sh -c "while true;do echo hello zhengkai;sleep 1;done"14、获取守护式容器的日志：docker logs (-f) mydockername15、查看容器内的进程docker top mydockername16、查看一个活多个容器的统计信息docker status mydockername1 mydockername2 mydockername317、在docker容器内部运行进程：docker exec -d mydockername touch /etc/new_config_file18、停止容器命令docker stop mydockername
docker kill mydockername19、自动重启容器：docker run --restart=always --name mydockername -d centos /bin/sh -c "while true;do echo zhengkai;sleep 1;done"always:无论容器推出代码是什么，都重启容器
on-failure：当容器的推出代码为非0时，退出容器，可以指定重启次数参数。
20、深入容器：docker inspect mydockername
docker inspet --format='{{ .State.Running }}' mydockername21、删除容器：docker rm mydockername
docker rm mydockername 'docker ps -a -q'22、列出docker镜像：
docker images23、单独拉取仓库中的镜像：
docker pull centos:11.01 下载完成后可以使用下面的命令查看：
docker images centos 查看全部
2、创建一个Docker虚拟机：docker-machine create --driver=virtualbox default
3、获得虚拟机的环境变量：docker-machine env default
4、把当前的PowerShell和虚拟机里面的Docker Linux建立连接，可以在PowerShell中使用docker命令：docker-machine env default | Invoke-Expression
5、查看虚拟机的ip地址：docker-machine ip6、查看当前有哪些镜像：docker images7、当前有哪些容器：docker ps –a8、查看docker所有容器和镜像的数量、docker使用的执行驱动和存储驱动，以及docker的基本配置：docker info9、创建容器：docker run -i -t ubuntu /bin/bash
-i标志保证容器中STDIN是开启的 -t告诉docker为创建的容器分配一个伪tty终端，进而该容器才能提供一个交互式的shell Ubuntu 是一个基础镜像，指定该容器基于那哥基础镜像为基础 仅启动了一个容器，未向容器内添加任何东西/bin/bash 命令告诉docker在新容器中要运行什么命令
10、给容器命名：--namedocker run --name mydockername -i -t ubuntu /bin/bash
11、容器的启动、重新启动和创建（不运行）：docker start mydockername
docker restart mydockername
docker create mydockername
12、附着到正在运行的容器上：docker attach mydockername/mydockerid13、创建守护式容器：-ddocker run --name mydockername -d centos /bin/sh -c "while true;do echo hello zhengkai;sleep 1;done"14、获取守护式容器的日志：docker logs (-f) mydockername15、查看容器内的进程docker top mydockername16、查看一个活多个容器的统计信息docker status mydockername1 mydockername2 mydockername317、在docker容器内部运行进程：docker exec -d mydockername touch /etc/new_config_file18、停止容器命令docker stop mydockername
docker kill mydockername19、自动重启容器：docker run --restart=always --name mydockername -d centos /bin/sh -c "while true;do echo zhengkai;sleep 1;done"always:无论容器推出代码是什么，都重启容器
on-failure：当容器的推出代码为非0时，退出容器，可以指定重启次数参数。
20、深入容器：docker inspect mydockername
docker inspet --format='{{ .State.Running }}' mydockername21、删除容器：docker rm mydockername
docker rm mydockername 'docker ps -a -q'22、列出docker镜像：
docker images23、单独拉取仓库中的镜像：
docker pull centos:11.01 下载完成后可以使用下面的命令查看：
docker images centos 查看全部
1、查看当前的Docker虚拟机的状态：
2、创建一个Docker虚拟机：
3、获得虚拟机的环境变量：
4、把当前的PowerShell和虚拟机里面的Docker Linux建立连接，可以在PowerShell中使用docker命令：
5、查看虚拟机的ip地址：
10、给容器命名：--name
11、容器的启动、重新启动和创建（不运行）：
12、附着到正在运行的容器上：
on-failure：当容器的推出代码为非0时，退出容器，可以指定重启次数参数。
20、深入容器：
docker-machine ls
2、创建一个Docker虚拟机：
docker-machine create --driver=virtualbox default
3、获得虚拟机的环境变量：
docker-machine env default
4、把当前的PowerShell和虚拟机里面的Docker Linux建立连接，可以在PowerShell中使用docker命令：
docker-machine env default | Invoke-Expression
5、查看虚拟机的ip地址：
docker-machine ip6、查看当前有哪些镜像：
docker images7、当前有哪些容器：
docker ps –a8、查看docker所有容器和镜像的数量、docker使用的执行驱动和存储驱动，以及docker的基本配置：
docker info9、创建容器：
docker run -i -t ubuntu /bin/bash
- -i标志保证容器中STDIN是开启的
- -t告诉docker为创建的容器分配一个伪tty终端，进而该容器才能提供一个交互式的shell
- Ubuntu 是一个基础镜像，指定该容器基于那哥基础镜像为基础
- 仅启动了一个容器，未向容器内添加任何东西
- /bin/bash 命令告诉docker在新容器中要运行什么命令
10、给容器命名：--name
docker run --name mydockername -i -t ubuntu /bin/bash
11、容器的启动、重新启动和创建（不运行）：
docker start mydockername
docker restart mydockername
docker create mydockername
12、附着到正在运行的容器上：
docker attach mydockername/mydockerid13、创建守护式容器：-d
docker run --name mydockername -d centos /bin/sh -c "while true;do echo hello zhengkai;sleep 1;done"14、获取守护式容器的日志：
docker logs (-f) mydockername15、查看容器内的进程
docker top mydockername16、查看一个活多个容器的统计信息
docker status mydockername1 mydockername2 mydockername317、在docker容器内部运行进程：
docker exec -d mydockername touch /etc/new_config_file18、停止容器命令
docker stop mydockername19、自动重启容器：
docker kill mydockername
docker run --restart=always --name mydockername -d centos /bin/sh -c "while true;do echo zhengkai;sleep 1;done"always:无论容器推出代码是什么，都重启容器
on-failure：当容器的推出代码为非0时，退出容器，可以指定重启次数参数。
20、深入容器：
docker inspect mydockername21、删除容器：
docker inspet --format='{{ .State.Running }}' mydockername
docker rm mydockername22、列出docker镜像：
docker rm mydockername 'docker ps -a -q'
docker images23、单独拉取仓库中的镜像：
docker pull centos:11.01下载完成后可以使用下面的命令查看：
docker images centos
Session 的存储方式
zkbhj 发表了文章 • 0 个评论 • 1346 次浏览 • 2016-11-21 16:57
Session 的存储方式
在 php.ini 文件中，进行配置。
涉及配置参数： - session.save_handler
- session.save_path注意：这两个参数可以在 PHP 中通过 ini_set 来设置，不用直接覆盖原 php.ini 中的值。
一、文件存储session.save_handler = files
session.save_path = "N;MODE;/path"注释：N 表示多级目录，值为数字。MODE 表示创建的 Session 文件权限。/path 表示 Session 存储路径。
这里我设置
session.save_path = "2;600;/tmp/"重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
结果报错
PHP Warning: session_start(): open(/tmp/h/p/sess_hpbfs95c9omtfn30h5lt43i597, O_RDWR) failed: No such file or directory
为什么呢？
我们来看下PHP官网怎么说的吧
此指令还有一个可选的 N 参数来决定会话文件分布的目录深度。例如，设定为 '5;/tmp' 将使创建的会话文件和路径类似于 /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。 要使用 N 参数，必须在使用前先创建好这些目录。 在 ext/session 目录下有个小的 shell 脚本名叫 mod_files.sh，windows 版本是 mod_files.bat 可以用来做这件事。 此外注意如果使用了 N 参数并且大于 0，那么将不会执行自动垃圾回收，更多信息见 php.ini。 另外如果用了 N 参数，要确保将 session.save_path 的值用双引号 "quotes" 括起来，因为分隔符分号（ ;）在 php.ini 中也是注释符号。 文件储存模块默认使用 mode 600 创建文件。通过 修改可选参数 MODE 来改变这种默认行为： N;MODE;/path ，其中 MODE 是 mode 的八进制表示。 MODE 设置不影响进程的掩码(umask)。 Caution：使用以上描述的可选目录层级参数 N 时请注意，对于绝大多数站点，大于1或者2的值会不太合适——因为这需要创建大量的目录：例如，值设置为 3 需要在文件系统上创建 64^3 个目录，将浪费很多空间和 inode。仅仅在绝对肯定站点足够大时，才可以设置 N 大于2。
了解这些，我们就开始处理 Session 存储目录的创建了，注意子目录的权限问题。
bash /path/to/mod_files.sh
使用多级目录的后果就是，你必须手动清理这些 Session。
二、Redis
首先你得安装了 Redis 扩展
session.save_handler = redis
//多节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5,tcp://ip2:port2?weight=2"
//单个节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5"
//socket 方式
session.save_path = "unix:///var/run/redis/redis.sock?persistent=1&weight=1&database=0
解释一下，涉及参数的含义：
ip: Redis 节点的 IP。
port: Redis 节点的端口。
auth: 与 Redis 节点进行权限验证。
weight: 权重，上面的例子表示session数量，ip2节点 是 ip1节点的两倍。
timeout: Redis 连接超时时间。单位：秒。连接失败时，Session不可用（风险！）
persistent: 持久连接。
prefix: 前缀，默认是 "PHPREDIS_SESSION:"。
database: 选择哪个 Redis 数据库。取值：int。参见 Redis 配置 databases 16。
重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
我们看看效果
redis-cli
127.0.0.1:6379> KEYS *
1) "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
127.0.0.1:6379> TYPE "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
string
127.0.0.1:6379> get "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
"admin_user|a:3:{s:8:\"username\";s:4:\"test\";s:4:\"name\";s:4:\"test";s:5:\"email\";s:12:\"test@test.cn\";}"
127.0.0.1:6379> ttl "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
(integer) 292
可以看到 Session 存入了 Redis 中，数据结构用的是 String。
Session 的过期时间
使用 php.ini 中的 session.gc_maxlifetime
可以通过 ini_set 在 php 中自定义。
多机房的 Redis 存储怎么弄？
同步呗！ 查看全部
在 php.ini 文件中，进行配置。
涉及配置参数： - session.save_handler
- session.save_path注意：这两个参数可以在 PHP 中通过 ini_set 来设置，不用直接覆盖原 php.ini 中的值。
一、文件存储session.save_handler = files
session.save_path = "N;MODE;/path"注释：N 表示多级目录，值为数字。MODE 表示创建的 Session 文件权限。/path 表示 Session 存储路径。
这里我设置
session.save_path = "2;600;/tmp/"重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
结果报错
PHP Warning: session_start(): open(/tmp/h/p/sess_hpbfs95c9omtfn30h5lt43i597, O_RDWR) failed: No such file or directory
为什么呢？
我们来看下PHP官网怎么说的吧
此指令还有一个可选的 N 参数来决定会话文件分布的目录深度。例如，设定为 '5;/tmp' 将使创建的会话文件和路径类似于 /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。 要使用 N 参数，必须在使用前先创建好这些目录。 在 ext/session 目录下有个小的 shell 脚本名叫 mod_files.sh，windows 版本是 mod_files.bat 可以用来做这件事。 此外注意如果使用了 N 参数并且大于 0，那么将不会执行自动垃圾回收，更多信息见 php.ini。 另外如果用了 N 参数，要确保将 session.save_path 的值用双引号 "quotes" 括起来，因为分隔符分号（ ;）在 php.ini 中也是注释符号。 文件储存模块默认使用 mode 600 创建文件。通过 修改可选参数 MODE 来改变这种默认行为： N;MODE;/path ，其中 MODE 是 mode 的八进制表示。 MODE 设置不影响进程的掩码(umask)。 Caution：使用以上描述的可选目录层级参数 N 时请注意，对于绝大多数站点，大于1或者2的值会不太合适——因为这需要创建大量的目录：例如，值设置为 3 需要在文件系统上创建 64^3 个目录，将浪费很多空间和 inode。仅仅在绝对肯定站点足够大时，才可以设置 N 大于2。
了解这些，我们就开始处理 Session 存储目录的创建了，注意子目录的权限问题。
bash /path/to/mod_files.sh
使用多级目录的后果就是，你必须手动清理这些 Session。
二、Redis
首先你得安装了 Redis 扩展
session.save_handler = redis
//多节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5,tcp://ip2:port2?weight=2"
//单个节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5"
//socket 方式
session.save_path = "unix:///var/run/redis/redis.sock?persistent=1&weight=1&database=0
解释一下，涉及参数的含义：
ip: Redis 节点的 IP。
port: Redis 节点的端口。
auth: 与 Redis 节点进行权限验证。
weight: 权重，上面的例子表示session数量，ip2节点 是 ip1节点的两倍。
timeout: Redis 连接超时时间。单位：秒。连接失败时，Session不可用（风险！）
persistent: 持久连接。
prefix: 前缀，默认是 "PHPREDIS_SESSION:"。
database: 选择哪个 Redis 数据库。取值：int。参见 Redis 配置 databases 16。
重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
我们看看效果
redis-cli
127.0.0.1:6379> KEYS *
1) "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
127.0.0.1:6379> TYPE "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
string
127.0.0.1:6379> get "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
"admin_user|a:3:{s:8:\"username\";s:4:\"test\";s:4:\"name\";s:4:\"test";s:5:\"email\";s:12:\"test@test.cn\";}"
127.0.0.1:6379> ttl "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
(integer) 292
可以看到 Session 存入了 Redis 中，数据结构用的是 String。
Session 的过期时间
使用 php.ini 中的 session.gc_maxlifetime
可以通过 ini_set 在 php 中自定义。
多机房的 Redis 存储怎么弄？
同步呗！ 查看全部
Session 的存储方式
在 php.ini 文件中，进行配置。
涉及配置参数：
一、文件存储
这里我设置
结果报错
为什么呢？
我们来看下PHP官网怎么说的吧
了解这些，我们就开始处理 Session 存储目录的创建了，注意子目录的权限问题。
使用多级目录的后果就是，你必须手动清理这些 Session。
二、Redis
首先你得安装了 Redis 扩展
解释一下，涉及参数的含义：
重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
我们看看效果
可以看到 Session 存入了 Redis 中，数据结构用的是 String。
Session 的过期时间
多机房的 Redis 存储怎么弄？
同步呗！
在 php.ini 文件中，进行配置。
涉及配置参数：
- session.save_handler注意：这两个参数可以在 PHP 中通过 ini_set 来设置，不用直接覆盖原 php.ini 中的值。
- session.save_path
一、文件存储
session.save_handler = files注释：N 表示多级目录，值为数字。MODE 表示创建的 Session 文件权限。/path 表示 Session 存储路径。
session.save_path = "N;MODE;/path"
这里我设置
session.save_path = "2;600;/tmp/"重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
结果报错
PHP Warning: session_start(): open(/tmp/h/p/sess_hpbfs95c9omtfn30h5lt43i597, O_RDWR) failed: No such file or directory
为什么呢？
我们来看下PHP官网怎么说的吧
此指令还有一个可选的 N 参数来决定会话文件分布的目录深度。例如，设定为 '5;/tmp' 将使创建的会话文件和路径类似于 /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。 要使用 N 参数，必须在使用前先创建好这些目录。 在 ext/session 目录下有个小的 shell 脚本名叫 mod_files.sh，windows 版本是 mod_files.bat 可以用来做这件事。 此外注意如果使用了 N 参数并且大于 0，那么将不会执行自动垃圾回收，更多信息见 php.ini。 另外如果用了 N 参数，要确保将 session.save_path 的值用双引号 "quotes" 括起来，因为分隔符分号（ ;）在 php.ini 中也是注释符号。 文件储存模块默认使用 mode 600 创建文件。通过 修改可选参数 MODE 来改变这种默认行为： N;MODE;/path ，其中 MODE 是 mode 的八进制表示。 MODE 设置不影响进程的掩码(umask)。 Caution：使用以上描述的可选目录层级参数 N 时请注意，对于绝大多数站点，大于1或者2的值会不太合适——因为这需要创建大量的目录：例如，值设置为 3 需要在文件系统上创建 64^3 个目录，将浪费很多空间和 inode。仅仅在绝对肯定站点足够大时，才可以设置 N 大于2。
了解这些，我们就开始处理 Session 存储目录的创建了，注意子目录的权限问题。
bash /path/to/mod_files.sh
使用多级目录的后果就是，你必须手动清理这些 Session。
二、Redis
首先你得安装了 Redis 扩展
session.save_handler = redis
//多节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5,tcp://ip2:port2?weight=2"
//单个节点
session.save_path = "tcp://ip:port?auth=secret?weight=1&timeout=2.5"
//socket 方式
session.save_path = "unix:///var/run/redis/redis.sock?persistent=1&weight=1&database=0
解释一下，涉及参数的含义：
ip: Redis 节点的 IP。
port: Redis 节点的端口。
auth: 与 Redis 节点进行权限验证。
weight: 权重，上面的例子表示session数量，ip2节点 是 ip1节点的两倍。
timeout: Redis 连接超时时间。单位：秒。连接失败时，Session不可用（风险！）
persistent: 持久连接。
prefix: 前缀，默认是 "PHPREDIS_SESSION:"。
database: 选择哪个 Redis 数据库。取值：int。参见 Redis 配置 databases 16。
重启PHP-FPM，然后写个测试脚本 test.php，代码里运行 session_start();
我们看看效果
redis-cli
127.0.0.1:6379> KEYS *
1) "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
127.0.0.1:6379> TYPE "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
string
127.0.0.1:6379> get "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
"admin_user|a:3:{s:8:\"username\";s:4:\"test\";s:4:\"name\";s:4:\"test";s:5:\"email\";s:12:\"test@test.cn\";}"
127.0.0.1:6379> ttl "PHPREDIS_SESSION:fi08i7ms4rtrdsb6n1oqb0fek2"
(integer) 292
可以看到 Session 存入了 Redis 中，数据结构用的是 String。
Session 的过期时间
使用 php.ini 中的 session.gc_maxlifetime
可以通过 ini_set 在 php 中自定义。
多机房的 Redis 存储怎么弄？
同步呗！