HSF/Dubbo序列化时的LocalDateTime, Instant的性能问题-阿里云开发者社区

开发者社区> renchie> 正文

HSF/Dubbo序列化时的LocalDateTime, Instant的性能问题

简介: ### 来源 在对Dubbo新版本做性能压测时,无意中发现对用例中某个TO(Transfer Object)类的一属性字段稍作修改,由Date变成LocalDateTime,结果是吞吐量由近5w变成了2w,RT由9ms升指90ms。
+关注继续查看

来源

在对Dubbo新版本做性能压测时,无意中发现对用例中某个TO(Transfer Object)类的一属性字段稍作修改,由Date变成LocalDateTime,结果是吞吐量由近5w变成了2w,RT由9ms升指90ms。

在线的系统,拼的从来不仅仅是吞吐量,
而是在保证一定的RT基础上,再去做其他文章的, 也就是说应用的RT是我们服务能力的基石所在, 拿压测来说, 我们能出的qps/tps容量, 必须是应用能接受的RT下的容量,而不是纯理论的数据,在集团云化的过程中计算过,底层服务的RT每增加0.1ms,在应用层就会被放大,

整体的成本就会上升10%以上。

要走向异地,首先要面对的阿喀琉斯之踵:延时,长距离来说每一百公里延时差不多在1ms左右,杭州和上海来回的延迟就在5ms以上,上海到深圳的延迟无疑会更大,延时带来的直接影响也是响应RT变大,
用户体验下降,成本直线上升。 如果一个请求在不同单元对同一行记录进行修改, 即使假定我们能做到一致性和完整性, 那么为此付出的代价也是非常高的,想象一下如果一次请求需要访问
10 次以上的异地 HSF 服务或 10 次以上的异地 DB调用, 服务再被服务调用,延时就形成雪球,越滚越大了。

普遍性

关于时间的处理应该是无处不在,可以说离开了时间属性,99.99%的业务应用都无法支持其意义,特别是像监控类的系统中更是面向时间做针对性的定制处理。

在JDK8以前,基本是通过java.util.Date来描述日期和时刻,java.util.Calendar来做时间相关的计算处理。JDK8引入了更加方便的时间类,包括Instant,LocalDateTime、OffsetDateTime、ZonedDateTime等等,总的说来,时间处理因为这些类的引入而更加直接方便。

Instant存的是UTC的时间戳,提供面向机器时间视图,适合用于数据库存储、业务逻辑、数据交换、序列化。LocalDateTime、OffsetDateTime、ZonedDateTime等类结合了时区或时令信息,提供了面向人类的时间视图,用于向用户输入输出,同一个时间面向不同用户时,其值是不同的。比如说订单的支付、发货时间买卖双方都用本地时区显示。可以把这3个类看作是一个面向外部的工具类,而不是应用程序内部的工作部分。

简单说来,Instant适用于后端服务和数据库存储,而LocalDateTime等等适用于前台门面系统和前端展示,二者可以自由转换。这方面,国际化业务的同学有相当多的体感和经验。

在HSF/Dubbo的服务集成中,无论是Date属性还是Instant属性肯定是普遍的一种场景。

问题复现

  • Instant等类的性能优势

