企业注册资本,seo网站改版,百事通做网站,建筑规范app上一篇谈了谈简单的前端的优化#xff0c;这次就以下几点谈谈后端的优化。
书写时常见的。
循环里面不要走IO流。 走IO#xff0c;是要对硬盘进读写操作的。就结论而言#xff0c;硬盘的读写速度是低于内存的#xff0c;比如说硬盘上读一次数据#xff0c;需要1秒#…上一篇谈了谈简单的前端的优化这次就以下几点谈谈后端的优化。
书写时常见的。
循环里面不要走IO流。 走IO是要对硬盘进读写操作的。就结论而言硬盘的读写速度是低于内存的比如说硬盘上读一次数据需要1秒内存里读一次数据需要0.1秒。那么如果对应的步骤执行10次、100次从硬盘读取数据的时间就会成倍的增加。 常见的IO操作如Excel的编辑、mysql的读取。善用多线程。 这是由上述的情况延伸出来的。实际的开发工作中确实有不得不进行循环中读写IO的情况发生。而硬盘的读写会导致当前的线程阻塞从而影响接口的执行最后导致前端因为等待接口的返回而卡死。 这里我们不去管前端对于接口超时怎么处理。如果说因为读写IO导致当前线程阻塞把这个需要耗费大量时间的任务单独分一个线程去处理让主线程继续执行并反馈结果是一种常见的解决方式。循环的嵌套不要太多。 这个大家都知道比如我有两个长度为100的数组A和B。如果循环是这样。
int[] a new int[100];
int[] b new int[100];
for(int i 0 ; i a.length; i ){for(int j 0; j b.length; j ){System.out.println();}
}这相当于打印执行了10000次。但是如果换成这么写
int[] a new int[100];
int[] b new int[100];
for(int i 0 ; i a.length; i ){}
for(int j 0; j b.length; j ){}两个循环加起来的处理也不过200次。 4. 编写时尽量小循环套大循环 这种情况多见于遇上条件处理的情况。比如
int[] a new int[10];
int[] b new int[100];
for(int i 0 ; i a.length; i ){for(int j 0; j b.length; j ){if(j 10){break;}}
}如上述例子如果j等于10 的时候结束当前的循环。这样实际执行的循环次数会小很多。
实际工作中常见的。
结合公司的技术架构和业务做出取舍。 很多公司实际的并发量并不大服务器也只是单台。但是这种情况下有一种为了技术而技术的情况发生例如只有一台服务器还要整什么分布式、负载均衡。这种说实话多余的依赖反而会增加硬件的负担。因此本着够用就行、留量应急的原则应该去掉那些不必要的依赖。多思考尽可能把手头的技术在业务中用到极致。 很多东西的设计都是在过程中才发现不是很适合。这种情况下应该好好分析一下业务。比如说大数据看板在需求上看大致上是有实时性要求或者没有实时性要求的。这里用没有实时性要求的来举例。 一般来说一个b/s架构的软件服务都是客户端发起请求到服务端然后服务端去数据库里面逛一圈拿到数据最后在响应到客户端。但是如果对实时性要求并不高的又不方便直接存在前端的完全可以提前把这种数据存一份。需要的时候去取并根据具体的业务比如定时器每天24:00执行一次更新。
