性能

一、总结前一天的学习 从“第三天”的性能测试一节中，我们得知了决定性能测试的几个重要指标，它们是： ü 吞吐量 ü Responsetime ü Cpuload ü MemoryUsage 我 们也在第三天的学习中对Apache做过了一定的优化，使其最优化上述4大核心指标的读数，那么我们的Apache调优了，我们的Tomcat也作些相应 的调整，当完成今的课程后，到时你的“小猫”到时真的会“飞”起来的，所以请用心看完，这篇文章一方面用来向那位曾写过“Tomcat如何承受1000个 用户”的作都的敬，一方面又是这篇原文的一个扩展，因为在把原文的知识用到相关的两个大工程中去后解决了： 1) 承受更大并发用户数 2) 取得了良好的性能与改善（系统平均性能提升达20倍，极端一个交易达80倍）。 另外值的一提的是，我们当时工程里用的“小猫”是跑在32位机下的， 也就是我们的JVM最大受到2GB内存的限制，都已经跑成“飞”了。。。。。。如果在64位机下跑这头“小猫”。。。。。。大家可想而知，会得到什么样的效果呢？下面就请请详细的设置吧！ 二、一切基于JVM（内存）的优化 2.1 32位操作系统与64位操作系统中JVM的对比 我们一般的开发人员，基本用的是都是32位的Windows系统，这就导致了一个严重的问题即：32位windows系统对内存限制，下面先来看一个比较的表格： 操作系统

Python编程规范及性能优化 Ptyhon编程规范 编码 所有的 Python 脚本文件都应在文件头标上 # -*- coding:utf-8 -*- 。设置编辑器，默认保存为 utf-8 格式。 注释 业界普遍认同 Python 的注释分为两种的概念，一种是由 # 开头的“真正的”注释，另一种是 docstrings。前者表明为何选择当前实现以及这种实现的原理和难点，后者表明如何使用这个包、模块、类、函数（方法），甚至包括使用示例和单元测试。 坚持适当注释原则。对不存在技术难点的代码坚持不注释，对存在技术难点的代码必须注释。但与注释不同，推荐对每一个包、模块、类、函数（方法）写 docstrings，除非代码一目了然，非常简单。 缩进 Python 依赖缩进来确定代码块的层次，行首空白符主要有两种：tab 和空格，但严禁两者混用。如果使用 tab 缩进，设定 tab 为 4 个空格。 公司内部推荐使用 4 个空格的 tab 进行缩进。 空格 空格在 Python 代码中是有意义的，因为 Python 的语法依赖于缩进，在行首的空格称为前导空格。在这一节不讨论前导空格相关的内容，只讨论非前导空格。非前导空格在 Python 代码中没有意义，但适当地加入非前导空格可以增进代码的可读性。 1）在二元算术、逻辑运算符前后加空格：如 a = b + c； 2）在一元前缀运算符后不加空格

不同视角 用户眼中的性能： 客户的机器，浏览器，网络状况，通信协议，服务器处理时间，浏览器解析时间。另外 1s左右 ，对用户来说是无区别的。 开发严重的性能：程序本身和相关子系统。响应延迟，系统吞吐量，并发处理能力，系统稳定性等。 运维人员：关注基础设施的资源和性能的利用率，合理利用，最优发挥（不浪费，不堵塞） 性能指标 响应时间 ：10000/n次时间和，除以10000/n。 并发数 吞吐量 ：TPS(每秒事务数),HPS(每秒请求数),QPS(每秒查询数) 。理论上讲 应该是个抛物线，峰值即为吞吐量值。 吞吐量，并发数，响应时间之间的关系 用高速公路形容很接近。车越少（并发数），资源越浪费（内存，硬盘，网络），车增多，开始吞吐量上升，到达峰值后会随之下降，直至瘫痪。 性能计数器：描述操作系统的性能指标（System Load，对象与线程数，内存使用，cpu使用，磁盘及网络io等指标） 测试方式 性能 测试：验证资源可接受范围 稳定性 测试：不均匀的施加压力，验证稳定性 压力 测试：超过安全负载的情况下，继续对系统施加压力，直至系统崩溃或者不能处理请求，来获取系统最大压力承受能力。 负载 测试：对系统不断增加并发，不断增加压力，直至系统或者应用多项指标达到临界值 性能优化 web前端，应用服务器，存储服务器性能优化。 Web前端优化 浏览器优化 1 减少http请求 2

请求数量 合并脚本和样式表，拆分初始化负载 请求带宽 移除重复脚本 缓存利用 使Ajax可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 来源： oschina 链接： https://my.oschina.net/u/1011494/blog/163945

集成crosswalk， 参考 http://my.oschina.net/u/2485194/blog/517964 跳转页面不流畅，页面切换等待较久，思路：尽可能减少立刻载入的资源量 跳转后的页面不要载入太多css或js文件， 采用提前载入方式（index中载入） 可考虑内容延迟载入方式，先跳转到下一页，通过loading效果等待内容载入 来源： oschina 链接： https://my.oschina.net/u/2485194/blog/518270

###Parcelable vs Serializable 在一开始学习Android的时候，我们就知道了不能在Activity和Fragment之间直接传递对象，必须使用Intent或者Bundle。 查看api后，我们发现有两个选择，让我们的对象要么实现Parcelable，要么实现Serializable。作为Java开发者，我们都知道Serializable机制，那么为什么还需要Parcelable呢？ 要接解答这个问题，先来看两个列子 ####Serializable-简洁之至 // access modifiers, accessors and constructors omitted for brevity public class SerializableDeveloper implements Serializable String name; int yearsOfExperience; List<Skill> skillSet; float favoriteFloat; static class Skill implements Serializable { String name; boolean programmingRelated; } } 正如你所见到的，只需要在类和成员变量引用类实现Serializable接口就可以了，并且不需要实现任何方法

