性能优化 | 易学教程

前端性能优化的三大类处理方式

阅读更多关于前端性能优化的三大类处理方式

1 . 减少 HTTP 的请求次数和传输报文的大小 -CSS SPRITE（雪碧图、图片精灵）技术 - 使用字体图标（ICON FONT）或者 SVG 等矢量图；可以减少 HTTP 请求次数或者减少请求内容的大小，使图片渲染的更快：因为他们是基于代码渲染的，而对于位图（png/jpg/gif）是需要先把图片编码再渲染，可以避免图片失真变形；可以使用 webp 格式图片，这种格式要小一些（但要保证服务器端支持这种格式的请求处理） - 图片懒加载（延迟加载）技术；第一次加载页面的时候不去请求真实的图片，将默认背景图替代真实图片进行加载，以提高第一次渲染页面的速度；当页面加载完，把出现在用户视野区域中的图片做真实加载，没有出现在用户页面时的资源先不加载（可以节约流量，也能减少对服务器的请求压力）；数据我们也尽可能分批加载（不要一次请求过多的数据，例如分页技术） - 音视频文件取消预加载（preload='none'），这样可以增加第一次渲染页面的速度，当需要播放的时候再加载 - 客户端和服务器端的数据传输尽可能基于 JSON 格式完成，XML 格式比 JSON 格式要大一些（还可以基于二进制编码或者文件流格式，这种格式比文件传输好很多） - 把页面中的 CSS/JS/图片等文件进行合并压缩：争取 CSS 和 JS 都只导入一个：基于 webpack 可以压缩

浅谈linux性能调优之三:分区格式化之前的考虑

阅读更多关于浅谈linux性能调优之三:分区格式化之前的考虑

上篇：浅谈linux性能调优之二:优化swap分区 http://my.oschina.net/sharelinux/blog/143318 有这么一种特殊情况可能在生产环境下发生：系统的某个ext3文件分区，当用户往此分区上写文件时，提示磁盘空间已满，但用df -h命令查看时发现此分区磁盘使用量是60%，请分析出现这种情况是由什么导致的，答案是inode已经耗尽！为什么呢？给出一个ext*文件系统的结构图在Linux中进行格式化必须考虑Block与inode，Block还好理解，它是磁盘可以记录的最小单位，是由数个扇区组成，所以大小通常为n*512Bytes，例如4K。那么inode是什么呢？ Block是记录文件内容的区域，inode则是记录该文件的属性及其放置在哪个Block之内的信息。每个inode分别记录一个档案的属性与这个档案分布在哪些datablock上(也就是我们说的指针,有的地方也叫索引编号)。具体如下：　　 ● inode 编号　　 ● 用来识别文件类型，以及用于 stat C 函数的模式信息　 ● 文件的链接数目　 ● 属主的 UID　● 最近一次访问的时间 ● 属主的组 ID(GID)　 ● 文件的大小　　● 文件所使用的磁盘块的实际数目　　● 最近一次修改的时间　　　　● 最近一次更改的时间小结：inode两个功能

MySQL查询性能优化

阅读更多关于 MySQL查询性能优化

一、是否查询了不需要的数据 1.多使用limit来分页 2.不要用select *，特别是在多表关联的时候 3.避免重复查询相同的数据，可以多使用缓存二、正确使用索引如何正确使用索引见上一篇文章《MySQL索引》，这里再补充几个索引失效的案例： key(last_name, first_name, dob) 1.select * from blog_user where last_name like ‘%A%’; //使用like时通配符在前 2.select * from blog_user where last_name is null; //is null或is not null会放弃使用索引 3.select * from blog_user where UPPER(last_name) like 'A%'; //对索引列做了函数计算 4.select * from blog_user where last_name like 'A%' or first_name = 'b'; //使用or会导致索引失效，除非or的左右两边都分别正确使用索引。如select * from blog_user where last_name like 'A%' or last_name = 'b'; 5.隐式类型转换 6.隐式字符编码转换创建blog_name表： CREATE

Web前端性能优化

阅读更多关于 Web前端性能优化

Web前端性能优化，应该怎么做？ 0.5922019.08.09 19:17:36字数 890阅读 427 想要成为一名合格的Web前端工程师，Web前端性能优化是一个必须要掌握的知识，那么应该怎么进行Web前端性能优化呢？ 1、CSS精灵 CSS Sprites在国内很多人叫CSS精灵，是一种网页图片应用处理方式。它允许你将一个页面涉及到的所有零星图片都包含到一张大图中去，这样一来，当访问该页面时，载入的图片就不会像以前那样一幅一幅地慢慢显示出来了。对于当前网络流行的速度而言，不高于200KB的单张图片的所需载入时间基本是差不多的，所以无需顾忌这个问题。 2、代码压缩（1）将table改为div布局尽量将table标签布局HTML重构div布局，可以节约至少40%的代码量。由于div代码少于table布局的HTML网页，所以搜索引擎索引权重也优于table布局的HTML网页。（2）缩减精简div、span、ul、li等系列标签布局DIV+CSS网页时候，有时候可以节约一些DIV布局代码，减少代码量。（3）删除多余空格删除多余空格换行，可以有效地压缩HTML代码占用字节，一般在开发完成后可以对HTML中代码进行删除换行和空格内容。（4）表格类型布局时候适当使用table替代div布局如果是本身是表格数据列表排版，我们最好选择table

Javascript 加载性能优化

阅读更多关于 Javascript 加载性能优化

浏览器对javascript的处理主要有2部分：下载和执行下载在有些浏览器中是并行的，有些浏览器中是串行的，如IE8、Firefox3、Chrome2都是串行下载的执行在所有浏览器中默认都是阻塞的，当js在执行时不会进行html解析等其它操作阻塞特性： javascript有个阻塞特性，当浏览器执行javascript代码时，不能同时做其它任何事情。无论当前javascript代码是内嵌还是在外链文件中，页面的下载和渲染都必须停下来等待脚本执行完成。浏览器在下载和执行脚本是进出现阻塞的原因在于，脚本可能会改变页面或javascript的命名空间，它们对后面页面内容造成影响。一、脚本位置浏览器在碰到一个引入外部javascript文件的<script>标签时会停下所有工作来下载并解析执行它，在这个过程中，页面渲染和用户交互完全被阻塞了。例： <html> <head> <title>无标题文档</title> <link rel="stylesheet" type="text/css" href="styles.css" /> <script type="text/javascript" src="file1.js"></script> <script type="text/javascript" src="file2.js"></script> <script type=

SQL 性能优化梳理

阅读更多关于 SQL 性能优化梳理

先简单梳理下Mysql的基本概念，然后分创建时和查询时这两个阶段的优化展开。 1 基本概念简述 1.1 逻辑架构第一层：客户端通过连接服务，将要执行的sql指令传输过来第二层：服务器解析并优化sql，生成最终的执行计划并执行第三层：存储引擎，负责数据的储存和提取 1.2 锁数据库通过锁机制来解决并发场景-共享锁（读锁）和排他锁（写锁）。读锁是不阻塞的，多个客户端可以在同一时刻读取同一个资源。写锁是排他的，并且会阻塞其他的读锁和写锁。简单提下乐观锁和悲观锁。乐观锁，通常用于数据竞争不激烈的场景，多读少写，通过版本号和时间戳实现。悲观锁，通常用于数据竞争激烈的场景，每次操作都会锁定数据。要锁定数据需要一定的锁策略来配合。表锁，锁定整张表，开销最小，但是会加剧锁竞争。行锁，锁定行级别，开销最大，但是可以最大程度的支持并发。但是MySql的存储引擎的真实实现不是简单的行级锁，一般都是实现了多版本并发控制（MVCC）。MVCC是行级锁的变种，多数情况下避免了加锁操作，开销更低。MVCC是通过保存数据的某个时间点快照实现的。 1.3 事务事务保证一组原子性的操作，要么全部成功，要么全部失败。一旦失败，回滚之前的所有操作。MySql采用自动提交，如果不是显式的开启一个事务，则每个查询都作为一个事务。隔离级别控制了一个事务中的修改，哪些在事务内和事务间是可见的

web前端性能优化总结

阅读更多关于 web前端性能优化总结

转自：http://www.2cto.com/kf/201604/498725.html 网站的划分一般为二：前端和后台。我们可以理解成后台是用来实现网站的功能的，比如：实现用户注册，用户能够为文章发表评论等等。而前端呢？其实应该是属于功能的表现。并且影响用户访问体验的绝大部分来自前端页面。而我们建设网站的目的是什么呢？不就是为了让目标人群来访问吗？所以我们可以理解成前端才是真正和用户接触的。除了后台需要在性能上做优化外，其实前端的页面更需要在性能优化上下功夫，只有这样才能给我们的用户带来更好的用户体验。就好像，好多人问，男人在找女朋友的时候是不是只看外表，一些智慧的男人给出了这样的回答：脸蛋和身材决定了我是否想去了解她的思想，思想决定了我是否会一票否决她的脸蛋和身材。同理，网站也是这样，网站前端的用户体验决定了用户是否想要去使用网站的功能，而网站的功能决定了用户是否会一票否决前端体验。不仅仅如此，如果前端优化得好，他不仅可以为企业节约成本，他还能给用户带来更多的用户，因为增强的用户体验。说了这么多，那么我们应该如何对我们前端的页面进行性能优化呢？一般说来，web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有浏览器访问、使用反向代理才、CDN等。浏览器访问优化浏览器请求处理流程如下图： 1、减少http请求，合理设置

