网站页面小图标怎么做,ui设计培训一般多久,三丰云免费服务器,企业门为什么要建设门户网站前提摘要
首先这个项目是接手的前一任先写的项目#xff0c;接手后#xff0c;要求对项目一些速度相对较慢的接口进行优化#xff0c;到第一个速度比较慢的接口后#xff0c;发现单接口耗时4-8秒#xff0c;是的#xff0c;请求同一个接口#xff0c;在参数不变的情况下…
前提摘要
首先这个项目是接手的前一任先写的项目接手后要求对项目一些速度相对较慢的接口进行优化到第一个速度比较慢的接口后发现单接口耗时4-8秒是的请求同一个接口在参数不变的情况下会出现浮动的时长这种之前我在其他项目里面也遇到过第一种是因为有其他用户在操作其他比较卡的接口时或者导出报表时造成接口卡顿的拥堵这种情况没有办法去排查只能一一把接口优化好速度才能提上来**第二种想到的是检测服务如果服务跑的时候间隔时间较短**然后又有大量的查询之类的可能也会造成整体性能的低下这种可以排查检查服务确实有一分钟跑一次的服务但是查询不大按理来说应该痛点不是在这里 随后对该接口进行优化首先是对数据库查询类的代码进行优化将查询语句一一挑出来之后再放到数据库中去排查查询速度比较慢的查询但是未发现查询比较慢的查询于是就只能先把缺掉的索引先补上在检查数据库查询类的代码的时候发现这个接口存在多次连接数据库查询数据大概有20-30次很明显是个隐患这个地方肯定会有拖累速度考虑到重写的话首先是不熟悉业务流程第二是可能需要花费大量时间所以还是争取在不改变原来的逻辑下去给接口进行优化所以查询多次的问题就先放一放了随后我给重点查询的地方添加上了计时想通过此方法来找出耗时比较明显的查询再针对性的去进行优化
Stopwatch watch new Stopwatch();
watch.Start();
//代码
watch.Stop();
//获取检测时长1
watch.ElapsedMilliseconds
watch.Start();
//代码
watch.Stop();
//获取检测时长2
watch.ElapsedMilliseconds通过Stopwatch很快就发现 整个检测时间下来整个接口跑完都不到200ms我觉得很奇怪既然接口整体完成速度不到200ms为何返回给postman的速度达到了惊人的几秒钟此时我怀疑Stopwatch不准确于是在代码开始前和开始后都加上了datetime.now但是显示时间也很短 猜测1计时不准 猜测2返回json给前端的时候时间耗费了很长 猜测1没有办法求证猜测2其实做了那么多项目其实也没有遇到而且感觉这个接口返回的json也没有那么离谱随后就只能抱着试一试的态度设定了以下几组返回的json以及他们最终测试的结果 第一种 返回原来的json 结果几秒 第二种 返回一个字符串 结果100-200毫秒 第三种 返回原来的json但是减少一些很长的对象 结果几秒 第四种 返回的对象再包一层 结果几秒 第五种 不使用框架的json返回方法自定义json返回方法 结果几秒
很显然第二种的出现让我认为json返回就是接口超时的最大原因这里我只能去猜测 第一种 这里我只能去猜测是不是服务器的内存不够造成的返回json时这么慢 第二种 会不会是c#识别到我没有用上面代码中的参数所以它自己省略了上面一些代码的逻辑直接就返回了字符串但是日志记录到了每个节点的计时而且这个结果跟一直计时的也对的上那就只能往下求证
然后把返回的json最小化这时候就用到了json压缩
后端代码
//data为需要转换的数据
public string GetJsonDataT(T data)
{// 序列化数据为JSONstring json JsonConvert.SerializeObject(data);// 如果需要压缩using (var memoryStream new MemoryStream()){using (var gzipStream new GZipStream(memoryStream, CompressionMode.Compress))using (var streamWriter new StreamWriter(gzipStream)){streamWriter.Write(json);}return Convert.ToBase64String(memoryStream.ToArray());}
}vue
npm install pako
import pako from pako
// b64Data--传入加密的数据进行解密
function unzip (b64Data) {let strData atob(b64Data)// Convert binary string to character-number arrayconst charData strData.split().map(function (x) { return x.charCodeAt(0) })// Turn number array into byte-arrayconst binData new Uint8Array(charData)// // unzipconst data pako.inflate(binData)// Convert gunzipped byteArray back to ascii string:strData String.fromCharCode.apply(null, new Uint16Array(data))return strData
}// 加密
function zip (str) {if (typeof str ! string) {str JSON.stringify(str)}const binaryString pako.gzip(str, { to: string })return btoa(binaryString)
}这种会中文乱码需要改一下let strData atob(拿到的数据)
const charData strData.split().map(function (x) { return x.charCodeAt(0) })
const binData new Uint8Array(charData)
strData pako.inflate(binData,{to: string})
//转换为json对象
ret.data JSON.parse(strData);这样整个压缩就结束了3.2k的字符大概能压到2.几K三分之一吧至于查询速度丝毫没有减少那只能再看看能不能继续减少json中的字符如果这条路行不通的话 1.后面可能会把查询修改为存储过程 2.重构数据结构优化查询频率之类的
整个过程下来其实测试站速度很快慢的也就是正式站但是两个服务器的配置不同这个没法横向比较测试站数据量也没有正式站多而且测试站的服务应该不是一直在跑的
破案了
破案了是上一任小伙伴把一个实体的扩展方法内返回字段的时候做了很慢的查询之前没发现是因为之前只是查询了这张表但是没有用这个字段但是在返回json的时候返回的是整个实体导致它会去拿所有的字段包括扩展类中的那个很慢查询的字段所以会导致看起来好像是json返回很慢的感觉也算是个坑吧
