【3.工程开发】-评估性能-中间件

盐析枚举
• 阅读 2620

一般中间件性能可以用一下来衡量:TPS/QPS M吞吐 延时(注意这个和QPS不一定*核数/s,还有IO时间等等待时间)。第一部分列出常用中间件的包含nginx,mq,zk,mysql,redis,leveldb,ceph。
除了中间件,在评估自身延时时考虑单机的IO,网络,计算瓶颈。包含常见内存文件网络耗时

第一部分:中间件

nginx

作为代理。万兆网卡,文件1k情况 24核,0.1ms. 50万pqs.500m/s吞吐
http://chenlinux.com/2013/02/...
作为反向代理
proxy_keepalive 的时候 请求1k。30万qps。500M。cpu40%
非keepalive时 并发2400.就满了 40ms延时

kafka

基本可以说延时2ms。单机1k大小 十万级TPS 百兆。多线程生产和消费更多。kafka线程不宜过多。rocketmq稳定(100*8万和100*8000的差别)。
对于这些测试,六台机器,每台都有以下规格:具有六个内核的Intel Xeon 2.5 GHz处理器,六个7200 RPM SATA驱动器,32GB的RAM,1Gb以太网
Kafka集群设置在三台机器上。六个驱动器直接安装,没有RAID(JBOD样式)。剩余的三台机器我用于Zookeeper并用于生成负载。

https://engineering.linkedin....

生产者
单线程 3x异步 100B时80万pqs.80m/s 1K时10万qps,100m/s
同步单副本 40万。40m
3线程 200万。200m
小字节更难处理(100B)

单一消费者 每秒940,521条记录(89.7 MB /秒)
三个消费者 每秒2,615,968条记录(249.5 MB /秒)

端到端延迟(副本复制)
2毫秒(中位数)
3毫秒(第99百分位数)
14毫秒(99.9百分位数)
Kafka仅在完全同步的副本集确认消息时才向消费者发出消息。因此,无论我们使用同步还是异步复制,此测试都会给出相同的结果,因为该设置仅影响对生产者的确认。

zk

zk性能 https://zookeeper.apache.org/...
很一般的机器2核。应该10万并发没问题
1k 5server 万到几十万
7台机器有失败1,2,3并迅速恢复,选举时间200ms。吞吐稳定4万

mysql,redis

mysql慢请求设置:100ms。正常单主键0.5ms。带复杂语句50ms。单实例控制T吧,总几T。
hbase PB
主从延时:1ms。不超过10ms
二级库延时:200ms
redis慢查询 。按照万/s,猜测在0.1ms以下。单实例5G,单台机器100G。
leveldb 4M 1M~10^7M 1T
mysql写入千条/s,读万应该没问题。redis 写入 万条/s 7M/s(k+v 700bytes,双核)读是写入的1.4倍 mem 3gb 2核。这两个网上搜的,不保证正确,就看个大概吧。
SSD上 rocksdb随机和顺序的性能差不多,写要比读性能稍好。随机读写1.7万条/s 14M/s (32核)。batch_write/read下SSD单线程会好8倍。普通write只快1.2倍。

ceph

https://zhuanlan.zhihu.com/p/...
https://cloud.tencent.com/inf...
http://www.dockerman.com/ceph...
1个DC SSD(日志&缓存)+16个大容量硬盘;
随机读
基于4KB随机读测得108万IOPS和3.5ms延时;8KB随机读IOPS下降到50万,延时上升到8.8ms;16KB随机读的IOPS和延时分别为30万和10ms。
随机写
4KB随机写IOPS只有14.4万,比8KB的13.2万没高出太多。 600M/s?
顺序写
Ceph集群的128KB顺序读性能达到了5248MB/s,基本发挥出每节点双万兆网口的带宽;128KB顺序写带宽测得1927MB/s(比随机写好多了)。

第二部分:计算

文件

以下均为1M————————————
【3.工程开发】-评估性能-中间件
内存 顺序0.25ms.非顺序1ms 顺序5G/S 随机比SSD块20倍 顺序5倍
SSD 顺序1ms.非顺序30ms. 顺序最快1G/S。平时单词少量可以说0.1ms了。数据小会更快。
普通磁盘 顺序读30ms.一次寻道10ms。最快应该是10ms,无论大小.目前是3ms

————————————————————————————

网络

同城跨机房网络延时:0.5ms
同机房网络延时:0.05ms
跨城北京到广州:50ms

性能分析实例

1.生成一张有30张缩略图(原始大小256K)的页面时间:
a.顺序操作,从磁盘读+压缩 3010ms+30256K/30Mps=560ms
b.并发:一次发送30个 18ms
2.1G 4B 整数快排

2^28 * log( 2^28 ) * 1/2(一半交换) = 21s。每次分割都要扫描一遍内存 28*1G/4Gps = 7s  和28s

3.bigtable 1k数据
随机读(缓存不命中) 先从GFS读64K 磁盘IOPS10块 每个100.理论1000qps/s 折损为300 因此:1k300ps
内存随机读 cpu限制按照10W,内存开销大折损2万=》20Mps

【3.工程开发】-评估性能-中间件
【3.工程开发】-评估性能-中间件
故障率
【3.工程开发】-评估性能-中间件
【3.工程开发】-评估性能-中间件

点赞
收藏
评论区
推荐文章
十月飞翔 十月飞翔
3年前
网络性能的四大指标:带宽、时延、抖动、丢包
衡量网络性能的四大指标:带宽、时延、抖动、丢包。如何客户需要我们去评估一个网络的性能,我们就可以从这四方面去进行评估。带宽1、带宽概念:带宽在百度百科中定义:在单位时间内从网络中的某一点到另一点所能通过的“最高数据率”。计算机网络的带宽是指网络可通过的最高数据率,即每秒多少比特(常用的单位是bps(bitpersecond))。简单的讲:带宽可以比喻是高
一文详解 Netty 组件
作者:京东物流张弓言一、背景Netty是一款优秀的高性能网络框架,内部通过NIO的方式来处理网络请求,在高负载下也能可靠和高效地处理I/O操作作为较底层的网络通信框架,其被广泛应用在各种中间件的开发中,比如RPC框架、MQ、Elasticsearch等,这
Stella981 Stella981
3年前
Nginx多进程高并发、低时延、高可靠机制在缓存(redis、memcache)twemproxy代理中的应用
_0\.手把手教你做中间件、高性能服务器、分布式存储技术交流群_手把手教你做中间件、高性能服务器、分布式存储等(redis、memcache、nginx、大容量redispika、rocksdb、mongodb、wiredtiger存储引擎、高性能代理中间件),git地址如下:git地址:https://github.com/y1234
Stella981 Stella981
3年前
Kafka、RabbitMQ、RocketMQ等消息中间件的对比 —— 消息发送性能和区别
Kafka、RabbitMQ、RocketMQ等消息中间件的对比——消息发送性能和区别那么,消息中间件性能究竟哪家强?带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了
Stella981 Stella981
3年前
Kafka、RabbitMQ、RocketMQ消息中间件的对比 —— 消息发送性能
引言分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品RocketMQ(MetaQ的内核)也顺利开源,得到大家的关注。那么,消息中间件性能究竟哪家强?带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性
Stella981 Stella981
3年前
Redis(1.7)Redis高可用架构(理论篇)
【0】常用架构种类  (0.1)单机Redis  (0.2)单纯的Redis主从复制  (0.3)哨兵SentinelRedis主从复制集群(实现高可用自动故障转移)  (0.4)RedisCluster分布式数据库集群  (0.5)第三方中间件Redis主从复制【1】Redis主从复制
Stella981 Stella981
3年前
Kafka 消息存储与索引设计
消息中间件的性能好坏,它的消息存储的机制是衡量该性能的最重要指标之一,而Kafka具有高性能、高吞吐、低延时的特点,动不动可以上到几十上百万TPS,离不开它优秀的消息存储设计。下面我按照自己的理解为大家讲解Kafka消息存储设计的那些事。在Kafka的设计思想中,消息的存储文件被称作日志,我们Java后端绝大部分人谈到日志,一般会联想到
Stella981 Stella981
3年前
Redis5.0:简单的集群模式——主从模式详解
主从模式主从模式是最简单的集群模式,其实就是复制基本只能解决读写分离问题,主机服务器一旦宕机基本完蛋,不具备高可用。基本上redis的性能瓶颈主要在于网络IO和内存主频上面,单机版Redis在不考虑高可用的情况下基本满足80%的项目需要,因为单机版Redis可以实现10W/S的请求,除非缓存KV值过大,通过读写分离缓存网卡的压
京东云开发者 京东云开发者
10个月前
聊聊JVM如何优化
首先应该明确的是JVM调优不是常规手段,JVM的存在本身就是为了减轻开发对于内存管理的负担,当出现性能问题的时候第一时间考虑的是代码逻辑与设计方案,以及是否达到依赖中间件的瓶颈,最后才是针对JVM进行优化。1.JVM内存模型针对JAVA8的模型进行讨论,J
盐析枚举
盐析枚举
Lv1
殊方日落玄猿哭,旧国霜前白雁来。
文章
5
粉丝
0
获赞
0