ASP.NET Core 2 High Performance 读书笔记,6~7章(网络和io性能优化)

解决网络性能

互联网协议

TCP/IP

TCP/IP协议不用多说,学过网络课程的基本都知道是啥,但这部分的优化主要是系统层面做的。
主要还是端到端之间,如何减少握手次数与传输量。
握手次数主要是指两个服务器之间tcp的建立连接时,需要进行三次确认的应答。
而传统意义上的http请求,都是短连接,每次http请求的时候,都创建一个新的tcp请求。
而Http 1.1协议更新后,增加了一个 Keep-Alive 头信息。就是告诉浏览器告诉服务端,咱们这次连接发完后,别急着关Socket,再等等,我可能还会再发其它的http请求。
现在的web服务器,基本上都实现了http 1.1协议,多次http请求造成tcp多次三次握手的情况会少很多。
那么,这意味着,之前的web优化里说过的,.js和.css文件重量保持在5个以内的优化措施,可以放宽一些限制了。
至少,建议吧.js的数量可根据实际情况,放宽到5个,也就是一些独立的三方库文件,独立出来不会有什么坏处的。而且,目前的网络环境已经相当好,就算是手机,也普及了4G网络,流量和连接速度都不是什么太大问题,只要你的前端包不是太bt,那么分文件比合并文件要好。当然也不能走极端,说可以分,你就分出几十个文件出来。

加密

简单说,加密就是让你的站点通过ssl加密实现https传输。
现在google浏览器新版本已经说了,如果你的网站不支持ssl,那么会将你的站点标记为不安全。
这部分配置也都是系统层面的,与.net关系不大。
你可以在nginx里配置ssl证书,后端的.net core里,配置可以维持原样。
当然。理论配置ssl会让你的网站变慢一点点。嗯真的只是一点点,这点对于他的好处,我们还是忽略掉吧

HTTP/2

好像该说的上面都说过了

WebSockets

未来,使用websockets的情况会越来越多。不过一般来说,在.net下直接用的不多,微软有一个解决方案:SignalR。当浏览器有WebSockets的时候,优先使用WebSockets,如果没有,则利用HTTP的长连接机制。

压缩

http的压缩,现在业内基本上都支持gzip了,而且配置方面,可以在nginx层面做配置,在nginx后面的asp.net core就可以忽略这个配置了。
默认gzip使用deflate算法,也就是哈夫曼算法的变形。谷歌在15年又发布了brotli算法,https可以开启,chrome49之后的版本支持。它可以提高html的压缩比,理论上比deflate增加20%的压缩密度,而压缩和解压速度没太大变化。如果不考虑ie浏览器,并且已经上https链接的项目,可以考虑把gzip的算法改为br。

打包和压缩文件

打包就是把多个js或者css合并成一个文件。
压缩文件不是指gizp,而是指把js,css里的空格,注释等内容删除。
总之这两个压缩方式已经是常见的处理方法了。

图像优化

没什么好介绍的了,无非是在jpeg和png里选择合适的文件格式,并且根据实际需要减小图片的尺寸。
对于Icon的图片,尽量合并成一张图片,通过css的方式显示。
这方面的优化需要根据实际的项目来进行处理的了。

缓存

浏览器缓存

这个,相关介绍的blog很多,书里也没特别的加强介绍,大家各自找网络文章看看。

服务器缓存

代理服务器的缓存

指的是Nginx这个层面开启缓存的配置,这样一些请求就直接返回给用户,而不会请求服务端。

CDN

CDN是代理服务器缓存是一样的,也是一个中间层的缓存,不过,他的好处是,它离用户很近,所以速度会很快。当然,开启CDN是要额外花钱的。如果只是单纯的网页与数据价格还不是大问题。如果你的应用是图片和视频,特别是大流量的视频,你会相当心痛的。

优化I/O性能

输入/输出分类

文章里主要介绍输入输出设备自身的性能问题与优化途径,加缓存等,不属于设备的优化的方案,属于外挂手段。

磁盘

这个是最最最常用的设备,目前来说,分为HDD和SSD,两者的性能差都不用多说了,价格在10:1,性能大约是1:5,不过,在相同价格下,用HDD组Raid的性能也不会比SSD差,安全性上比SSD要可靠一些。不过文件的随机读写,HDD还是要比SSD差一些。如果你是土豪,可以用SSD组RAID,性能会飞上天的哦。不过就从整体架构来说,SSD用于系统盘,与业务数据存储,HDD来放大数据与历史数据。

虚拟文件系统(Virtual filesystems)

目前的的互联网应用都是上云的系统,很少有自己部署独立主机的了。而用云服务器就不可避碰上虚拟文件系统。基本上就是在物理设备上又套了一个软硬盘,性能会下降一些。但更主要的是,云服务器会涉及到多租户同时操作io的情况,这样不可避免的会导致磁盘的延迟等待情况。

碰上这样的性能问题,你也只能干着急了,唯一内做的就是在创建云服务器的时候,将服务器的磁盘设置为高效磁盘(SSD),贵点,好歹可以让性能不要延迟太多。

API

一般都是指调用三方或者自己设计的API,性能影响的因素很多,基本上就是网络环境与首次访问延迟了。优化的重点也就在这两点上。

网络诊断工具

PING 啥,不懂,真的不懂

Tracert 路由追踪

Nslookup 域名查询工具

性能解决方案

批量化API请求

书中介绍的例子不一定实用,但大家都如果上方的api都能方便的批量化调用,那系统设计起来就简单很多了。
当然另外一种方案是.net下的异步调用,能在一定程度上,优化你的整体api调用效率。

数据库

主要是改变代码,减少代码请求返回的量与批量化处理。

数据库自身的优化,就是对表加索引,这个得根据具体情况具体分析了。好在很多数据库工具都提供了相关的检测工具,可以让你看到当前,最近的比较忙的查询请求。

数据库调优的问题,可以单独出书了,但更多的是实践的时候解决,除非是极大的表,很多的问题其实都是程序员偷懒,不愿意花时间优化sql语句有关。

«   2023年9月   »
123
45678910
11121314151617
18192021222324
252627282930
网站分类
文章归档

Powered By Z-BlogPHP 1.6.5 Valyria

Copyright csharptools.cn Rights Reserved. 桂ICP备17007292号-1