hbaseV0.96 multiPut性能下降问题分析

背景

现场反馈，基于hbase put(List<Put> puts)封装的multiPut服务性能很差，一次100条记录，每条记录1k作用，耗时6s左右。这个结果，确实与原先所内做的压测差距很大，先前测试大概100ms左右。比对了两次测试，代码一致，与该操作相关的数据库查询操作，均缓存化处理；不同的地方在于所内采用CDH4.6版本，其中hbase为V0.94，现场为CDH5.0.2，其中hbase为V0.96。

分析

Step1.开始怀疑是两边环境参数不一致，经比对后，影响到写操作的参数，基本一致。

Step2.从耗时时间来看，难道涉及到的元数据没被缓存住，直接查询数据库里？沿着这个思路，debug代码，第一次请求数据库，后面从缓存加载元数据。改假设证明不成立。

Step3.定位耗时代码。在代码中，用log4j记录可能耗时的操作，发现组织List<Put> puts操作，耗了6s作用，hbase 的put操作，只用了几十毫秒。

定位到问题，一切好办。走读了该段代码，没发现啥异样，数据序列化成bytes直接，构建Put对象，无其它。该段代码，未涉及到write-buffer/网络通信，

所以和通信/write-buffer问题可以排除。难道是序列化问题？Bytes.toBytes(String)有问题？

比对了下CDH460和CDH502版本客户端代码+服务器，发现该段代码，在CDH460上面跑快了将近20倍！基本可以肯定和Bytes.toBytes(String)相关。从Cloudera下载两个版本的HBase代码，提取Bytes代码，比对Bytes.toBytes代码

分析：hbase0.96版本，Bytes.toBytes(String) 慢点根源在于toBytes中的方法体内，使用了String.getBytes(Charset)，它的编码处理，涉及到StringDecoder对象重新生成，字符串复制构造等，从而导致了096版本的toBytes(String) 相比非常慢。

处理

修改multiPut服务中的Bytes.toBytes(String)为hbaseV0.94的代码，问题解决。

public static byte[] toBytes(String s) {
    try {
      return s.getBytes(HConstants.UTF8_ENCODING);//String
    } catch (UnsupportedEncodingException e) {
      LOG.error("UTF-8 not supported?", e);
      return null;
    }
  }