互联网系统性能优化方向

之前弄过一个门户系统,其最初每天只有几百个用户会访问使用,后来在公司业务各种推广后,这个门户系统在最高峰的时候,每秒并发1000,

而在这期间,进行了许多分析和优化,作以此文记录。

本文将从代码层面,硬件层面进行分析

代码层面:

许多业务系统性能不够,其在代码层面其实有很大的优化空间。

例如一个对常用业务进行分析,很多时候,我们开发这个功能的时候,并没有考虑到其性能,尤其是在当初功能急着上线的时候,这类只实现功能,却性能比较差的模块,到处都是,面对庞大的功能模块,我们如何定位是哪里消耗时间最多?

这个时候,我们可以用最古老的方式,打印时间,通过对常用业务流程,进行记录进入代码的时间,和离开此段代码的时间,就可以得出业务执行消耗的时间。一般超过5秒才执行完的业务就要仔细分析,CPU的处理业务能力的很强的,如果一段逻辑需要处理5秒,就得考虑这个模块是否存在优化空间,可以从业务场景去分析,例如如下的场景:

1.此模块频繁对数据库进行IO

分析是否有相关属性值可以预存到内存中,而不用每次都从数据库去获取。

2.是否有些业务并非需要实时

许多业务,只是为了更新数据库做记录,类似场景不需要实时去处理,可以考虑延时处理。即弄个定时器,每次数据过来,先存在缓存,一定时间再存回数据库。

3.代码是否写的性能低下

如果一段简单的功能,当初实现时可能只为了赶时间,可能会写的复杂离谱,可以考虑重新写过,尽量减少多层循环。

4.功能剥离

有些高并发的场景,可能只是一个特殊的场景,如抢红包功能,每天只是某个时候,特别多人前来,可以考虑将这个功能单独抽离出来,这样即便红包出现严重高并发,对原系统都不会什么影响。

5.恶意攻击:

如果一个系统有金钱派送,可能会有许多羊毛党通过一些恶意刷工具,进行攻击套利,这个时候需要考虑能否从业务场景去限制流量,或者对用户进行拉黑处理,终究不能因小失大。

关于代码层还有很多优化空间,前面只是列举了大方向。真正对于系统的优化,还需要具体问题,具体分析。

硬件层面:

如果对于代码层的优化已经达到无能为力的时候,硬件层还是需要扩展,终究你不能在一台小霸王机器上运行windows。

集群的方案在网上已经有相当多了,这里就不说什么,只是提醒各位,在对硬件进行集群升级的时候,原来代码层面还是有许多地方需要考虑更改,例如写在内存的变量和定时任务等等这些。