性能优化

默认情况下，innodb的参数设置的非常小，在生产环境中远远不够用 比如最重要的两个参数 innodb_buffer_pool_size 默认是8M innodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解) innodb_buffer_pool_size： 这是InnoDB最重要的设置，对InnoDB性能有决定性的影响。默认的设置只有8M，所以默认的数据库设置下面InnoDB性能很差。在只有 InnoDB存储引擎的数据库服务器上面，可以设置60-80%的内存。更精确一点，在内存容量允许的情况下面设置比InnoDB tablespaces大10%的内存大小。 innodb_data_file_path：指定表数据和索引存储的空间，可以是一个或者 多个文件。最后一个数据文件必须是自动扩充的，也只有最后一个文件允许自动扩充。这样，当空间用完后，自动扩充数据文件就会自动增长（以8MB为单位）以 容纳额外的数据。例如： innodb_data_file_path=/disk1 /ibdata1:900M;/disk2/ibdata2:50M:autoextend两个数据文件放在不同的磁盘上。数据首先放在ibdata1 中，当达到900M以后，数据就放在ibdata2中。一旦达到50MB，ibdata2将以8MB为单位自动增长

https://www.cnblogs.com/chenwolong/p/7531955.html 1、合理使用AsNoTracking 　　若对查询的数据不需要做任何修改，则可采用AsNoTracking；但若在查询过程中做了select映射之类的操作，则不需要添加。 2、合理使用AsNonUnicode 　　var a = context.Student.Where(A => A.StuName=="赵刚").ToList(); 　　var b = context.Student.Where(A => A.StuName == DbFunctions.AsNonUnicode("赵刚")).ToList(); 　　 　　不加AsNonUnicode SQL中会有N，查询过程中需要把数据库默认格式转化为Unicode格式来查询，因此性能被拉低。如果不使用N前缀，字符串将转换为数据库的默认代码格式，可能导致不识别的字符。 3、判断是否存在使用Any 4、延迟加载 　　为导航属性添加virtual属性，才会延迟加载数据；但延迟加载会产生严重的性能问题，如foreach 　　使用Include显示连接查询将懒加载变成显示加载(需要手动导入System.Data.Entity，不然Include只能传入字符串) 　　　　var scores = db.Scores.Take(100)

简单叙述 这个过程可以大致分为两个部分：网络通信和页面渲染。 一、网络通信 互联网内各网络设备间的通信都遵循TCP/IP协议，利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。分层由高到低分别为：应用层、传输层、网络层、数据链路层。发送端从应用层往下走，接收端从数据链路层网上走。如图所示： 1. 在浏览器中输入url 用户输入url，例如http:// www.baidu.com 。其中http为协议， www.baidu.com 为网络地址，及指出需要的资源在那台计算机上。一般网络地址可以为域名或IP地址，此处为域名。使用域名是为了方便记忆，但是为了让计算机理解这个地址还需要把它解析为IP地址。 2.应用层DNS解析域名 客户端先检查本地是否有对应的IP地址，若找到则返回响应的IP地址。若没找到则请求上级DNS服务器，直至找到或到根节点。 3.应用层客户端发送HTTP请求 HTTP请求包括请求报头和请求主体两个部分，其中请求报头包含了至关重要的信息，包括请求的方法（GET / POST）、目标url、遵循的协议（http / https / ftp…），返回的信息是否需要缓存，以及客户端是否发送cookie等。 4.传输层TCP传输报文 位于传输层的TCP协议为传输报文提供可靠的字节流服务。它为了方便传输，将大块的数据分割成以报文段为单位的数据包进行管理

