性能优化

JVM性能优化, Part 1 ―― JVM简介

浪子不回头ぞ 提交于 2019-11-29 05:27:05
众所周知,Java应用程序是运行在JVM上的,但是你对JVM有所了解么?作为这个系列文章的第一篇,本文将对经典Java虚拟机的运行机制做简单介绍,内容包括“一次编写,到处运行”的利弊、垃圾回收的基本原理、常用垃圾回收算法的示例和编译器优化等。后续的系列文章将会JVM性能优化的内容进行介绍,包括新一代JVM的设计思路,以及如何支持当今Java应用程序对高性能和高扩展性的要求。 如果你是一名程序员,那么毫无疑问,你肯定有过某种兴奋的感觉,就像是当一束灵感之光照亮了你思考方向,又像是神经元最终建立连接,又像是你解放思想开拓了新的局面。就我个人来说,我喜欢这种学习新知识的感觉。我在工作时就常常会有这种感觉,我的工作会涉及到一些JVM的相关技术,这着实令我兴奋,尤其是工作涉及到垃圾回收和JVM性能优化的时候。在这个系列中,我希望可以与你分享一些这方面的经验,希望你也会像我一样热爱JVM相关技术。 这个系列文章主要面向那些想要裂解JVM底层运行原理的Java程序员。文章立足于较高的层面展开讨论,内容涉及到垃圾回收和在不影响应用程序运行的情况下对安全快速的释放/分配内存。你将对JVM的核心模块有所了解:垃圾回收、GC算法、编译器行为,以及一些常用优化技巧。此外,还会讨论为什么对Java做基准测试(benchmark)是件很困难的事,并提供一些建议来帮助做基准测试。最后

Web前端性能优化

元气小坏坏 提交于 2019-11-29 04:56:10
web性能优化,主要分为前端和后台两个部分性能优化,后台性能优化决定了web能不能用,前端优化决定了其好不好用,也就是牵涉到前端用户体验和web易用性等情况,所以前端性能与用户体验是有着极大的关联的。 首先,前端优化之前,我们需要知道其整体性能情况,然后对整体情况进行细分与分析,了解其每一步所损耗的时间和消耗的原由,然后进行细节优化,才能达成一个整体性能质的飞越,并不是其中一部分或者一个步骤的优化就能够解决问题的,只有优化的量才能达到性能质的飞越。 对web的性能检测一般使用浏览器或者性能检测工具 下面是我们通常进行优化的方向点: 一、HTTP请求 1.减少HTTP请求数量 80%的响应的时间是消耗在网页内容的下载上,例如:图片,样式、脚本、Flash等。所以减少请求次数以是缩短响应时间的关键之处。 I. 合并文件:将相关代码文件进行合并 II. Css Sprites:将多张图片合并成单张图片,通过css来控制什么地方显示图片的那个位置。 III. 图片映射:也是将多图拼在一起,然后通过坐标来控制。通常在页面中连续的时候才有用,比如导航条。 IV. 行内图片(Base64编码): 通过编码的字符串将图片内嵌到网页文本中。 2.避免重定向 重定向是一个比较常使用的技术手段,比如服务器地址进行迁移,修改了请求的url地址,这时通常会使用重定向,把访问原网址的用户重定向到新的url。

MyEclipse8.6 性能优化

我们两清 提交于 2019-11-29 04:34:03
第一步: 取消自动validation validation有一堆,什么xml、jsp、jsf、js等等,我们没有必要全部都去自动校验一下,只是需要的时候才会手工校验一下! 取消方法: windows–>perferences–>myeclipse–>validation 除开Manual下面的复选框全部选中之外,其他全部不选 手工验证方法: 在要验证的文件上,单击鼠标右键–>myeclipse–>run validation 第二步: 取消Eclipse拼写检查 1、拼写检查会给我们带来不少的麻烦,我们的方法命名都会是单词的缩写,他也会提示有错,所以最好去掉,没有多大的用处 windows–>perferences–>general–>validation->editors->Text Editors->spelling 第三步: 取消myeclipse的启动项 myeclipse会有很多的启动项,而其中很多我们都用不着,或者只用一两个,取消前面不用的就可以 windows–>perferences–>general–>startup and shutdown (详见底端介绍) 第四步: 更改jsp默认打开的方式 安装了myeclipse后,编辑jsp页面,会打开他的编辑页面,同时也有预览页面,速度很慢,不适合开发。所以更改之 windows–>perferences–

Linux性能优化实战: 案例篇:Redis响应严重延迟,如何解决?(29)

