那么我们在评论辩论高并发的时候,究竟在谈些什么东西呢?高并发究竟是什么?
这里先给出结论:高并发的基本表现为单位韶光内系统能够同时处理的要求数,高并发的核心是对 CPU 资源的有效压榨。
举个例子,如果我们开拓了一个叫做 MD5 穷举的运用,每个要求都会携带一个 MD5 加密字符串,终极系统穷举出所有的结果,并返回原始字符串。
这个时候我们的运用处景或者说运用业务是属于 CPU 密集型而不是 IO 密集型。
这个时候 CPU 一贯在做有效打算,乃至可以把 CPU 利用率跑满,这时我们评论辩论高并发并没有任何意义。(当然,我们可以通过加机器也便是加 CPU 来提高并发能力,这个是一个正常猿都知道的废话方案,评论辩论加机器没有什么意义,没有任何高并发是加机器办理不了,如果有,那解释你加的机器还不足多!)
对付大多数互联网运用来说,CPU 不是也不应该是系统的瓶颈,系统的大部分韶光的状况都是 CPU 在等 I/O (硬盘/内存/网络) 的读/写操作完成。
这个时候就可能有人会说,我看系统监控的时候,内存和网络都很正常,但是 CPU 利用率却跑满了这是为什么?
这是一个好问题,后文我会给呈现实的例子,再次强调上文说的 '有效压榨' 这 4 个字,这 4 个字会环绕本文的全部内容!
掌握变量法
万事万物都是相互联系的,当我们在评论辩论高并发的时候,系统的每个环节该当都是须要与之相匹配的。我们先来回顾一下一个经典 C/S 的 HTTP 要求流程。
如图中的序号所示:
我们会经由 DNS 做事器的解析,要求到达负载均衡集群。负载均衡做事器会根据配置的规则,将要求分摊到做事层。做事层也是我们的业务核心层,这里可能也会有一些 RPC、MQ 的一些调用等等。再经由缓存层。末了持久化数据。返回数据给客户端。要达到高并发,我们须要负载均衡、做事层、缓存层、持久层都是高可用、高性能的。
乃至在第 5 步,我们也可以通过压缩静态文件、HTTP2 推送静态文件、CDN 来做优化,这里的每一层我们都可以写几本书来谈优化。
本文紧张谈论做事层这一块,即图红线圈出来的那部分。不再考虑讲述数据库、缓存干系的影响。高中的知识见告我们,这个叫掌握变量法。
再谈并发
网络编程模型的演化历史
并发问题一贯是做事端编程中的重点和难点问题,为了优化系统的并发量,从最初的 Fork 进程开始,到进程池/线程池,再到 Epoll 事宜驱动(Nginx、Node.js 反人类回调),再到协程。
从上中可以很明显的看出,全体演化的过程,便是对 CPU 有效性能压榨的过程。什么?不明显?
那我们再谈谈高下文切换
在评论辩论高下文切换之前,我们再明确两个名词的观点:
并行:两个事宜同一时候完成。并发:两个事宜在同一韶光段内交替发生,从宏不雅观上看,两个事宜都发生了。线程是操作系统调度的最小单位,进程是资源分配的最小单位。由于 CPU 是串行的,因此对付单核 CPU 来说,同一时候一定是只有一个线程在占用 CPU 资源的。因此,Linux 作为一个多任务(进程)系统,会频繁的发生进程/线程切换。
在每个任务运行前,CPU 都须要知道从哪里加载,从哪里运行,这些信息保存在 CPU 寄存器和操作系统的程序计数器里面,这两样东西就叫做 CPU 高下文。
进程是由内核来管理和调度的,进程的切换只能发生在内核态,因此虚拟内存、栈、全局变量等用户空间的资源,以及内核堆栈、寄存器等内核空间的状态,就叫做进程高下文。
前面说过,线程是操作系统调度的最小单位。同时线程会共享父进程的虚拟内存和全局变量等资源,因此父进程的资源加上线上自己的私有数据就叫做线程的高下文。
对付线程的高下文切换来说,如果是同一进程的线程,由于有资源共享,以是会比多进程间的切换花费更少的资源。
现在就更随意马虎阐明了,进程和线程的切换,会产生 CPU 高下文切换和进程/线程高下文的切换。而这些高下文切换,都是会花费额外的 CPU 资源的。
进一步谈谈协程的高下文切换
那么协程就不须要高下文切换了吗?须要,但是不会产生 CPU 高下文切换和进程/线程高下文的切换,由于这些切换都是在同一个线程中。
即用户态中的切换,你乃至可以大略的理解为,协程高下文之间的切换,便是移动了一下你程序里面的指针,CPU 资源依旧属于当前哨程。
须要深刻理解的,可以再深入看看 Go 的 GMP 模型。终极的效果便是协程进一步压榨了 CPU 的有效利用率。
回到开始的那个问题
这个时候就可能有人会说,我看系统监控的时候,内存和网络都很正常,但是 CPU 利用率却跑满了。这是为什么?
把稳本篇文章在谈到 CPU 利用率的时候,一定会加上有效两字作为定语,CPU 利用率跑满,很多时候实在是做了很多低效的打算。
以\公众天下上最好的措辞\"大众为例,范例 PHP-FPM 的 CGI 模式,每一个 HTTP 要求:
都会读取框架的数百个 PHP 文件都会重新建立/开释一遍 MySQL/Redis/MQ连接都会重新动态阐明编译实行 PHP 文件都会在不同的 php-fpm 进程直接一直的切换切换再切换PHP 的这种 CGI 运行模式,根本上就决定了它在高并发上的灾害性表现。
找到问题,每每比办理问题更难。当我们理解了当我们在评论辩论高并发究竟在谈什么之后,我们会创造高并发和高性能并不是编程措辞限定了你,限定你的只是你的思想。
找到问题,办理问题!当我们能有效压榨 CPU 性能之后,能达到什么样的效果?
下面我们看看 PHP+Swoole 的 HTTP 做事与 Java 高性能的异步框架 Netty 的 HTTP 做事之间的性能差异比拟。
性能比拟前的准备
Swoole 是什么
Swoole 是一个为 PHP 开拓职员用 C 和 C++ 编写的基于事宜的高性能异步&协程并行网络通信引擎。
Netty 是什么
Netty 是由 JBOSS 供应的一个 Java 开源框架。Netty 供应异步的、事宜驱动的网络运用程序框架和工具,用以快速开拓高性能、高可靠性的网络做事器和客户端程序。
单机能够达到的最大 HTTP 连接数是多少?回顾一下打算机网络的干系知识,HTTP 协议是运用层协议,在传输层,每个 TCP 连接建立之前都会进行三次握手。
每个 TCP 连接由本地 IP,本地端口,远端 IP,远端端口,四个属性标识。
TCP 协议报文头如上图(图片来自维基百科):
本地端口由 16 位组成,因此本地端口的最多数量为 2^16 = 65535个。远端端口由 16 位组成,因此远端端口的最多数量为 2^16 = 65535个。同时,在 Linux 底层的网络编程模型中,每个 TCP 连接,操作系统都会掩护一个 File descriptor(fd) 文件来与之对应,而 fd 的数量限定,可以由 ulimt -n 命令查看和修正。
测试之前我们可以实行命令:ulimit -n 65536 修正这个限定为 65535。
因此,在不考虑硬件资源限定的情形下:
本地的最大 HTTP 连接数为:本地最大端口数 65535 本地 IP 数 1 = 65535 个。远真个最大 HTTP 连接数为:远端最大端口数 65535 远端(客户端)IP 数+∞ = 无限制~~ 。PS: 实际上操作系统会有一些保留端口占用,因此本地的连接数实际也是达不到理论值的。
性能比拟
测试资源
各一台 Docker 容器,1G 内存+2 核 CPU,如图所示:
docker-compose 编排如下:
# java8 version: \"大众2.2\"大众 services: java8: container_name: \"大众java8\"大众 hostname: \公众java8\"大众 image: \"大众java:8\"大众 volumes: - /home/cg/MyApp:/MyApp ports: - \"大众5555:8080\"大众 environment: - TZ=Asia/Shanghai working_dir: /MyApp cpus: 2 cpuset: 0,1 mem_limit: 1024m memswap_limit: 1024m mem_reservation: 1024m tty: true # php7-sw version: \公众2.2\"大众 services: php7-sw: container_name: \公众php7-sw\"大众 hostname: \公众php7-sw\"大众 image: \"大众mileschou/swoole:7.1\"大众 volumes: - /home/cg/MyApp:/MyApp ports: - \公众5551:8080\"大众 environment: - TZ=Asia/Shanghai working_dir: /MyApp cpus: 2 cpuset: 0,1 mem_limit: 1024m memswap_limit: 1024m mem_reservation: 1024m tty: true
PHP 代码:
<?php use Swoole\Server; use Swoole\Http\Response; $http = new swoole_http_server(\"大众0.0.0.0\"大众, 8080); $http->set([ 'worker_num' => 2 ]); $http->on(\"大众request\"大众, function ($request, Response $response) { //go(function () use ($response) { // Swoole\Coroutine::sleep(0.01); $response->end('Hello World'); //}); }); $http->on(\"大众start\"大众, function (Server $server) { go(function () use ($server) { echo \"大众server listen on 0.0.0.0:8080 \n\"大众; }); }); $http->start();
Java 关键代码:(源代码来自:https://github.com/netty/netty)
public static void main(String[] args) throws Exception { // Configure SSL. final SslContext sslCtx; if (SSL) { SelfSignedCertificate ssc = new SelfSignedCertificate(); sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build(); } else { sslCtx = null; } // Configure the server. EventLoopGroup bossGroup = new NioEventLoopGroup(2); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.option(ChannelOption.SO_BACKLOG, 1024); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new HttpHelloWorldServerInitializer(sslCtx)); Channel ch = b.bind(PORT).sync().channel(); System.err.println(\"大众Open your web browser and navigate to \公众 + (SSL? \"大众https\公众 : \"大众http\公众) + \"大众://127.0.0.1:\"大众 + PORT + '/'); ch.closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } }
由于我只给了两个核心的 CPU 资源,以是两个做事均只开启两个 Work 进程即可:
5551 端口表示 PHP 做事。5555 端口表示 Java 做事。压测工具结果比拟
ApacheBench (ab)命令:
docker run --rm jordi/ab -k -c 1000 -n 1000000 http://10.234.3.32:5555/
在并发 1000 进行 100 万次 HTTP 要求的基准测试中,Java + Netty 压测结果:
PHP + Swoole 压测结果:
PS:上图选择的是三次压测下的最佳结果。
总的来说,性能差异并不大,PHP+Swoole 的做事乃至比 Java+Netty 的做事还要轻微好一点,特殊是在内存占用方面,Java 用了 600MB,PHP 只用了 30MB。
这能解释什么呢?没有 IO 壅塞操作,不会发生协程切换。
这个仅仅只能解释多线程+Epoll 的模式下,有效的压榨 CPU 性能,你乃至用 PHP 都能写出高并发和高性能的做事。
性能比拟:见证奇迹的时候
上面代码实在并没有展现出协程的精良性能,由于全体要求没有壅塞操作,但每每我们的运用会伴随着例如文档读取、DB 连接/查询等各种壅塞操作,下面我们看看加上壅塞操作后,压测结果如何。
Java 和 PHP 代码中,我都分别加上 Sleep(0.01) //秒的代码,仿照 0.01 秒的系统调用壅塞,代码就不再重复贴上来了。
带 IO 壅塞操作的 Java + Netty 压测结果:
大概 10 分钟才能跑完所有压测,带 IO 壅塞操作的 PHP + Swoole 压测结果:
从结果中可以看出,基于协程的 PHP + Swoole 做事比 Java + Netty 做事的 QPS 高了 6 倍。
当然,这两个测试代码都是官方 Demo 中的源代码,肯定还有很多可以优化的配置,优化之后,结果肯定也会好很多。
可以再思考下,为什么官方默认线程/进程数量不设置的更多一点呢?
进程/线程数量可不是越多越好哦,前面我们已经谈论过了,在进程/线程切换的时候,会产生额外的 CPU 资源花销,特殊是在用户态和内核态之间切换的时候!
对付这些压测结果来说,我并不是针对 Java,我是指只要明白了高并发的核心是什么,找到这个目标,无论用什么编程措辞,只要针对 CPU 利用率做有效的优化(连接池、守护进程、多线程、协程、Select 轮询、Epoll 事宜驱动),你也能搭建出一个高并发和高性能的系统。
以是,你现在明白了,当我们在评论辩论高性能的时候,究竟在谈什么了吗?思路永久比结果主要!
来源:Segmentfault
天下数据与环球近120多个国家顶级机房直接互助,供应包括喷鼻香港、美国、韩国、日本、台湾、新加坡、荷兰、法国、英国、德国、埃及、南非、巴西、印度、越南等国家和地区的做事器、云做事器的租用做事,须要的请联系天下数据客服!