性能优化

要：添加Expires头能有效的利用浏览器的缓存能力来改善页面的性能，能在后续的页面中有效避免很多不必要的Http请求，WEB服务器使用Expires头来告诉Web客户端它可以使用一个组件的当前副本，直到指定的时间为止。 例如：Expires：Thu，15 Apr 2010 20：00：00 GMT; 他告诉浏览器缓存有效性持续到2010年4月15日为止，在这个时间之内相同的请求使用缓存，这个时间之外使用http请求。 Cathe-Control：max-age=315360000 Expires有一个非常大的缺陷，它使用一个固定的时间，要求服务器与客户端的时钟保持严格的同步，并且这一天到来后，服务器还得重新设定新的时间。 HTTP1.1引入了 Cathe-Control，它使用max-age指定组件被缓存多久， 从请求开始在max-age时间内浏览器使用缓存，之外的使用请求，这样就可以消除Expires的限制， 如果对浏览器兼容性要求很高的话，可以两个都使用。 这里对http 304 状态结合max-age做一个总结： 浏览器初次访问服务器---------------服务器返回200状态 如下图： 浏览器再次请求服务器时，浏览器会先判断max-age，如果到期则直接请求服务器，否则直接从缓存中取， 服务器收到请求后，判断文件是否被修改过，若是则直接返回200，否则返回304

一直听说HTTP2.0，对此也仅仅是耳闻，没有具体研读过，这次正好有两个篇章，分别讲HTTP1.1和HTTP2.0。 两者还能好好对比一下，两者之间的巨大区别，以及HTTP2.0解决了哪些实际问题。 无论什么网络，也不管所用网络协议是什么版本，所有应用都应该致力于 消除或减少不必要的网络延迟 ， 将需要传输的数据压缩至最少 。 HTTP2.0就是为了做这些优化而出现的。 一、HTTP1.1的几个特点 1）持久连接 每个TCP连接开始都有三次握手，要经历一次客户端与服务器间完整的往返，而开启了持久化连接就能不必每次都要握手。 在连接中有这个属性的就是打开了持久化连接。下图展示了通过持久 TCP 连接取得 HTML 和 CSS 文件： 2） HTTP管道 持久HTTP多次请求必须严格满足先进先出（ FIFO ）的队列顺序：发送请求，等待响应完成，再发送客户端队列中的下一个请求。 HTTP管道可以让我们把FIFO队列从客户端（请求队列） 迁移到服务器 （响应队列）。 这样的话在第一个请求完成后，能马上开始处理第二个请求。 但HTTP 1.x不允许一个连接上的多个响应数据交错到达（多路复用），因而一个响应必须完全返回后，下一个响应才会开始传输。 也就是说即使客户端同时发送了两个请求，而且CSS资源先准备就绪，服务器也会 先发送HTML 响应，然后 再交付CSS 。 而HTTP2