以常见的格式化场景举例

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public String date_format() {
        Date date = new Date();
        return new SimpleDateFormat("yyyyMMddhhmmss").format(date);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public String instant_format() {
        return Instant.now().atZone(ZoneId.systemDefault()).format(DateTimeFormatter.ofPattern(
                "yyyyMMddhhmmss"));
    }

在本地通过4个线程来并发运行30秒做压测,结果如下。

Benchmark                            Mode  Cnt        Score   Error  Units
DateBenchmark.date_format           thrpt       4101298.589          ops/s
DateBenchmark.instant_format        thrpt       6816922.578          ops/s

可见,Instant在format时性能方面是有优势的,事实上在其他操作方面(包括日期时间相加减等)都是有性能优势,大家可以自行搜索或写代码测试来求解。

  • Instant等类在序列化时的陷阱

针对Java自带,Hessian(淘宝优化版本)两种序列化方案,压测序列化和反序列化的处理性能。

Hessian是集团内应用的HSF2.2和开源的Dubbo中默认的序列化方案。

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public Date date_Hessian() throws Exception {
        Date date = new Date();
        byte[] bytes = dateSerializer.serialize(date);
        return dateSerializer.deserialize(bytes);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public Instant instant_Hessian() throws Exception {
        Instant instant = Instant.now();
        byte[] bytes = instantSerializer.serialize(instant);
        return instantSerializer.deserialize(bytes);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public LocalDateTime localDate_Hessian() throws Exception {
        LocalDateTime date = LocalDateTime.now();
        byte[] bytes = localDateTimeSerializer.serialize(date);
        return localDateTimeSerializer.deserialize(bytes);
    }

结果如下。可以看出,在Hessian方案下,无论还是Instant还是LocalDateTime,吞吐量相比较Date,都出现“大跌眼镜”的下滑,相差100多倍;通过通过分析,每一次把Date序列化为字节流是6个字节,而LocalDateTime则是256个字节,这个放到网络带宽中的传输代价也是会被放大。 在Java内置的序列化方案下,有稍微下滑,但没有本质区别。

Benchmark                         Mode  Cnt        Score   Error  Units
DateBenchmark.date_Hessian       thrpt       2084363.861          ops/s
DateBenchmark.localDate_Hessian  thrpt         17827.662          ops/s
DateBenchmark.instant_Hessian    thrpt         22492.539          ops/s
DateBenchmark.instant_Java       thrpt       1484884.452          ops/s
DateBenchmark.date_Java          thrpt       1500580.192          ops/s
DateBenchmark.localDate_Java     thrpt       1389041.578          ops/s

分析解释

Hession中其实是有针对Date类做特殊处理,遇到Date属性,都是直接获取long类型的相对来做处理。

1560245363047_11686c4e_ea4a_4e7c_aa2e_ea43695996bf


通过分析Hessian对Instant类的处理,无论是序列化还是反序列化,都需要Class.forName这个耗时的过程。。。,怪不得throughput急剧下降。

20


延展思考

1) 可以通过扩展实现Instant等类的com.alibaba.com.caucho.hessian.io.Serializer,并注册到SerializerFactory,来升级优化Hessian。但会有前后兼容性上,这个是大问题,在集团内这种上下游依赖比较复杂的场景下,极高的风险也会让此不可行。从这个角度看,只有建议大家都用Date来做个TO类的首选的时间属性。

2) HSF的RPC协议从严格意义上讲是 Session握手层的协议定义,其中的版本识别也是这个层面的行为,而业务数据的presentation展示层是通过Hessian等自描述的序列化框架来实现,这一层其实是缺少版本识别,从而导致升级起来就异常困难。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
intel xeon(skylake) platinum 8163 性能评测 阿里云第四代ECS服务器
intel xeon(skylake) platinum 8163 性能评测阿里云第四代ECS服务器http://www.bieryun.com/4559.html 阿里云ECS服务器是一种弹性可伸缩的云服务器,通过虚拟化平台将服务器集群虚拟为多个性能可配的虚拟机(KVM),对整个集群系统中所有KVM进行监控和管理,并根据实际资源使用情况灵活 分配和调度资源池。
38726 0
Linux性能测试 mpstat命令
mpstat是MultiProcessor Statistics的缩写,是实时系统监控工具。其报告与CPU的一些统计信息,这些信息存放在/proc/stat文件中。在多CPUs系统里,其不但能查看所有CPU的平均状况信息,而且能够查看特定CPU的信息。
882 0
4G LTE/LTE-A系统的主要性能特点 | 带你读《5G UDN(超密集网络)技术详解》之四
宏基站 eNB 和微基站 eNB 配置提供的服务小区之间的主要区别是:系统 容量和无线覆盖的区域大小不同,只有当它们以不同方式、不同类型搭配,混 合地部署组网在一起时,才能形成上述所谓的“同构宏蜂窝”与“异构微蜂 窝”网络之间的诸多差别。
1082 0
Data Lake Analytics助力加和科技广告智能业务 - 性能提升4倍+,临时业务需求承接率提升200%+
阿里云Data Lake Analytics助力加和科技广告智能业务 - 性能提升4倍+,临时业务需求承接率提升200%+
2227 0
Sql性能检测工具:Sql server profiler和优化工具:Database Engine Tuning Advisor
原文:Sql性能检测工具:Sql server profiler和优化工具:Database Engine Tuning Advisor 一、工具概要     数据库应用系统性能低下,需要对其进行优化,     如果不知道问题出在哪里,可以使用性能检测工具sql server profiler。
1660 0
transient:将属性脱离序列化 | 带你学《Java语言高级特性》之七十一
transient关键字是类似于static、final等关键字的修饰符,它可以使类中的属性在序列化时跳过该属性,本节将为读者介绍其相关内容与用法。
528 0
Linux性能测试 iostat命令
Linux系统出现了性能问题,一般我们可以通过top、iostat、free、vmstat等命令 来查看初步定位问题。其中iostat可以给我们提供丰富的IO状态数据。iostat 由 Red Hat Enterprise Linux AS 发布。
879 0
Json.Net系列教程 3.Json.Net序列化和反序列化设置
原文 Json.Net系列教程 3.Json.Net序列化和反序列化设置 上节补充 首先补充一点,Json.Net是支持序列化和反序列化DataTable,DataSet,Entity Framework和NHibernate的.
759 0
+关注
6
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载