Low overhead time stamp acquisition

Master of insect catching 2021-04-16 18:08:11
low overhead time stamp acquisition


Preface

In the previous article 《Cobar SQL Design and implementation of audit 》 A question about the performance of time stamp acquisition is raised in

Get the operating system time , stay Java Call directly System.currentTimeMillis(); Can , But in Cobar If you get the time in this way , It will lead to very serious performance loss ( How to solve ? Go to Cobar Of github Look at the code in the warehouse ).

Let's talk about this topic in detail , We are Java The way to get a timestamp in is System.currentTimeMillis(), It returns a millisecond timestamp , View source code , The notes are clear , Although the method returns a millisecond timestamp , But the accuracy depends on the operating system , Many operating systems return precision of 10 millisecond .

    /**
     * Returns the current time in milliseconds.  Note that
     * while the unit of time of the return value is a millisecond,
     * the granularity of the value depends on the underlying
     * operating system and may be larger.  For example, many
     * operating systems measure time in units of tens of
     * milliseconds.
     *
     * <p> See the description of the class <code>Date</code> for
     * a discussion of slight discrepancies that may arise between
     * "computer time" and coordinated universal time (UTC).
     *
     * @return  the difference, measured in milliseconds, between
     *          the current time and midnight, January 1, 1970 UTC.
     * @see     java.util.Date
     */

    public static native long currentTimeMillis();

About why System.currentTimeMillis() slow , A big man wrote an article to explain the reasons in detail , It is recommended that you read , Very deep and detailed , Article address

http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

To sum up, the reason is System.currentTimeMillis Called gettimeofday()

  • call gettimeofday() You need to switch from user state to kernel state ;
  • gettimeofday() The performance of Linux The timer of the system ( Clock source ) influence , stay HPET The performance of the timer is especially poor ;
  • The system has only one global clock source , High concurrency or frequent access can cause serious contention .

So let's test that out System.currentTimeMillis() Performance in different threads , Here we use the common middleware JHM To test , test 1 To 128 Get under thread 1000 What is the time required for 10000 timestamps , Here are the test data on my computer :

Benchmark                    Mode  Cnt  Score   Error  Units
TimeStampTest.test1Thread    avgt       0.271           s/op
TimeStampTest.test2Thread    avgt       0.272           s/op
TimeStampTest.test4Thread    avgt       0.278           s/op
TimeStampTest.test8Thread    avgt       0.375           s/op
TimeStampTest.test16Thread   avgt       0.737           s/op
TimeStampTest.test32Thread   avgt       1.474           s/op
TimeStampTest.test64Thread   avgt       2.907           s/op
TimeStampTest.test128Thread  avgt       5.732           s/op

As can be seen in the 1-4 It's faster under the thread ,8 After the thread is linear growth .

Test code reference :

@State(Scope.Benchmark)
public class TimeStampTest {

    private static final int MAX = 10000000;

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(TimeStampTest.class.getSimpleName())
                .forks(1)
                .warmupIterations(1)
                .measurementIterations(1)
                .warmupTime(TimeValue.seconds(5))
                .measurementTime(TimeValue.seconds(5))
                .mode(Mode.AverageTime)
                .syncIterations(false)
                .build()
;

        new Runner(opt).run();
    }

    @Benchmark
    @Threads(1)
    public void test1Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(2)
    public void test2Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(4)
    public void test4Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(8)
    public void test8Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(16)
    public void test16Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(32)
    public void test32Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(64)
    public void test64Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(128)
    public void test128Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    private static long currentTimeMillis() {
        return System.currentTimeMillis();
    }
}

solution

The easiest way to think of it is to cache timestamps , And use a separate thread to update it . In this way, the access is just taken from the memory , The cost is very small , But the disadvantages are obvious , The update frequency determines the accuracy of the timestamp .

Cobar

Cobar The code for getting and updating timestamps is located in

https://github.com/alibaba/cobar/blob/master/server/src/main/server/com/alibaba/cobar/util/TimeUtil.java

/**
 *  Weak precision timer , Consider performance without using synchronization strategy .
 * 
 * @author xianmao.hexm 2011-1-18  Afternoon 06:10:55
 */

public class TimeUtil {
    private static long CURRENT_TIME = System.currentTimeMillis();

    public static final long currentTimeMillis() {
        return CURRENT_TIME;
    }

    public static final void update() {
        CURRENT_TIME = System.currentTimeMillis();
    }

}

The timing scheduling code is located in

https://github.com/alibaba/cobar/blob/master/server/src/main/server/com/alibaba/cobar/CobarServer.java

timer.schedule(updateTime(), 0L, TIME_UPDATE_PERIOD);
...
//  The system time is updated regularly
private TimerTask updateTime() {
    return new TimerTask() {
        @Override
        public void run() {
            TimeUtil.update();
        }
    };
}

and Cobar Update interval in TIME_UPDATE_PERIOD yes 20 millisecond

Sentinel

Sentinel Cache timestamps are also used , Its code is located in

https://github.com/alibaba/Sentinel/blob/master/sentinel-core/src/main/java/com/alibaba/csp/sentinel/util/TimeUtil.java

public final class TimeUtil {

    private static volatile long currentTimeMillis;

