性能优化的改进方法:性能问题从发现到优化一般思路

技术系统的开发经历了这样的过程:业务初期以业务功能与目标的实现为主,因为数据与访问量较小,性能问题没有被列为第一考虑因素。

但在业务发展的过程中,伴随着数据的增加以及访问量的增加甚至剧增,导致比如首页5秒才显示出来等等,这样糟糕的体验将导致用户的损失,这时性能是一个不得不面对的问题。为了解决这些问题,需要进行优化设计来提高服务器的性能。本文介绍了Hadoop平台下的负载均衡算法在云计算数据中心中的应用,并通过实际案例加以验证。我们将技术系统划分为前期,中期和后期:

前期:以实现业务需求为主,表现不侧重

中期:出现性能问题的注解,对业务的开展造成影响

晚期:技术迭代性能和操作必须兼顾

怎样找到性能问题并最终解决性能问题是本论文论述的重点。

我们可在4个层面上引入何为性能:

两个层面界定了性能:

速度比较慢

压力很大

2个维度说明性能:

定性——直观感受

定量:指标分析

页面的打开时间较长、列表加载速度较慢、接口访问造成超时异常等明显的问题都可归结为这类问题。

某公司现有职工7200人,每天8:00-8:30上班打卡,每打卡5秒钟系统实施时长,则RT, QPS,并发量各为多少?

RT代表响应时间。提问中已包括回答:

RT=5 s

QPS代表每秒钟的访问量。假定行为的平均分配是:

QPS = 7200 / (30 * 60) = 4.

并发量代表系统一次处理的请求数量:

根据以上例子得出公式:

QPS(Queries Per Second):每秒查询量TPS(Transactions Per Second):每秒事务数

应该指出的是,这个事务并非是指数据库中的事务,它是由下列3个阶段组成的:

收到要求

办理业务

回到结果

QPS = N * TPS (N>=1)

N=1,说明界面上存在事务:。

public class OrderService { public Order queryOrderById(String orderId) { return orderMapper.selectById(orderId); }}

N大于1,说明界面中存在多种交易:

