前段时间公司的分布式图片文件系统(FastDFS)做了图片裁剪和缩放功能,并把缩放计算和FastDFS做了解耦分离,前端用虚拟机作为图片文件缩放的訪问代理层(Nginx Proxy),后端使用nginx直接訪问FastDFS的文件系统。

下面是測试和分析过程。

1測试场景

为了測试解耦后的图片读取并发和分析系统瓶颈,我们在内网中搭建了一个測试环境。

下面是測试环境的网络的物理架构图:

上图中:

NginxProxy:CPU解耦后的图片裁剪代理server

Storage:图片的存储server

ab:图片訪问的模拟压力測试client

訪问的原图大小:75KB,分辨率640 * 480

裁剪后的图片大小:23KB

Nginx Proxy的CPU:4核 2.5G

Nginx Proxy的内存:4G

2測试用例

全部測试的样本请求总数都是100000个

2.1 ab直接对storage获取原图

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVhbnJ4ZHU=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

Ab连接并发

TPS

Storage CPU(%)

请求失败数

响应延迟(ms)

Storage带宽(KB/S)

浏览器訪问图片

32

1496

15%

0

21

119313

无延迟感

64

1495

20%

0

42

119728

无延迟感

128

1490

20%

0

85

120299

无延迟感

512

1492

18%

0

343

120157

略微延迟,不明显

1024

1491

25%

167

670

124660

略微延迟,不明显

小结:

从上面的数据能够看出,这样的方式的測试主要瓶颈是在网络带宽上,TPS的能力直接是受限于网络的带宽。CPU和内存不会是瓶颈。这里要注意的是我们採用的是訪问同一种图片,所以无法分析磁盘IO的并发,关于Storage的磁盘IO并发我们在后面做具体的分析总结。

2.2 ab通过Nginx proxy訪问图片

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVhbnJ4ZHU=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

2.2.1原图訪问

Ab并发

TPS

Proxy cpu(%)

失败数

响应延迟(ms)

Storage带宽(KB/S)

浏览器訪问图片

32

1213

30%

0

26

102020

无延迟感

64

1254

30%

0

51

102553

无延迟感

128

1287

40%

0

99

104841

无延迟感

256

1321

42%

0

193

110028.2

无延迟感

512

1337

45%

0

381

108868.8

略微延迟

1024

1354

48%

0

755

115988

略微延迟

小结:

这个case和2.1情况差点儿相同。TPS稍有下降,proxy的CPU尽管比較高(没过50%),可是并发数是受storage带宽的限制。带宽是这样的case最大的瓶颈.这里CPU高的原因是由于HTTP是短连接请求,nginx不停的受理来之ab的TCP请求和发起对storage的upstream的TCP请求导致的。

2.2.2裁剪图訪问

Ab并发

TPS

Proxy cpu(%)

失败数

响应延迟(ms)

Storage带宽(KB/S)

浏览器訪问图片

32

264

89%

0

121

21563

稍有延迟

64

273

97%

0

234

23472

稍有延迟

128

279

100%

0

458

24270

稍有延迟

256

278

100%

0

917

27656

稍有延迟

512

277

100%

0

1844

24646

稍有延迟

1024

274

100%

0

3723

18408

明显延迟

小结:

这个case的測试数据能够看出。NginxProxy的CPU成为整个系统的瓶颈,TPS仅仅有280左右。

Storage的带宽还有近100M的富余。在这样的情况測试后,我们添加一个PROXY来进行測试。

2.3 通过两台Nginx Proxy訪问裁剪图片


有两个abclient同一时候发起測试请求,比如64个并发,那么每一个ab 发起32个并发

Ab并发

TPS

Proxy cpu(%)

失败数

响应延迟(ms)

Storage带宽(KB/S)

浏览器訪问图片

64

497

86%

0

127

40133

稍有延迟

128

529

95%

0

242

44907

稍有延迟

256

548

98%

0

464

45048

稍有延迟

512

551

100%

0

920

47411

稍有延迟

1024

553

100%

0

1821

47745

稍有延迟

2048

552

100%

0

3725

50552

明显延迟

小结

这个case和2.2.2的case比較能够得出,添加NginxProxy的数量在Storage有富余带宽的情况下是基本成线性增长的关系。在Storage 磁盘IO无线和1G带宽的情况下,一个Storage能够挂在4核 2.5GHZ CPU运算能力的proxy最多4个。

3測试结果分析

3.1 CPU

从以上4个測试case的结果看,耗CPU的主要是在图片的裁剪上。依据2.2.2的測试数据。我们能够得出一个主要的CPU与裁剪图片的数据之间的关系,例如以下:

