`
donlianli
  • 浏览: 336359 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
Group-logo
Elasticsearch...
浏览量:216606
社区版块
存档分类
最新评论

软件系统性能瓶颈真相

阅读更多

请看一个测试:

1、快速排序100次,然后计算排序一次所需要的时间。

 

public QuickSort() {
		long beginTime = System.nanoTime();
		//排100遍
		int b[]=a.clone();
		for(int i=0;i<100;i++){
			quick(b);
		}
		long total = System.nanoTime() - beginTime;
		//18133
		System.out.println("小数组快速排序所需平均时间:" + total/100);
	}

 在我的机器上,大概时间是:

小数组快速排序所需平均时间:18133

 

2、计算使用system.out.println打印一个字符串使用的时间:

  

public static void main(String[] args) {
		long beginTime = System.nanoTime();
		for(int i=0;i<100;i++){
			System.out.println("hello World");
		}
		long total = System.nanoTime() - beginTime;
		/**
		 * 18214
		 */
		System.out.println("平均每次磁盘IO时间:" + total/100);
	}

 打印时间大概是:

  

平均每次磁盘IO时间:18334

 

3、记录从局域网的机器上获取一个数据所需要的时间,我们使用虚拟机的memcached作为测试对象。

  

public class MemcachedTest {
	private MemcachedClient memCachedClient ;
	MemcachedTest() throws IOException{
		memCachedClient = new MemcachedClient(
				new InetSocketAddress("192.168.1.103", 11211));
	}
	
	public static void main(String[] args) throws IOException {
		new MemcachedTest().test();
	}

	private void test() throws IOException {
		long beginTime = System.nanoTime();
		for(int i=0;i<100;i++){
			memCachedClient.get("dfsdf" + i);
		}
		long totalTime = System.nanoTime()-beginTime;
		//计算平均时间,这里抹掉了小数点,平均:516486
		System.out.println("从局域网的memcached取一次数据所需平均时间:" + (totalTime/100));
	}
}

 打印时间:

  

从局域网的memcached取一次数据所需平均时间:528065

 

 

其实测试1是计算机最擅长的操作,通常这个操作在计算机的内存进行,测试2操作其实是一个IO操作,会涉及到一个向显卡写数据的IO,第三个操作,其实是一个网络IO,计算机会向网卡发送一个指令,到另外一条机器接收到命令,最后再从网卡读结果。

最后得出,各时间大概有如下关系:

快速排序≈一次磁盘IO≈1/29memcached所需要的时间。

 

可以看出,系统中一旦发生IO,其所需的时间通常比直接操作内存慢好几百倍,因为一个快速排序,会有好几百次的数据移动和比较。对于经过网络的操作,通常其速度又会比磁盘慢至少一个数量级。

 

尽管现在各种分布式产品很流行,但是这些基础常识,还是应该牢记在心,这样才能够写出高效率,高稳定性的软件。下面是我总结出的代码中几条涉及到性能的几条准则:

一、能够在内存解决的尽量不要访问磁盘,能在本机磁盘解决的,尽量不要访问网络。

二、多线程并发访问程序中,能不共享数据的尽量不要共享(StringBuilder优于StringBuffer);能够使用并发工具类(Atomic相关类,ConcurrentHashMap,CAS等)的,尽量不要使用synchronized。

三、在访问数据库时,对于常用的查询条件一定要建好复合索引。能够不排序的尽量不要排序,如果需要排序的,一定把排序字段提前存好,而不要在查询的时候再计算排序字段。

四、批量优于单个操作,很多产品,比如数据库,memcached等,都有批量及单个操作。在一些任务类中,如果能够批量操作,则优先使用批量接口。

五、某些计算时间长(比如用户要导出大文件)的操作,尽量进行优化。如果系统中必须存在这样的操作,那就用队列来专门解决这些问题,一定要控制系统线程的数量。

 

另外,在项目中,大多数系统的瓶颈可能都在数据库,通常,如果一个系统的用户超过1w,缓存就非常必要了。其实,性能问题,不仅仅出在代码级别,还有可能是在中间件上发生,比如apache的默认配置,就非常不适合大的并发系统,mysql的缓存,oracle的最大连接数等等,甚至前段的JS加载及运行,都可能带来性能问题。精通一些中间件,同样可以提高系统的性能和吞吐量。

 

通常性能都是在用户使用时才被发现,因此,排查问题比较困难。关于他的话题,写出好几本书也阐述不完,在这里,写的标题有点夸张,但是,不可置疑,软件中的IO确实是系统瓶颈很重要的一个原因。

 

 

对这类话题感兴趣?欢迎发送邮件至donlianli@126.com
关于我:邯郸人,擅长Java,Javascript,Extjs,oracle sql。
更多我之前的文章,可以访问 我的空间

 

2
2
分享到:
评论
8 楼 saiyaren 2013-08-05  
Shen.Yiyang 写道
楼主你这套结论适合大型机,把所有的性能都在单机器范围内做好。但是现在的趋势是水平扩展,这种架构下,就不可能像你说的那样各种避免IO,最常见的做法是分离计算和IO,来提升性能。


其实大部分还都是在计算上消耗,IO一般来说瓶颈不大,包括数据库中,IO瓶颈其实一般换架构可以解决,比如SSD,或者内存模型等等,如果是数据库的话,一般操作在WA消耗也不是太大
7 楼 Shen.Yiyang 2013-08-05  
楼主你这套结论适合大型机,把所有的性能都在单机器范围内做好。但是现在的趋势是水平扩展,这种架构下,就不可能像你说的那样各种避免IO,最常见的做法是分离计算和IO,来提升性能。
6 楼 saiyaren 2013-08-05  
donlianli 写道
saiyaren 写道
你的性能瓶颈分析我觉得并不赞同,因为我是专门做性能优化的的,而且是做日访问量PV 在亿级别以上的:
1.前端分析:
一般来说前端分析的话,一般都是计算密集型的,也就是对于CPU的消耗,所以这时候需要分析的瓶颈一般来说,如果CPU没有跑满,但是已经无法处理更多的吞吐,那么一定要分析是否是NET IO遇到了瓶颈,如果NET IO没有瓶颈,那么可能是其中出现了等待过多造成的延迟,一种是增加web server简单的proxy分配多个压力,一种是通过profiler工具分析瓶颈,看消耗cpu的点;
如果是网络瓶颈(NET IO),一般出现在cdn服务器上,这时一般是增加网卡吞吐(一般目前常用的是千兆和万兆网卡),或者看4层负载是否均衡(LVS)

2.后端分析:
如果是数据密集型的,一般问题出现在WA上,比如CDN,这些一般是读的内容加载内存文件系统中(或者自己写个内存文件系统模块),然后持久用SSD
如果是库的话一般来说前端会通过CACHE去进行读的缓存,数据库的瓶颈一般是通过架构修改来进行提升的;

我之前做过一个优化,修改架构后性能提高10倍;

总结:
一般计算密集型的瓶颈点事CPU,一般通过NET IO一起分析
一般存储密集型的分析平静是WA

个人之言,简单的分析,许多细节可能还需要跟踪瓶颈解决瓶颈才是硬道理,上述算法一般不是瓶颈点;

还有就是一般解决瓶颈的也有通过语言解决的如我们目前用的HIPHOP就是把php转换成c++后来转换成了JIT VM

点不同,所以还需要根据每个系统的瓶颈来进行分析提高性能


一看就是很专业的高手,我说的只是从编程方面来说的,文中也说道,性能是一个很复杂的问题。可能你站的高度更高,看到的更全面些吧。


没有没有,只是做了一点点优化方面的东西,有点经验,其实我最近也一直想分析一些分析性能的方式和profiler的工具,这是比较常用的,更深层次一般都是从系统角度和编译角度优化了,那个一般人都不会接触的
5 楼 donlianli 2013-08-04  
saiyaren 写道
你的性能瓶颈分析我觉得并不赞同,因为我是专门做性能优化的的,而且是做日访问量PV 在亿级别以上的:
1.前端分析:
一般来说前端分析的话,一般都是计算密集型的,也就是对于CPU的消耗,所以这时候需要分析的瓶颈一般来说,如果CPU没有跑满,但是已经无法处理更多的吞吐,那么一定要分析是否是NET IO遇到了瓶颈,如果NET IO没有瓶颈,那么可能是其中出现了等待过多造成的延迟,一种是增加web server简单的proxy分配多个压力,一种是通过profiler工具分析瓶颈,看消耗cpu的点;
如果是网络瓶颈(NET IO),一般出现在cdn服务器上,这时一般是增加网卡吞吐(一般目前常用的是千兆和万兆网卡),或者看4层负载是否均衡(LVS)

2.后端分析:
如果是数据密集型的,一般问题出现在WA上,比如CDN,这些一般是读的内容加载内存文件系统中(或者自己写个内存文件系统模块),然后持久用SSD
如果是库的话一般来说前端会通过CACHE去进行读的缓存,数据库的瓶颈一般是通过架构修改来进行提升的;

我之前做过一个优化,修改架构后性能提高10倍;

总结:
一般计算密集型的瓶颈点事CPU,一般通过NET IO一起分析
一般存储密集型的分析平静是WA

个人之言,简单的分析,许多细节可能还需要跟踪瓶颈解决瓶颈才是硬道理,上述算法一般不是瓶颈点;

还有就是一般解决瓶颈的也有通过语言解决的如我们目前用的HIPHOP就是把php转换成c++后来转换成了JIT VM

点不同,所以还需要根据每个系统的瓶颈来进行分析提高性能


一看就是很专业的高手,我说的只是从编程方面来说的,文中也说道,性能是一个很复杂的问题。可能你站的高度更高,看到的更全面些吧。
4 楼 saiyaren 2013-08-03  
性能的东西不是你说的这么简单的,是一个很复杂的分析过程,尤其是分析瓶颈找到最大的消耗点(hot point)才可以解决问题
3 楼 saiyaren 2013-08-03  
你的性能瓶颈分析我觉得并不赞同,因为我是专门做性能优化的的,而且是做日访问量PV 在亿级别以上的:
1.前端分析:
一般来说前端分析的话,一般都是计算密集型的,也就是对于CPU的消耗,所以这时候需要分析的瓶颈一般来说,如果CPU没有跑满,但是已经无法处理更多的吞吐,那么一定要分析是否是NET IO遇到了瓶颈,如果NET IO没有瓶颈,那么可能是其中出现了等待过多造成的延迟,一种是增加web server简单的proxy分配多个压力,一种是通过profiler工具分析瓶颈,看消耗cpu的点;
如果是网络瓶颈(NET IO),一般出现在cdn服务器上,这时一般是增加网卡吞吐(一般目前常用的是千兆和万兆网卡),或者看4层负载是否均衡(LVS)

2.后端分析:
如果是数据密集型的,一般问题出现在WA上,比如CDN,这些一般是读的内容加载内存文件系统中(或者自己写个内存文件系统模块),然后持久用SSD
如果是库的话一般来说前端会通过CACHE去进行读的缓存,数据库的瓶颈一般是通过架构修改来进行提升的;

我之前做过一个优化,修改架构后性能提高10倍;

总结:
一般计算密集型的瓶颈点事CPU,一般通过NET IO一起分析
一般存储密集型的分析平静是WA

个人之言,简单的分析,许多细节可能还需要跟踪瓶颈解决瓶颈才是硬道理,上述算法一般不是瓶颈点;

还有就是一般解决瓶颈的也有通过语言解决的如我们目前用的HIPHOP就是把php转换成c++后来转换成了JIT VM

点不同,所以还需要根据每个系统的瓶颈来进行分析提高性能
2 楼 商人shang 2013-08-03  
本人也是邯郸人。。。。
1 楼 jahu 2013-08-03  
计算结果不正确,
测试二,不仅有io,还有显示时间,
测试三,网络连接时间,你不算进入,比如tpc的三次握手?

相关推荐

Global site tag (gtag.js) - Google Analytics