MySQL 优化 表关联查询时务必遵循 小表驱动大表 原则； 使用查询语句 where 条件时，不允许出现 函数，否则索引会失效； 使用单表查询时，相同字段尽量不要用 OR，因为可能导致索引失效，比如：SELECT * FROM table WHERE name = '手机' OR name = '电脑'，可以使用 UNION 替代； LIKE 语句不允许使用 % 开头，否则索引会失效； 组合索引一定要遵循 从左到右 原则，否则索引会失效；比如：SELECT * FROM table WHERE name = '张三' AND age = 18，那么该组合索引必须是 name,age 形式； 索引不宜过多，根据实际情况决定，尽量不要超过 10 个； 每张表都必须有 主键，达到加快查询效率的目的； 分表，可根据业务字段尾数中的个位或十位或百位（以此类推）做表名达到分表的目的； 分库，可根据业务字段尾数中的个位或十位或百位（以此类推）做库名达到分库的目的； 表分区，类似于硬盘分区，可以将某个时间段的数据放在分区里，加快查询速度，可以配合 分表 + 表分区 结合使用； MySQL EXPLAIN 语句 EXPLAIN 显示了 MySQL 如何使用索引来处理 SELECT 语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 使用方法，在 SELECT 语句前加上 EXPLAIN

magento的网站实在是太慢了，想了好多办法，参考了好多资料，做了很多测试，总结一下大概的步骤如下 （继续） ： １、压缩js,css代码，如果有必要把所有的css,js分别综合到一个文件中，并压缩，缓存 ２、清除magento模板中不必要的注释，为所使用到的图片瘦身 ３、 优化magento代码，这个步骤工作量大，但可能是效果显著的步骤，不过前提是你非常熟悉magento，彻底删除不用的模块，关闭没用的block， 清除无效，无用的xml（解析xml非常昂贵的），在一个页面中尽量不要大量调用magento的image resize功能，非常消耗内存，除非你自己优化代码。 ４、mysql配置优化，充分发挥你的硬件资源，下面的数值要根据你的配置调整 key_buffer_size = 512M max_allowed_packet = 64M table_cache = 512 sort_buffer_size = 4M net_buffer_length = 8K read_buffer_size = 4M read_rnd_buffer_size = 2M myisam_sort_buffer_size = 64M tmp_table_size = 128M query_cache_size = 96M query_cache_type = 1 thread_cache

第一章 打开网站慢现状分析 在公司访问部署在 IDC 机房的 VIP 网站时会感觉很慢。是什么原因造成的？为了缩短页面的响应时间，改进我们的用户体验，我们需要知道用户的时间花在等待什么东西上。 可以跟踪一下我们的登录页面，如下图所示 从上图我们可以分析知道， HTML 文档只占了总响应时间的 20% ，其它 80% 响应时间用来下载 JS 、 CSS 、图片等组件。所以 WEB 前端有很大的优化空间，我们将从 WEB 的前端优化、后端优化两方面综合考虑给出 WEB 的性能优化方案。 第二章 WEB 前台的优化规则 一、 尽量减少 HTTP 请求 有几种常见的方法能切实减少 HTTP 请求： 1 、 合并脚本跟样式文件，如可以把多个 CSS 文件合成一个，把多个 JS 文件合成一个。 2 、 CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位 , 把多个图片合成一个图片。 二、 使用浏览器缓存 在用户浏览网站的不同页面时，很多内容是重复的，比如相同的 JS 、 CSS 、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件，将大大降低页面产生的流量，从而降低页面载入时间。 根据服务器端的响应 header ，一个文件对浏览器而言，有几级不同的缓存状态。 1 、服务器端告诉浏览器不要缓存此文件，每次都到服务器上更新文件。 2

代码优化，一个很重要的课题。可能有些人觉得没用，一些细小的地方有什么好修改的，改与不改对于代码的运行效率有什么影响呢？这个问题我是这么考虑的，就像大海里面的鲸鱼一样，它吃一条小虾米有用吗？没用，但是，吃的小虾米一多之后，鲸鱼就被喂饱了。 代码优化也是一样，如果项目着眼于尽快无BUG上线，那么此时可以抓大放小，代码的细节可以不精打细磨；但是如果有足够的时间开发、维护代码，这时候就必须考虑每个可以优化的细节了，一个一个细小的优化点累积起来，对于代码的运行效率绝对是有提升的。 代码优化的目标是 减小代码的体积 提高代码运行的效率 代码优化细节 1、尽量指定类、方法的final修饰符 带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String，整个类都是final的。为类指定final修饰符可以让类不可以被继承，为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final，则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法，内联对于提升Java运行效率作用重大，具体参见Java运行期优化。此举能够使性能平均提高50%。 2、尽量重用对象 特别是String对象的使用，出现字符串连接时应该使用StringBuilder/StringBuffer代替

