Web前端、应用服务器、数据库SQL等性能优化总结

2018年9月11日16:49:38 发表评论 5 阅读

对于web应用开发,多数性能瓶颈均出现在数据库上,除了采用分布式架构或云处理(大公司基本上都是),更重要的是平时程序设计时要遵照一些规则,从根本上提高系统的性能,以下总结了一些常用的规则方法,仅供参考,欢迎跟帖补充。。。

1、 把数据、日志、索引放到不同的I/O设备上,增加读取速度。数据量(尺寸)越大,提高I/O越重要。

2、 纵向、横向分割表,减少表的尺寸,如:可以把大数据量的字段拆分表。

3、 根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,尽量使用字节数小的列建索引,不要对有限的几个值的列建单一索引。

4、 用OR的字句可以分解成多个查询,并且通过UNION链接多个查询。它们的速度只与是否使用索引有关,如果查询需要用到联合索引,用UNION all执行的效率更高。

5、 在查询SELECT语句中用WHERE子句限制返回的行数,避免表扫描。如果返回不必要的数据,则浪费了服务器的I/O资源,加重了网络的负担,降低了性能。如果表很大,在表扫描期间将表锁住,禁止其他的联结访问表,后果很严重。

6、 注意使用DISTINCT,在没有必要时不要用,它同UNION一样会使查询变慢。

7、 在IN后面值的列表中,将出现最频繁的值放在最前面,出现最少的放在最后面,减少判断的次数。

8、 一般在GROUP BY和HAVING子句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作,也就是说尽可能在WHERE中过滤数据。

9、 尽量将数据的处理工作放在服务器上,减少网络的开销,如使用存储过程。存储过程是编译、优化过,并且被组织到一个执行规划里,且存储在数据库中的SQL语句(存储过程是数据库服务器端的一段程序),是控制流语言的集合,速度当然快。

10、 不要在一句话里再三地使用相同的函数,浪费资源,将结果放在变量里再调用更快。

11、 针对大量只读查询操作进行优化的方法

Web前端、应用服务器、数据库SQL等性能优化总结

web前端性能优化

Web前端指网站业务逻辑之前的部分,包括:

1.浏览器加载

2.网站视图模型

3.图片服务

4.CDN服务等

主要优化手段有优化浏览器访问,使用反向代理,CDN等。

1.浏览器访问优化

(1)减少http请求

HTTP协议是无状态的应用层协议,意味着每次HTTP请求都需要简历通信链路,进行数据传输,而在服务器端,每个HTTP都需要启动独立的线程去处理,这些通信和服务的开销都很昂贵,减少HTTP请求的数目可有效提高访问性能。

减少HTTP请求的主要手段是:

合并CSS,以及压缩CSS大小合并JavaScript,以及压缩JS大小合并图片将浏览器一次访问需要的JavaScript,CSS合并成一个文件,这样浏览器就只需要一次请求。多张图片合并成一张,如果每张图片都有不同的超链接,可通过CSS偏移响应鼠标点击操作,构造不同的URL。

(2)使用浏览器缓存

对一个网站而言,CSS,JavaScript,Logo,图标等这些静态资源文件更新的频率都比较低,而这些文件又几乎是每次HTTP请求都需要的,如果将这些文件缓存在浏览器中,可以极好地改善性能。通过设置HTTP头中Cache-Control和Expires属性,可设定浏览器缓存,缓存时间可以是数天甚至是几个月。有时候,静态资源文件变化需要及时应用到客户端浏览器,这种情况可以通过改变文件名实现,比如一般会在JavaScript后面加上一个版本号,使浏览器刷新修改的文件。

(3)启用压缩

在服务器端对文件进行压缩,在浏览器端对文件解压缩,可有效较少通信传输的数据量。文本文件的压缩效率科大80%以上。

(4)CSS放在页面最上面,JavaScript放在页面最下面

浏览器会在下载完全部CSS之后对整个页面进行渲染,因此最好的做法是将CSS放在页面最上面,让浏览器尽快下载CSS。JS则想法,浏览器在加载JS后立即执行,有可能会阻塞整个页面,造成页面显示缓慢,因此JS最好放在页面最下面。

(5)减少Cookie传输

一方面,Cookie包含在每次请求和响应中,太大的Cookie会严重影响数据传输,因此哪些数据需要写入Cookie需要慎重考虑,尽量减少Cookie中传输的数据量。另一方面,对于某些静态资源的访问,如CSS,JS等,发送Cookie没有意义,可以考虑静态资源使用独立域名访问,避免请求静态资源时发送Cookie,减少Cookie传输的次数。