ぐ巨炮叔叔 提交于 2019-11-29 04:25:56
一、上讲总结 你好,我是倪朋飞。 在访问商品搜索接口时,我们发现接口的响应特别慢。通过对系统 CPU、内存和磁盘 I/O等资源使用情况的分析,我们发现这时出现了磁盘的 I/O 瓶颈,并且正是案例应用导致的。 接着,我们借助 pidstat,发现罪魁祸首是 mysqld 进程。我们又通过 strace、lsof,找出了 mysqld 正在读的文件。根据文件的名字和路径,我们找出了 mysqld 正在操作的数据 库和数据表。综合这些信息,我们猜测这是一个没利用索引导致的慢查询问题。 为了验证猜测,我们到 MySQL 命令行终端,使用数据库分析工具发现,案例应用访问的字段果然没有索引。既然猜测是正确的,那增加索引后,问题就自然解决了。 从这个案例你会发现,MySQL 的 MyISAM 引擎,主要依赖系统缓存加速磁盘 I/O 的访问。可如果系统中还有其他应用同时运行, MyISAM 引擎很难充分利用系统缓存。缓 存可能会被其他应用程序占用,甚至被清理掉。 所以,一般我并不建议,把应用程序的性能优化完全建立在系统缓存上。最好能在应用程序的内部分配内存,构建完全自主控制的缓存;或者使用第三方的缓存应用, 比如Memcached、Redis 等。 Redis 是最常用的键值存储系统之一,常用作数据库、高速缓存和消息队列代理等。Redis基于内存来存储数据,不过,为了保证在服务器异常时数据不丢失

web性能优化

情到浓时终转凉″ 提交于 2019-11-29 04:20:15
前端是庞大的,包括 HTML、 CSS、 Javascript、Image 、Flash等等各种各样的资源。前端优化是复杂的,针对方方面面的资源都有不同的方式。那么,前端优化的目的是什么 ?   1. 从用户角度而言,优化能够让页面加载得更快、对用户的操作响应得更及时,能够给用户提供更为友好的体验。   2. 从服务商角度而言,优化能够减少页面请求数、或者减小请求所占带宽,能够节省可观的资源。   总之,恰当的优化不仅能够改善站点的用户体验并且能够节省相当的资源利用。   前端优化的途径有很多,按粒度大致可以分为两类,第一类是页面级别的优化,例如 HTTP请求数、脚本的无阻塞加载、内联脚本的位置优化等 ;第二类则是代码级别的优化,例如 Javascript中的DOM 操作优化、CSS选择符优化、图片优化以及 HTML结构优化等等。另外,本着提高投入产出比的目的,后文提到的各种优化策略大致按照投入产出比从大到小的顺序排列。    一、页面级优化     1. 减少 HTTP请求数   这条策略基本上所有前端人都知道,而且也是最重要最有效的。都说要减少 HTTP请求,那请求多了到底会怎么样呢 ?首先,每个请求都是有成本的,既包含时间成本也包含资源成本。一个完整的请求都需要经过 DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据这样一个 “漫长” 而复杂的过程

PHP性能优化利器:生成器 yield理解

杀马特。学长 韩版系。学妹 提交于 2019-11-29 01:42:34
如果是做Python或者其他语言的小伙伴,对于生成器应该不陌生。但很多PHP开发者或许都不知道生成器这个功能,可能是因为生成器是PHP 5.5.0才引入的功能,也可以是生成器作用不是很明显。但是,生成器功能的确非常有用。 优点 直接讲概念估计你听完还是一头雾水,所以我们先来说说优点,也许能勾起你的兴趣。那么生成器有哪些优点,如下: 生成器会对PHP应用的性能有非常大的影响 PHP代码运行时节省大量的内存 比较适合计算大量的数据 那么,这些神奇的功能究竟是如何做到的?我们先来举个例子。 概念引入 首先,放下生成器概念的包袱,来看一个简单的PHP函数: function createRange($number){ $data = []; for($i=0;$i<$number;$i++){ $data[] = time(); } return $data; } 这是一个非常常见的PHP函数,我们在处理一些数组的时候经常会使用。这里的代码也非常简单: 我们创建一个函数。 函数内包含一个 for 循环,我们循环的把当前时间放到 $data 里面 for 循环执行完毕,把 $data 返回出去。 下面没完,我们继续。我们再写一个函数,把这个函数的返回值循环打印出来: $result = createRange(10); // 这里调用上面我们创建的函数 foreach($result as

mysql性能优化

别说谁变了你拦得住时间么 提交于 2019-11-29 00:28:00
1、索引的实现 2、mysql体系结构 连接池、 服务和工具层、 sqlInterface、 parser、 optimizer、 caches indexes: pluggable storage engines 存储引擎:MyISAM InnoDB federated archive merge memory cluster example file system logs and files binary ,redo ,undo 3、索引的定义 为了加速对表中数据的检索而创建的一种分散存储的数据结构。 索引 —— 表数据(磁盘地址 数据) 4、使用索引的好处 索引能极大的减少存储引擎需要扫描的数据量; 可以将随机IO编程顺序IO 索引可以在我们进行分组、排序等操作时,避免使用临时表 5、数据结构为什么使用B+Tree? 树的概览 1、二叉树查找 Binary Tree Search 2、平衡二叉树 Balanced binary search tree 相对平衡的树 缺点:·太深 了:数据处的深度决定了索引的IO操作,IO操作耗时大    太小了:每一个磁盘块(节点/页)保存的数据量太小了,没有很好 的利用操作磁盘IO的数据交换特性,也没有很利用好磁盘IO的预读能力(空间局部性原理),从而带来频繁的IO操作 3、多路平衡二叉树B-tree 绝对平衡树 4、加强版多路平衡查找树

