性能优化

// 用n的阶乘来演示 保存上一步计算的数据，进行下一次计算时候先判断是否有上次执行过的，如果有直接获取保存的值然后再进行下一步计算 // n! n*(n-1)*....*2*1 // 0! = 1 // n! = n*(n-1)! // 实现记忆前 var count = 0　　// 执行的次数 function factorial(n) { count ++ if(n == 0 || n==1) { return 1 } return n * factorial(n-1) } for(var i=1; i<=5; i++) { console.log(factorial(i)) } // 实现记忆后 var count = 0　　// 执行的次数 var cache = []　　//执行过的数据保存起来 ---比如从5开始计算，再计算6的阶乘时候只执行6x5！ 而5的阶乘则直接从保存的数据中获取 function factorial(n) { count++ if (cache[n]) { // 如果有缓存(cache的值)直接获取缓存内的值 return cache[n] } else {　　//没有则进行计算 if (n == 0 || n == 1) { cache[0] = 1 cache[1] = 1 return 1 } else { cache[n] = n *

ORACLE会自我监控，但并不一定会自我调优。对于数据库的性能，传统的理解是：一般来说内存的命中率越高就代表“性能好”，所以早其的优化是围绕着命中率来展开的，这也意味着优化的方法常常是通过提升硬件能力来提高命中率，可是我们还有更好的方法。 数据库相应时间模型（响应时间=服务时间+等待时间）更加接近终端用户的体验，也将数据库性能调优提升到了一个新的高度。DBA在进行性能跟踪诊断的时候，时刻应该把响应时间牢记心中，而响应时间慢，往往是由于等待某些资源可用的时间过长导致。关注响应时间比关注命中率更重要的原因在于，时间对于终端用户的感受是最直接的，一位开发向你抱怨一个任务执行缓慢，或者网站的一位客户投诉网页打开慢，他们都是对响应时间的不满，他们根本不关心是因为某种命中率低或者其他技术原因。对数据库事务处理过程中的等待进行技术（次数+时间），并且通过各种v$师徒进行崭新啊的功能接口叫做OWI. OWI是量化的，能指导DBA们有目的性的进行优化。OWI记录了所有等待时间的等待次数、等待时间、平均等待时间。在没有OWI的情况下遭遇系统缓慢，可能会通过种种猜测来进行试错。活跃会话数过多？系统可能会有锁等待？硬解析过多？命中率太低？但是若果是通过OWI分析，那么就可以理直气壮的得出结果。所以熟练使用OWI后，能够摆脱以往对性能问题的“猜测性”，将复杂的性能优化问题解释为任何人都容易理解的量化的值。

SQL性能优化 一、SQL的执行顺序 顺序：FROM——ON——JOIN——WHERE——GROUP BY——SUM、COUNT——HAVING——SELECT——DISTINCT——ORDER BY——LIMIT 与写SQL的顺序不同，SQL的执行顺序并不是从select开始，而是从from开始 1、FROM：先去获取from里面的表，拿到对应的数据，生成虚拟表1。 2、ON：对虚拟表1应用ON筛选，符合条件的数据生成虚拟表2。 3、JOIN：根据JOIN的类型去执行相对应的操作，获取对应的数据，生成虚拟表3。 4、WHERE：对虚拟表3的数据进行条件过滤，符合记录的数据生成虚拟表4。 5、GROUP BY：根据group by中的列，对虚拟表4进行数据分组操作，生成虚拟表5。 6、CUBE|ROLLUP（聚合函数使用）：主要是使用相关的聚合函数，生成虚拟表6。 7、HAVING：对虚拟表6的数据过滤，生成虚拟表7，这个过滤是在where中无法完成的，同时count（expr）返回不为NULL的行数，而count（1）和count（*）是会返回包括NULL在内的行数。 8、SELECT：选择指定的列，生成虚拟表8。 9、DISTINCT：数据去重，生成虚拟表9。 10、ORDER BY：对虚拟表9中的数据进行指定列的排序，生成虚拟表10。 11、LIMIT：取出指定行的记录

