02讲如何制定性能调优策略

02讲如何制定性能调优策略

你好，我是刘超。

上⼀讲，我在介绍性能调优重要性的时候，提到了性能测试。⾯对⽇渐复杂的系统，制定合理的性能测试，可以提前发现性能瓶颈，然后有针对性地制定调优策略。总结⼀下就是“测试-分析-调优”三步⾛。

今天，我们就在这个基础上，好好聊⼀聊“如何制定系统的性能调优策略”。

性能测试攻略
性能测试是提前发现性能瓶颈，保障系统性能稳定的必要措施。下⾯我先给你介绍两种常⽤的测试⽅法，帮助你从点到⾯地测试系统性能。

1.微基准性能测试
微基准性能测试可以精准定位到某个模块或者某个⽅法的性能问题，特别适合做⼀个功能模块或者⼀个⽅法在不同实现⽅式下的性能对⽐。例如，对⽐⼀个⽅法使⽤同步实现和⾮同步实现的性能。

2.宏基准性能测试
宏基准性能测试是⼀个综合测试，需要考虑到测试环境、测试场景和测试⽬标。

⾸先看测试环境，我们需要模拟线上的真实环境。

然后看测试场景。我们需要确定在测试某个接⼝时，是否有其他业务接⼝同时也在平⾏运⾏，造成⼲扰。如果有，请重视，因为你⼀旦忽视了这种⼲扰，测试结果就会出现偏差。

最后看测试⽬标。我们的性能测试是要有⽬标的，这⾥可以通过吞吐量以及响应时间来衡量系统是否达标。不达标，就进⾏优化；达标，就继续加⼤测试的并发数，探底接⼝的 TPS（最⼤每秒事务处理量），这样做，可以深⼊了解到接⼝的性能。除了测试接⼝的吞吐量和响应时间以外，我们还需要循环测试可能导致性能问题的接⼝，观察各个服务器的 CPU、内存以及
I/O 使⽤率的变化。

以上就是两种测试⽅法的详解。其中值得注意的是，性能测试存在⼲扰因⼦，会使测试结果不准确。所以，我们在做性能测试时，还要注意⼀些问题。

1.热身问题

当我们做性能测试时，我们的系统会运⾏得越来越快，后⾯的访问速度要⽐我们第⼀次访问的速度快上⼏倍。这是怎么回事呢？

在 Java 编程语⾔和环境中，.java ⽂件编译成为 .class ⽂件后，机器还是⽆法直接运⾏ .class ⽂件中的字节码，需要通过解释器将字节码转换成本地机器码才能运⾏。为了节约内存和执⾏效率，代码最初被执⾏时，解释器会率先解释执⾏这段代码。

随着代码被执⾏的次数增多，当虚拟机发现某个⽅法或代码块运⾏得特别频繁时，就会把这些代码认定为热点代码（Hot Spot
Code）。为了提⾼热点代码的执⾏效率，在运⾏时，虚拟机将会通过即时编译器（JIT compiler，just-in-time compiler）把这些代码编译成与本地平台相关的机器码，并进⾏各层次的优化，然后存储在内存中，之后每次运⾏代码时，直接从内存中获取即可。

所以在刚开始运⾏的阶段，虚拟机会花费很⻓的时间来全⾯优化代码，后⾯就能以最⾼性能执⾏了。

这就是热身过程，如果在进⾏性能测试时，热身时间过⻓，就会导致第⼀次访问速度过慢，你就可以考虑先优化，再进⾏测试。

2.性能测试结果不稳定
我们在做性能测试时发现，每次测试处理的数据集都是⼀样的，但测试结果却有差异。这是因为测试时，伴随着很多不稳定因素，⽐如机器其他进程的影响、⽹络波动以及每个阶段 JVM 垃圾回收的不同等等。

我们可以通过多次测试，将测试结果求平均，或者统计⼀个曲线图，只要保证我们的平均值是在合理范围之内，⽽且波动不是很⼤，这种情况下，性能测试就是通过的。

3.多JVM情况下的影响
如果我们的服务器有多个 Java 应⽤服务，部署在不同的 Tomcat 下，这就意味着我们的服务器会有多个 JVM。任意⼀个
JVM 都拥有整个系统的资源使⽤权。如果⼀台机器上只部署单独的⼀个 JVM，在做性能测试时，测试结果很好，或者你调优的效果很好，但在⼀台机器多个 JVM 的情况下就不⼀定了。所以我们应该尽量避免线上环境中⼀台机器部署多个 JVM 的情况。