2.CDN加速

CDN(Content Distribute Network,内存分发网络)的本质上仍然是一个缓存,而且将数据缓存在离用户最近的地方,是用户以最快速度获取数据,即所谓网络访问第一跳。

CDN一般缓存的是静态资源,如图片,文件,CSS,Script脚本,静态网页等,但是这些文件访问频率很高,将其缓存在CDN可极大改善网页的打开速度。

3.反向代理

传统代理服务器位于浏览器一侧,代理浏览器将HTTP请求发送到互联网上,而反向代理服务器位于网站机房一侧,代理网站Web服务器接收HTTP请求。和传统代理服务器可以保护浏览器安全一样,反向代理服务器也具有保护网站安全的作用,来自互联网的访问请求必须经过代理服务器,相当于在Web服务器和可能的网络攻击之间建立了一个屏障。

除了安全功能,代理服务器也可以通过配置缓存功能加速Web请求,当用户第一次访问静态内容的时候,静态内容就被缓存在反向代理服务器上,这样当其他用户访问该静态内容的时候,就可以直接从反向代理服务器返回,加速Web请求响应速度,减轻服务器负载要。

应用服务器性能优化

应用服务器就是处理网站业务的服务器,网站的业务代码都部署在这里,是网站开发最复杂,变化最多的地方,优化手段主要有缓存、集群和异步等。

网站性能优化第一定律:优先考虑使用缓存优化性能。

缓存的本质是一个内存Hash表,网站应用中,数据缓存以一对Key,Value的形式存储在内存Hash表中。缓存主要用来存放那些读写比很高、很少变化的数据。

二八定律:80%的访问落在20%的数据上

使用缓存需要注意的问题:

把频繁修改的数据放入缓存。容易出现数据写入缓存后,应用还来不及读取缓存,数据就已经失效的情形,徒增系统负担。一般来说,数据的读写比在2:1以上,缓存才有意义。没有热点的访问。 缓存使用的内存资源非常宝贵,只能将最新访问的数据缓存起来,而把历史数据清理出缓存。即缓存资源应该留给20%的热点数据。数据不一致与脏读。 一般会对缓存设置失效时间,超过失效时间,就要从数据库重新加载。因此应用要忍受一定时间的数据不一致。另一种策略是数据更新时立即更新缓存,不过这也会带来更多的系统开销和事务一致性的问题。缓存可用性。 业务发展到一定阶段时,缓存会承担大部分数据访问的压力,数据库已经习惯了有缓存的日子,所以当缓存服务器崩溃时,数据库会因为完全不能承受如此大的压力而宕机,进而导致整个网站不可用。这种情况被称作缓存雪崩,发生这种故障,甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。 解决方式:1、缓存热备(当某台服务器宕机时,将缓存访问切换到热备服务器上。);2、缓存服务器集群缓存预热。 缓存中存放的是热点数据,热点数据是缓存系统用LRU对不断访问的数据筛选出来的,这个过程需要较长的时间。新启动的缓存系统没有任何数据,此时系统的性能和数据库负载都不太好。因此可以选择在启动缓存是就把热点数据预加载好。缓存穿透。 因为不恰当的业务或恶意攻击,持续高并发地访问某一个不存在的数据,如果缓存不保存该数据,就会有大量的请求压力落在数据库上。简单的解决方式是把请求的不存在的数据也放进缓存,其value是null。对应可以考虑的分布式缓存有memcached、redis,降低对数据库的读操作。

数据库SQL性能优化

最后就是考虑数据库端的性能优化,如果访问量巨大,除了sql优化外,还会涉及到分库分表、读写分离、利用数据库中间件来解决(下面架构师系列有讲),这里就不再重复。

1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

select id from t where num is null3.应尽量避免在 where 子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件,如果一个字段有索引,一个字段没有索引,将导致引擎放弃使用索引而进行全表扫描。

5.in和 not in 也要慎用,否则会导致全表扫描,如:

select id from t where num in(1,2,3)对于连续的数值,能用 between就不要用 in 了:

select id from t where num between 1 and 36.对于多张大数据量(这里几百条就算大了)的表JOIN,要先分页再JOIN,否则逻辑读会很高。

7.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有 必要。

8.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连 接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。

9.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

10.尽量避免大事务操作,提高系统并发能力。

hcyaobin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: