性能优化

参考: http://www.techrepublic.com/blog/linux-and-open-source/tuning-nfs-for-better-performance/ 1.服务器端查看是否有瓶颈 # nfsstat -rc Client rpc stats: calls retrans authrefrsh 3409166 330 0 retrans过高,说明NFS线程数不足,一般安装缺省设置为8个. centos 下/etc/rc.d/init.d/nfs # Number of servers to be started by default [ -z "$RPCNFSDCOUNT" ] && RPCNFSDCOUNT=8 修改后需要重启NFS 2.客户端mount优化 缺省为8KB,,增加到32KB block size rsize=32768,wsize=32768,intr,noatime noatime 这个参数来禁止记录最近一次访问时间戳 linux在每次文件被访问的时候会记录访问时间,查看方法 ls –lu 来源： https://www.cnblogs.com/jjkv3/p/3869599.html

1. 优化简介 　　MySQL性能优化包括：查询优化、数据库结构优化、MySQL服务器优化等。 2. 查询优化 2.1 分析查询语句 　　MySQL提供EXPLAIN和DESCRIBE，用来分析查询语句。 　　EXPLAIN语句的基本语法： EXPLAIN [EXTENDED] SELECT select_options 　　其中，EXTENDED用于EXPLAIN产生附加信息，select_options是SELECT语句的查询选项，包括FROM WHERE子句等。 mysql> EXPLAIN SELECT * FROM product; +----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+---------+------------+------+---------------+------+---------+------+-----

mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 测试实验 1. 直接用limit start, count分页语句， 也是我程序中用的方法： select * from product limit start, count 当起始页较小时，查询没有性能问题，我们分别看下从10， 100， 1000， 10000开始分页的执行时间（每页取20条）， 如下： select * from product limit 10, 20 0.016秒 select * from product limit 100, 20 0.016秒 select * from product limit 1000, 20 0.047秒 select * from product limit 10000, 20 0.094秒 我们已经看出随着起始记录的增加，时间也随着增大， 这说明分页语句limit跟起始页码是有很大关系的，那么我们把起始记录改为40w看下（也就是记录的一般左右） select * from product limit 400000, 20 3.229秒 再看我们取最后一页记录的时间 select * from product limit 866613, 20 37.44秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

原文出处： http://www.cnblogs.com/wy123/p/5933734.html 先看常用的一种表结构设计方式： 那么可能会遇到一种典型的查询方式，主子表关联，查询子表中的某些（或者全部）Key点对应的Value，横向显示（也即以行的方式显示） 这种查询方式很明显的一个却显示多次对字表查询（暂时抛开索引） 相比这种查询方式很多人都遇到过，如果子表是配置信息之类的小表的话，问题不大，如果字表数据量较大，可能就会有影响了。 这个查询目的是将”纵表”存储的结果“横向”显示，相当于横列转换的感觉了。 可以将子表的结果一次性将纵表的结果转换成横标，再跟主表连接， 然后得到一个最终一样的查询结果（格式），就能够减少子表的查询次数 这里将子表的结果“一次性将纵表的结果转换成横标”，是典型的行列转换操作 首先先看一下这里所说的一次转换成横标的这一步骤，需要借助pivot，一步一步来 然后看跟主表join之后，两种查询方式的整体查询结果 那么看一下后一种查询方式也即通过行业转换之后做join的执行计划，可以看到只对字表进行了一次查找（这里是index seek，但是暂抛开索引） 观察一下两条SQL的IO信息，可以发现，前者的Scan count是5，逻辑读是65，后者的Scan count是1，逻辑读是13，65=13*5。可见后者是一次性将表中的几个Key值读取出来的

