各位好，在生产环境中遇到问题，向大家寻求帮助
先给出想通过本次邮件解决的问题：
1. 在日志记录中，存在较多$request_time 和 $upstream_response_time 执行时间很久的记录，可能是什么原因？与我的配置参数设置或部署结构是否有关？
2. $upstream_response_time 格式会变成2部分 xxxx, xxxx ，可能是什么原因？被拆分的字段代表什么含义？
3. 代理端和处理端配置中的 worker_processes 个数以及 worker_connections个数的目前的设置是否是产生较长执行时间的原因？结合给出的物理机信息，该如何设置才合理？
4. 对于worker_processes设定，cpu绑定，结合物理机信息，到底应该怎么绑定（参照core个数还是逻辑cpu个数）
问题有点多，确实在应用过程中遇到难题，希望大家抽点时间，能帮忙我分析一下，非常感谢！
基于上述问题的一些线索，帮助理解：
在使用nginx完成业务功能时，我们希望了解nginx在接收请求到处理完毕的访问时间（$request_time），以及当代理缓存不存在时，访问上游服务器的完整响应时间（$upstream_response_time）
我们自定义了如下日志格式：
#各项之间使用 \t 分隔
log_format custom '[$time_local] "$request" $status $bytes_sent $request_time $upstream_response_time';
通过日志分析，我发现存在如下几类日志
#访问上游服务器后的正常日志
[21/Jun/2013:00:00:09 +0800] "GET /carnews/2013/5/12/tp_20130512232510597213.jpg HTTP/1.1" 200 23750 0.134 0.134
[20/Jun/2013:23:30:24 +0800] "GET /carnews/2013/6/9/u_201306091538449644661.jpg HTTP/1.1" 200 21014 2.422 2.385
这部分能理解，上游服务器执行的时间 <= $request_time
#命中代理缓存，快速返回的日志
[21/Jun/2013:01:09:24 +0800] "GET /carnews/spec/4469/c_201111241509118403655.jpg HTTP/1.1" 200 20759 0.000 -
这部分能理解，由于命中缓存，并没有访问上游服务器，所以$upstream_response_time 为 -
且$request_time比较短，甚至为 0.000
#状态也是200，但是执行时间巨长的请求日志
[20/Jun/2013:00:02:33 +0800] "GET /carnews/2012/9/17/u_201209171731357133655.jpg HTTP/1.1" 200 24385 60.212 60.000, 0.212
这部分不太能理解，主要想让大家帮忙分析一下：
1. 为什么$response_response_time 会呈现成两部分 60.000, 0.212。是否与我们配置多个上游服务器有关
2. 大量的日志记录中，存在较多$request_time 和 $upstream_response_time 超过20秒，甚至达到60秒的情况？是否与我们的配置有关。
尽可能多的给出结构和配置信息，便于大家理解和帮我分析
1. 物理部署：一台物理机上存在2个nginx sbin 部署版本。
其中一个作为代理端，hold大量的请求，同时作为代理缓存内容存储，使用80端口
另一个作为处理端，执行业务处理，在80的upstream中被调用，使用8012端口。
共有三台物理机，每台的部署都一样。处理机在代理端配置中，使用upstream组织。
代理缓存的存储磁盘在三台机器上各是各的，会有重复数据。
其中，nginx_proxy代表代理端、nginx代表处理端
每一台机器上的nginx进程情况：
代理端配置：
worker_processes 12;
google_perftools_profiles /tmp/tcmalloc;
events {
use epoll;
worker_connections 65535;
}
http {
upstream y0.autoimg.cn {
server IP1:8012;
server IP2:8012;
server IP3:8012;
}
server{
listen 80;
server_name xxxx(一些列域名);
location ~* ^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp)$ {
add_header Cache-Control max-age=2592000;
proxy_pass http://$host;
proxy_cache tmpcache;
proxy_cache_valid 200 15d;
proxy_cache_key $uri;
}
}
}
====================================================
处理端配置：
worker_processes 12;
google_perftools_profiles /tmp/tcmalloc;
events {
use epoll;
worker_connections 65535;
}
http {
server {
listen 8012;
server_name localhost;
location ~* ^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp|JPE?G)$ {
rewrite "^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp|JPE?G)$" /myredirect last;
}
location /myredirect {
custom_module_directive;
}
}
}
每台物理机的信息