一、WEB服务器 1.1 概述： 1.2 区别： 1.2.1 Apache 1.2.2 Tomcat 1.2.3 Jboss 二、浏览器端，关于浏览器端优化 2.1 压缩源码和图片 2.2 选择合适的图片格式 2.3 合并静态资源 2.4 开启服务器端的Gzip压缩 2.5 使用CDN 2.6 延长静态资源缓存时间 2.7 把CSS放在页面头部，把JavaScript放在页面底部 三、服务端优化 3.1 HTML静态化 3.2 图片服务器分离 3.3 数据库集群、库表散列 3.4 缓存 3.5 镜像 3.6 负载均衡 3.6.1 硬件四层交换 3.6.2 软件四层交换 一、WEB服务器 1.1 概述： Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。 Apache与Tomcat都是Apache开源组织开发的用于处理HTTP服务的项目，两者都是免费的，都可以做为独立的Web服务器运行。 Apache是Web服务器而Tomcat是Java应用服务器。 1.2 区别： 1.2.1 Apache 是C语言实现的，专门用来提供HTTP服务。 特性：简单、速度快、性能稳定、可配置（代理） 1、主要用于解析静态文本，并发性能高，侧重于HTTP服务； 2、支持静态页（HTML）

说说自己踩到的坑 某个项目中遍历一个 List 集合，该集合比较大，大概有几万条数据，我使用了 for 循环遍历： public void readList(List<String> list) { if (list != null) { for (int i=0; i<list.size(); i++) { // do something... } } } 做测试的时候发现程序执行特别慢，找了好久找到了原因，就是上面的方法中的问题：由于方法参数中给定的 List 集合可能是 ArrayList ，也可能是 LinkedList 。当遍历 LinkedList 的时候，如果集合很大，会出现程序执行效率慢的问题。 将上面的方法重构： public void readList(List<String> list) { if (list != null) { Itarator<String> iter = list.iterator(): while (iter.hasNext()) { // do something... } } } 重构后程序执行确实快了不少，这源于 ArrayList 和 LinkedList 内部实现的区别， LinkedList 随机读取要比 ArrayList 慢，关于 ArrayList 和 LinkedList 区别不多说了，其他网站有很多异同点的比较。

优化php性能的五个实用技巧： 以下是五个优化技巧，熟练掌握后对于开发还是很有帮助的。 1. 对字符串使用单引号 PHP 引擎允许使用单引号和双引号来封装字符串变量，但是这个是有很大的差别的！使用双引号的字符串告诉 PHP 引擎首先去读取字符串内容，查找其中的变量，并改为变量对应的值。一般来说字符串是没有变量的，所以使用双引号会导致性能不佳。最好是使用字符串连接而不 是双引号字符串。 BAD: $output = “This is a plain string”; GOOD: $output = 'This is a plain string'; BAD: $type = “mixed”; $output = “This is a $type string”; GOOD: $type = 'mixed'; $output = 'This is a ' . $type .' string'; 2. 不要随便就复制变量 有时候为了使 PHP 代码更 加整洁，一些 PHP 新手（包括我）会把预定义好的变量复制到一个名字更简短的变量中，其实这样做的结果是增加了一倍的内存消耗，只会使程序更加慢。试想一下，在下面的例子 中，如果用户恶意插入 512KB 字节的文字到文本输入框中，这样就会导致 1MB 的内存被消耗！ BAD: $description = $_POST['description

性能优化 – 综合 理解业务，切合业务特点的优化效果最好 业务规划，容量预估，建立基线模型 压测数据采集，预留峰值 尽一切努力减少IO(磁盘、网络) 转变随机IO为顺序IO 努力提高内存利用率 上线前做好评估审核 性能优化 – 架构设计 保持优雅：越小越好，单库100G内 垂直拆分：按功能 水平拆分：按key哈希 单实例下数据表数量不高于1024 单表数据量尽量不高于1000万 主库写，从库只读、统计、汇总 前端做好一切cache 性能优化 – 硬件 NUMA架构，CPU直接和内存打交道 CPU不再是瓶颈，MySQL多核支持不佳 设备越来越廉价，大内存解决很多问题 SSD应用越来越广泛，未来是主力 RAID卡可有效提升IOPS及数据安全 RAID卡必须配备BBU，FORCE WB RIAD卡的条带设置有讲究 FushionIO还是贵族 性能优化 – 系统 升级到64位 内核 IO调度：deadline，noop VM管理：vm.swappiness=0 文件系统：xfs、ext4 全B+树，高效 分配组，提高并发度 延迟分配，减少IO mount：nobarrier、data=ordered,writeback 加大请求队列：nr_requests 关闭NUMA 性能优化 – MySQL 化繁为简 读写分离 加大内存分配 创建合适的索引 减少锁，提高并发 合并随机IO为顺序IO

最近一直在解决线上一个问题，表现是： Tomcat每到凌晨会有一个高峰，峰值的并发达到了3000以上，最后的结果是Tomcat线程池满了，日志看很多请求超过了1s。 服务器性能很好，Tomcat版本是7.0.54，配置如下： <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="3000" minSpareThreads="800"/> <Connector executor="tomcatThreadPool" port="8084" protocol="org.apache.coyote.http11.Http11AprProtocol" connectionTimeout="60000" keepAliveTimeout="30000" maxKeepAliveRequests="8000" maxHttpHeaderSize="8192" URIEncoding="UTF-8" enableLookups="false" acceptCount="1000" disableUploadTimeout="true" redirectPort="8443" /> 事后thread dump看其实真正处于RUNNABLE状态的线程很少，绝大部分线程都处于TIMED_WAITING状态：

前段时间面试得时候，面试的人有问到一个问题，就是UITableView得Cell里如果有尺寸比较大得图片，滑动得时候会有卡顿现象，问我是什么原因造成的，还有就是有没有改良的建议。 为此，我特地的google了一下这方面的知识，这里贴出来，方面大家学习。 个人感觉，导致的原因大多数说因为在主线程中去加载的，这样的话，因为阻塞了线程，所以导致的滑动卡顿，还有一点就是，因为表格的重绘机制，所以每次还要重新加载视图。 主要的优化方案，下面的这篇文章说的很仔细了。 在iOS应用中，UITableView应该是使用率最高的视图之一了。iPod、时钟、日历、备忘录、Mail、天气、照片、电话、短信、Safari、App Store、iTunes、Game Center⋯几乎所有自带的应用中都能看到它的身影，可见它的重要性。 然而在使用第三方应用时，却经常遇到性能上的问题，普遍表现在滚动时比较卡，特别是table cell中包含图片的情况时。 实际上只要针对性地优化一下，这种问题就不会有了。有兴趣的可以看看 LazyTableImages 这个官方的例子程序，虽然也要从网上下载图片并显示，但滚动时丝毫不卡。 下面就说说我对UITableView的了解。不过由于我也是初学者，或许会说错或遗漏一些，因此仅供参考。 首先说下UITableView的原理。有兴趣的可以看看 《About Table

参数配置 1、spark-env.sh 2、程序通过SparkConf或System.setProperty 性能观察与日志 1）Web UI。 2）Driver程序控制台日志。 3）logs文件夹下日志。 4）work文件夹下日志。 5）Profiler工具。 调度与分区优化 1.小分区合并 频繁的过滤或者过滤掉的数据量过大就会产生问题，造成大量小分区的产生。Spark是每个数据分区都会分配一个任务执行，如果任务过多，则每个任务处理的数据量很小，会造成线程切换开销大，很多任务等待执行，并行度不高； 解决方式：可以采用RDD中重分区的函数进行数据紧缩，减少分区数，将小分区合并变为大分区。 通过coalesce函数来减少分区。这个函数会返回一个含有numPartitions数量个分区的新RDD，即将整个RDD重分区。 当分区由10000重分区到100时，由于前后两个阶段的分区是窄依赖的，所以不会产生Shuffle的操作。 但是如果分区数量急剧减少，如极端状况从10000重分区为一个分区时，就会造成一个问题：数据会分布到一个节点上进行计算，完全无法开掘集群并行计算的能力。为了规避这个问题，可以设置shuffle=true 由于Shuffle可以分隔Stage，这就保证了上一阶段Stage中的上游任务仍是10000个分区在并行计算。如果不加Shuffle