上个月发的谈团队每周技术交流引起不少同行感兴趣，如果那篇文章能起到促进业界公司内部技术交流那就是最大的贡献了。
上周五我们继续内部技术讨论，对某Java Web应用进行了latency分析。Latency主要是分析一个URL高并发请求下消耗时间的分布，比如ab(ApacheBench)输出结果最后一段
Percentage of the requests served within a certain time (ms) 50% 5 66% 6 75% 6 80% 6 90% 7 95% 8 98% 10 99% 18 100% 92 (longest request)
表示99%的调用是在18ms返回的，从结果来看latency比较低，反映相应URL的性能是比较理想。
这次技术讨论首先是情况介绍，测试工程师介绍了主要URL从本地IDC到全国的latency的分布图。另外DBA也从数据库的角度介绍了DB层面常见的latency来源。这样会后我们可以对最明显的问题进行优化和改进。
除去通用的问题之后当然是讨论方法，程序员关注的重心大部分还是从应用层面怎么降低latency。
压力测试
很多Web开发的朋友也经常讨论Web应用如何有效的进行压力测试，目前也没有万能的方法。可以使用的工具有loadrunner, 或者Erlang语言开发的tsung等，很多公司也有自己的内部工具。HTTP/Memcache/MySQL等协议压力测试其实相对简单，通常用自己脚本或者高级语言开发的工具比起通用工具来说效果会更佳。
profiling
对接口进行Profiling是发现瓶颈最直观的方法，Google据说就有很完善的内部profiler工具(当然Google内部什么工具都有)。我们讨论了目前不同开发人员使用的profiling方法的优缺点。
- 直接使用专业工具，比如JProfiler, 还有Java自带的JVisualVM等。
- AOP(Aspect-oriented programming)的方式，优点是对程序没有污染，在外部配置需要profiling的方法。
- 工具类的方法，需要在service方法前后加入小量关键点，优点是纯Java的实现，可以运行时动态打开或关闭profiler。比如通过给进程发signals的方法(见Signals and Java)动态让程序输出当前运行情况，起到了能够动态profiling服务器但在正常情况下又不影响服务器性能的作用。
从讨论情况来看大部分开发人员还是倾向于方法3，我们也希望团队能逐步建立类似Google内部profiler之类自己的工具。