    static {
        currentTimeMillis = System.currentTimeMillis();
        Thread daemon = new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    currentTimeMillis = System.currentTimeMillis();
                    try {
                        TimeUnit.MILLISECONDS.sleep(1);
                    } catch (Throwable e) {

                    }
                }
            }
        });
        daemon.setDaemon(true);
        daemon.setName("sentinel-time-tick-thread");
        daemon.start();
    }

    public static long currentTimeMillis() {
        return currentTimeMillis;
    }
}

You can see Sentinel What is achieved is every 1 One millisecond cache .

Let's modify the test code and test Sentinel The way to achieve this is 1-128 Performance under threads

Benchmark                    Mode  Cnt   Score   Error  Units
TimeStampTest.test1Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test2Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test4Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test8Thread    avgt       ≈ 10⁻³           s/op
TimeStampTest.test16Thread   avgt        0.001           s/op
TimeStampTest.test32Thread   avgt        0.001           s/op
TimeStampTest.test64Thread   avgt        0.003           s/op
TimeStampTest.test128Thread  avgt        0.006           s/op

It can be used directly System.currentTimeMillis contrast , The gap is very clear .

Last

Although cache timestamp performance can be improved a lot , But it's also limited to very high concurrency systems , It is generally suitable for middleware with high concurrency , If the general system does this optimization , The effect is not obvious . Performance optimization still needs to grasp the main contradiction , Solve the bottleneck , Avoid transition optimization .


Welcome to my official account. “ Master bug catcher ”


版权声明
本文为[Master of insect catching]所创,转载请带上原文链接,感谢
https://javamana.com/2021/04/20210416162222558B.html

  1. 【计算机网络 12(1),尚学堂马士兵Java视频教程
  2. 【程序猿历程,史上最全的Java面试题集锦在这里
  3. 【程序猿历程(1),Javaweb视频教程百度云
  4. Notes on MySQL 45 lectures (1-7)
  5. [computer network 12 (1), Shang Xuetang Ma soldier java video tutorial
  6. The most complete collection of Java interview questions in history is here
  7. [process of program ape (1), JavaWeb video tutorial, baidu cloud
  8. Notes on MySQL 45 lectures (1-7)
  9. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  10. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  11. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  12. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  13. 【递归,Java传智播客笔记
  14. [recursion, Java intelligence podcast notes
  15. [adhere to painting for 386 days] the beginning of spring of 24 solar terms
  16. K8S系列第八篇(Service、EndPoints以及高可用kubeadm部署)
  17. K8s Series Part 8 (service, endpoints and high availability kubeadm deployment)
  18. 【重识 HTML (3),350道Java面试真题分享
  19. 【重识 HTML (2),Java并发编程必会的多线程你竟然还不会
  20. 【重识 HTML (1),二本Java小菜鸟4面字节跳动被秒成渣渣
  21. [re recognize HTML (3) and share 350 real Java interview questions
  22. [re recognize HTML (2). Multithreading is a must for Java Concurrent Programming. How dare you not
  23. [re recognize HTML (1), two Java rookies' 4-sided bytes beat and become slag in seconds
  24. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  25. RPC 1: how to develop RPC framework from scratch
  26. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  27. RPC 1: how to develop RPC framework from scratch
  28. 一次性捋清楚吧,对乱糟糟的,Spring事务扩展机制
  29. 一文彻底弄懂如何选择抽象类还是接口,连续四年百度Java岗必问面试题
  30. Redis常用命令
  31. 一双拖鞋引发的血案,狂神说Java系列笔记
  32. 一、mysql基础安装
  33. 一位程序员的独白:尽管我一生坎坷,Java框架面试基础
  34. Clear it all at once. For the messy, spring transaction extension mechanism
  35. A thorough understanding of how to choose abstract classes or interfaces, baidu Java post must ask interview questions for four consecutive years
  36. Redis common commands
  37. A pair of slippers triggered the murder, crazy God said java series notes
  38. 1、 MySQL basic installation
  39. Monologue of a programmer: despite my ups and downs in my life, Java framework is the foundation of interview
  40. 【大厂面试】三面三问Spring循环依赖,请一定要把这篇看完(建议收藏)
  41. 一线互联网企业中,springboot入门项目
  42. 一篇文带你入门SSM框架Spring开发,帮你快速拿Offer
  43. 【面试资料】Java全集、微服务、大数据、数据结构与算法、机器学习知识最全总结,283页pdf
  44. 【leetcode刷题】24.数组中重复的数字——Java版
  45. 【leetcode刷题】23.对称二叉树——Java版
  46. 【leetcode刷题】22.二叉树的中序遍历——Java版
  47. 【leetcode刷题】21.三数之和——Java版
  48. 【leetcode刷题】20.最长回文子串——Java版
  49. 【leetcode刷题】19.回文链表——Java版
  50. 【leetcode刷题】18.反转链表——Java版
  51. 【leetcode刷题】17.相交链表——Java&python版
  52. 【leetcode刷题】16.环形链表——Java版
  53. 【leetcode刷题】15.汉明距离——Java版
  54. 【leetcode刷题】14.找到所有数组中消失的数字——Java版
  55. 【leetcode刷题】13.比特位计数——Java版
  56. oracle控制用户权限命令
  57. 三年Java开发,继阿里,鲁班二期Java架构师
  58. Oracle必须要启动的服务
  59. 万字长文!深入剖析HashMap,Java基础笔试题大全带答案
  60. 一问Kafka就心慌?我却凭着这份,图灵学院vip课程百度云