2019年，Golang开始吊打Java性能了！！！

最近要同事debug性能，不经意间发现现在Golang性能开始吊打Java了！！！感觉Go发展神速！！ 之前Go和Java基本是平手，甚至还有较大差距，请见https://www.cnblogs.com/sunsky303/p/6506663.html。借此机会对比了下，Java/Go http server最近的性能，毕竟这是后端同学最关心的问题之一！！

java 10 vs Golang1.12， Google上最快的2个http server性能PK, 压测10次，取平均值。

Java

import org.rapidoid.buffer.Buf;
import org.rapidoid.http.AbstractHttpServer;
import org.rapidoid.http.HttpStatus;
import org.rapidoid.http.MediaType;
import org.rapidoid.net.abstracts.Channel;
import org.rapidoid.net.impl.RapidoidHelper;

public class RapidoidHttpFast extends AbstractHttpServer
{
 private static final int port = 8080;
 private static final byte HOME[] = "/".getBytes();
 private static final byte HELLO_WORLD[] = "Hello World".getBytes();

 @Override
 protected HttpStatus handle(Channel ctx, Buf buf, RapidoidHelper req)
 {
  if (req.isGet.value && matches(buf, req.path, HOME))
  {
   return ok(ctx, req.isKeepAlive.value, HELLO_WORLD, MediaType.TEXT_PLAIN);
  }

  return HttpStatus.NOT_FOUND;
 }

 public static void main(String[] args) throws Exception
 {
  new RapidoidHttpFast().listen(port);
 }
}

sysctl -n machdep.cpu.brand_string ;java --version ;java -cp ".:/Users/wuqj/Downloads/jar_files/*" HelloWorldExample
Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
java 10 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)
19:50:33.353 [main] INFO o.r.config.RapidoidInitializer - Starting Rapidoid v5.5.5, built on 2018-05-27 15:45 UTC
19:50:33.358 [main] INFO o.r.config.RapidoidInitializer - System info | os = Mac OS X | java = 10 | process = [email protected] | max memory = 2048 MB | dir = /labs/java
19:50:33.639 [main] INFO org.rapidoid.env.Environment - No profiles were specified, activating ‘default‘ profile
19:50:33.645 [main] INFO org.rapidoid.env.Environment - No production/dev/test mode was configured, inferring mode | mode = DEV
19:50:33.645 [main] INFO org.rapidoid.env.Environment - Initialized environment | mode = DEV | profiles = [default, dev]
19:50:33.932 [main] INFO org.rapidoid.config.ConfigImpl - Loaded configuration | namespace = config | files = [built-in-config.yml, built-in-config-default.yml, built-in-config-dev.yml]
19:50:34.065 [main] INFO o.rapidoid.http.impl.HttpRoutesImpl - GET / | setup = main | roles = [] | transaction = NONE | mvc = false | cacheTTL = 0
19:50:34.072 [main] INFO org.rapidoid.setup.App - Inferred application root | main = HelloWorldExample | package =
19:50:34.080 [main] INFO org.rapidoid.setup.WatchForChanges - Watching classpath for changes... | classpath = [/labs/java/.]
19:50:34.175 [server] INFO o.r.net.impl.RapidoidServerLoop - Starting server | address = 0.0.0.0 | port = 8080 | I/O workers = 4 | sync = true | accept = non-blocking
19:50:34.399 [main] INFO org.rapidoid.setup.Setup - Server has started | setup = main | home = http://localhost:8080
19:50:34.400 [main] INFO org.rapidoid.setup.Setup - Static resources will be served from the following locations | setup = main | locations = [static, default/static]

ab -c100 -n100000 -k ‘http://127.0.0.1:8080/‘
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests

Server Software:        Rapidoid
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      100
Time taken for tests:   2.872 seconds
Complete requests:      100000
Failed requests:        0
Keep-Alive requests:    100000
Total transferred:      17000000 bytes
HTML transferred:       1100000 bytes
Requests per second:    34822.08 [#/sec] (mean)
Time per request:       2.872 [ms] (mean)
Time per request:       0.029 [ms] (mean, across all concurrent requests)
Transfer rate:          5781.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0      11
Processing:     0    3   1.6      2      27
Waiting:        0    3   1.6      2      27
Total:          0    3   1.6      2      27

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      3
  75%      3
  80%      3
  90%      5
  95%      6
  98%      8
  99%      9
 100%     27 (longest request)

Golang

package main

import (
    "flag"
    "fmt"
    "github.com/valyala/fasthttp"
    "log"
)

var (
    addr     = flag.String("addr", ":8080", "TCP address to listen to")
    compress = flag.Bool("compress", false, "Whether to enable transparent response compression")
)

func main() {
    flag.Parse()
    h := requestHandler

    if err := fasthttp.ListenAndServe(*addr, h); err != nil {
        log.Fatalf("Error in ListenAndServe: %s", err)
    }
}

func requestHandler(ctx *fasthttp.RequestCtx) {
    fmt.Fprintf(ctx, "Hello world")
}
 sysctl -n machdep.cpu.brand_string ;go version ; go run ../fasthttp/helloworldserver.go
Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
go version go1.12.4 darwin/amd64

ab -c100 -n100000 -k ‘http://127.0.0.1:8080/‘
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests

Server Software:        fasthttp
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      100
Time taken for tests:   2.282 seconds
Complete requests:      100000
Failed requests:        0
Keep-Alive requests:    100000
Total transferred:      17000000 bytes
HTML transferred:       1100000 bytes
Requests per second:    43819.46 [#/sec] (mean)
Time per request:       2.282 [ms] (mean)
Time per request:       0.023 [ms] (mean, across all concurrent requests)
Transfer rate:          7274.72 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       7
Processing:     0    2   1.8      2     138
Waiting:        0    2   1.8      2     138
Total:          0    2   1.8      2     140

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      3
  90%      4
  95%      4
  98%      6
  99%      7
 100%    140 (longest request)
QPS上 Go 43819.46吊打 Java 34822.08！！！

看来走Golang路线没错。 后续我有空会分析下原理。

原文地址：https://www.cnblogs.com/sunsky303/p/11680025.html

时间： 2024-10-12 09:10:11

2019年，Golang开始吊打Java性能了！！！的相关文章

Java性能优化技巧及实战

Java性能优化技巧及实战 关于Java代码的性能优化,是每个javaer都渴望掌握的本领,进而晋升为大牛的必经之路,但是对java的调优需要了解整个java的运行机制及底层调用细节,需要多看多读多写多试,并非一朝一夕之功.本文是近期笔者给公司员工内部做的一个培训,主要讲述在系统压测过程中出现的性能问题,以及如何在编码过程中提升代码的运行效率,需要掌握哪些实战技巧.片子里干货较多,也很具有实操性,因此发文出来,共享给大家(部分数据做了去除公司特征信息,见谅).(PS:由于原文是ppt,因此做了导

Java性能调优笔记

Java性能调优笔记 调优步骤:衡量系统现状.设定调优目标.寻找性能瓶颈.性能调优.衡量是否到达目标(如果未到达目标,需重新寻找性能瓶颈).性能调优结束. 寻找性能瓶颈 性能瓶颈的表象:资源消耗过多.外部处理系统的性能不足.资源消耗不多但程序的响应速度却仍达不到要求. 资源消耗:CPU.文件IO.网络IO.内存. 外部处理系统的性能不足:所调用的其他系统提供的功能或数据库操作的响应速度不够. 资源消耗不多但程序的响应速度却仍达不到要求:程序代码运行效率不够高.未充分使用资源.程序结构不合理. C

Java 性能分析工具

如何利用 JConsole观察分析Java程序的运行,进行排错调优 http://jiajun.iteye.com/blog/810150 如何使用JVisualVM进行性能分析 http://jiajun.iteye.com/blog/1180230 全功能的Java剖析工具(profiler) http://www.blogjava.net/mrzhangshunli/archive/2007/08/27/140088.html http://www.cnblogs.com/jayzee/p

java性能优化技巧

一.通用篇 "通用篇"讨论的问题适合于大多数 Java应用. 1.1     new 1.1     new 11..11 不用 nneeww关键词创建类的实例 用new 关键词创建类的实例时,构造函数链中的所有构造函数都会被自动调用.但如 果一个对象实现了Cloneable 接口,我们可以调用它的clone()方法.clone()方法不会调用任 何类构造函数. 在使用设计模式(Design Pattern)的场合,如果用 Factory模式创建对象,则改用clone() 方法创建新的

JAVA性能优化的五种方式

一,JAVA性能优化之设计优化 设计优化处于性能优化手段的上层.它往往须要在软件开发之前进行.在软件开发之前,系统架构师应该就评估系统可能存在的各种潜在问题和技术难点,并给出合理的设计方案,因为软件设计和系统架构对软件总体设计质量有决定性的影响.所以,设计调优对系统的性能影响也是最大的,假设说,代码优化.JVM优化都是对系统微观层次的"量"的优化,那设计优化就是对系统"质"的优化. 设计优化的一大显著特征是:它能够规避某一个组件的性能问题,而是改良组件的实现;比方:

关于 Java 性能监控您不知道的 5 件事，第 1 部分

责怪糟糕的代码(或不良代码对象)并不能帮助您发现瓶颈,提高 Java? 应用程序速度,猜测也不能帮您解决.Ted Neward 引导您关注 Java 性能监控工具,从5 个技巧开始,使用Java 5 的内置分析器JConsole 收集和分析性能数据. 当应用程序性能受到损害时,大多数开发人员都惊慌失措,这在情理之中.跟踪 Java 应用程序瓶颈来源一直以来都是很麻烦的,因为 Java 虚拟机有黑盒效应,而且 Java 平台分析工具一贯就有缺陷. 然而,随着 Java 5 中 JConsole 的

Java性能优化指南系列(二）：Java 性能分析工具

进行JAVA程序性能分析的时候,我们一般都会使用各种不同的工具.它们大部分都是可视化的,使得我们可以直观地看到应用程序的内部和运行环境到底执行了什么操作,所以性能分析(性能调优)是依赖于工具的.在第2章,我强调了基于数据驱动的性能测试是非常重要的,我们必须测试应用的性能并理解每个指标的含义.性能分析和数据驱动非常类似,为了提升应用程序的性能,我们必须获取应用运行的相关数据.如何获取这些数据并理解它们是本章的主题.[本章重点介绍JDK中提供的性能分析工具] 操作系统工具及其分析 程序分析的起点并不

Java性能优化，不得不付诸实践的JVM

暂附贴图,详情稍后叙述,欢迎留言交流 图一.JVM知识体系(部分) 图二.通过jconsole监控jvm 图三.通过jvisualvm监控jvm Java性能优化,不得不付诸实践的JVM,布布扣,bubuko.com

java 性能调优工具

1.jstack 用法jstack [option] pid -l long listings,会打印出额外的锁信息,在发生死锁时可以用jstack -l pid来观察锁持有情况 -m mixed mode,不仅会输出Java堆栈信息,还会输出C/C++堆栈信息(比如Native方法) 找出进程内最耗费CPU的线程,可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid printf "%x\n" pid 得到pid的