项目上线之后，以为可以放松一段时间，结果又被老板叫回去连夜加班，优化性能，提高系统在线并发数。满脑子一头雾水，不知道从何下手？今天小编就带大家一起看看如何进行系统系统优化。
一、应用服务性能优化
优化应用服务框架，对代码进行重构并优化SQL
对项目中关键的接口，访问页面等进行性能压测，抓取数据库AWR性能分析报告；通过分析报告，找出消耗时间比较长的SQL，并对其进行优化；如果数据库服务购买的是云服务器，对应云服务器厂商都有服务器后台，可以查看慢SQL的运行情况。
AWR分析报告AWR分析报告在应用框升级改造的同时，也应充分考虑该架构的安全性，包括B/S形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑系统自身体系架构内部的安全，以及与外系统接口的安全。针对某些特殊应用，还需考虑恢复、抗攻击等安全机制。
业务安全：主要是指业务系统的自身业务流程和数据的安全，其中包括：身份一致性、业务数据篡改和关键流程绕过等；应用安全：主要指应用系统非功能性需求的信息安全，主要包括：SQL注入、XSS攻击、框架注入等安全防护；中间件安全：主要是指采用的第三方开源或非开源的组件服务，比如，tomcat服务、消息中间件、mysql、structs2.0组件等；主机安全：主机是指系统所运行的服务器的安全防护，包括：服务器的弱口令、口令的强度策略、操作系统特权、恶意代码或病毒的检测等；数据安全：主要指HTTP业务数据、数据库数据、资源文件等信息的安全防护，包括信息的脱敏、信息的加密、文件的下载限制等；网络安全：主要是指系统所在网络安全监控、流量预警、防火墙规则设置、源IP地址请求限制等防护，能够抵御端口扫描、强力攻击、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP碎片攻击和网络蠕虫攻击。增加数据一二级缓存，减轻数据库压力
增加数据一、二级缓存，减轻数据库压力，包括应用缓存，网络缓存；比如使用Redis缓存集群服务；
使用redis数据缓存，相信很多开发人员比较熟悉，很多的开源项目也都会集成redis服务，那么使用redis到底有什么好处呢？
读写速度快，这也是他最大的优势了，redis把数据存储在内存中，不需要直接请求数据库；支持的数据类型资源丰富，可以支持支持HashMap、string，list等等；支持事务，操作都是原子性操作。即对数据的更改要么全部执行，要么全部不执行；可以自定义设置缓存的生命周期，设置过期时间，过期后将会自动删除，不影响更新数据的缓存。调整应用服务部署架构，增加服务的负载能力
若应用服务是单应用节点部署方式，可以扩展服务部署节点数和物理服务器数，防止单点故障；除此之外，也可把应用服务中高并发的读写服务分离，一个服务只负责读，另外一个服务只负责写。通过代理服务，对多个物理服务进行负载均衡，设置策略，应用服务会优先访问优先级比较高的服务节点。
服务部署示意图
升级系统框架，提高系统可拓展性
升级系统框架，提高系统可拓展性，使系统可以满足对接更多的中间件和第三方支持等。比如使用RabbitMQ消息队列主要有以下优势：
异步解耦：消息队列AMQP可用于单体应用被拆解为微服务后不同微服务间的通信。应用解耦的好处是不同应用的迭代不再相互依赖，而异步通信的好处是数据不再需要被立即处理。异步解耦能有效缩短数据链路长度，提高数据处理效率；削峰填谷：大型活动带来较高流量脉冲时，没有做好相应保护容易导致系统超负荷甚至崩溃，限制太过则会导致请求大量失败而影响用户体验。消息队列AMQP版能做到削峰填。其超高性能的消息处理能力可以承接流量脉冲而不被击垮，在确保系统可用性同时，因快速有效的请求响应而提升用户的体验。其海量消息堆积能力确保下游业务在安全水位内平滑稳定的运行，避免超高流量的冲击;分布式缓存同步：大量并发访问数据库会导致页面响应时间长。通过消息队列AMQP版构建分布式缓存，能实时通知数据变化，有效降低页面响应时间，满足对变更的大量访问需求；
网页资源性能优化
对于普通的网页访问，80%的响应时间消耗在前端，动态请求时间占比较少，优化难度大。那么我们可以从哪些方面来进行优化呢？小编罗列了以下几点：
使用更少的HTTP请求：每个HTTP请求都需要经历以下过程:阻挡-建立连接-发送请求-等待响应-接收数据；请求的HTTP请求越少，建立连接的过程也就越少；资源压缩合并：对文件大小比较大的图片、JS、CSS等资源进行压缩或者合并；添加过期头：浏览器每次请求资源前检查通过max-age、expires检查本地资源是否可用，如果可用将不发起请求到服务器，以此节约服务器资源，加快网页加载速度；使用云上文件存储服务：文件资源可以上传到阿里云OSS或者华为云OBS等文件存储服务，达到可以对资源服务进行CDN加速，提高资源的访问速度二、数据库性能优化
冗余表字段、减少表关联操作
我们在初始数据库表结构的建模设计时，可能诸多世界无法考虑周全，导致部分字段定义过大，表结构定义的字段与实际使用占用大小相差较大。或者部分表的冗余字段过多，甚至有一部分的冗余字段始终为空。针对这样的问题，小编建议应当实际情况定义各字段大小，并缩小冗余字段大小。选择合理的大小可以大大减小磁盘空间及磁盘I/O读写开销，减小内存占用，减小CPU的占用率。
小编遇到的另外一个问题就是部分表的设计拆分过细，主表保存的字段信息很少，很多业务在查询时都需要同时很多子表，有一部分信息完全可以放置在主表中，减少关联表的查询。
除此之外，小编建议大家在开发项目中建议根据实际业务需求整理一份数据字典，便于系统的运营维护。
合理使用索引
大家有没有遇到以下一些问题呢？
部分表无主键和索引，部分表数据量较大，但是表结构既没有主键也没索引部分表ID已经有主键，但又创建了唯一索引部分表的联合索引过多空字段导致索引不生效小编给出以下一些建议：
根据实际生产的增删改查语句进行分析，创建索引；同一个表的同一字段已设置成主键，无须再创建唯一索引；联合索引需要根据SQL语句所需进行创建，无须太多，容易造成解析计划混乱；建议部分语句中增加强制索引数据库读写分离
根据业务场景区分读写操作，访问读写数据库，数据库读写分离有一个前提就是，数据库有多个备份，有主库，有从库。读写分离就是基于主从复制架构，一个主库，有多个从库，主库主要负责写，写完后主库会自动把数据同步给从库，从库执行查询的一些操作
数据库分库分区
分库又叫垂直切分，就是把原本存储于一个库的表拆分存储到多个库上，通常是将表按照功能模块、关系密切程度划分出来，部署到不同的库上。如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的首选就是分库。分库的优点是：实现简单，库与库之间界限分明，便于维护，缺点是不利于频繁跨库操作，单表数据量大的问题解决不了；
顾名思义，分区就是将一个表分解成多个区块进行操作和保存，从而降低每次操作的数据，提高性能。而对应用来说是透明的，从逻辑上看是只有一个表，但在物理上这个表可能是由多个物理分区组成的，每个分区都是一个独立的对象，可以进行独立处理。
调整数据连接池配置
系统需要满足不同的并发数，项目中需要配置数据库连接池的大小，可根据并发来设置连接池的各项参数。以MYSQL为例，可以从以下几个参数进行优化设置：
连接池支持的最大连接数maxActive，并发的时候该值就可以设置为；连接池中最多可空闲连接数maxIdle，该值表示即使没有数据库连接时依然可以保持空闲的连接数，而不被清除；连接池中最小空闲连接数minIdle，当连接数少于此值时，连接池会创建连接来补充到该值的数量；初始化连接数目initialSize；最大请求等待时间maxWait，连接池中连接用完时,新的请求等待时间。以上介绍的就是性能优化的一些知识，希望给大家在以后的项目优化中有一些帮助，如果还有其他比较好的建议，也可以给小编留言哦。