在CPU100%的时候,Storage上的带宽是24270KB。那么1GHZ运能能力能裁剪大概的带宽数据:

1GHZ每秒裁剪的带宽数据 = 24270KB / (4 * 2.5G) = 2427KB =2.4MB

1GHZ每秒裁剪的图片数 = 279 / (4 * 2.5G) = 28张。

(分辨率640 x 480 成 300 x 300)

由于线上生产环境是原图套图和裁剪图混合訪问。1GHZCPU的实际运算能力应该在40 ~ 50左右。这个详细要看各种图片的分布比例。

3.2内存

在整个測试过程中,Nginx Proxy的每一个进程的内存始终保持在50M左右。假设在Storage和Proxy之间带宽不足或者网络不稳定的情况下,Proxy的内存将会大大添加(在10月21日的測试中,4个nginx总共占用了1.7G的内存),这是因为图片分片从storage发送过来时。Proxy须要在内存中拼接图片导致的。

3.3磁盘IO

这个測试过程中,我们始终都是訪问同一张图片。所以不存在磁盘IO的測试。我们能够依据SATA硬盘(7200转速)的一些特性做随机文件訪问的分析。基于LevelDB和innoDB引擎对SATA硬盘的两个基本參数我们能够做详细的分析。这两个參数是:

1、  磁盘在seek一次须要耗费10ms左右的时间

2、  磁盘顺序读取1M数据到内存须要10ms左右的时间。

基于我们的Storage上都是随机訪问小文件(大部分100KB~ 200KB以内),那么Storage在读取一个小文件的时候必须seek一次,在进行顺序读取。我们线上环境有各种图片格式。大小不一,我们暂且以图片大小平均100KB来分析。

从上面两个參数我们非常easy知道随机读取一张100KB的图片大概须要的时间:

Readdelay = seek + read time = 10ms + 10ms / 10 = 11ms;

那么一秒钟我们单个SATA盘最大能够读取的图片数:

Percount = 1000 / 11 = 90张。

线上环境通常是单个Storage配置12个SATA盘。

那么一个Storage最大能够的图片数:

Maxread count = 90 * 12 = 1080张。

假设考虑文件的PageCache的话,Max Read count可能会略大于这个数字。

这个计算不过12个磁盘所实用于读。没有 写的情况。在实际情况是有写的,由于商家会不定时添加或者改动图片。Max read count在实际系统中是会小于1080张的。

尤其是在遇到类似图片搬家之类操作时,磁盘的IO能力会大大打折扣。

从这个分析结果再对照我们2.1中的TPS = 1495能够看出,Max readcount < TPS,也就是说假设Storage的带宽是千兆,那么带宽是大于磁盘IO的。所以在带宽达到极限之前,磁盘IO首先会成为瓶颈。

从上面分析的结果我们能够得出,一个Storage磁盘IO读的TPS 在600 ~ 700左右就应该是瓶颈了。

3.4网络带宽

通过上面4个CASE,我们基本知道Storage和Nginx Proxy之间的带宽是一个非常重要的因素。由于做了CPU解耦。无疑添加了一次原图拉取的开销。我们线上环境可能是採用例如以下的物理网络拓扑:

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVhbnJ4ZHU=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

假设Nginx Proxy集群的CPU运算能力和右边的Storage集群的磁盘IO都能力超过交换机之间的网络传输能力的话,那么瓶颈就会在交换机之间的带宽上。我们还是以原图平均大小为100KB来计算,假设交换机之间是千兆网络,那么转换成字节带宽为:

Bandwidth=1024 mb / 8 = 128MB

proxy集群每秒能同一时候获得的原图数:

PerPic count = 128M / 0.1 = 1280张。

这里的计算并没有除去TCP本身的净核,一般用到120M就是比較高效的。

也就是说最多不超过1200张图片。

4结论

我们能够初步依照2.2.2的case和3.3的磁盘IO分析得出主要的proxy/storage和带宽之间的相应关系。我们能够得出一个主要的结论:

50GHZ的CPU运算能力每秒能够裁剪近1200~1500张图片。带宽在120MB/S.

         3台storage除去磁盘IO写负载。大概每秒能读取1000
~ 1100张图片。

         配上1GB的传输带宽。

通过Nginx訪问FastDFS文件系统并进行图片文件裁剪的性能測试和分析的更多相关文章

  1. Nginx 訪问日志增长暴增出现尖刀的具体分析

    前言:          Nginx日志里面Mobileweb_access.log增长特别大.一天上百兆.将近100W的訪问记录.依照我们眼下的规模,热点用户才500个左右.就算人人用手机app訪问 ...

  2. Linux 终端訪问 FTP 及 上传下载 文件

    今天同事问我一个问题,在Linux 下訪问FTP,并将文件上传上去. 我之前一直是用WinSCP工具的. 先将文件从linux copy到windows下,然后在传到ftp上. google 一下. ...

  3. Hadoop HDFS (3) JAVA訪问HDFS

    如今我们来深入了解一下Hadoop的FileSystem类. 这个类是用来跟Hadoop的文件系统进行交互的.尽管我们这里主要是针对HDFS.可是我们还是应该让我们的代码仅仅使用抽象类FileSyst ...

  4. HDFS简单介绍及用C语言訪问HDFS接口操作实践

    一.概述 近年来,大数据技术如火如荼,怎样存储海量数据也成了当今的热点和难点问题,而HDFS分布式文件系统作为Hadoop项目的分布式存储基础,也为HBASE提供数据持久化功能,它在大数据项目中有很广 ...

  5. Fusioncharts的导出图片訪问官网问题

    Fusioncharts3.5使用自带的导出功能,须要訪问官网 问题描写叙述:使用fusioncharts自带的exportchart方法来导出图片的时候.要訪问export.api3.fusionc ...

  6. [加入用户]解决useradd 用户后没有加入用户Home文件夹的情况,Linux改变文件或文件夹的訪问权限命令,linux改动用户password,usermod的ysuum安装包。飞

    usermod的yum安装包: shadow-utils 将nobody用户加入到nogroup 组: usermod -g nogroup nobody cat /etc/passwd|grep n ...

  7. Django訪问量和页面PV数统计

    http://blog.csdn.net/pipisorry/article/details/47396311 以下是在模板中做一个简单的页面PV数统计.model阅读量统计.用户訪问量统计的方法 简 ...

  8. GMGDC专訪戴亦斌:具体解释QAMAster全面測试服务6大功能

    GMGDC专訪戴亦斌:具体解释QAMAster全面測试服务6大功能 2014/10/10 · Testin · 业界资讯 在9月24-25日第三届全球移动游戏开发人员大会上,Testin云測COO戴亦 ...

  9. Nginx 因 Selinux 服务导致无法远程訪问

    文章来源:http://blog.csdn.net/johnnycode/article/details/41947581 2014-12-16日 昨天晚上处理好的网络訪问连接.早晨又訪问不到了. 现 ...

随机推荐

  1. 单机 &amp; 弱联网手游 防破解、金币改动 简单措施

    手游经常使用破解方法 对于一个弱联网或者单机游戏,能够从下面方面去破解: 1.找得到存档文件的,直接破解改动存档文件. 2.找不到存档文件,就在游戏执行时借助一些软件来改动数值,比方用各种改动器手游助 ...

  2. 一个简单的推断抢购时间是否到达的js函数

    原型函数,功能非常easy,找到时钟的id,计算数值.到达抢购时间时运行任务. function nwt() {var str=$('#deal_expiry_timer_e3cdcd2a').tex ...

  3. 王立平--TF卡

    最终知道TF卡是什么了... TF卡又称microSD,是一种极细小的快闪存储器卡,由SanDisk(闪迪)公司发明创立. 这样的卡主要于手机使用.但因它拥有体积极小的长处,随着不断提升的容量. 它慢 ...

  4. hdu2767 Proving Equivalences,有向图强联通,Kosaraju算法

    点击打开链接 有向图强联通,Kosaraju算法 缩点后分别入度和出度为0的点的个数 answer = max(a, b); scc_cnt = 1; answer = 0 #include<c ...

  5. 9. Palindrome Number[E]回文数

    题目 Determine whether an integer is a palindrome. An integer is a palindrome when it reads the same b ...

  6. BZOJ 4184 线段树+高斯消元

    思路: 线段树表示的是时间 每回最多log个段 区间覆盖 一直到叶子 的线性基 xor 一下 就是答案 一开始没有思路 看了这篇题解 豁然开朗 http://www.cnblogs.com/joyou ...

  7. WPF向系统发送消息 并传递结构体

    场景 :需要开发一个通讯组件 流程为:界面-开启接收服务-通过发送组件发送信息到 其他客户端和服务端 接受服务接收其他客户端发送的消息 需要传递给对应组件或者界面 因此会出现类库重复引用问题.因为采用 ...

  8. React组件化开发

    环境搭建: 1.安装node.js 2.安装cnpm  # npm install -g cnpm --registry=https://registry.npm.taobao.org 3.全局安装c ...

  9. gdb usage

    list stack of all threads thread apply all bt

  10. 一个helloword hibernate配置以及查询

    搭建一个Hibernate环境,开发步骤: 1. 下载源码 版本:hibernate-distribution-3.6.0.Final 2. 引入jar文件 hibernate3.jar核心  +   ...