最近研究应用流畅度专题时，发现RecyclerView里边的坑真多，有很多可以优化的点，在理解优化点之前，最好对RecyclerView的缓存机制有一些了解，比如得知道CacheView和RecycledViewPool的区别和联系，RecyclerView的绘制流程有一定了解，再来谈RecyclerView的性能提升。缓存机制可以看看这篇文章：基于滑动场景解析RecyclerView的回收复用机制原理 还有一篇外国人写的，ViewHolder的探究，这篇文章把RecyclerView的各级缓存作用剖析得很清晰，以前看过很多人写的文章，感觉都是一知半解，总结下： 1、RecyclerView缓存 1.1 RecyclerView主要有三级缓存： （1）Attached scrap & Changed scrap ArrayList<ViewHolder> mAttachedScrap 主要用在插入或是删除itemView时，先把屏幕内的ViewHolder保存至AttachedScrap中，作用在LayoutManager中，它仅仅把需要从ViewGroup中移除的子view设置它的父view为null，从而实现了从RecyclerView中移除操作detachView()。需要新插入的view从cacheView/Pool中找，没找到则createViewHolder

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最近对系统进行性能优化 避免超时 死锁 数据处理能力不够等常见的性能问题 这里不从架构方面出发 毕竟动大手脚成本比较高 那么我们以实例为前提 从细节开始 优化角度 业务逻辑优化 DB优化 数据处理优化 锁与性能 cpu飙高小结 业务逻辑优化 这一条不具有普遍性 不同的业务不同的场景 如果归纳起来 就是在不影响业务的前提下进行流程精简 1. 废弃冗余逻辑 常见于各种基于数据库的检查 很多同学在维护别人代码的时候 没有深入理解别人的逻辑 也许别人在取数据的时候已经在查询条件中已经过滤了相关逻辑 而后来维护的同学又来了一次check 当然如果处于数据安全的角度 double check无可厚非，但是如果连锁都没有的double check 其实不做也罢。 毕竟 省一次dbcall 可能效果胜于你做的N多优化 2. 合并业务请求 出发点和上述一致 节省dbcall 但是存在一个矛盾的点 如果业务包在事务里 这条需要慎重考虑 事务的设计原则里 当然能小则小 DB优化 这个其实是比较核心的点 1. 索引优化 这个点比较泛泛 但是做好的人不多 一个专攻于索引优化的人也可以在运维方面独当一面了 我们拿实例来看一个索引优化例子 首先利其器 选中你需要的调试信息 然后打开自动统计信息更新 特别对于测试阶段

优化分析 SQL性能下降的表现 执行时间长 等待时间长 SQL性能下降的原因 查询语句写的不好：各种连接以及子查询，导致没用上索引或者就没有建立索引。 建立的索引失效：建立了索引，在真正执行的时候，索引失效了导致没用上索引。 关联查询使用了太多的Join。 服务器优化和参数配置不合适：如果设置的不合理，比例不恰当也会导致性能下降，SQL变慢。 索引 什么是索引 索引是一个帮助MySQL高效获取数据的一种数据结构，类似字典的索引目录可以通过索引快速的查找到排好序的数据。 为什么要建立索引 为了提高查询数据的效率 建立索引的优势 提高了数据检索的效率，降低了数据库IO的开销 通过索引对数据进行排序，降低了排序的成本，降低了CPU的消耗 建立索引的劣势 索引是以文件的形式存储在磁盘中。会占用空间。 索引也是一张表，该表保存了主键与索引字段并指向实体表的记录。所以也占空间。 更新表时，MYSQL不仅要保存数据，还要对索引文件进行保存，每次更新添加了索引的字段就会导致性能下降。 索引提高了查询速度但是降低了更新速度。 会调整因为更新带来的键值变化后索引的信息。 索引尽量加在经常用来查询的字段上，避免加在那些常常发生变化的字段上。 索引的分类 单值索引：一个索引只包含单个列，一个表可以有多个单值索引。 唯一索引：索引列的值必须唯一，但是可以有空值 复合索引：一个索引包含多个列 全文索引

数据库IO {CPU 缓存 内存}:执行,缓存数据访问,比较,排序,事务检测,SQL解析,函数或逻辑运算 {SSD硬盘,普通硬盘}:执行:数据访问,数据写入,日志记录,大数据量排序,大表连接 {网卡}:执行:结果数据传输,sql请求,远程数据库访问 数据库访问优化漏斗法则 减少数据访问(减少磁盘访问) 返回更少数据(减少网络传输或磁盘访问) 减少交互次数(减少网络传输) 减少服务器CPU开销(减少CPU及内存开销) 利用更多资源(增加资源) 来源： CSDN 作者： 小白爱Python 链接： https://blog.csdn.net/weixin_45010894/article/details/103647900

以阿里云ECS为例 1.打开服务器管理器（无该快捷图标就去 开始->管理工具->服务器管理器） 2.打开后点击角色，添加角色，点击下一步 3.选择web服务器（IIS），点击下一步选择需要安装的模块，开始安装。 4.附配置，应用程序模块建议安装（用于性能优化），ftp可以不装 来源： CSDN 作者： 兰先生丶 链接： https://blog.csdn.net/qq_39178411/article/details/103646439

★finalize 函数的调用机制 　　俺经常啰嗦：“了解本质机制的重要性”。所以今天也得先谈谈 finalize 函数的调用机制。在聊之前，先声明一下：Java虚拟机规范，并没有硬性规定垃圾回收该不该搞，以及该如何搞。所以俺这里提到的 finalize 函数的调用机制，或许适用于大多数 JVM，但【不保证】适用于所有的 JVM。 ◇何时被调用？ 　　finalize 啥时候才会被调用捏？一般来说，要等到JVM开始进行垃圾回收的时候，它才【 有可能 】被调用。而 JVM 进行垃圾回收的时间点是【非常】不确定的，依赖于各种运行时的环境因素。正是由于 finalize 函数调用时间点的不确定，导致了后面提到的某些缺点。 ◇谁来调用？ 　　说完何时调用，咱接着来聊一下被谁调用？ 　　常见的 JVM 会通过 GC 的垃圾回收线程来进行 finalize 函数的调用。由于垃圾回收线程比较重要（人家好歹也是 JVM 的一个组成部分嘛），为了防止 finalize 函数抛出的异常影响到垃圾回收线程的运作，垃圾回收线程会在调用每一个 finalize 函数时进行 try/catch，如果捕获到异常，就直接丢弃，然后接着处理下一个失效对象的 finalize 函数。 ★对 finalize 函数的误解和误用 ◇把 finalize 理解为“析构函数” 　　学过 C++ 的同学应该都知道“析构函数”

web性能优化之重要，这里并不打算赘述。本系列课程将带领大家认识、熟悉、深刻体会并且懂得如果去为不同的站点做性能优化 同时，本系列将还会穿插浏览器兼容性相关问题的解决方案，因为在我看来，兼容性同样属于性能优化的范畴 本系列参考了大量互联网资料及相关书籍。如：Pro HTML5 Performance、web性能权威指南等 本系列通过自己实践、研究后的成果，将会不间断更新。主要用于学习交流。同时欢迎任何形式的转载，但请保留作品链接 web性能优化目录 浏览器渲染过程 浏览器中JavaScript执行原理 来源： https://www.cnblogs.com/inJS/p/4876916.html

前言 最近hyddd一直看Oracle的资料，今天特地总结一下这段时间了解到的 关于Oracle性能优化的下手点 。 一 . 数据库优化的方向 1.程序设计（这点最重要，如果程序本身设计有问题，再怎么进行下面的优化都是徒劳的。） 2.操作系统优化 3.硬件优化 4.数据库优化 5.SQL语句优化 二 . 硬件优化 这里涉及到的硬件主要有：硬盘，内存。 1.硬盘的读写速度：建议增加硬盘的数量，从而增加每秒的并发操作。 2.内存大小。 三 . 数据库优化 以上是Oracle 9i的体系结构，关于Oracle数据库的优化，很大程度上图有关。 1. 根据数据库的使用方式得出合理的优化策略 （1）OLTP：连机事务处理。 需要实时处理大量请求，而每次处请求的数据量都是很小的。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。 性能好坏的重要指标：响应时间与请求处理并发数。 （2）OLAP：联机分析处理。 可以简单地理解为在海量数据中得出统计/综合信息，是数据仓库的主要应用。做OLAP应用的数据库，数据量通常量非常大。和OLTP不同，OLAP应用的并发处理量是很低的，所以基本不用考虑并发问题。而在处理数据量方面，OLAP每次操作所需要处理的数据量通常都是非常大的，这点也和OLTP相反。 性能好坏的重要指标：查询大量数据的速度。