合理分析结果，制定调优策略
这⾥我将“三步⾛”中的分析和调优结合在⼀起讲。

我们在完成性能测试之后，需要输出⼀份性能测试报告，帮我们分析系统性能测试的情况。其中测试结果需要包含测试接⼝的平均、最⼤和最⼩吞吐量，响应时间，服务器的 CPU、内存、I/O、⽹络 IO 使⽤率，JVM 的 GC 频率等。

通过观察这些调优标准，可以发现性能瓶颈，我们再通过⾃下⽽上的⽅式分析查找问题。⾸先从操作系统层⾯，查看系统的
CPU、内存、I/O、⽹络的使⽤率是否存在异常，再通过命令查找异常⽇志，最后通过分析⽇志，找到导致瓶颈的原因；还可以从 Java 应⽤的 JVM 层⾯，查看 JVM 的垃圾回收频率以及内存分配情况是否存在异常，分析⽇志，找到导致瓶颈的原因。

如果系统和 JVM 层⾯都没有出现异常情况，我们可以查看应⽤服务业务层是否存在性能瓶颈，例如 Java 编程的问题、读写数据瓶颈等等。

分析查找问题是⼀个复杂⽽⼜细致的过程，某个性能问题可能是⼀个原因导致的，也可能是⼏个原因共同导致的结果。我们分
析查找问题可以采⽤⾃下⽽上的⽅式，⽽我们解决系统性能问题，则可以采⽤⾃上⽽下的⽅式逐级优化。下⾯我来介绍下从应
⽤层到操作系统层的⼏种调优策略。

1.优化代码
应⽤层的问题代码往往会因为耗尽系统资源⽽暴露出来。例如，我们某段代码导致内存溢出，往往是将 JVM 中的内存⽤完了，这个时候系统的内存资源消耗殆尽了，同时也会引发 JVM 频繁地发⽣垃圾回收，导致 CPU 100% 以上居⾼不下，这个时候⼜消耗了系统的 CPU 资源。

还有⼀些是⾮问题代码导致的性能问题，这种往往是⽐较难发现的，需要依靠我们的经验来优化。例如，我们经常使⽤的
LinkedList 集合，如果使⽤ for 循环遍历该容器，将⼤⼤降低读的效率，但这种效率的降低很难导致系统性能参数异常。

这时有经验的同学，就会改⽤ Iterator （迭代器）迭代循环该集合，这是因为 LinkedList 是链表实现的，如果使⽤ for 循环获取元素，在每次循环获取元素时，都会去遍历⼀次 List，这样会降低读的效率。

2.优化设计
⾯向对象有很多设计模式，可以帮助我们优化业务层以及中间件层的代码设计。优化后，不仅可以精简代码，还能提⾼整体性能。例如，单例模式在频繁调⽤创建对象的场景中，可以共享⼀个创建对象，这样可以减少频繁地创建和销毁对象所带来的性能消耗。

3.优化算法
好的算法可以帮助我们⼤⼤地提升系统性能。例如，在不同的场景中，使⽤合适的查找算法可以降低时间复杂度。

4.时间换空间
有时候系统对查询时的速度并没有很⾼的要求，反⽽对存储空间要求苛刻，这个时候我们可以考虑⽤时间来换取空间。

例如，我在 03 讲就会详解的⽤ String 对象的 intern ⽅法，可以将重复率⽐较⾼的数据集存储在常量池，重复使⽤⼀个相同的对象，这样可以⼤⼤节省内存存储空间。但由于常量池使⽤的是HashMap数据结构类型，如果我们存储数据过多，查询的性 能就会下降。所以在这种对存储容量要求⽐较苛刻，⽽对查询速度不作要求的场景，我们就可以考虑⽤时间换空间。

5.空间换时间
这种⽅法是使⽤存储空间来提升访问速度。现在很多系统都是使⽤的 MySQL 数据库，较为常⻅的分表分库是典型的使⽤空间换时间的案例。