About the Speaker: Romain Guy Romain是谷歌的安卓工程师。在加入Robotics之前，他在安卓Framwork组参与了安卓1.0到5.0的开发工作。他现在又重新加入了安卓的新UI和图形图像相关的项目。 @romainguy About the Speaker: Chet Haase Chet 也是谷歌的工程师。 他现在是安卓UI Toolkit 组的组长，他擅长于动画，图像， UI控件和其他能带来安卓更好的用户体验的UI组件的开发。他还擅长撰写和表演喜剧。 @chethaase 介绍 (0:00) 本次演讲是以安卓平台组写的近10篇文章为基础的。所有的文章都能够在Medium网站上看到，文章的第一部分请看这里. 今天我们会讲到这些文章里面的一些东西，如果你对特定的话题感兴趣或者想深入了解它们，请去阅读原文。 为什么移动开发如此艰难？ (1:47) 有限的内存 (1:47) 我们发现谷歌公司里面的应用开发者有一个大问题，他们对口袋里每天都携带着的安卓手机的本质都有些误解。这些设备内存，CPU的处理能力和电池的待 机能力都非常有限。开发者们必须理解你们的应用不是在设备上唯一运行的应用。内存是非常有限的资源，并且被整个系统共享着。我所在的Android平台组 非常小心地对待这个问题，这也是为什么有的时候我们建议的一些规则看起来会有一点极端的原因

如何优化性能： 如果重复计算量大的话，使用缓存来保存旧的结果，以便下次计算时使用； 减少阻塞，运行和阻塞会增加上下文切换。 因为锁是串行的这会引起大量的阻塞:所以我们在使用锁的时候要尽量的做到以下几点： 减少锁的持有时间(尽量使用synchronized或者显示锁将不必要同步的代码移除加锁的范围内,但不要把一个synchronized块分拆成多个块这会适得其反)； 减少请求锁的操作； 使用协调机制取代独占所。 使用分离锁可以增加并发访问容器的量.这可以使容器并发的get等相同的操作： 分离锁的实现: 使用多个Object作为synchronized的代码块的"对象锁" 在取出或者写入的利用 获取对象的hash%锁数量 随即使用一个"对象锁" 分离锁:其实就是使用一个Array保存固定数量的Object(其实随便任意对象)使用这些对象的锁作为"分离锁".然后在get/put等操作中随即使用其中任意一个锁. 竞争锁是造成多线程应用程序性能瓶颈的主要原因： 区分竞争锁和非竞争锁对性能的影响非常重要。如果一个锁自始至终只被一个线程使用，那么 JVM 有能力优化它带来的绝大部分损耗。如果一个锁被多个线程使用过，但是在任意时刻，都只有一个线程尝试获取锁，那么它的开销要大一些。我们将以上两种锁称为非竞争锁。而对性能影响最严重的情况出现在多个线程同时尝试获取锁时。这种情况是 JVM 无法优化的

一、Spark集成ElasticSearch的设计动机 ElasticSearch 毫秒级的查询响应时间还是很惊艳的。其优点有： 1. 优秀的全文检索能力 2. 高效的列式存储与查询能力 3. 数据分布式存储(Shard 分片) 相应的也存在一些缺点： 1. 缺乏优秀的SQL支持 2. 缺乏水平扩展的Reduce(Merge)能力，现阶段的实现局限在单机 3. JSON格式的查询语言，缺乏编程能力，难以实现非常复杂的数据加工，自定义函数(类似Hive的UDF等) Spark 作为一个计算引擎，可以克服ES存在的这些缺点： 1. 良好的SQL支持 2. 强大的计算引擎，可以进行分布式Reduce 3. 支持自定义编程(采用原生API或者编写UDF等函数对SQL做增强) 所以在构建即席多维查询系统时，Spark 可以和ES取得良好的互补效果 二、Spark与ElasticSearch结合的架构和原理 ES-Hadoop无缝打通了ES和Hadoop两个非常优秀的框架，我们既可以把HDFS的数据导入到ES里面做分析，也可以将es数据导出到HDFS上做备份，归档，其中值得一提的是ES-Hadoop全面的支持了Spark框架，其中包括Spark，Spark Streaming，Spark SQL，此外也支持Hive，Pig，Storm，Cascading，当然还有标准的MapReduce

3 月，跳不动了？>>> 大家在使用MongoDB的时候有没有碰到过性能问题呢？这里总结了MongoDB性能优化的五个步骤，希望能够有所帮助。 第一步：找出慢语句 一般来说查询语句太慢和性能问题瓶颈有着直接的关系，所以可以用MongoDB的性能分析工具来找出这些慢语句： db.setProfilingLevel(1, 100); 第二步：使用explain分析 通过使用explain来对这些慢语句进行诊断。此外还可以mtools来分析日志。 第三步：创建索引 分析完之后需要创建新的索引(index)来提升查询的性能。别忘了在MondoDB中可以在 后台创建索引 以避免collections 锁和系统崩溃。 第四步：使用稀疏索引来减少空间占用 如果使用sparse documents，并重度使用关键字$exists，可以使用 sparse indexes 来减少空间占用提升查询的性能。 第五步：读写分离 如果读写都在主节点的话，从节点就一直处在空置状态，这是一种浪费。对于报表或者搜索这种读操作来说完全可以在从节点实现，因此要做的是在connection string中设置成secondarypreferred。 小结 这些方法虽然能够起一定的作用，但最主要的目的还是为架构上的提升争取点时间罢了。 来源： oschina 链接： https://my.oschina.net/u