webpack 构建性能优化策略小结

阅读更多关于 webpack 构建性能优化策略小结

背景如今前端工程化的概念早已经深入人心，选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配，而在诸多的构建工具中， webpack 以其丰富的功能和灵活的配置而深受业内吹捧，逐步取代了grunt和gulp成为大多数前端工程实践中的首选，React，Vue，Angular等诸多知名项目也都相继选用其作为官方构建工具，极受业内追捧。但是，随者工程开发的复杂程度和代码规模不断地增加，webpack暴露出来的各种性能问题也愈发明显，极大的影响着开发过程中的体验。问题归纳历经了多个web项目的实战检验，我们对webapck在构建中逐步暴露出来的性能问题归纳主要有如下几个方面：代码全量构建速度过慢，即使是很小的改动，也要等待长时间才能查看到更新与编译后的结果（引入HMR热更新后有明显改进）；随着项目业务的复杂度增加，工程模块的体积也会急剧增大，构建后的模块通常要以M为单位计算；多个项目之间共用基础资源存在重复打包，基础库代码复用率不高； node的单进程实现在耗cpu计算型loader中表现不佳；针对以上的问题，我们来看看怎样利用webpack现有的一些机制和第三方扩展插件来逐个击破。慢在何处作为工程师，我们一直鼓励要理性思考，用数据和事实说话，“我觉得很慢”，“太卡了”，“太大了”之类的表述难免显得太笼统和太抽象，那么我们不妨从如下几个方面来着手进行分析：

MySQL · 性能优化 · MySQL常见SQL错误用法

阅读更多关于 MySQL · 性能优化 · MySQL常见SQL错误用法

作者：db匠来源： https://yq.aliyun.com/articles/72501 前言 MySQL在2016年仍然保持强劲的数据库流行度增长趋势。越来越多的客户将自己的应用建立在MySQL数据库之上，甚至是从Oracle迁移到MySQL上来。但也存在部分客户在使用MySQL数据库的过程中遇到一些比如响应时间慢，CPU打满等情况。阿里云RDS专家服务团队帮助云上客户解决过很多紧急问题。现将《ApsaraDB专家诊断报告》中出现的部分常见SQL问题总结如下，供大家参考。常见SQL错误用法 1. LIMIT 语句分页查询是最常用的场景之一，但也通常也是最容易出问题的地方。比如对于下面简单的语句，一般DBA想到的办法是在type, name, create_time字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。 SELECT * FROM operation WHERE type = 'SQLStats' AND name = 'SlowLog' ORDER BY create_time LIMIT 1000, 10; 好吧，可能90%以上的DBA解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时，程序员仍然会抱怨：我只取10条记录为什么还是慢？要知道数据库也并不知道第1000000条记录从什么地方开始

iOS性能优化-预排版

阅读更多关于 iOS性能优化-预排版

参考地址: https://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/ 前面一篇说了异步绘制文字 , 异步渲染图片 ,这篇主要是预排版 ,经过这三种处理之后,基本上已经非常流畅了. 下面的demo就使用了这三种处理来做优化. 我使用的demo是我之前做的一个列表: https://www.cnblogs.com/alan12138/p/9619336.html 下面是优化前的demo地址和效果: github: https://github.com/alan12138/InfoFlow 可以看到滑动很快的时候到最后已经达到33FPS的程度了,当然如果正常浏览不那么快的时候还是没有很大差别的. 下面是优化后的demo地址和效果: github: https://github.com/alan12138/Interview-question/tree/master/3/InfoFlow 可以看到无论如何滑动,基本稳定在60FPS. 因为图片异步渲染和异步绘制文字我上一篇博文已经写过了所以这篇主要写一下预排版. 预排版主要做的就是这件事: 1 dispatch_async(dispatch_get_global_queue(0, 0), ^{ 2 //造一些数据 3 self.feeds =

订阅性能优化