继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

django2入门课程之web开发的一些可优化性能的点

2019-10-14 14:38:504930浏览

deweizhang

1实战 · 19手记 · 4推荐
TA的实战

大家好,很高兴能为大家录制一个 django2入门课程 。(Django入门到进阶-更适合Python小白的系统课程   在学习了django2入门知识之后,是否觉得还有很多似乎还有些意犹未尽呢?的确,在真实的工作中,入门知识只能是一个基础,代表你可以用这些工具干一些事情,但是想把他干好,还需要深入了解这些工具才可以。那么今天,我们在这里讲一讲在工作中如何较为简单的提升我们的服务性能,对于新手朋友来说,我认为还是有一定的帮助的。当然, 如果大家python基础还没有非常牢固,可以先去打基础:神奇的穿越门

一:io的优化

在真实工作中,我们应该尽量避免多次连接数据库,减少对db的io次数。那么如何可以减少对db的io次数呢?缓存层是必不可少的。那么我们知道,缓存数据是存放在内存中,一般来说缓存的容量还是要小于硬盘空间的(土豪公司或个人请自行无视)。那么我们就要有针对性的进行缓存,即:根据内容的重要性进行缓存,并防止缓存穿透(缓存穿透:即用户访问无缓存以至于直接大量io到数据库层,给数据库待在极大的压力),那么如何避免缓存穿透呢?

1:缓存空对象 ,并将本次请求交由队列去完成并更新缓存(有的时候我们请求某些网站的服务会偶尔出现错误或数据为空的情况,但刷新后就恢复了,有很大一些时候是因为这个缓存空对象造成的。等你在请求的时候数据通过队列已经完成了重新缓存,并返回给用户)

2:缓存与数据库采用双写的方式,这样保证了写入既有缓存(当然读写分离也是一个不错的选择)

3:缓存预加载,在上线之前,对一些早已存在的数据,通过pm等分析人员分析,将访问量很大的数据提前进行缓存

这里我们并没有过多 的去说sql的优化,大家有兴趣也可以去看看,就拿我们课上用的mysql来说,单mysql服务中 最大连接数,缓存池等都是可优化的点,大家如果工作中需要自己去部署mysql,也要去关注一下,那么我提到的这两个配置也是最基础简单的,比如连接数越大,肯定能承受的访问量也就越大,当然系统服务是否能支持那么大的链接呢?(可以设置滴~)。索引虽然可以提高查询效率,也不是越多越好。那么在真实的工作中,项目适用于关系型数据库还是非关系型数据库,要非常谨慎的思考。才能让数据库发挥出自己最大的优势。


二:有效利用每一次的数据库连接

1:尽量在每次连接的时候 都可以进行批量的增删改查,这样就可以不至于每次请求只能操作1个数据库信息,达到每次数据库连接利用率最大化。

2:每一次的数据库链接-断开,都会有性能的损耗,那么连接池就是一个不存的选择。


三:高可用,即:分布式的部署

目前的互联网已经是高并发的时代,那么单节点肯定是一个不再适应社会潮流的方式,如果用户量很大,很可能就直接瘫痪了。所以多地分布式部署,可以即可保证提高了同时访问量,也可以保证只要有1台机器存活就可以依然顺利访问。那么目前推荐大家两种分布式的方式:

1:通过阿里云进行分布式部署,阿里云自带分布式的功能,通过把服务部署在阿里云上并进行设置,可以比较好的保证一个分布式的方案

2:通过k8s 部署,k8s(kubernetes)是一个开源的,管理云平台中多个主机上容器花的应用,他提供了应用部署,规划更新维护等多个功能。当然如果你有很良好的运维知识才好,而且有一定的学习成本。

以上也是我经历过的两种方案,我相信还有更多的部署服务的方案,大家也可以互相交流,那么从我的角度来说,哪种部署方案更好呢?我来给大家以我的角度进行一下分析,然后大家可以自己权衡,当然也要看公司的要求:

首先第一种方案阿里云已经自动帮助我们实现了,我们只需要购买功能,设置就好,一切都是傻瓜式操作,前提是需要钱;

那么第二种方案需要一定的运维知识(至少linux要玩儿的很溜吧~),因为部署k8s还是有些难度(至少像我这种不是很喜好运维的开发来说是的~虽说现在devops越来越普及。不过当你理解了k8s的原理后就会觉得并没那么难,但部署的时候可能依然会有很多让你抓头的情况产生)当然有难度不怕,我们可以解决,那么我推荐大家一个工具:rancher,他其实就是一个工具化的k8s,部署与使用起来也更简单。当然从我工作的经验来看,rancher可能还有些小问题,可以等待rancher的开发者们修复并优化,但并不妨碍我们的正常使用。


四:传输数据的大小

简单来说 就是每次请求返回的数据量,那么数据的提及越小,自然效率越高。那么对数据的压缩肯定是必不可少的,最简单的压缩是gzip压缩方式,可以让我们的数据体积进行降低;目前知道的压缩效率最好(或者说非常好的)是protobuf 的形式,那么目前grpc服务都是使用这种传输方式;

除了数据体积的优化以外,如果我们能不传是不是更好呢?(什么鬼?)简单来说如果每次用户请求的数据都是一样的,我们是否可以让前端每次先缓存某接口的数据,并前后端各保留一个id,每次请求的时候后端判断该id是否发生变更(该id代表数据,不同的数据内容id不同)如果没有变更,是不是就不用返回数据了,用户可以直接使用前端已经缓存好的数据。当然还有更多细节需要探究,这里只是抛砖引玉而已。


web开发的道路上还有很多要注意的地方,比如安全等,我们本次主要探讨一些常规的,较为容易的可优化的点,在平时的工作中可以多关注。那么我们今天就先到这里吧~

··································

欢迎关注课程:

《Django入门到进阶-更适合Python小白的系统课程》

  金职位 Python工程师2020版

  

打开App,阅读手记
3人推荐
发表评论
随时随地看视频慕课网APP

热门评论

什么时候能做个关于Django业务流的课程或者介绍就好了

abcdefghij

1234567891

查看全部评论