其实很多人都知道淘宝目前有几万台Java应用服务器，上千名Java工程师以及上百个Java应用。为了应付及保障整体性能的稳定以及降低成本，在阿里巴巴核心系统研发部专用计算组的工作主要是专注于OpenJDK的优化及定制，根据自己的业务、应用特点及开发者需要，提供稳定，高效和深度定制的JVM版本：TaobaoJVM。目前已经在淘宝、天猫上线，全部替换了Oracle官方JVM版本，在性能，功能上都初步体现了它的价值。
在2013年阿里巴巴集团主办的ADC•阿里技术嘉年华这一场专属于<互联网工程师>的“技术盛宴”，倡导<干货分享>的大会上，51CTO记者有幸采访到了阿里巴巴核心系统部专用计算组负责人 王琤（长仁）老师，基于Taobao JVM的各个基本性能指标的理论极限和衡量方法介绍，以帮助大家认识、评估自己的算法实现是否高效，进一步指导优化工作，以及介绍了淘宝的下一个项目：反图像的搜索引擎技术iflake。
王琤（花名长仁），阿里巴巴核心系统部专用计算组负责人。在阿里巴巴致力于专用计算的推广及实践，以追求最佳性能及性耗比为目的为特定应用针对特定硬件架构进行算法及实现优化。在图像搜索、机器学习等领域，针对特定 CPU 微架构， GPGPU等不同体系结构进行关键算法及实现进行优化并获得了指数级的性能提升。同时负责淘宝JVM的开发工作，基于OpenJDK VM 为淘宝定制、优化更加贴近应用需求的专用JVM。
以下是采访实录：
记者：对于Taobao JVM我们都知道目前淘宝产品全部都替换了原来的Oracle官方版本，那么Taobao JVM在这方面的性能提升比较大还是基于自己的产品比较放心？
长仁：我们之前在线上推广taobao JVM，其实性能方面是次要的。因为性能比Oracle官方的版本肯定是要提升，但提升不是特别大，除非它应用会利用到taobao JVM的某一个性能特性，它可能获得十倍的提升，这是有可能的。但是在通常情况下，线上的应用是各种各样的。当各种各样的应用在淘宝时，如果看到GC，那么我们可能有提升20%到30%左右，但是从性能角度来说，整体性能跟官方的产品领先幅度不是非常的大。
我们为什么要做呢？其实主要是从运维上考虑。我们成立了一个版本，并且这个版本是淘宝自己来维护的，这样在将来我们一旦出现问题后，因为这是我们自己版本，所以我们直接就可以找到相应版本的代码来检查，到底问题出在哪儿？这样我们解决问题会很快，同时我们的支持力度会很好。同一个版本，在升级这些方面运维成本会很低。同时我们有一个很好的支持，就是我们可以更好地帮助运维同时来解决系统出现的问题。这是最大的考虑。
记者：主要还是说自己的产品比较放心，运维这块成本比较低。
长仁：是的。这个东西是我们做的，出了问题，有一个专门旺旺群，会在那里面报一下他们的号，我们就帮他们去支援，就是这样，很方便。
记者：你目前在做一下淘宝性能优化，性能方面有没有遇到哪些瓶颈？比较困难的。
长仁：性能方面最大的问题就是需求，对于我们来说，如果有需求，你把性能提上去，这不是一个大问题，因为这是技术问题。最大的问题是什么？我们不了解应用的话，我们不能直接的一个渠道应用就告诉我们哪儿有问题，第一，比如说我的系统，假如说现在不知道究竟这个是高是低？有可能说120，最高的极限。有可能500是极限，但是谁也不知道。一般的程序员觉得自己的程序没有问题的，很多程序员都会这么认为，性能也没有问题，符合我们的设计，其实这样就够了。所以我们可能没有很多的机会去真正接触到一线的应用，来看它们里面还有什么提升？对于这些来说，其实应用方面和开发者来说，觉得现在性能够用了。我们真正面对的问题都是出现了性能不够用的时候，上线不了，性能没达标。这个时候就会接触，这种机会不多的。
对于我们来说，我们能够把性能做到极致，必须有一个前提，就是说我们要针对确定的应用来做，究竟是哪儿有问题你来做。假如说让我们做一个产品，放在任何的应用上都可以跑的很快，那就是Oracle的产品，那已经做了。所有Oracle的人做的工作都是给你一个平台，跑什么都OK，不是最快，但是已经应该满足它的需求了。
我们做通用性能提升，这个是我们做不了的，因为什么？对于通用性能提升，我们能改，大家想到的能改的东西，其实Oracle的人已经做了。我们做的点，其实你看我们做通用性能提升，我们现在的patch。唯一的就是编译级的优化，能够把这些性能提升。第二点，比如说我们再做一些微调，也能把性能稍微再提升。但是也就这些，再说给一个通用的东西做到，用之四海而皆准，这些东西是非常难。因为有那样的东西，Oracle的人肯定也想到，也做了。我们的特点是确定应用，你有特定的需求，我针对你的特点做优化，这是我们擅长的，在专的情况下我们才有机会。
记者：我们都知道TaobaoJVM是基于OpenJDK HotSpot VM深度定制的，您认为Taobao JVM的天花板是否还是取决于OpenJDK HotSpot VM？
长仁：从通用的角度来说，我们会给它做的好一点，但是不会好的非常多，从专用的角度来说，我们肯定能够突破它，举个例子像Hadoop的优化，在做taobao JVM我们用一种新的指令，把它能提高将近十倍的性能。这些在Oracle的JVM是不提供这个支持的。对于我们来说，我们就完全把这个做出来，做出来以后线上就用，这个就是确定领域的话，能给它确定需求、确定应用，我们可以针对它的特点，做出很不一样的东西。
记者：之前咱们聊的时候，我记得您说做一个关于JVM优化的一些工具。
长仁：我们现在确实是在做一个，做一个是有关JVM的诊断优化系统。最主要的目的是什么？就是说我们其实刚才讲了，我们有一个旺旺群，在这个群上我们会回答运维同行、开发同行的各种问题。其中很多的问题就是，我们线上的应用很大，不是现在的所有都用淘宝这边的业务，还有Oracle版本出现。JVM Crash，或者说GC有点异常，这个时间很长，他们可以问问题，这个问题我们上层有一套数据流程，我们上层去做一些诊断，看一些Crash log，GC log，然后来排查问题，究竟哪儿出了问题，这么一个过程。
很多运维、开发同行说，貌似这个东西，我们自己解决不了，只能靠你们。希望我们的支持能够固化下来，提供一个东西，能把一些基础的问题、简单问题，帮助我们排查出来，我们其实也觉得很累。我们去年一年处理的线上的Crash问题是52起，平均一周一起，平均处理一次的时间大概一到三天。所以你看光是一个快速问题，我们自己也非常想有一个工具。出了问题，你先用这个系统查一下，它会告诉你，我们经常碰到一些简单问题，就告诉你基本的原因，假如说有一些诡异的我们再应用系统，这个系统其实就叫JVM诊断系统。大名JVM故障排查系统，小名还没起好，这个东西已经快做好了。
记者：怎样工作，它的主要功能？
长仁：就是说到时候线下那台机器出问题了，GC问题，还是说JVM Crash，你只要在我的系统里告诉我这个机器IP是什么？你点一个钮，你上去就把Crash log，GC log还是我们其他的一些日志抓下来。抓下来以后，我们有一个分析系统，大致地就告诉你，一个简单问题就能告诉你，你这个Crash是因为什么问题？GC频度有多少？有什么问题？潜在有什么问题？应该朝哪个方向去想？等等就告诉你这些简单的，这样运维同学就很愿意使，我自己有些简单问题，我也能解决，我依靠那个系统去。所以我们来说，我们相当于用这个系统过滤了一些简单问题，剩下复杂的我们再解决。就是这个东西，这个东西马上就要开放了。我们现在淘宝的内部先使，以后很有可能要开放出去，我们自己使好了，肯定要开放出去。
#p#
记者：恩，那么能否介绍一下你们目前在做的反图像的搜索引擎iflake，这是一个什么样的东西？主要应用在哪一块？
长仁：最好回答这个的话是我们图像组的回答是最合适的，我们的了解对于它，以及这个应用，我们了解都是很片面的。片面的我介绍一下，阿里集团有一个世界一流的图像搜索。
这个跟其他的图片搜索是不一样的，比如你现在使用哪张图，那些东西很多人使用。它是基于神经网络，我对这些方面不了解，但是图像组的雷音跟我说，目前基于神经网络的准确率只能达到大约百分之三四十，雷音他们用的实际上是更传统的方法。它的准确率能够到百分之八九十。
我们淘宝有一个重要业务，比如盗图，你拍了一张照片放到淘宝上，别的商家就盗你的图，他就不用拍了。我们就要找到这个图片跟这个是不是一个图，它在这里面做剪裁，或者是说里面打上几个字，我也要能区别出这几个是不是一个图片。图像搜索，一个应用方面就是应用在这儿。用在这儿以后，它可以打相似的图片搜索，具体的实现方式是算法问题。我们IC的是什么？其实就是整个系统一部分，这一部分要做什么？其实就是要把图像最终提取完特征点以后，它实际上跟传统搜索基本上一样，都是有DAO。包括影像。每个DAO上的ID，ID之间根据你的要求进行ID的合并。
我们主要做的话就是这个优化，为什么要做这个？是因为原来淘宝的这个图的规模，图片的规模，分到不同机器上，每一台机器是千万张信息，一千万张图片。在这个规模下，原来的计算实现的算法可以做什么？基本上会做到一台机器QPS十几，就是说我们每秒钟能处理十几次的这种请求来进行合并，这个结果就出来了。当我们的规模扩到亿量级，从千万到一亿扩大十倍以后，一台机器的话，基本上一秒才能处理一次请求。这个完完全全的不能符合上线的预期，这个性能太差了。那怎么办？增加十倍的机器可以解决问题，但是这个开销很大。
我们组就介入了，我们来看一看这个东西怎么来优化，优化的结果就是，同样的机器的话，我们把性能提升10倍，但原来的千万量级，我的QBS能上百，到亿量级的话，我也能保证跟原来是一样的。相当于你不用加十倍的机器了，现在你数据量提高十倍以后，我整个的性能跟原来差不多，还是满足你需求的，我们做的是这个。
记者：我想了解除了商家积极地应用这个技术以外，像用户，我看到的这个东西，我不知道它是什么，通过这个图片去搜索出来。
长仁：对，以图找图也是它的应用的典型之一，你看到这个东西，我想把它买下来，我拿手机一拍，淘宝上这一类的，这个东西在淘宝上列出来，这也是应用之一。应用很多，图像搜索在淘宝的应用，以后会越来越多。
记者：毕竟在淘宝上图片占用的比例是比较大的，还有一个就是，一般来讲，通过什么样的设施和手段知道他们的极限性能在哪里？
长仁：方法很多。对于我们来说，接触到一个系统，首先做一个整体的profiling，先看最后，你们会看到，算的最慢的那部分在哪儿？那一部分占整体计算时间的80%，举个例子，那我们去优化它，优化好了这个收益就会很好。比如说我有80%，CPU都耗在80%那一块，我把它提升了20%，那相当于议程是16的差异。如果优化了20%，我假如说能快一倍，占的比例由于很小，所以整体提升很大。所以我们第一步就是，起码最弱的部分找到，找到以后，然后看究竟是由于什么原因造成它跑的慢，是算法的问题、实现的问题，还是说各种各样的问题，我们会把这一部分进行优化。优化完了以后就会上线测试。
记者：这个还是通过你刚才说，很多方法。你们在做淘宝X86平台优化的时候，你们碰到过，刚刚说过的天花板，就是一个极限。这个极限，能不能突破这个极限？
长仁：可以突破的，第一我们换正适合的硬件。天花板就可以，它天然的不同的硬件上，它的天花板是不同高度的，有的话它自然就高了，这是有可能来获得突破的。第二个点，假如硬件固定了，天花板在那儿，有可能天花板那儿是因为你实现的原因，你非要这么算，天花板这么高。你换一种算法，实现方式改变了之后，没准天花板就变得更高了。这样的话，你就更有可能突破。举个例子比如从计算量，假如说A的算法的实践，我们计算量需要什么？假如说需要一百万次。换一个算法实现的话，发现A计算量只需要五十万次。这样的话，相当于无形中就高了，那我就能往上更走一步。
记者：对于天花板来说，一般是做到满足自己的应用需求，不会去说盲目把性能提高，你们队这个性能的点是如何理解的。
长仁：这是非常重要的一个问题，优化到什么程度结束？满足刚才讲的曲线，工作曲线有一部分是花的时间比较少，但是性能提升会很明显。那一部分其实就是我们所谓的工作的甜点区，这一部分花的时间不用很多就能提到很高，如果这个时候用户已经满足了需求，OK，就到此为止了。为什么？因为既然应用已经满足需求了，我们花的时间再把它进一步提升的话，对于应用方来说，他觉得这个部分没有太大的改善。而且越往上的话会越难做，这是肯定的。所以这样的话，如果达到应用需求，我们可能去做其他的项目，接着做另外的东西。这一部分只要用户满足需求了，我们就可以适可而止，这样也节约我们的时间。我们不是为了一定要寻求一个极致来去做，因为寻求一个极致，有的应用要求水平很高，要求达到一个什么，那时候必须要到极致才可能达到。但是很多应用，我们现有的机器，规模一变的话，你也能满足我了，他们就满意了。满意以后，这个就适可而止。
记者：如果说这部分的性能天花板特别高的，但是说你们只要优化一点点，优化一些，就能提升数十倍。就是说你们还可以通过这些小小的优化，还可以把性能再一次提高。但是不需要浪费太多的时间，这种优化你们会不会考虑去做？
长仁：有时候会考虑，我举个例子iflack，刚才讲了能提高十倍。实际上它再提升50%，十倍假如是1的话，再提高到1.5其实也是可能的。这个花的时间我也估计过，其实我们这边做的工作很少，不多。但是整体的为了这50%，原始做的那些东西要进行重新索引。这样的话对于工程方面、运维方面会有一个成本，这个成本是我们估计不了的。但是这个成本我们知道，比我们的成本高很多。为了这50%有没有必要？我们也不知道，所以我们要征求应用方的意见。其实iflack做十倍，其实根本就不是极限，还能再做。我们也知道该怎么做能再提升50%，但是由于各种各样的因素，因为不是就我们自己，我们是一个整体。有应用方、运维方，都要考虑到他们相应的成本付出了多少，必须把这个考虑进去。权衡之下来决定，我们做不做？什么时候做？这不是我们决定的。