聊一聊百度移动端首页前端速度那些事儿

久未见 提交于 2019-11-28 23:29:28
欢迎大家收看聊一聊系列,这一套系列文章,可以帮助前端工程师们了解前端的方方面面(不仅仅是代码): http://my.oschina.net/MrHou/blog?catalog=477313&temp=1466755903794 这一期,咱们一起来聊一聊----百度移动端首页前端速度的那些事儿 1 长什么样? 我们的业务就是 https://m.baidu.com 别以为只有一个搜索框,我们还有下面丰富的卡片内容,可以提供各式各样的服务。如图1.1 图1.1 其实整个页面的逻辑相对是比较复杂的。 还有各式各样的卡片,轻轻下拉,即可看到,如图1.2 图1.2 2 面临的挑战 可能代码的量级没有很多webapp恐怖,可是“ 百度首页要秒开 ”却是一个共识,可以看到(如图2.1),在利用上了缓存的情况下,我们的首页包大小gzip后只有11.1k左右。耗时也就是500多毫秒。大部分用户“秒开”不是事儿。 图2.1 但是,我们的业务在不断的增长的同时,要维持这样的包大小,就是一门艺术了。 要快,但是我们的服务也必须万无一失,(后续我会分享百度移动端首页的前端架构设计)那么这样的优化,是如何做到的呢,又如何兼顾稳定性,架构性,与速度呢?别急,让我们把这些优化一一道来。 3 我们的业务与我们的优化 3.1 静态文件在哪里? 为了求快,首页是没有js和css外链的,这样会再发起多次请求

app性能优化(面试实战)

守給你的承諾、 提交于 2019-11-28 22:47:08
性能优化有几种 1.电量优化 1.1电量优化分为两个点我们围绕这两个点唠1.屏幕亮度:避免自己的背景是白色(白色背景对于电量的消耗比较大这个我需要和Ul进行沟通) 1.2硬件方面:网络发生器,减少网络请求有几个点1.合并网络请求,2.添加缓存3.避免重复点击4.减少请求(比如长连接)还有就是对于蓝牙(BT)GPS,感应器不用的时候关闭,对于后台应用当应用退出后台的时候判断停止还是继续执行 2.流量优化 1.减少请求次数:合并请求,添加缓存,防止重复点击,减少请求(长连接) 2.减少请求内容:对于图片1.先展示缩略图,分页加载,选择正确的请求格式(与后台沟通),去除无用阐述 3.内存优化 4.用户体验 对于用户体验首先我们要保证应用不崩,和流畅保证不崩溃我们就要对应用的核心代码进行(try catch)保护,全局的异常捕获(bugly),流畅 那么就要说一下app流畅的标准是16ms/帧要保证这一点我们首先要对不局进行优化减少布局的层级尽量要使用相对布局和约束布局,我们可以用include 对不局进行复用,merge减少布局的层级 viewstop可以对不局进行隐藏在需要用的时候调用这样也有优化的作用,然后就是防止过度的渲染,UI界面的优化(懒加载,冷白屏)白屏的时候是初始化 来源: https://blog.csdn.net/qq_42609613/article/details

CSS性能优化的技巧(一)

邮差的信 提交于 2019-11-28 22:33:30
下面我们开始介绍 实践型的4个优化技巧 ,先从首屏关键CSS开始。 1. 内联首屏关键CSS(Critical CSS) 性能优化中有一个重要的指标——首次有效绘制(First Meaningful Paint,简称FMP)即指页面的首要内容(primary content)出现在屏幕上的时间。这一指标影响用户看到页面前所需等待的时间,而**内联首屏关键CSS(即Critical CSS,可以称之为首屏关键CSS)**能减少这一时间。 大家应该都习惯于通过link标签引用外部CSS文件。但需要知道的是,将CSS直接内联到HTML文档中能使CSS更快速地下载。而使用外部CSS文件时,需要在HTML文档下载完成后才知道所要引用的CSS文件,然后才下载它们。所以说,内联CSS能够使浏览器开始页面渲染的时间提前,因为在HTML下载完成之后就能渲染了。 既然内联CSS能够使页面渲染的开始时间提前,那么是否可以内联所有的CSS呢?答案显然是否定的,这种方式并不适用于内联较大的CSS文件。因为 初始拥塞窗口 3存在限制(TCP相关概念,通常是 14.6kB,压缩后大小),如果内联CSS后的文件超出了这一限制,系统就需要在服务器和浏览器之间进行更多次的往返,这样并不能提前页面渲染时间。因此,我们应当只将渲染首屏内容所需的关键CSS内联到HTML中。 既然已经知道内联首屏关键CSS能够优化性能了