因为 MySQL 单表在存储千万数据以上时，读写性能会明显下降，这个时候我们需要将表数据通过某个字段 Hash 值或者其他
⽅式分拆，系统查询数据时，会根据条件的 Hash 值判断找到对应的表，因为表数据量减⼩了，查询性能也就提升了。

6.参数调优
以上都是业务层代码的优化，除此之外，JVM、Web 容器以及操作系统的优化也是⾮常关键的。

根据⾃⼰的业务场景，合理地设置 JVM 的内存空间以及垃圾回收算法可以提升系统性能。例如，如果我们业务中会创建⼤量的⼤对象，我们可以通过设置，将这些⼤对象直接放进⽼年代。这样可以减少年轻代频繁发⽣⼩的垃圾回收（Minor GC）， 减少 CPU 占⽤时间，提升系统性能。

Web 容器线程池的设置以及 Linux 操作系统的内核参数设置不合理也有可能导致系统性能瓶颈，根据⾃⼰的业务场景优化这两部分，可以提升系统性能。

兜底策略，确保系统稳定性
上边讲到的所有的性能调优策略，都是提⾼系统性能的⼿段，但在互联⽹⻜速发展的时代，产品的⽤户量是瞬息万变的，⽆论
我们的系统优化得有多好，还是会存在承受极限，所以为了保证系统的稳定性，我们还需要采⽤⼀些兜底策略。

什么是兜底策略？
第⼀，限流，对系统的⼊⼝设置最⼤访问限制。这⾥可以参考性能测试中探底接⼝的 TPS 。同时采取熔断措施，友好地返回没有成功的请求。

第⼆，实现智能化横向扩容。智能化横向扩容可以保证当访问量超过某⼀个阈值时，系统可以根据需求⾃动横向新增服务。

第三，提前扩容。这种⽅法通常应⽤于⾼并发系统，例如，瞬时抢购业务系统。这是因为横向扩容⽆法满⾜⼤量发⽣在瞬间的请求，即使成功了，抢购也结束了。

⽬前很多公司使⽤ Docker 容器来部署应⽤服务。这是因为 Docker 容器是使⽤ Kubernetes 作为容器管理系统，⽽
Kubernetes 可以实现智能化横向扩容和提前扩容 Docker 服务。

总结
学完这讲，你应该对性能测试以及性能调优有所认识了。我们再通过⼀张图来回顾下今天的内容。

我们将性能测试分为微基准性能测试和宏基准性能测试，前者可以精准地调优⼩单元的业务功能，后者可以结合内外因素，综
合模拟线上环境来测试系统性能。两种⽅法结合，可以更⽴体地测试系统性能。

测试结果可以帮助我们制定性能调优策略，调优⽅法很多，这⾥就不⼀⼀赘述了。但有⼀个共同点就是，调优策略千变万化， 但思路和核⼼都是⼀样的，都是从业务调优到编程调优，再到系统调优。

最后，给你提个醒，任何调优都需要结合场景明确已知问题和性能⽬标，不能为了调优⽽调优，以免引⼊新的Bug，带来⻛险和弊端。

思考题
假设你现在负责⼀个电商系统，⻢上就有新品上线了，还要有抢购活动，那么你会将哪些功能做微基准性能测试，哪些功能做宏基准性能测试呢？

