从系统架构本身来说，一般系统优化主要从三个方面入手，数据持久层、业务逻辑层和前端展示层。
限制系统性能主要有两个方面，一是数据库自身的性能，二是对数据库操作的方式，数据库自身相对简单，一般通过优化配置、采用高可用方案、搭建集群或者使用性能更好的数据库来提升性能；数据库操作主要是数据库读写操作，可以通过SQL优化的方式来提升读写速度，或者通过缓存的方式减低并发、提升性能。
代码层面常见的问题有内存泄露、资源泄露、线程死锁等，主要通过优化相关的代码和算法来提升性能，使用数据库连接、文件读取时及时关闭IO流，注意线程死锁，以及静态对象的使用等，降低JVM的内存消耗，使用高性能的框架、算法，从代码层面提升系统性能。
前端主要考虑从代码和资源角度进行优化，如优化、压缩JS代码，优化页面渲染效果，减低渲染频率，使用异步加载数据，采用缓存减少服务器的访问以及静态资源的访问。
评论0
加载中...
对于业务系统的性能优化，我原来系统的谈过分析和诊断的思路，今天再谈下业务系统性能优化里面我们常见的一些思考和分析系统性能问题的方法。
有时候大家可能觉得奇怪，为何我们系统再上线前都做了性能测试，为何上线后还是会出现系统性能问题。那么我们可以考虑下实际上我们上线前性能测试可能存在的一些无法真实模拟生产环境的地方，具体为：
1. 硬件能否完全模拟真实环境？最好的性能测试往往是直接在搭建完成的生产环境进行。
2. 数据量能否模拟实际场景？真实场景往往是多个业务表都已经存在大数据量的积累而非空表。
3. 并发能否模拟真实场景？一个是并发需要录制复合业务场景，一个是并发量大时候需要多台压测机。
而实际上我们在做性能测试的时候以上几个点都很难真正做到，因此要想完全模拟出生产真实环境是相当困难的，这也导致了很多性能问题是在真正上线后才发现。
第二个点也是我们经常谈的比较多的点，就是我们的业务系统在进行架构设计的时候，特别是面对非功能性需求，我们都会谈到系统本身的数据库，中间件都采用了集群技术，能够做到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题？
实际上我们看到对于数据库往往很难真正做到无限的弹性水平扩展，即使对于Oracle RAC集群往往也是最多扩展到单点的2到3倍性能。对于应用集群往往可以做到弹性水平扩展，当前技术也比较成熟。
当中间件能够做到完全弹性扩展的时候，实际上仍然可能存在性能问题，即随着我们系统的运行和业务数据量的不断积累增值。实际上你可以看到往往非并发状态下的单用户访问本身就很慢，而不是说并发上来后满。因此也是我们常说的要给点，即：
单点访问性能正常的时候可以扩展集群来应对大并发状态下的同时访问
单点访问本身性能就有问题的时候，要优先优化单节点访问性能
业务系统性能诊断的分类
对于业务系统性能诊断，如果从静态角度我们可以考虑从以下三个方面进行分类
那么一个业务系统应用功能出现问题了，我们当然也可以从动态层面来看实际一个应用请求从调用开始究竟经过了哪些代码和硬件基础设施，通过分段方法来定位和查询问题。
比如我们常见的就是一个查询功能如果出现问题了，首先就是找到这个查询功能对应的SQL语句在后台查询是否很慢，如果这个SQL本身就慢，那么就要优化优化SQL语句。如果SQL本身快但是查询慢，那就要看下是否是前端性能问题或者集群问题等。
对于业务系统性能问题，我们经常想到的就是要扩展数据库的硬件性能，比如扩展CPU和内存，扩展集群，但是实际上可以看到很多应用的性能问题并不是硬件性能导致的，而是由于软件代码性能引起的。对于软件代码常见的性能问题我在以往的博客文章里面也谈过到，比较典型的包括了。
1. 循环中初始化大的结构对象，数据库连接等
2. 资源不释放导致的内存泄露等
3. 没有基于场景需求来适度通过缓存等方式提升性能
4. 长周期事务处理耗费资源
5. 处理某一个业务场景或问题的时候，没有选择最优的数据结构或算法
以上都是常见的一些软件代码性能问题点，而这些往往需要通过我们进行Code Review或代码评审的方式才能够发现出来。因此如果要做全面的性能优化，对于软件代码的性能问题排查是必须的。
对于性能问题的发现一般有两条路径，一个就是通过我们IT资源的监控，APM的性能监控和预警来提前发现性能问题，一个是通过业务用户在使用过程中的反馈来发现性能问题。
而随着DevOps和自动化运维的思路推进，我们更加希望是通过APM等工具主动监控来发现性能问题，对于APM工具最大的好处就是可以进行服务链间和全链路的性能分析，方便我们发现性能问题究竟发生在哪里。比如我们提交一个表单很慢，通过APM分析我们很容易发现究竟是调用哪个业务服务慢，或者是处理哪个SQL语句慢。这样可以极大的提升我们性能问题分析诊断的效率。
评论0
加载中...
面试官：给我讲讲你的项目是怎么性能优化的？
https://mp.weixin.qq.com/s/t_tCxI9b4rmJOye1BiB1oQ
评论0
加载中...
很多时候我们为了节省开支，会在ECS自建Mysql数据库或者采用第三方一键环境来运行WP数据库，虽然有时会出现访问延迟等问题，但总体而言还是挺合适的一种方式。只不过并不是每个朋友都具备处理突发问题的能力，一旦在一个相对重要的时刻出现了宕机等难题，抓狂可能是很多人能做也是唯一能做的事情。因此，从成本和运营效率上考虑，推荐大家借助RDS来运行站点数据库。
评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
