线程的上下文开销真得那么厉害吗(2)?
2006-01-07 23:04
351 查看
线程切换的开销的确是比较厉害的。这是从今天的实验中得出的结果。
为了解决上次提出的疑问,今天在实验室做了一个试验,来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响,所以,具体的测试环境就不提了,只要每次实验在同等的条件下即可。
首先,在MQ的Server端启动100个读线程,100个写线程,100个消息deliver线程,客户端同时启动100个发送者,100个接收者,对4个queue进行不断发送1K大小的消息,测试结果为大约每秒可以发送&接收600个左右的消息。而此时客户端的cpu消耗大概在80%左右,服务器端的cpu消耗在100%,但是线程切换大概占了30%左右。也就是说,只有70%的cpu用于消息的处理。
接着,在MQ的Server端启动10个读线程,10个写线程,10个消息deliver线程,客户端同时启动100个发送者,100个接收者,对4个queue进行不断发送1K大小的消息,测试结果为大约每秒可以发送&接收800个左右的消息。此时客户端的cpu消耗一般在90%以上,服务器端的cpu消耗在100%,而线程切换大概占了10%左右。也就是说,有90%的cpu用于消息的处理。
随后,又对server端采用4个读写线程、消息deliver线程,以及20个,50个等不同线程数进行了测试,测试结果都没有优于10个线程数的情况。
所以,可以得出结论,对于单cpu的情况,线程的切换的确会带来相当大的开销。今天的测试结果同时也表明了JTangMQ在100个发送者,100个接收者的情况下已经比JBossMQ每秒多发送&接收100个消息,而在400个发送者,400个接收者的情况下,发送速度比JBossMQ多出几十个,接收着少了几十个,总体性能已经相当。当然,在发送者&接收者数目较少的时候,性能明显优于JBossMQ。所以,接下来的目标是在多发送者&接收者的条件下,超过JBossMQ,做到性能的全部提升。
为了解决上次提出的疑问,今天在实验室做了一个试验,来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响,所以,具体的测试环境就不提了,只要每次实验在同等的条件下即可。
首先,在MQ的Server端启动100个读线程,100个写线程,100个消息deliver线程,客户端同时启动100个发送者,100个接收者,对4个queue进行不断发送1K大小的消息,测试结果为大约每秒可以发送&接收600个左右的消息。而此时客户端的cpu消耗大概在80%左右,服务器端的cpu消耗在100%,但是线程切换大概占了30%左右。也就是说,只有70%的cpu用于消息的处理。
接着,在MQ的Server端启动10个读线程,10个写线程,10个消息deliver线程,客户端同时启动100个发送者,100个接收者,对4个queue进行不断发送1K大小的消息,测试结果为大约每秒可以发送&接收800个左右的消息。此时客户端的cpu消耗一般在90%以上,服务器端的cpu消耗在100%,而线程切换大概占了10%左右。也就是说,有90%的cpu用于消息的处理。
随后,又对server端采用4个读写线程、消息deliver线程,以及20个,50个等不同线程数进行了测试,测试结果都没有优于10个线程数的情况。
所以,可以得出结论,对于单cpu的情况,线程的切换的确会带来相当大的开销。今天的测试结果同时也表明了JTangMQ在100个发送者,100个接收者的情况下已经比JBossMQ每秒多发送&接收100个消息,而在400个发送者,400个接收者的情况下,发送速度比JBossMQ多出几十个,接收着少了几十个,总体性能已经相当。当然,在发送者&接收者数目较少的时候,性能明显优于JBossMQ。所以,接下来的目标是在多发送者&接收者的条件下,超过JBossMQ,做到性能的全部提升。
相关文章推荐
- 线程的上下文开销真得那么厉害吗(1)?
- java多线程之:创建开启一个线程的开销
- ASP EF框架,数据库操作类(上下文类)的实例创建,线程内唯一对象(HttpContext)
- Java类加载器之线程上下文类加载器(ContextClassLoader)
- 使用request.getContextPath()可以获得上下文资源, 那么什么是上下文资源? 使用上下文资源有什么作用?
- [转]线程上下文类加载器
- 进程、应用程序域、上下文及线程之间的关系
- linux进程、调度、线程、进程上下文等几点理解
- 如何向其他线程的地址空间中注入代码并在这个线程的上下文中执行之
- 两个线程并发执行以下代码,假设a是全局变量,那么以下输出___哪个是可能的?
- 熊猫烧香真的那么厉害吗?我看是你们的安全意识太差了吧!
- 223_尚学堂_高淇_java300集最全视频教程_JVM核心机制_线程上下文类加载器_web服务器类加载机制_OSGI技术模块开发原理介绍
- 任意线程上下文
- 线程锁的开销时间
- EF(Entity Framework)发生错误”正在创建模型,此时不可使用上下文“的解决办法。 正在创建模型,此时不可使用上下文。如果在 OnModelCreating 方法内使用上下文或如果多个线程同时访问同一上下文实例,可能引发此异常。请注意不保证 DbContext 的实例成员和相关类是线程安全的。 临时解决了这个问题,在Context的构造函数中,禁用了自动初始化:
- 正在创建模型,此时不可使用上下文“的解决办法。 正在创建模型,此时不可使用上下文。如果在 OnModelCreating 方法内使用上下文或如果多个线程同时访问同一上下文实例,可能引发此异常。请注意不
- 怎么理解线程使用而不拥有资源?为什么进程切换的开销比线程切换大呢?
- 异常信息:CLR无法从COM 上下文0x645e18 转换为COM上下文0x645f88,这种状态已持续60秒。拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积
- EF上下文对象创建之线程内唯一
- 使用线程上下文类加载器加载class