期待在留⾔区看到你的答案。也欢迎你点击“请朋友读”，把今天的内容分享给身边的朋友，邀请他⼀起讨论。

    精选留⾔         <br />![](https://cdn.nlark.com/yuque/0/2022/png/1852637/1646316067122-ba617e06-8270-48a0-9c28-5e705928a728.png#)何何何何何少侠

1. 新品上线需要对系统基础功能、尤其是上线涉及改动、有耦合的业务做宏基准测试，如：⽤户服务、商品服务、订单服务、

⽀付服务、优惠券服务等。从⽽保证⽀撑抢购活动的服务正常运⾏

1. 针对抢购活动，如：秒杀 团购等促销。需要做微基准测试以验证服务是否达到预期。测试过程中需要留意诸如 qps、内存、

cpu、⽹络带宽、线程堆栈等指标是否达标。不仅考虑单机性能，更要拓展到集群时性能的阈值能达到多少从⽽给出更加准确的性能测试评估报告

1. 多说⼀句：此外还要考虑服务的质量，要测试出抢购活动的瓶颈在哪⼉从⽽应对即将到来的⼤促活动，以⽅便开发、运维团队制定更好的如服务限流、降级、动态伸缩等⽅案。

2019-05-24 01:02
作者回复
回答的很全⾯，赞⼀个
2019-05-24 09:03

业余草
总结的很好，期待后⾯的实战内容！！！
2019-05-23 10:37
昨夜星⾠
新上线的系统作宏基础测试，抢购活动作微基本测试
2019-05-23 08:03

SlamDunk
如果我们的服务器有多个 Java 应⽤服务，部署在不同的 Tomcat 下，这就意味着我们的服务器会有多个 JVM。不同tomcat也可以使⽤同⼀个jrm下的同⼀个jvm呀，为什么这⾥要说会有多个jvm呢？
2019-06-07 23:35

CharlesCai
期待作者的新内容！朗读者的声⾳好听⼜专业！提⼀个⼩功能，⽹⻚版能不能实现⼀下标记或做笔记的功能。
2019-05-23 19:47
作者回复
接收成功！谢谢你的建议。
2019-05-24 00:26

⽊偶笨笨
感觉论题有⼀点过于发散，讲到限流熔断这些内容了，我理解限流熔断实际是架构师的事情，是不是另开⼀课再讲。这⻔课foc
us在调优⽅法、⼯具、技巧，以及相关理论⽐如jvm、多线程原理是不是会更合适。
2019-05-23 09:00
作者回复
感谢你的建议。我相信很多同学跟你有⼀样的想法，那就是赶紧学会使⽤性能排查⼯具，性能如何监测分析，如何解决性能问题。

由于不同的性能问题，性能排查以及调优都是不固定的，所以在后⾯的⼀些章节中，会有⼀些结合实际场景来进⾏性能排查的实战。

在⼤家了解⼀些理论性的知识点以及基础之后，也有专⻔⼀讲来讲述性能监测⼯具、调优⼯具的使⽤，所以⼤家保持耐⼼，切记⼼急吃不了热⾖腐。

在这⾥我们强调了即使我们性能测试做的再好，兜底策略是⼀定要做的，兜底也是性能调优的⼀部分。试想下，我们的性能调优做的再好，系统同样存在极限，当系统达到极限，系统肯定出现性能瓶颈。

在学习成⻓的过程中，我们切忌将知识点局限于某个层级，或者将⾃⼰局限于某⼀种语⾔。例如线程池的⼤⼩设置，其实也是
⼀种限流的⽅式，所以限流熔断并不只是局限于架构这块的内容。

我们要做性能调优最重要的⽬的是什么？在我看来就是为了避免发⽣线上事故，如果发⽣线上事故，也是要避免线上⼤⾯积事故。所以性能调优做的再好，系统也是存在极限的，兜底策略是系统的保护伞，特别在⾼并发的系统中，降级/熔断/限流成为保证系统性能稳定性的重要环节。
2019-05-23 10:21

-W.LI-
抢购秒杀，感觉架构层⾯的优化⽐较多吧，尽量缩短链路，缩短响应时间，没有依赖的服务串⾏优化为并⾏。或者本地持久化后保证最终⼀致性。查询商品详情，下单⽀付这些接⼝宏观测试，内部的⽐较占⽤系统资源的关键代码(占⽤IO资源，逻辑复杂消耗CPU资源等)做微测试。还有就是需要做限流兜底，读服务采⽤合理的缓存策略等。
2019-05-24 09:06
阿厚
多少别⼈⼀天没有解决的问题，被我⽤⼀部分⼀部分注释代码，半⼩时解决了。
2019-06-04 18:59
作者回复
如果能⽤排除法去解决问题，是⼀个⽐较好的⽅式。不过很多线上事故，在线下是⽆法重现的，这个⽅式就⽐较难派上⽤场了
。
2019-06-05 09:47

zhangtnty
⽼师好, 我理解⽂中题⽬中抢购的不同实现⽅式是微观调优，综合考虑上线后流量峰值等可为宏观调优。
⽼师在⽂中提到的降级和限流是⽇常关键的⼀环，⽼师把它说成兜底，我常理解为”保命” 。也希望⽼师对于降级和限流可以展开分享⼀篇。各种调优最终都会有极限。
2019-05-24 08:55
作者回复
同学你好，你理解的很到位，兜底就是保命，但⾼于保命，我们不仅仅需要保证系统不挂掉，还要保证流量范围内的请求是正常的。微基准性能测试可以理解为对某块代码进⾏测试，包括对不同实现⽅式的性能测试⽐较。

后⾯我会在实战中讲到限流、降级的实现和使⽤，由于这个属于优化的辅助功能，不做具体实现⽅式的讲解。如果对相关知识感兴趣，可以留⾔保持沟通。
2019-05-24 12:20

建国
⽼师我⼜来了，两个问题，1.您在这节中介绍的那么多的知识点在后⾯的课程中都会逐个讲解到吧 2.有没有nginx调优呢，因为我们给客户部署时发现，⽤阿⾥云的SLB和⾃⼰搭建的nginx，某个接⼝响应时间差10+倍
2019-05-24 08:05
作者回复
你好 建国，欢迎多提问。我先回答你的第⼀个问题，前⾯两讲中，⼀⽅⾯，是让你对性能调优有⼀个全⾯的认识: 调优的⽬的是什么，有没有指标可衡量，如何发现性能问题，发现后，我们有什么策略可以调优; 另⼀⽅⾯，我多次强调了基础知识以及调优的思维⽅式的重要性。所以接下来我将从基础讲起，再到⾼级篇，学会⾼性能编程的同时，总结出⼀惯的调优思维⽅式。从中很多章节中会有结合实际场景使⽤到⼀些测试⼯具以及性能调优⼯具。除了这些，我还会在最后⽤实战的⽅式来为你讲解实际业务场景下的调优。

从这个专栏的⽬录来看，没有专题专⻔讲nginx的调优，nginx如果只是作为转发，由于nginx是基于事件驱动模型实现的web请求转发，使⽤异步处理⽅式来避免阻塞，对性能损耗应该不⼤。如果⽤lua脚本做了⼀些逻辑判断，或者限流等等，这个是有损的，会带来很⼤的损耗。
2019-05-24 09:44

⼃北纬91度灬
⽼师您好，思考题中，新产品中的抢购活动，针对抢购的商品数量、⽀付等内容进⾏微基性能测试，对于商品数量、⽀付这些
⽐较关键的代码，多线程⾼并发下商品数量的读写，数据同步，⽀付的安全等需要精准的测试，⽽宏基准性能测试更是偏向于整体的业务逻辑，针对整个新产品的整体功能，例如秒杀活动的从开始抢购到成功⽀付，或者开始抢购到未抢购到商品等流程进⾏宏基准性能测试，我这样理解对嘛⽼师
2019-05-23 23:02
作者回复
这位同学，你理解的很好。微基准测试我在这⾥纠正⼀点，包括进⼊抢购⻚⾯、提交订单、⽀付调起，再细⼀些包括排队等待功能、库存扣减的分布式锁功能、幂等性校验等。
2019-05-24 20:09

进步慢是⼀种罪
抢购活动（秒杀）作为微基准测试，商品详情⻚浏览，⽀付，⽀付后的通知等做宏基准测试。
2019-05-23 16:56

ANYI
hi，⽼师，⼊职新公司，直接派去客户现场调优，有⼀份压测报⼯，知道是哪些场景性能有问题，但对于业务不熟，只有⼀堆代码；该如何快速进⼊；
2019-05-23 13:37
作者回复
你好 ANYI，建议可以先对⼀个⼀个⼩模块进⾏性能测试和调优。先对⼀些代码性问题进⾏优化，例如之前有同学提到的，合并多次请求，减少多次数据库操作，优化sql（优化join以及索引），优化Java基础代码（集合的合理使⽤，序列化的优化）等等，先完成这些基础性优化。

在这基础之上，我们再去针对⼀些业务进⾏优化，例如业务存在⾼耦合，我们可以解耦业务，使⽤⼀些好的设计⽅法。通过这种⽅式逐步了解整个系统的业务以及架构。

代码层级优化之后，我们可以考虑调优JVM、容器以及操作系统，我相信代码层的优化可以满⾜⼤部分的性能优化需求，其他的性能调优则是满⾜⼀些特殊的场景下的⾼性能需求。

2019-05-23 20:55

etdick
⽼师，现在的微服务架构，⼀台物理机部署了多个微服务。每个服务相当于⼀个JVM。如何调优？
2019-05-23 07:57
作者回复
你好 etdick。

⾸先，在做性能测试时，我们应该单独部署测试每个微服务的性能，尽量排除服务之间的⼲扰，先完成单个服务的性能调优;

其次，模拟线上环境下多个服务部署，根据实际业务来模拟多个服务的⾼峰值的性能测试，如果服务与服务之间存在性能上的互相⼲扰，且属于不同的业务，我们应该考虑实际⽣产环境中，两个业务场景是不是存在相同的峰值期，若是，则需考虑分开不同服务器部署或根据需求进⾏服务降级。

除此之外，我们还可以设置JVM参数来调优各个JVM的内存分配以及垃圾回收。我们知道两个JVM会互相产⽣影响的主要原因是对CPU的使⽤情况，⽽垃圾回收频率是抢占CPU的主要因素。我们可以调优内存分配降低垃圾回收频率，或设置合适的垃圾回收器。由于不同场景具体的分配调优⽅式不同，我们将会在之后的内容中讲解到。
2019-05-23 09:32

Vincent
微基准测试：抢购接⼝，新产品主⻚接⼝，系统现有接⼝。维基准测试保证每个接⼝的功能完备性，接⼝性能符合要求。
宏基准测试：抢购接⼝，涉及促销类活动，抢购接⼝设计较多关联接⼝，⽐如账号，账号，折扣接⼝，业务相关联⽅较多需要综合测试。
2019-07-18 23:47

zengxiangcai
⽼师，你好，关于测试我有⼏个问题
1、⼀般测试环境服务器个线上服务器配置等可能不⼤⼀样，想测试环境搭建和线上⼀个配置⼀样代价也有点⾼，这种情况⼀般该怎么做呢？

2、测试的数据测试环境个线上可能量级不⼤⼀样，这样也必然影响测试结果的吧？

3、像jmeter这种在⼀台机器模拟多线程去访问服务进⾏测试，会不会测试机⽆法模拟那么多线程影响测试效果
2019-07-11 19:20

aofeng
⽼师，你好！
压测时，关注的主要指标是响应时间和系统吞吐量，那么⽤户并发数的⼤⼩反应的是什么呢？
2019-06-25 19:52
作者回复
⽤户并发数的⼤⼩反应了系统的并发能⼒，这个并发数也是⼀个指标。
2019-06-26 11:29

Hammy
⽼师你好，听了你的课受益匪浅。但是我有⼀个问题，您在将空间换时间的举例中使⽤了数据库分表这种当做案例，我个⼈觉得数据库分表本质上不属于空间换时间的样例。因为单表和多表存储数据的总量本质上是恒定的，之所以能提⾼性能是因为分表以后，b+tree索引维护的数据量会降低，从⽽可以减少查询数据的总量以及索引的维护成本。我个⼈觉得分表这种样例是属于将数据结构进⾏拆分，减少单个数据结构存储的数据总量从⽽提升性能，但本质上并没有增加额外的空间。如果⾃⼰的理解有问题，希望可以指出。
2019-06-21 14:31

Jxin
请教⼤佬个问题。函数内部打印⽇志，⽇志的⽂本为中⽂⻓篇描述。是不是每次调⽤该函数都会有new这个⽇志⽂本的开销。毕竟从字节码来看，⽅法内部的字符串不会被纳⼊常量池。
2019-06-03 12:48
作者回复
是的，但这种打印⽇志的字符串⼀般很少被⻓时间引⽤，打完⽇志对象很快会被回收。
2019-06-03 21:51

Geek_ebda96
⽼师，这句话
这就是热身过程，如果在进⾏性能测试时，热身时间过⻓，就会导致第⼀次访问速度过慢，你就可以考虑先优化，再进⾏测试
。
指的优化是优化JVM的⼀些参数，还是指优化代码呢？如果是优化代码，热身时间过⻓，有没有例⼦能够说明⼀些，第⼀次查询数据先放⼊缓存这个算吗？
2019-06-02 15:45
作者回复
可以通过设置CompileThreshold参数降低执⾏⽅法次数阈值来提前预热代码，也可以通过调⽤WarmUpContextListener.invoke
⽅法指定需要预热的⽅法，当然也可以在启动时提前写个循环或多线程调⽤该⽅法。

我们还可以使⽤⼀些⼯具来预热，例如之前有同学提到的JMH。
2019-06-03 21:47