本博客是阅读<java time and space performance tips>这本小书后整理的读书笔记性质博客，增加了几个测试代码，代码可以在此下载： java时空间性能优化测试代码 ，文件StopWatch是一个秒表计时工具类，它的代码在文末。 1. 时间优化 1.1 标准代码优化 a. 将循环不变量的计算移出循环 我写了一个测试例子如下： import util.StopWatch; /** * 循环优化： * 除了本例中将循环不变量移出循环外，还有将忙循环放在外层 * @author jxqlovejava * */ public class LoopOptimization { public int size() { try { Thread.sleep(200); // 模拟耗时操作 } catch(InterruptedException ie) { } return 10; } public void slowLoop() { StopWatch sw = new StopWatch("slowLoop"); sw.start(); for(int i = 0; i < size(); i++); sw.end(); sw.printEclapseDetail(); } public void optimizeLoop() { StopWatch sw =

一、mysql数据类型优化原则 (1) 能够使用最小数据类型存储时，尽量使用最小数据类型存储（前提是要评估字段值的真实数据存储范围） 　　　　 eg：create table aaa(id1 int(10) zerofill,id2 int (10));　　(1) int(n) 中的 n代表宽度，表示没有设定宽度的时候，用0填充，需要配合zerofill来使用。 eg: insert into aaa values(12,11); (2) varchar 存储变长的字符串，即根据存入的值的长度来动态变化 存储空间： 　　非空：65533字节 　　可空：65532字节 优点：节省空间，操作简单 缺点：在update的时候，如果数据的长度变化了，就会去申请空间，从而有额外的工作，对性能有影响。 应用场景：1.字符串最大长度比平均真实值大的比较多，这个时候就会用。 　　 2.更新频率比较低的字符串字段 (3) char 存储定长的字符串 存储长度：create table t (char(10) not null) 　　非空：存储255字节 　　可空：存储254字节 应用场景： 　　1.适合存储比较短的字符串 　　2.存储固定的长度或者存储长度比较接近的字符串 　　　　例如：手机号、MD5加密的密码、邮编等 　　3.经常变更的数据（不需要释放空间重新申请，即不会产生内存碎片） 　　4

本篇网文，引自网络： http://www.ibm.com/developerworks/cn/linux/l-cn-python-optim/ 选择了脚本语言就要忍受其速度，这句话在某种程度上说明了 python 作为脚本的一个不足之处，那就是执行效率和性能不够理想，特别是在 performance 较差的机器上，因此有必要进行一定的代码优化来提高程序的执行效率。如何进行 Python 性能优化，是本文探讨的主要问题。本文会涉及常见的代码优化方法，性能优化工具的使用以及如何诊断代码的性能瓶颈等内容，希望可以给 Python 开发人员一定的参考。 Python 代码优化常见技巧 代码优化能够让程序运行更快，它是在不改变程序运行结果的情况下使得程序的运行效率更高，根据 80/20 原则，实现程序的重构、优化、扩展以及文档相关的事情通常需要消耗 80% 的工作量。优化通常包含两方面的内容：减小代码的体积，提高代码的运行效率。 改进算法，选择合适的数据结构 一个良好的算法能够对性能起到关键作用，因此性能改进的首要点是对算法的改进。在算法的时间复杂度排序上依次是： O(1) -> O(lg n) -> O(n lg n) -> O(n^2) -> O(n^3) -> O(n^k) -> O(k^n) -> O(n!) 因此如果能够在时间复杂度上对算法进行一定的改进，对性能的提高不言而喻

前端性能优化： 一、尽可能减少前端http请求。 　　1、合并优化脚本文件和css文件。 　　2、同种类型的背景图片尽量放在一起，用css控制显示。 二、使用浏览器缓存。 　　如果能强制浏览器缓存在本地，将会降低页面产生的流量。 三、页面压缩。 　　压缩gzip,html,js,css,图片等。 四、html代码结构优化* 　　1、正确布置页面脚本。 　　　　1>、尽可能使用外部脚本和配置文件。 　　　　2>、js文件放到文档末尾。 　　　　3>、脚本放在文档前面，文档内容可能会被阻塞。放在末尾会出现就是未加载完用户就会触发行为。 　　2、减少dom结构的层级。 　　3、减少cookie的大小。 　　4、尽量用div取代table。 　　　　table会影响页面展示速度，应为只有table完全加载才会展示在页面上。 五、组件分为多个域，提高页面组件并行下载能力。 六、图片，脚本，数据预加载。 移动端的性能优化： 属于前端性能优化范畴，但移动性能优化在PC端同样适用。 　　1、使用css动画。应为css加载速度优于js。 　　2、适当使用touch事件代替click事件。 　　3、合理使用css3样式，减少使用css3渐变阴影等效果。 　　4、用transform开启硬件加速。 　　5、不滥用float,web字体。 ------------------华丽的分割线---------

在网上看了一些关于前端性能优化的相关方法，分享给大家~ 1.代码约束，比如驼峰式写法，注释方法，代码简洁性。 2.比如雪碧图，和http协议优化。 2.使用CDN（内容分发网络）通俗的说就是通过分布式服务器来提高网站性能（比如服务器在北京有一台服务器，在同等条件的情况下，北京的人民访问速度肯定香港人民要快的多）。 3.使用一些代码压缩（例如Gzip压缩，在服务器端压缩传输到浏览器解压，速度会有很高的提示，原始文件79Kb压缩后25kb，还有代码的空格，注释等处理都有性能提升）。 4.将Css放在页面最上面（原因是在低端浏览器 例如IE上面，加载顺序是默认从上往下加载的，如果网速不好的情况下放在下面就会出现纯HTML，这样不好。放在上面可以避免页面空白和闪烁。）视情况而定， 复用性比较强的放在外部引用更好 ）。 5.将JS放在页面底部（原因是当DOM元素没有加载完毕的时候，js不会对浏览器性能造成困扰。比如说Js控制了某个id，但是当加载到js的时候DOM元素还没有加载出来，就会报错，或者有for循环的时候容易造成浏览器卡死。视情况而定， 复用性比较强的放在外部引用更好 ）。 6.避免在Css中使用Expressions(意思是Css的值等于Js表达式计算的结果，当页面缩放，滚动，以及鼠标移动都会重新计算，对性能占用太多。特别是IE6和IE7)。 7.减少DNS查询

CSS性能优化 CSS选择器优化 如果可以直接选中元素，不需要加一些多余的修饰 /*不要使用类选择器和ID选择器修饰元素标签，这样多此一举，还会降低效率。*/ div#slider.slider { } 一般来说，class用于样式，id用于js，因为id定义的样式不利于复用 保证不会误选的情况下，尽量保持简单 避免冲突可以在命名时区分好 /*保持简单，不要使用嵌套过多过于复杂的选择器*/ /*浏览器从右向左解析CSS*/ /*.slider .slider-item-container .slider-item .slider-link .slider-img { width: 100%; }*/ .alex-slider-img { /*嵌套少*/ /*权重低 便于使用的时候覆盖*/ width: 100%; } 尽量少用通配符选择器，可以单独写出来，罗列出来 /*避免通配选择器*/ * { } ul, li, dl, dt, dd, p { padding: 0; margin: 0; } 不必要的样式和没有用到的样式直接删除即可 /*移除无匹配的样式*/ .slider { /*width: 100%;*/ } 高级选择器少用（类似正则的），还有属性选择器，性能并不高 但是必须的情况下可少量使用 /*避免类正则的属性选择器*/ [class*="slider