class Public OrderService{updateOrder Public void(Order order){

public class FastTestService { public void test01() { long start = System.currentTimeMillis(); biz1(); biz2(); long costTime = System.currentTimeMillis() – start; System.out.println(“costTime=” costTime); } private void biz1() { try { System.out.println(“biz1”); Thread.sleep(500L); } catch (Exception ex) { log.error(“error”, ex); } } private void biz2() { try { System.out.println(“biz2”); Thread.sleep(1000L); } catch (Exception ex) { log.error(“error”, ex); } }}

import org.springframework.util.StopWatch;import org.springframework.util.StopWatch.TaskInfo;public class FastTestService { public void test02() { StopWatch sw = new StopWatch(“testWatch”); sw.start(“biz1”); biz1(); sw.stop(); sw.start(“biz2”); biz2(); sw.stop();

输出结果:

costTime=1526taskInfo={“taskName”:”biz1″,”timeMillis”:510,”timeNanos”:510811200,”timeSeconds”:0.5108112}taskInfo={“taskName”:”biz2″,”timeMillis”:1015,”timeNanos”:1015439700,”timeSeconds”:1.0154397}StopWatch ‘testWatch’: running time = 1526250900 ns

Arthas作为阿里开源Java的诊断工具:

Arthas作为线上监控与诊断产品,从全局视角来实时观察应用load,内存, gc,线程等状态信息,并且可以无需修改应用代码就可以诊断出业务中存在的问题,主要表现为观察方法调用出入参,异常情况,监控方法执行所需时间,类加载信息等等,极大地促进了线上问题检查的效率

Arthastrace指令监测链路中的每一个节点所花费的时间:

https:

我们用一个例子来说明先写和操作代码:

package java.front.optimize;public class FastTestService { public static void main(String[] args) { FastTestService service = new FastTestService(); while (true) { service.test03(); } } public void test03() { biz1(); biz2(); } private void biz1() { try { System.out.println(“biz1”); Thread.sleep(500L); } catch (Exception ex) { log.error(“error”, ex); } } private void biz2() { try { System.out.println(“biz2”); Thread.sleep(1000L); } catch (Exception ex) { log.error(“error”, ex); } }}

步骤1进入arthas控制台:

$ java -jar arthas-boot.jar[INFO] arthas-boot version: 3.6.2[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER* [1]: 14121 [2]: 20226 java.front.optimize.FastTestService.

步骤2,录入监控进程号,返回车辆:;

步骤3 trace命令对对应的方法进行监测:1。

trace java.front.optimize.FastTestService test03

步骤4看链路耗时:1。

`—[1518.7362ms] java.front.optimize.FastTestService:test03() —[33.66% 511.2817ms ] java.front.optimize.FastTestService:biz1() #54 `—[66.32% 1007.2962ms ] java.front.optimize.FastTestService:biz2() #55.

系统压力大时还会呈现速度缓慢的特点,但这一缓慢并不只是要在几秒钟后才能够打开页面,它是页面始终在加载状态下最后出现白屏的现象。

服务器的常用压力指标有:

内存方面

CPUs

磁盘

网络

服务端的开发更易造成内存, CPU等方面的问题,因此本文着重讨论。

先写一段导致CPU飙高的代码,然后运行:

public class FastTestService { public static void main(String[] args) { FastTestService service = new FastTestService(); while (true) { service.test(); } } public void test() { biz(); } private void biz() { System.out.println(“biz”); }}

dashboard看了一下目前系统的实时面板发现线程的ID=1 CPU占用很大(此ID不能对应jstack nativeID):1。

$ dashboardID NAME GROUP PRIORI STATE %CPU DELTA TIME TIME INTERRU DAEMON1 main main 5 RUNNA 96.06 4.812 2:41.2 false false.

thread在最繁忙的之前看N条线程:

$ thread -n 1″main” Id=1 deltaTime=203ms time=1714000ms RUNNABLE at app//java.front.optimize.FastTestService.biz(FastTestService.java:83) at app//java.front.optimize.FastTestService.test(FastTestService.java:61) at app//java.front.optimize.FastTestService.main(FastTestService.java:17)

$free-htotal used free shared buff.cache available.Mem:10G5.5 G3.1 G28M 1.4 G4.4GSwap:2.0 G435M 1.6Gtotal服务器的总内存used已经利用了内存free,没有任何应用程序利用了空闲内存shared共享的物理内存cacheIO装置读缓存(Page Cache)buffIO装置写缓存(Buffer Cache)availableMem:1 G5 G3.5 G2.6.8 G4.6.6.7.7.8.8.9.9.10 G4.8.10 G3.8.8 Mem:1.6.8.6.9.8.8 G2.8。

Arthasmemory指令查看JVM的内存信息:

https:

请看JVM内存信息,这是一个正式例子

$ memoryMemory used total max usageheap 32M 256M 4096M 0.79%g1_eden_space 11M 68M -1 16.18%g1_old_gen 17M 184M 4096M 0.43%g1_survivor_space 4M 4M -1 100.00%nonheap 35M 39M -1 89.55%codeheap_’non-nmethods’ 1M 2M 5M 20.53%metaspace 26M 27M -1 96.88%codeheap_’profiled_nmethods’ 4M 4M 117M 3.57%compressed_class_space 2M 3M 1024M 0.29%codeheap_’non-profiled_nmethods’ 685K 2496K 120032K 0.57%mapped 0K 0K – 0.00%direct 48M 48M – 100.00%

看JAVA程序的进程号

jps-l

看实时内存占用情况

jhsdb jmap

输出快照文件

jmap -dump:format=b,file=/home/tmp/my-dump.hprof 20196

内存溢出会自动输出堆快照的

-XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath==/home/tmp/my-dump.hprof

Arthasheapdump指令支持导出堆快照:

https:

dump到指定的文档

heapdump /home/tmp/my-dump.hprof

dump live的对象到指定的文档

heapdump

dump到临时文件

heapdump

jstat能看到垃圾回收的状况,并观察节目是经常GC还是GC用时太久:

jstat -gcutil<interval(ms)></interval(ms)>

每秒钟看一次垃圾回收

$ jstat -gcutil 20196 1000 S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT 0.00 0.00 57.69 0.00 – – 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 57.69 0.00 – – 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 57.69 0.00 – – 0 0.000 0 0.000 0 0.000 0.000.

各项参数描述如下。

S0:Survivor 0区域在新生代的被利用空间的占比S1:Survivor0区域在新生代被利用的空间的占比E:SurvivoO:老年代被利用的空间占比P:永久带被利用的空间占比YGC:应用开始到现在出现YoungGC的数量YGCT:应用开始到今天出现Young GC的数量FGC:应用结束到现在出现FullGC的数量FGCT:垃圾回收的总量

进行系统压测可主动揭露系统的问题和评价系统的容量。简单而常见的参数有:

常用的工具:JMeter

阶梯发压:线程数分别为10, 20, 30增加到瓶颈处

时间:维持一分钟, Ramp-Up=0

TPS:Throughput

响应时间:集中在95Line

该监控系统能更友好地显示相关的指标,若企业有一定的技术实力能够自研,不然可选择采用行业内通用的方案。

减少要求

空间换取时间

任务并行化

任务异步化

代理层

前端层

服务层

缓存层

在数据层

一提到性能优化就不难联想到比如加索引,加缓存之类的计划,这种想法或许没错,但这种考虑可能导致疏漏,因为它只适用于缓存层与数据层之间。

若能把无效的流量拒于最外一层,则该系统就能得到较好的防护。如果能够有效地阻止用户的恶意行为,那也是系统更有价值的一种表现。本文提出了四种防止无效流攻击的解决方案;数据加密、协议分析和防火墙技术。有4种办法可适用于各个级别,不妨举例说明:

设定秒杀场景下的前置验证码

能否将多次RPC换算成单次批量RPC

导入缓存

介绍了多级缓存

增加新的索引

若多次调用不依赖则利用Future进行并行化

若不需要等待返回的结果则可异步执行

首先这篇文章探讨的是系统的早,中,后三个阶段怎样看待系统的性能,其次探讨的是什么叫系统的性能,再次探讨的是如果找到系统的性能,最后探讨的是怎样优化系统的性能,期望这篇文章能起到抛砖引玉的作用。

原文链接:http://www.sfdkj.com/24547.html

© 版权声明
THE END
喜欢就支持一下吧
点赞8 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片