性能优化

Nginx配置参数优化 Nginx作为高性能web服务器，即使不特意调整配置参数也可以处理大量的并发请求。 以下的配置参数是借鉴网上的一些调优参数，仅作为参考，不见得适于你的线上业务。 worker进程 worker_processes 该参数表示启动几个工作进程，建议和本机CPU核数保持一致，每一核CPU处理一个进程。 worker_rlimit_nofile 它表示Nginx最大可用的文件描述符个数，需要配合系统的最大描述符，建议设置为102400。 还需要在系统里执行ulimit -n 102400才可以。 也可以直接修改配置文件/etc/security/limits.conf修改 增加： #* soft nofile 655350 (去掉前面的#) #* hard nofile 655350 (去掉前面的#) worker_connections 该参数用来配置每个Nginx worker进程最大处理的连接数，这个参数也决定了该Nginx服务器最多能处理多少客户端请求 （worker_processes * worker_connections)，建议把该参数设置为10240，不建议太大。 http和tcp连接 use epoll 使用epoll模式的事件驱动模型，该模型为Linux系统下最优方式。 multi_accept on

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秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

J ava性能优化的五种方式 一,JAVA性能优化之设计优化 设计优化处于性能优化手段的上层。它往往须要在软件开发之前进行。在软件开发之前，系统架构师应该就评估系统可能存在的各种潜在问题和技术难点，并给出合理的设计方案，因为软件设计和系统架构对软件总体设计质量有决定性的影响。所以，设计调优对系统的性能影响也是最大的，假设说，代码优化。JVM优化都是对系统微观层次的“量”的优化，那设计优化就是对系统”质”的优化. 设计优化的一大显著特征是:它能够规避某一个组件的性能问题,而是改良组件的实现;比方:组件A通过循环监控不断的检測时间E是否发生,其检測行为必定会占用部分系统资源,因此,开发者必须检測频率和资源消耗上取得平衡,假设检測频率太低,尽管降低了资源消耗,可是系统实时反应性就会降低,假设进行代码层的调优,就须要优化检測方法的实现及要求得一个最为恰当的检測频率.对于这个问题我们就能够用设计模式中的观察者模式 ,当事件E发生的时刻,由事件E通知组件A,从而触发组件A的行为.这样的设计从根本上攻克了存在性能隐患的循环监控,从根本上攻克了这一问题. 进行设计优化时,设计人员和必须熟悉经常使用的设计方法,设计模式,以及主要的性能组件和经常使用的优化思想,并将其有机地集成在软件系统中. 注意:一个良好的系统设计能够规避非常多潜在在的性能问题.因此,尽可能多花些时间在系统设计上

　　先让我们看看一张网页是怎么来的，也就是从用户输入完一个网址点下“ENTER”键到整个页面加载出来中间发生了什么。首先我们了解下HTTP过程： 一、寻找IP（每一步都是在上一步没找到的情况下进行的） 本地阶段： 1、浏览器搜索自身缓存； 2、搜索操作系统自身的DNS缓存； 3、地区本地HOST文件； 4、浏览器发送DNS系统调用； 路由阶段： 1、宽带运营商服务器查看本地缓存； 2、运营商服务器发起一个迭代DNS解析请求； com -> baidu.com -> www.baidu.com 3、运营商服务器把结果返回给操作系统内核同时缓存起来； 4、操作系统内核把结果返回个浏览器 浏览器得到IP了。 二、建立连接并获取内容 1、发起HTTP三次握手，建立TCP/IP连接； 2、发起HTTP请求； 3、服务器端读取数据库并处理数据后返回页面内容； 这样获得了一个页面，但是页面的js文件、css文件、图片都要经过这样的过程！ 4、渲染页面； 我们写baidu.com和www.baidu.com同样都会跳转到百度首页，但是baidu.com是经过了一次301页面跳转到www.baidu.com的，多了一次DNS查询； 常见状态码： 1xx 请求已接受 2xx 处理完毕 3xx 重定向 4xx 客户端错误 5xx 服务器端错误 200 OK成功 400 客户端语法错误 401

1. 减少http请求数 合并文件，通过把所有脚本置于一个脚本文件里或者把所有样式表放于一个样式表文件中，从而减少Http请求的数量。 CSS Sprites是减少图片请求的首选方案。把所有的背景图片合并到一张图中，使用CSS的background-image 和background-position 属性去控制展现恰当的图片区域。 内联图片使用data: URL scheme 把图片数据嵌入页面，但这会增加Html文档的大小。 2. 使用内容分布式网络 内容分布式网络（CDN）是一系列分布在不同地域的服务器的集合，能够更有效的给用户发送信息。它会根据一种衡量网域距离的方法，选取为某个用户发送数据的服务器。比如，到达用户最少跳或者最快相应速度的服务器会被选中。 3. 给头部添加一个失效期或者Cache-Control 对于静态组件：把头部的缓存期设为某个遥远的未来，使其能够“永不过期”。 对于动态组件：使用适当的Cache-Control头部帮助浏览器执行特定的请求。 4. Gzip压缩组件 在HTTP请求的头部中Accept-Encoding指定的压缩格式： ν Accept-Encoding: gzip, deflate ν Content-Encoding: gzip 5. 把样式表放在前面 把样式表挪到文档的头部可以让页面的加载显得更快

