性能优化

有很多人认为Hibernate天生效率比较低，确实，在普遍情况下，需要将执行转换为SQL语句的 Hibernate的效率低于直接JDBC存取，然而，在经过比较好的性能优化之后，Hibernate的性能还是让人相当满意的，特别是应用二级缓存之 后，甚至可以获得比较不使用缓存的JDBC更好的性能，下面介绍一些通常的Hibernate的优化策略： 1.抓取 优化 抓取是指Hibernate如何在关联关系之间进行导航的时候，Hibernate如何获取关联对象的策略，其主要定义了两个方面：如何抓取和何时抓取 1）如何抓取。 Hibernate3主要有两种种抓取方式，分别应用于对象关联实例(many-to-one、one-to-one)和对象关联集合(set、map等)，总共是四种变种 JOIN抓取： 通过在SELECT语句中使用OUTER JOIN来获得对象的关联实例或者关联集合） SELECT抓取： 另外发送一条SELECT语句来抓取当前对象的关联实体和集合 在我的开发经历中，此处对性能的优化是比较有限的，并不值得过多关注 例： A.应用于对象关联实例（默认是false） <many-to-one name=".." outer-join="true/false/auto" .../> B.应用于对象关联集合（默认是auto） <set name=".." fetch="join

作者：Robbin Fan 一。 inverse = ? inverse=false(default) 用于单向one-to-many关联 parent.getChildren().add(child) // insert child parent.getChildren().delete(child) // delete child inverse=true 用于双向one-to-many关联 child.setParent(parent); session.save(child) // insert child session.delete(child) 在分层结构的体系中 parentDao, childDao对于CRUD的封装导致往往直接通过session接口持久化对象，而很少通过关联对象可达性 二。 one-to-many关系 单向关系还是双向关系？ parent.getChildren().add(child)对集合的触及操作会导致lazy的集合初始化，在没有对集合配置二级缓存的情况下，应避免此类操作 select * from child where parent_id = xxx; 性能口诀： 1. 一般情况下避免使用单向关联，尽量使用双向关联 2. 使用双向关联，inverse=“true” 3. 在分层结构中通过DAO接口用session直接持久化对象

大多数的Nginx安装指南告诉你如下基础知识——通过apt-get安装，修改这里或那里的几行配置，好了，你已经有了一个Web服务器了。而且，在大多数情况下，一个常规安装的Nginx对你的网站来说已经能很好地工作了。然而，如果你真的想挤压出Nginx的性能，你必须更深入一些。在本指南中，我将解释Nginx的那些设置可以微调，以优化处理大量客户端时的性能。需要注意一点，这不是一个全面的微调指南。这是一个简单的预览——那些可以通过微调来提高性能设置的概述。你的情况可能不同。 基本的 (优化过的)配置 我们将修改的唯一文件是Nginx.conf，其中包含Nginx不同模块的所有设置。你应该能够在服务器的/etc/nginx目录中找到nginx.conf。首先，我们将谈论一些全局设置，然后按文件中的模块挨个来，谈一下哪些设置能够让你在大量客户端访问时拥有良好的性能，为什么它们会提高性能。本文的结尾有一个完整的配置文件。 高层的配置 Nginx.conf文件中，Nginx中有少数的几个高级配置在模块部分之上。 user www-data; pid /var/run/nginx.pid; worker_processes auto; worker_rlimit_nofile 100000; user和pid应该按默认设置 - 我们不会更改这些内容，因为更改与否没有什么不同。 worker

