性能优化

一、MySQL 的主要适用场景 1、Web网站系统 2、日志记录系统 3、数据仓库系统 4、嵌入式系统 二、 MySQL 架构图： 三、 MySQL 存储引擎概述 1 ） MyISAM 存储引擎 MyISAM存储引擎的表在数据库中，每一个表都被存放为三个以表名命名的物理文件。首先肯定会有任何存储引擎都不可缺少的存放表结构定义信息的.frm文件，另外还有.MYD和.MYI文件，分别存放了表的数据（.MYD）和索引数据（.MYI）。每个表都有且仅有这样三个文件做为MyISAM存储类型的表的存储，也就是说不管这个表有多少个索引，都是存放在同一个.MYI文件中。 MyISAM支持以下三种类型的索引： 1、B-Tree索引 B-Tree索引，顾名思义，就是所有的索引节点都按照balancetree的数据结构来存储，所有的索引数据节点都在叶节点。 2、R-Tree索引 R-Tree索引的存储方式和b-tree索引有一些区别，主要设计用于为存储空间和多维数据的字段做索引，所以目前的MySQL版本来说，也仅支持geometry类型的字段作索引。 3、Full-text索引 Full-text索引就是我们长说的全文索引，他的存储结构也是b-tree。主要是为了解决在我们需要用like查询的低效问题。 2 ） Innodb 存储引擎 1、支持事务安装 2、数据多版本读取 3、锁定机制的改进 4