客户端 一、减少HTTP请求数 　　1、合并JavaScript、CSS等文件 　　2、使用CSS Sprite：将背景图片合并成一个文件，通过background-image和background-position控制显示　　 　　3、字体图标 　　4、将请求划分到不同的域名上 二、减少DNS查询 　　用户输入URL后，浏览器首先要查询域名对应服务器的IP地址，一般需要耗费20到120毫秒时间。DNS查询完成之前，浏览器无法从服务器下载任何数据。首次访问、没有相应的DNS缓存，域名越多，查询时间越长。所以应尽量减少域名数量。但基于并行下载考虑，把资源分布到2个域名上（最多不超过4个）。 三、避免重定向 　　客户端收到服务器的重定向响应后，会根据响应头中 Location 的地址再次发送请求。重定向会影响用户体验，尤其是多次重定向时，用户在一段时间内看不到任何内容，只看到浏览器进度条一直在刷新。 四、缓存Ajax请求 五、延迟加载 　　1、非首屏使用的数据、样式、脚本、图片等； 　　2、用户交互时才会显示的内容。 六、预先加载 　　1、无条件预先加载：页面加载完成（load）后，马上获取其他资源。 　　2、有条件预先加载：根据用户行为预判用户去向，预载相关资源。 七、减少DOM元素数量　　 八、划分内容到不同的域名 　　 九、尽量减少iframe使用 　　iframe优点 　　　

规则1：减少HTTP请求 我们只有20%的时间花在所请求的HTML页面上，剩下的80%是发生在浏览器前端，特别是页面和页面中各种元素（图片、CSS、Javascript、 flash…）的下载之上。 图片技术，CSSsprite,内联图片和脚本，样式表的合并，这些技术既可以减少HTTP请求，又可以避免在性能和设计之间进行艰难的选择。 规则2：使用内容发布网络 内容发布网络（CDN）是一组分布在多个不同地理位置的web服务器，用于更加有效的向用户发布内容。 除了缩短时间之外，CDN还可以带来其他优势。他们的服务包括备份，扩展存储能力和进行缓存。CDN还有助于缓和web流量峰值压力，比如在获取天气或股市新闻，浏览流行的体育或娱乐事件时。 规则3：增加Expires header 现在的WEB页面都包含了大量的组件，并且其数量在不断增长，页面的初访者会进行很多的HTTP请求，但通过使用一个长久的Expires头，让这些组件被缓存，这会在后续的页面浏览中避免不必要的HTTP请求。长久的Expires头常用于图片，但应该用在所有的组件上，包括脚本，样式表。 规则4：压缩组件 如果http产生的响应包很小，传输时间就会很少，因为只需要很小的包从服务器传递到客户端。压缩响应包，并由此减少网络的响应时间，这是减少页面大小的最简单的技术，但影响是最大的。 规则5：将样式表放在顶部 规则6

1.　　请减少HTTP请求　　 　　 基本原理： 　　在浏览器(客户端)和服务器发生通信时，就已经消耗了大量的时间，尤其是在网络情况比较糟糕的时候，这个问题尤其的突出。 　　一个正常HTTP请求的流程简述：如在浏览器中输入"www.xxxxxx.com"并按下回车，浏览器再与这个URL指向的服务器建立连接，然后浏览器才能向服务器发送请求信息，服务器在接受到请求的信息后再返回相应的信息，浏览器接收到来自服务器的应答信息后，对这些数据解释执行。 　　 而当我们请求的网页文件中有很多图片、CSS、JS甚至音乐等信息时，将会频繁的与服务器建立连接，与释放连接，这必定会造成资源的浪费，且每个HTTP请求都会对服务器和浏览器产生性能负担。 　　网速相同的条件下，下载一个100KB的图片比下载两个50KB的图片要快。所以， 请减少HTTP请求。 　　 解决办法： 　　合并图片（css sprites），合并CSS和JS文件；图片较多的页面也可以使用 lazyLoad 等技术进行 优化 。 2.　　请正确理解 Repaint 和 Reflow　　 　　注：Repaint 和 Reflow 也就是重绘和重排，请允许我在这卖弄下我有限认识的那么几个英语单词...囧 　　 基本原理： 　　R epaint(重绘)就是在一个元素的外观被改变，但没有改变布局(宽高)的情况下发生，如改变visibility

tomcat基本流程 // Start our child containers, if any Container children[] = findChildren(); List<Future<Void>> results = new ArrayList<>(); for (int i = 0; i < children.length; i++) { // 这句代码就是会调用ContainerBase下的一个个子容器的call方法 results.add(startStopExecutor.submit(new StartChild(children[i]))); } 查看new StartChild要执行的call方法 private static class StartChild implements Callable<Void> { private Container child; public StartChild(Container child){ this.child = child; } @Override public Void call() throws LifecycleException { child.start(); return null; } } deployDescriptors(configBase, configBase.list());

一、Fetch抓取 1、理论分析 Fetch抓取是指，Hive中对某些情况的查询可以不必使用MapReduce计算。例如：SELECT * FROM employees;在这种情况下，Hive可以简单地读取employee对应的存储目录下的文件，然后输出查询结果到控制台。 在hive-default.xml.template文件中hive.fetch.task.conversion默认是more，老版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit查找等都不走mapreduce。 复制代码 hive.fetch.task.conversion more Expects one of [none, minimal, more]. Some select queries can be converted to single FETCH task minimizing latency. Currently the query should be single sourced not having any subquery and should not have any aggregations or distincts (which incurs RS), lateral views and joins. 0. none : disable