一、概述 在笔者的上一篇博客介绍了Spring Cloud ELK+kafka日志分析平台的搭建，http://xuyangyang.club/articles/2018/05/24/1527176074152.html，但是笔者在测试环境中发现，在logstash采用了grok插件去处理日志埋点和解析的时候发现了高资源占用，在阿里云8核16G的服务器部署后，测试环境大概每秒不超过几百条的日志的解析下竟然CPU占用高达95%左右，笔者分析了其中的原因，首先由于几个服务的日志格式相关配置还没有落地导致了日志格式无法解析和解析慢，其次grok天生解析正则表达式非常耗CPU。在笔者分析原因后立马进行了改造，将无法解析的格式不做任何处理直接输出到elasticsearch,另外多起了同一个group的基于kafka的logstash去消费日志，发现CPU占用虽然降低了，但任然在高达70%的CPU占用，这使得笔者不得不放弃原先的logstash插件grok，采用了ruby来解析日志和处理日志埋点，并且这次同时对docker启动shell脚本做相应修改，原先由于书写filter导致脚本杂乱无法查看改为启动传入配置文件的方式。 二、改造logstash 本次主要的问题主要发生在logstash的grok插件，在笔者查阅相关资料中发现，logstash提供了grok、mutate、ruby

本文简单介绍下后端服务开发中常用的一些性能优化策略。 1、代码 优化代码实现是第一位的，特别是一些不合理的复杂实现。如果结合需求能从代码实现的角度，使用更高效的算法或方案实现，进而解决问题，那是最简单有效的。 2、数据库 数据库的优化，总体上有3个方面： 1） SQL调优：除了掌握SQL基本的优化手段，使用慢日志定位到具体问题SQL，使用explain、profile等工具来逐步调优。 2） 连接池调优：选择高效适用的连接池，结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数。 3） 架构层面：包括读写分离、主从库负载均衡、水平和垂直分库分表等方面，一般需要的改动较大，需要从整体架构方面综合考虑。 3、缓存 分类 本地缓存（HashMap/ConcurrentHashMap、Ehcache、RocksDB、Guava Cache等）。 缓存服务（Redis/Tair/Memcache等）。 设计关键点 1、什么时候更新缓存？如何保障更新的可靠性和实时性？ 更新缓存的策略，需要具体问题具体分析。基本的更新策略有两个： 1） 接收变更的消息，准实时更新。 2） 给每一个缓存数据设置5分钟的过期时间，过期后从DB加载再回设到DB。这个策略是对第一个策略的有力补充，解决了手动变更DB不发消息

从输入 URL 到页面加载完成，完整的链路 http层面优化 DNS 解析: DNS 实现域名到IP的映射。通过域名访问站点，每次请求都要做DNS解析。目前每次DNS解析，通常在200ms以下。一般采用DNS Prefetch 一种DNS 预解析技术，当你浏览网页时，浏览器会在加载网页时对网页中的域名进行解析缓存，这样在你单击当前网页中的连接时就无需进行DNS的解析，减少用户等待时间，提高用户体验。 <link rel="dns-prefetch" href="www.baidu.com" /> 只有部分浏览器支持 TCP 连接： 采用http2.0，可以复用tcp通道，采用二进制格式而非文本格式，使用报头压缩，HTTP/2降低了开销，支持cache push 浏览器并发 基于端口跟线程切换开销，浏览器不可能无限的并发请求。chrome的并发为6，超过限制数目的请求就会被阻塞； 对于某些静态资源，图片等等，我们可以对其URL分散处理 ，不同的资源域名(部署在cdn上)。 http请求次数 减少http的请求次数，将多个请求合并成同一个，减少http的开销 webpack 充分利用webpack提供给我们的能力，利用DllPlugin与commonPlugins等插件对我们代码进行 优化，文件的分割与合并，公共代码的提取，长缓存等策略，webpack是个很好的东西，值得大家仔细研究