Traceview是分析Android性能不可或缺的利器。目前一般是用DDMS或者ADT里面的traceview工具来查看的。哪怕是 AndroidStudio官网 也是如此推荐。 一个偶然的机会，发现AndroidStudio本身可以查看Traceview文件，而且更直观。 它分成三部分：顶部工具栏，中间的“Flamechart”显示执行过程及调用堆栈，底部的表格显示该线程中各个函数的执行时间与调用次数。 顶部工具栏 Thread: 选择你要查看哪个线程的执行情况，默认是主线程的。 x-axis: Wall Clock Time就是Real Time，该函数开始执行和结束执行之间的时间差。Thread Time就是CPU Time，真实消耗CPU的时间。 Color by inclusive time: 在中间的Flamechart中，默认是根据exclusive time着色的。如果根据inclusive time着色，函数执行时间越长，颜色越深，所以顶层的函数颜色是最深的。 Zoom fit：缩放用的，用鼠标滚轮也能实现。 Find：查找某个函数。 中间的Flamechart 横向表示时间线上函数的执行情况，长度越长，表示函数的执行时间越长。纵向表示调用堆栈。 以上图为例。第一行只有一个main()函数，它是函数调用堆栈的root，我们的trace一直在main(

Traceview是分析Android性能不可或缺的利器。目前一般是用DDMS或者ADT里面的traceview工具来查看的。哪怕是 AndroidStudio官网 也是如此推荐。 一个偶然的机会，发现AndroidStudio本身可以查看Traceview文件，而且更直观。 它分成三部分：顶部工具栏，中间的“Flamechart”显示执行过程及调用堆栈，底部的表格显示该线程中各个函数的执行时间与调用次数。 顶部工具栏 Thread: 选择你要查看哪个线程的执行情况，默认是主线程的。 x-axis: Wall Clock Time就是Real Time，该函数开始执行和结束执行之间的时间差。Thread Time就是CPU Time，真实消耗CPU的时间。 Color by inclusive time: 在中间的Flamechart中，默认是根据exclusive time着色的。如果根据inclusive time着色，函数执行时间越长，颜色越深，所以顶层的函数颜色是最深的。 Zoom fit：缩放用的，用鼠标滚轮也能实现。 Find：查找某个函数。 中间的Flamechart 横向表示时间线上函数的执行情况，长度越长，表示函数的执行时间越长。纵向表示调用堆栈。 以上图为例。第一行只有一个main()函数，它是函数调用堆栈的root，我们的trace一直在main(

Traceview是分析Android性能不可或缺的利器。目前一般是用DDMS或者ADT里面的traceview工具来查看的。哪怕是 AndroidStudio官网 也是如此推荐。 一个偶然的机会，发现AndroidStudio本身可以查看Traceview文件，而且更直观。 它分成三部分：顶部工具栏，中间的“Flamechart”显示执行过程及调用堆栈，底部的表格显示该线程中各个函数的执行时间与调用次数。 顶部工具栏 Thread: 选择你要查看哪个线程的执行情况，默认是主线程的。 x-axis: Wall Clock Time就是Real Time，该函数开始执行和结束执行之间的时间差。Thread Time就是CPU Time，真实消耗CPU的时间。 Color by inclusive time: 在中间的Flamechart中，默认是根据exclusive time着色的。如果根据inclusive time着色，函数执行时间越长，颜色越深，所以顶层的函数颜色是最深的。 Zoom fit：缩放用的，用鼠标滚轮也能实现。 Find：查找某个函数。 中间的Flamechart 横向表示时间线上函数的执行情况，长度越长，表示函数的执行时间越长。纵向表示调用堆栈。 以上图为例。第一行只有一个main()函数，它是函数调用堆栈的root，我们的trace一直在main(

性能优化实现方式(单纯考虑代码层面): 1.减小代码体积 2.提高运行效率 如何做: 1.尽量指定类.方法的final修饰符 带有final修饰的类是不可派生的,该类所有的方法都是final的,java编译器会寻找机会内联所有的final方法,有助于提高运行效率. 2.尽量复用对象 对象的创建和维护都会花费java虚拟机的精力,特别是String对象的使用,出现的字符串连接要使用StringBuilder/StringBuffer来替代+号,因此,生成过多的对象将会给虚拟机带来不必要的负担; 3.及时关闭流 使用I/O流对数据进行操作是会对系统造成非常大的负担,用完要及时close; 4.不要在循环语句中进行复杂的处理,以及一些异常处理,应该把这些提取到循环外层 例如try...catch...应该放在外层 5.循环内不要进行对象的频繁创建,除非不得已的情况下; 6.尽量使用HashMap、ArrayList、StringBuilder，除非对线程安全有需求，不推荐使用HashTable、Vector、StringBuffer后三者因为做了同步机制对性能有较高的要求； 7.清除不需要的会话； 8.将常量声明为static final，并且用大写来命名 9.不创建一些不使用的对象，不导入一些不使用的包 10.程序运行过程中避免使用反射

减少HTTP请求次数和请求大小 尽量合并CSS和JS文件（把需要引入的CSS合并为一个，JS也是合并为一个），原理是在减少HTTP请求次数，尽可能的把合并后的代码进行压缩，减小HTTP请求资源的大小 A:webpack这种自动化构建工具，可以帮我们实现代码的合并和压缩（工程化开发） B:在移动开发(或者追求高性能的PC端开发[例如百度首页])，如果CSS或者JS不是需要很多，我们可以选择把css和js编程内嵌式（也就是代码直接写在HTML中） 采用图片的“懒加载”（延迟加载） 目的是为了减少页面“第一次加载”过程中HTTP的请求次数，让页面打开速度变快 步骤：开始加载页面的时候，所有的真实图片都不去发送HTTP请求加载，而是给一张占位的背景图，当页面加载完，并且图片在可视区域内我们再去做图片加载 利用浏览器和服务器端的缓存技术(304缓存)，把一些不经常更新的静态资源文件做缓存处理（例如：JS、CSS、静态图片等都可以做缓存） 原理是为了减少HTTP请求大小，让获取速度更快 CSS雪碧图技术(css sprite / css 图片精灵) 把所有相对较小资源图片汇总到一张大图上，后期我们只需要把大图加载下来，用背景定位的方式展示对应的小图即可 .bg{ background:url('xxx.png'); } .box1{ background-position:xx xx; }

从前的日色变得慢，车，马，邮件都慢······ 巴特，现在前端是庞大的，针对方方面面的资源都有不同的方式。 站在用户角度，我们希望页面加载得更快、页面对用户的操作响应得更及时，能够给用户提供更为友好的体验。 站在服务商的角度，我们希望前端优化能够减少页面请求数、或者减小请求所占带宽，能够节省可观的资源。 1. 减少请求资源或者次数 尽量合并压缩 css 和 js 文件 ：为了减少http请求次数以及减少请求资源的大小 采用图片懒加载（延迟加载） ：减少页面第一次加载过程中http的请求次数 能用css做的效果，不要用js做，能用原生js做的，不要轻易去使用第三方插件 ：避免引入第三方大量的库 减少对cookie的使用 ：减少本地cookie存储内容的大小 2. 代码优化 在js中尽量减少闭包的使用 ：原因：使用闭包后，闭包所在的上下文不会被释放 减少DOM操作，主要是减少DOM的重绘与回流（重排） 在js中避免嵌套循环和"死循环" ：一旦遇到死循环，浏览器就会直接卡掉 把css放在body上，把js放在body下面 尽量将一个动画元素单独设置为一个图层 ：避免重绘或者回流的大小 js封装过程中，尽量做到低耦合高内聚 ：减少页面的冗余代码 3. 其他 图片压缩 使用内容分发cdn加速 静态资源缓存 来源： https://www.cnblogs.com/hefeifei/p

前几天买了阿里云主机后，配置了基本的web环境，apache性能没有做优化；导致今天在公布 opms 系统的时候，访问太慢，本身的云主机配置是低配，自己玩的。具体环境配置请看《 再谈centOS7.2 LAMP源码安装及注意要点 》。 现把apache性能优化上做一下配置： 一. deflate和expires 我在安装apache的时候，已经自动静态编译了deflate和expires模块，所以可能在配置文件里直接添加相关指令： #deflate gzip启用 可以在主机配置文件httpd.conf或虚拟主机vhost下添加下面指令 DeflateCompressionLevel 9 SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/html text/plain text/xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE image/gif image/png image/jpe image/swf image/jpeg image/bmp #expires 缓存模块，这里配置了1天的时间

在MySQL的大数据量测试时，发现MySQL单表数据约超过4000万行时出现性能拐点。查询性能逐步下降，但下降还算缓慢。 继续添加数据，又出现一次明显的性能拐点。性能可谓是陡降，磁盘IO显著上升，开始使用交换分区。 此时MySQL的数据文件和内存一般大！这不太可能吧，当数据文件和内存一般大时就会出现性能下降？那以前服务器内存小的时候，MySQL岂不是不用干了？ 部分内存是被操作系统吃了。手动干掉操作系统的文件缓存` echo 3 > /proc/sys/vm/drop_caches `，以为这样会让MySQL可用内存更多。但结果并未见好转，反而是缓存刚被清是性能更差了。 经过一轮搜索，原来是需要告诉操作系统尽可能的不要使用磁盘作交换：` echo 0 > /proc/sys/vm/swappiness `（更新到系统配置，在/etc/sysctl.conf上添加 vm.swappiness = 0 ）。 此值默认为60，即(60%)。当然，设为0并非禁用，而是最大限度地使用物理内存。 OK，加此设置之后，MySQL在更多数据量时也未出现swap交换的现象、性能随数据量的增加平缓下降 来源： oschina 链接： https://my.oschina.net/u/187935/blog/173932

1、集群规划优化实践 1.1 基于目标数据量规划集群 在业务初期，经常被问到的问题，要几个节点的集群，内存、CPU要多大，要不要SSD？ 最主要的考虑点是：你的 目标存储数据量 是多大？可以针对目标数据量反推节点多少。 1.2 要留出容量Buffer 注意：Elasticsearch有三个警戒水位线，磁盘使用率达到85%、90%、95%。 不同警戒水位线会有不同的应急处理策略。 这点，磁盘容量选型中要规划在内。控制在 85%之下 是合理的。 当然，也可以通过配置做调整。 1.3 ES集群各节点尽量不要和其他业务功能复用一台机器。 除非内存非常大。 举例：普通服务器，安装了ES+Mysql+redis，业务数据量大了之后，势必会出现内存不足等问题。 1.4 磁盘尽量选择SSD Elasticsearch官方文档肯定 推荐SSD ，考虑到成本的原因。需要结合业务场景，如果业务对写入、检索速率有较高的速率要求，建议使用SSD磁盘。 阿里的业务场景，SSD磁盘比机械硬盘的速率提升了5倍。但要因业务场景而异。 1.5 内存配置要合理 官方建议：堆内存的大小是官方建议是：Min（32GB，机器内存大小/2）。 Medcl和wood大叔都有明确说过，不必要设置32/31GB那么大，建议： 热数据设置：26GB，冷数据：31GB 。 总体内存大小没有具体要求，但肯定是内容越大，检索性能越好。