代码优化，一个很重要的课题。可能有些人觉得没用，一些细小的地方有什么好修改的，改与不改对于代码的运行效率有什么影响呢？这个问题我是这么考虑的，就像大海里面的鲸鱼一样，它吃一条小虾米有用吗？没用，但是，吃的小虾米一多之后，鲸鱼就被喂饱了。 代码优化也是一样，如果项目着眼于尽快无BUG上线，那么此时可以抓大放小，代码的细节可以不精打细磨；但是如果有足够的时间开发、维护代码，这时候就必须考虑每个可以优化的细节了，一个一个细小的优化点累积起来，对于代码的运行效率绝对是有提升的。 代码优化的目标是 减小代码的体积 提高代码运行的效率 代码优化细节 1、尽量指定类、方法的final修饰符 带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String，整个类都是final的。为类指定final修饰符可以让类不可以被继承，为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final，则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法，内联对于提升Java运行效率作用重大，具体参见Java运行期优化。此举能够使性能平均提高50%。 2、尽量重用对象 特别是String对象的使用，出现字符串连接时应该使用StringBuilder/StringBuffer代替

如果项目着眼于尽快无BUG上线，那么此时可以抓大放小，代码的细节可以不精打细磨；但是如果有足够的时间开发、维护代码，这时候就必须考虑每个可以优化的细节了，一个一个细小的优化点累积起来，对于代码的运行效率绝对是有提升的。 作者：程序猿久一 前言 代码优化 ，一个很重要的课题。可能有些人觉得没用，一些细小的地方有什么好修改的，改与不改对于代码的运行效率有什么影响呢？这个问题我是这么考虑的，就像大海里面的鲸鱼一样，它吃一条小虾米有用吗？没用，但是，吃的小虾米一多之后，鲸鱼就被喂饱了。 代码优化也是一样，如果项目着眼于尽快无BUG上线，那么此时可以抓大放小，代码的细节可以不精打细磨；但是如果有足够的时间开发、维护代码，这时候就必须考虑每个可以优化的细节了，一个一个细小的优化点累积起来，对于代码的运行效率绝对是有提升的。 代码优化的目标是 1、减小代码的体积 2、提高代码运行的效率 代码优化细节 1、 尽量指定类、方法的final修饰符 带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String，整个类都是final的。为类指定final修饰符可以让类不可以被继承，为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final，则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法

话说前头： 上次写了一篇webpack的学习心得，webpack能做到提升前端的性能，其模块打包最终生成一个或少量的文件能够减少对服务端的请求。除此之外，本次的图片懒加载（当然不仅限于图片，还可以有视频，flash等）也是一种优化前端性能的方式。使用懒加载可以想要看图片时才加载图片，而不是一次性加载所有的图片，从而在一定程度从减少服务端的请求。 懒加载介绍： 通俗介绍：懒加载怎么个懒法，就是你不想看就不给你看，我也懒得加载出来，懒得去请求。通俗的说就是你不要就不给你，怎么地。举个栗子，比如在进入某个页面的时候，它会有许多的图片，有些图片可能在下面，当我们点进页面但没有滑动下去或没看完整个页面，那么下面的图片就会"没用"，加载了也白加载，而且还降低了网页的加载速度。因此用懒加载能当滚动到可视区域时才加载当前的图片。 原理：图片的加载是由src的值引起，当对src赋值时浏览器就会请求图片资源，基于这个，可以利用html5属性data-XXX来保存图片的路径，当我们需要加载图片的时候才将data-xxx的值赋予src，酱就能实现图片的按需加载，也就是懒加载了。 优点：提高前端性能，图片在需要的时候才加载，减轻服务的负担，提高页面的加载速度，能够减少带宽。 懒加载实现方式: 1.使用jquery-lazyload.js，jQuery的插件用于懒加载使用，需要依赖jQuery。 jquery