应用系统上线运行后,随着系统数据量的不断增加、访问量的不断上升,系统的响应速度一般会愈来愈慢,尤为平常峰值状况下常不能知足业务须要,甚至出现应用服务中断的现象,给企业形成巨大的品牌损失和经济损失。大量数据代表,每0.1秒的核心体验响应时间延长会致使1%的营收降低。企业应用系统上云,如何在云端利用云的优点进行性能优化,是一个值得深刻分析的重点问题。前端
一、性能优化价值数据库
性能是一个应用系统最重要的指标,除非没有选择,不然没有用户会忍受一个响应缓慢的应用系统或网站。大量数据代表,每0.1秒的核心体验响应时间延长会致使1%的营收降低。浏览器
应用系统上线运行后,随着系统数据量的不断增加、访问量的不断上升,系统的响应速度一般会愈来愈慢,尤为峰值状况下常不能知足业务须要,甚至出现应用服务中断,给企业形成巨大的品牌损失和经济损失,所以性能优化会显得相当重要。缓存
经过性能优化,能够用更少的硬件资源,支撑更大量的业务发展,从而达到节省硬件成本的目的;同时,能够在有限资源的状况下,提高系统的响应能力,为用户带来更好的使用体验,促进业务增加。性能优化
二、性能优化策略服务器
对于应用系统来讲,用户从浏览器发出请求到数据库完成事务操做,中间须要通过不少环节,若是系统响应慢,必须对请求通过的各个环节进行分析,排查可能出现性能瓶颈的地方,定位问题。网络
排查瓶颈的方法一般是检查请求处理的各个环节的日志,分析哪一个环节响应时间不合理、超出预期;而后检查监控数据,分析影响性能的主要因素是CPU,仍是内存、磁盘、网络等基础设施资源的问题,仍是架构设计的问题,或是慢SQL语句的问题等。session
定位出致使性能问题的具体缘由后,再作针对性的性能优化。架构
一、性能优化体系负载均衡
性能优化,简而言之,就是在不影响系统运行正确性的前提下,使之运行的更快,完成特定功能所需的时间更短。
性能优化的维度不少,综合来看能够从下面五个方面展开性能优化:资源层、架构层、应用层、数据库层、中间件层。性能优化体系以下图:
二、资源层优化
云资源层的优化包括云资源水平方向和垂直方向扩展,资源层面优化的依据可来自云监控的量化指标数据。
云监控可实时监控云资源动态指标,是全部云产品的监控管理总入口。能够经过云监控查看最全、最详细的监控数据。云监控可以实时对云服务器、云数据库、负载均衡等云产品进行监控,提取云产品关键指标,以监控图表形式展现。能够经过使用云监控全面地了解资源使用率、应用程序性能和云产品运行情况。
水平方向扩展是增长云服务器、云数据库等实例数量,垂直方向扩展是升级云服务器、云数据库等云资源的规格配置,好比CPU、内存、磁盘、带宽等参数配置,从解决资源瓶颈的角度来优化系统的访问性能。
三、架构层优化
系统的性能问题也有多是系统架构设计不合理形成的。好比在架构设计上,没有考虑作读写分离、数据库分库分表、动静分离、CDN加速、缓存加速、弹性伸缩等。
读写分离与数据库分库分表解决的是数据库访问性能问题,在云上实现读写分离很是方便,建立只读实例后,在应用程序中配置读写分离地址,就可使写请求自动转发到主实例,读请求自动转发到各个只读实例。
动静分离、CDN加速、缓存解决的是静态文件或热点数据快速读取问题,好比图片、视频、热门商品、库存等等,企业上云时须要尽量使用一些成熟的云原生解决方案,从架构设计层面去优化访问性能的问题。
弹性伸缩解决的是应用服务器自动扩展的问题,经过提早配置伸缩规则与策略,在业务需求增加时自动增长云服务器实例以保证计算能力,避免访问延时和资源超负荷运行。
四、应用层优化
应用层优化的关键是首先快速诊断出应用的问题瓶颈。
互联网业务的高速发展带来了日益增加的流量压力,业务逻辑也日趋复杂,传统的单机应用已经没法知足需求。愈来愈多的网站或系统逐渐采用了分布式部署架构。
同时,随着 Spring Cloud/Dubbo 等基础开发框架不断成熟,愈来愈多的企业开始对应用架构按照业务模块进行垂直拆分,造成了更适合团队协同开发、快速迭代的微服务架构。
分布式的微服务架构在开发效率上具有先进性,但给传统的监控、运维、诊断技术带来了巨大挑战。主要挑战包括:
定位问题难:
微服务分布式架构一个业务请求一般要通过多个服务/节点后返回结果,一旦请求出现错误,每每要在多台机器上反复翻看日志才能初步定位问题,对简单问题的排查也经常涉及多个团队。
发现瓶颈难:
当用户反馈系统出现卡顿现象,很难快速发现瓶颈在哪里:是用户终端到服务端的网络问题,是服务端负载太高致使响应变慢,仍是数据库压力过大?即便定位到了致使卡顿的环节,也很难快速定位到代码层面的根本缘由。
架构梳理难:
在业务逻辑变得逐渐复杂之后,很难从代码层面去梳理某个应用依赖了哪些下游服务(数据库、HTTP API、缓存),以及被哪些外部调用所依赖。业务逻辑的梳理、架构的治理和容量的规划也变得更加困难。
一般,须要使用性能压测工具(好比PTS)、应用实时监控服务(好比ARMS)等工具,基于前端、应用、业务自定义等维度进行链路追踪,实现完整的调用链路还原、调用请求量统计、链路拓扑和应用依赖分析等。链路追踪可以帮助快速分析和诊断分布式应用架构下的性能瓶颈,提升微服务时代下的开发诊断效率。
定位瓶颈问题后,展开针对性的优化工做,好比优化慢SQL语句、优化调用报错程序代码、优化调用异常API等。一般应用优化后可结合性能压测工具对系统性能、容量水位进行再次压力测试,经过压测结果进一步分析系统瓶颈,对应用不断迭代优化。
五、数据库优化
影响数据库系统性能主要有以下几个因素:系统的硬件配置、数据库文件的物理分布、数据库实例的参数、数据库的物理设计、应用的SQL语句。
数据库性能优化,首先须要进行下述数据内容采集:
系统软硬件环境:包括服务器的操做系统设置、硬件配置、网络配置、软件环境、启动选项、进程信息、性能信息、磁盘使用状况等。
硬件运行状况:包括CPU、内存、磁盘、网络的运行数据。
数据库实例的配置: 实例配置参数。
数据库配置:包括恢复模式、自动收缩、空间增加等信息。
数据库磁盘使用:包括数据库大小、表大小、记录数、索引大小、占用空间等。
索引及碎片状况:包括表上的索引、索引的碎片状况、索引的维护计划等。
SQL语句执行状况:包括SQL 语句执行时间、启动时间、所在数据库、语句内容、死锁、阻塞等状况。
应用程序运行情况:包括系统高峰时段、晚间的数据库维护任务、用户报告比较慢的业务、系统运行特色。
数据库性能主要优化项见下图:
六、中间件优化
在信息系统中,很多性能问题是由不起眼的应用中间件形成的。应用中间件之因此诞生,是为了帮助应用程序的编码人员处理与业务逻辑没有太大关系而又必须处理的常常性事物,好比处理应用程序和数据库之间的关系,设置开启多少个session来处理客户请求,session的超时时间等等。
然而在享受便利的同时,应用中间件也会成为系统性能问题的缔造者,开发人员和测试人员每每忽视了中间件自己对性能的影响,这种影响包括交易吞吐量的制约、响应时间的影响、交易成功率的影响等等。
中间件优化的目标是把耗费在中间件的时间缩短(提高用户体验),提升整个应用服务器的吞吐量。中间件优化,调什么参数,必定要了解其含义、原理、调整后的收益和风险是什么,最好是N个参数能在脑子里缠绕为一个总体。
高优先:调整JDBC链接池大小、线程池、JVM虚拟机的heap size。
中优先:会话数、垃圾回收GC策略。
另外还有高速缓存、数据源语句缓存大小。
不当的配置也会致使中间件处于假死状态。好比某类资源(session或jdbc)被应用彻底占满了,而且短时间不释放,这样新的请求就无法执行,形成了假死的状况。这类状况,要作好超时放弃的参数配置。
性能优化是一个复杂的系统工程,首先须要定位性能瓶颈,而后从云资源、系统架构、应用程序、数据库、中间件等方面进行综合分析和优化;性能优化的最终目的是为了改善用户的体验,离开这个目的而追求技术上的所谓高性能是舍本逐末,没有任何意义。
随着系统数据量、访问用户量的不断增长,以及系统功能的不断迭代,系统须要持续进行性能优化,性能优化是一场持久战,只有这样才能让用户拥有更好的访问体验,从而支撑业务增加。
做者:龚华兵