不知不觉就过了十天了，仿佛经历了好多，回忆起来发现这10天干的活比在公司一个月干的还要多。每天活在发现问题和寻求解决问题钟，沉浸在解决问题的喜悦里，看着自己的项目一步步地完成，心里的成就感更是难以比拟。
好的，今天主要是在寻求提高Nginx服务器性能的方法，虽然问题没有解决，但是却也收获不少，至少对内核参数的配置有了一定的了解了。中午刚刚看到内核参数配置那里，头瞬间就晕了，直接倒在床上，歇了15分钟才有勇气一步步研究。内核参数我觉得是没问题的了，都是将系统的限制尽可能地打开。Nginx的配置也按照别人的博客一步步配置，当我觉得没什么问题，即将大功告成时。一测，发现性能完全没有改变啊！！！
这我就蒙了，别人行为什么我不行呢？
马上下了个htop在服务器上，然后在自己的机器上用ab工具“ab -kc 1000 -n 20000 http://www.fatjb.com:8008/task.plist"，看着服务器的htop我就震惊了！我的work_processor设置auto，也就是会根据我cpu的核数来生成相应个工作进程，即4条工作进程。可是htop里面看到cpu的负载一点都不均衡啊！基本上就一个cpu在那里跑，使用率只有1%~2%，如此之低！接着回去看测试结果，接近50%是失败的！4核/4G/20G/50G/2M的配置连1000并发都跑不起来？那Nginx谈何C10K连接？
肯定是我打开的方式不对！
抱着这样的想法，我就试着用10并发来测试，请求1000次，失败率也是50%左右。不死心的我再来了个10并发，请求10次，失败了6次！失败的都是返回503（服务器暂时不可用）按照这样推断服务器完全不具备并发的能力啊！完全是一个请求在执行的时候，别的请求被堵在外面啊！为了进一步证实我的猜测，我用1并发，请求1k次和10k次，一次失败都没有！对的，它就是不具备并发的能力！
由于下载task.plist比较耗时，且不具备并发的能力，那么在处理下一次业务时，有几个请求被拒绝了，从而导致失败了。随着task.plist的体积增大(现阶段是416字节，即约0.5k)，失败率越高。
这下就头疼了，这很不科学啊！不具备并发的能力？是不是我哪里配错了啊？先留个悬念，明天再研究出来。
此外，在弄log的时候也遇到个奇葩问题。
因为我看到把所有log记录在access.log里面，实在是太难查看了，而且有些真的不用记录。所以我就把access_log关了，取而代之的是在需要记录的location里面打开相应的access_log。比如我请求是http://www.fatjb.com/ask_task，那么它对应的log就是ask_task.log，接着我在自己的机器上就能通过curl -O http://www.fatjb.com/ask_task.log来查看log，但是命令返回200而log没下下来！提升我[data not shown]！如此神奇！后面把ask_task.log的名字换成askTask.log才可以！真的搞不懂Nginx了，连log的名字规范都有限制，快奔溃了。
睡觉睡觉，累死了。