1、B+Tree 索引 索引是为了加速对表中数据行的检索而创建的一种分散存储的数据结构。 为什么要使用索引？ （1）索引可以极大的减少存储引擎需要扫描大数据量； （2）索引可以把随机IO转变为顺序IO； （3）索引在分组、排序等操作时，避免使用临时表 2、二叉树查找树（Binary Search Tree） 缺点： （1）数据的深度决定着IO次数，深度太深IO耗时大。 （2）每一个磁盘块（节点/页）保存的数据量太小， 没有很好的利用操作磁盘IO的数据交换特性，也没有利用好磁盘IO的预读写能力（空间局部性原理），从而带来频繁的IO操作。 3、多路平衡二叉树（B-Tree） 节点数量n，路数n+1 相比二叉平衡树： 减少了数的深度，磁盘块可以存储更多信息；但是还是没有很好的利用磁盘的IO特性。 4、加强版多路平衡二叉树（B+Tree） B+Tree 与B-Tree的区别 （1）B+Tree节点关键词搜索采用了左闭合区间 （2）B+Tree非叶子节点不保存数据相关信息，只保存关键字和子节点的引用 （3）B+Tree关键字对应的数据保存在叶子结点； （4）B+Tree叶子节点是顺序排列的，并且相邻节点具有顺序引用的关系。 为什么选择B+Tree？ （1）B+Tree是B-Tree的变种，拥有B-Tree的优势； （2）B+Tree树扫库、扫表能力更强； （3）B+Tree的磁盘读写能力更强

数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） 数据库对象的命名要能做到见名识意，并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀，备份表必须以bak_为前缀并以日期(时间戳)为后缀 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） 数据库基本设计规范 1. 所有表必须使用Innodb存储引擎 没有特殊要求（即Innodb无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用Innodb存储引擎（mysql5.5之前默认使用Myisam，5.6以后默认的为Innodb）。 Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 2. 数据库和表的字符集统一使用UTF8 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储emoji表情的需要，字符集需要采用utf8mb4字符集。 3. 所有表和字段都需要添加注释 使用comment从句添加表和列的备注，从一开始就进行数据字典的维护 4. 尽量控制单表数据量的大小，建议控制在500万以内。

在集群环境下，大家会碰到一直困扰的问题，即多个 APP 下如何用 quartz 协调处理自动化 JOB 。 大家想象一下，现在有 A ， B ， C3 台机器同时作为集群服务器对外统一提供 SERVICE ： A ， B ， C 3 台机器上各有一个 QUARTZ ，他们会按照即定的 SCHEDULE 自动执行各自的任务。 我们先不说实现什么功能，就说这样的架构其实有点像多线程。 那多线程里就会存在“资源竞争”的问题，即可能产生脏读，脏写，由于三台 APP SERVER 里都有 QUARTZ ，因此会存在重复处理 TASK 的现象。 一般外面的解决方案是只在一台 APP 上装 QUARTZ ，其它两台不装，这样集群就形同虚设了； 另一种解决方案是动代码，这样就要影响到原来已经写好的 QUARTZ JOB 的代码了，这对程序开发人员来说比较痛苦； 本人仔细看了一下 Spring 的结构和 QUARTZ 的文档，结合 Quartz 自身可以实例化进数据的特性找到了相关的解决方案。 本方案优点： 1. 每台作为集群点的 APP SERVER 上都可以布署 QUARTZ ； 2. QUARTZ 的 TASK （ 12 张表）实例化如数据库，基于数据库引擎及 High-Available 的策略（集群的一种策略）自动协调每个节点的 QUARTZ ，当任一一节点的 QUARTZ

性能优化系列阅读 Android性能优化 性能优化 - 消除卡顿 性能优化 - 内存优化 性能分析工具 - TraceView Android性能分析工具 消除卡顿 什么是卡顿及卡顿的衡量标准 产生卡顿的原因 通用优化流程 定位卡顿原因 什么是卡顿 卡顿是人的一种视觉感受，比如我们滑动界面时，如果滑动不流程我们就会有卡顿的感觉，这种感觉我们需要有一个量化指标，在编程时如果开发的程序超过了这个指标我们认为其是卡顿的。 FPS（帧率）：每秒显示帧数（Frames per Second）。表示图形处理器每秒钟能够更新的次数。高的帧率可以得到更流畅、更逼真的动画。一般来说12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。30fps就是可以接受的，但是无法顺畅表现绚丽的画面内容。提升至60fps则可以明显提升交互感和逼真感，但是一般来说超过75fps就不容易察觉到有明显的流畅度提升了，如果是VR设备需要高于75fps，才可能消除眩晕的感觉。 开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms≈1000/60的时间来处理所有的任务。Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps。 如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候就无法进行正常渲染