关于Linux的线程和Windows的线程比较

[lurenfu]

前段时间，在该版有位兄弟发了一篇贴子：http://community.csdn.net/Expert/TopicView3.asp?id=5185751

在该贴子中，楼主在设计网络服务端程序时“为了稳定，不考虑多线程。”
我“对于楼主这句话表示怀疑
如果设计得当，线程一样很稳定，而且性能绝对比多进程要好得多”

楼主随后找出一篇文章来证明他的观点，说linux的线程如何低效。
需要指出的是，楼主给出的那篇文章抱的是老黄历，是linux2.4及以前版本的内核对线程的支持效率不高。
linux的技术是在不断的发展中的，在2.6的内核中对thread的支持也有相当大的改进，最新的线程实现NPTL效率相当高，不信的可以做个验证。

windows xp中执行如下代码，执行结果为：672毫秒左右
我的是windows xp，release版，优化为最快速度

#include <windows.h>
#include <stdio.h>


DWORD WINAPI ThreadFunc( LPVOID *param )
{
return 0;
}


int main()
{
HANDLE hThread;
int i;
DWORD dwBegin, dwEnd;
dwBegin = GetTickCount();
for ( i = 0; i < 10000; ++i ) {
hThread = CreateThread( NULL, 0, ThreadFunc, NULL, 0, NULL );
WaitForSingleObject( hThread, INFINITE );
CloseHandle( hThread );
}
dwEnd = GetTickCount();
printf( "time=%d\n", dwEnd - dwBegin );
return 0;
}


Linux(2.6内核，NPTL线程，我的是FC6)中执行以下代码，执行结果为：275毫秒左右

#include <pthread.h>
#include <stdio.h>
#include <sys/time.h>

void* ThreadFunc( void *param )
{
return NULL;
}

int main()
{
int i;
struct timeval tv1, tv2;
pthread_t tid;

gettimeofday( &tv1, NULL );
for ( i = 0; i < 10000; i++ ) {
pthread_create( &tid, NULL, ThreadFunc, NULL );
pthread_join( tid, NULL );
}
gettimeofday( &tv2, NULL );
printf( "time=%d\n", (tv2.tv_sec-tv1.tv_sec)*1000 + tv2.tv_usec/1000-tv1.tv_usec/1000 );
return 0;
}


各位有条件的请在同一台电脑上测试看看结果如何。

[test2002]

所以，崩溃了，就应该是程序的错吧？cpu不转了，硬盘坏了，主板坏了，也把崩溃说成程序蹦了，呵呵。

发现上面很多同志，总是在比较windows和linux创建进程，线程的快慢，这样比较有意义吗？

谁不知道windows代码是上5千万级别，甚至上亿级别的代码行！！代码多10倍，复杂度何止多10倍捏？？？

在个别领域，linux 快是正常，其实很好理解，复杂度低了，执行的机器码少了，快了点那是当然的，如果要还慢了，那就是代码写得很有问题了。

所以关键看业务有没有慢下来，在windows 下跑的业务sql server2005在高端机器上跑，数据库性能比linux下的oracle在相同硬件配置下速度还快捏，那怎么解释捏。

所以是否快，关键看业务，业务流程序的算法是否高效率。看一些表面的东西，反映不了实际问题。

[test2002]

六年磨一剑
—实测SQL Server 2005

■ 《计算机世界》评测实验室 秦钢


--------------------------------------------------------------------------------



作为微软企业级服务器产品的基础部分，SQL Server产品线从诞生至今才10年多，但最近两个版本的发布时间却相差近6年之久。不过，与SQL Server 2000相比，微软公司对两个月前刚推出的SQL Server 2005的期望值要高得多。

为了适应新的企业应用环境的需求，微软将SQL Server 2005定位成新一代企业数据管理分析平台，它集成了关系型数据库、复制服务、通知服务、集成服务、分析服务（OLAP）、报表服务和管理工具，并且在企业级支持、商业智能应用、管理开发效率等诸多方面均有质的提高，实现了集数据管理与商业智能分析于一体的数据管理和分析平台。

与频繁升级的Windows系统不同，由于已经被吊足了胃口，对于多数现有的SQL Server 2000用户来说，升级几乎是必然的选择。但与此同时，新的SQL Server 2005在性能方面到底有多强就成了用户普遍关心的问题。为了帮助用户了解SQL Server新旧版本在主流服务器平台上的性能差异，我们进行了本次测试。

选择合适的测试方法

在数据库性能测试方面，业界公认的是TPC系列基准测试，各厂商都乐于使用最新的产品在最新的硬件平台上创造新的性能记录，以便将竞争对手的产品挤出排行榜。事实上，在SQL Server 2005正式发布之前，它的测试版已经登上了TPC-H的排行榜首位。由于我们本次测试的目的主要是考察SQL Server 2005在当前主流的硬件平台上运行中小企业主流应用的性能表现，以及新老SQL Server版本之间的性能差异，为此，我们选择使用Nile来作为性能测试的基准应用。

与前些日子成为J2EE和.NET性能之争焦点的PetShop一样，Nile是一个专门为性能测试而产生的虚拟应用。它实现了一个“网上书店”的基本功能，包括用户登录和签出，基于书名、序号和作者的书目检索、分类浏览、购物车等。Nile在最初开发中借鉴了TPC-W的一些思想。多年来，它被逐步发展，并常被微软公司和第三方测试机构用来进行SQL Server的性能测试，尤其是SQL Server和其他竞争对手的数据库产品的比较测试。

我们使用的测试脚本由一个简单查询脚本和一套复合脚本组成。前者执行单次数据库查询操作，侧重于数据库访问的极限性能；后者是我们经过一段时间的监测和优化最终确定的，由12个URL组成，包括了用户登录、基于多种条件查询书目、分类浏览、向购物车添加书目、提交购物车、用户签出等所有的典型操作。各操作顺序完成，无等候时间。这套访问脚本能够比较准确地模拟电子商务网站的真实压力，从而得到比较贴近实际应用的性能基准数据。确定了访问脚本之后，我们使用Avalanche 2500测试仪模拟4000个用户，对Nile应用进行并发访问，Avalanche 2500具有分析返回结果页面的能力，从而能够统计出成功和失败访问请求的数量。为了保证测试结果的准确性，对于每次测试，我们都重复三次，取平均值，并在两次测试之间将系统重新启动。

虽然我们使用的Nile 4.0是最新版本，但它早在2003年就发布了，我们相信微软在不久之后就会发布为SQL Server 2005优化的Nile 5.0或者其他的基准性能测试套件，但在此之前，我们只能拿到为SQL Server 2000优化的Nile 4.0。当然，这样的好处也是显而易见——我们可以由此看到SQL Server 2005对于已有应用的兼容性和性能表现。

Nile的一个重要特点是，它使用几种方式来实现同样的功能，从而方便用户在多种实现机制之间进行比较。Nile 4.0包括ASP和ASP.NET两种实现，由于ASP将淡出Web平台，我们在测试中只使用了ASP.NET版本。

测试结果解读

需要指出的是，使用Nile进行的测试已经有很多，但是各次测试的环境和方法之间往往会存在差异，即使Nile的版本一致，各家使用的客户端工具以及运行的客户端测试脚本也都不尽相同，这造成了基于Nile的测试结果很难使用统一的标准进行判读。只有了解测试的机制，才能理解测试结果的意义。

在本次测试中，我们使用了Nile 4.0版，对其代码没有进行任何修改，但是出于提高查询随机性的需要，我们通过修改数据库生成脚本将其默认的表容量扩大了100倍。测试结果是由横轴为时间线，纵轴为每秒完成的页面数，在其二维坐标系中，蓝色曲线表示尝试请求数，红色曲线表示失败请求数，绿色曲线表示成功请求数。

搭建典型测试环境

我们的测试环境模拟了一个典型的中等规模电子商务网站的配置，可以承受3000-5000个用户同时访问，应用模式为典型的三层架构，使用SQL Server数据库服务器、IIS Web服务器以及 .NET应用服务器。考虑到我们所测试的应用为32位结构，我们在测试中使用的操作系统和各应用也都是32位版本。测试环境包括3台服务器，其中数据库服务器运行在一台华硕AP2400R-E2之上，该平台的配置为双路3.0Ghz Intel至强处理器（800Mhz FSB/1MB L2 Cache/EM64T/超线程）、2GB PC2700 DDR内存、3块Seagate Cheetah 10000RPM 73GB SCSI硬盘，安装了Windows Server 2003企业版。另外两台服务器作为前端Web服务器和.Net应用服务器，两者配置一样，为双路至强2.2GHz（512KB L2 Cache）、1GB内存，由两块Seagate Barracuda 7200RPM 120GB SATA硬盘组成的Raid 0磁盘阵列。在这两台服务器上，我们安装了Windows 2003 Server标准版，并添加了具有.NET支持的IIS应用服务器角色。

由于AP2400R-E2该平台配备了3块SCSI硬盘，为了方便操作，我们使用其中两块硬盘各安装一套Windows Server 2003，然后分别安装SQL Server 2000标准版（加装SP4）和SQL Server 2005标准版，在测试时分别作为第一块硬盘使用，余下一块硬盘用做SQL Server的数据存储。这样做是考虑到我们所进行的测试并不是I/O密集型的，因此不使用RAID阵列也能够提供足够的IOPS（每秒支持的I/O操作数）。

由于三台服务器都配备了双千兆以太网接口，我们将AP2400R-E2的两个网络接口分别接至两台前端服务器，再将两台前端服务器余下两个网络接口连接到一台千兆交换机，同时将Avalanche 2500的一个端口也连接到该千兆交换机。

对于所有的测试平台和应用，我们都没有进行优化，这主要是为了让我们的测试结果具有更强的典型参考意义。除此之外的另外一个原因是，与Linux不同，基于Windows平台的优化对于基准测试来说，得到的性能提升往往非常有限，因为Windows平台在默认状态下就已经被很好地优化了。需要特别指出的是，对于所有的查询请求，我们都使用了随机的请求变量，于是每次请求的返回结果不同。因此，我们没有关闭服务器端的页面缓存。

实战SQL Server

从安装过程来看，SQL Server 2005要比SQL Server 2000复杂一些，因为它集成了更多的功能，此外，.net framework 2.0也成为SQL Server 2005的必备组件。为了避免外围应用和服务影响数据库的运行效率，我们仅启用了数据库运行所必需的组件和服务。

虽然Nile是为SQL Server 2000开发的应用，但是其安装过程对于SQL Server 2005来说一样简单和顺利。

在运行简单查询脚本时，在SQL Server 2005的支持下，Nile每秒能够完成约3310次请求，如图1所示；而在使用SQL Server 2000时，这一数字略有降低，为2960左右，如图2所示。
图1 运行简单查询脚本，在SQL Server 2005的支持下，Nile每秒完成3310次页面请求。 图2 运行简单查询脚本，在SQL Server 2000的支持下，Nile每秒完成2960次页面请求。
图中蓝色曲线表示尝试请求数，红色曲线表示失败请求数，绿色曲线表示成功请求数。


在复合脚本的测试中，两者的性能差距被进一步放大。在使用SQL Server 2005时，平均每秒能够完成约2650次页面请求，如图3所示；而在使用SQL Server 2000时，每秒钟仅能完成约1820次请求，如图4所示。
图3 运行复合脚本，在SQL Server 2005的支持下，Nile每秒完成2650次页面请求。 图4 运行复合脚本，在SQL Server 2000的支持下，Nile每秒完成1820次页面请求。
图中蓝色曲线表示尝试请求数，红色曲线表示失败请求数，绿色曲线表示成功请求数。


在SQL Server 2005正式发布时，微软公布的材料提到:“根据最新的SAP销售和分销三层标准应用基准，运行在惠普和英特尔硬件上的SQL Server 2005和Windows Server 2003实现了创记录的93,000名用户同时使用的性能。这项新的64位处理器基准在2005年11月3日得到认证，比 SQL Server 2000的性能提高了3.5倍，充分显示出SQL Server 2005的企业级计算能力。”而我们的测试表明，在主流的硬件平台上运行已有32位应用时，用户显然无法期望获得数倍的性能提高，但是约10%-40%的提升也算不错。

事实上，如果把这个数据和Linux平台的典型方案做个简单比较，SQL Server的用户会更加兴奋。我们的测试表明，在同样的平台之上安装CentOS Linux 4.2，使用默认配置，运行基于PHP/mySQL的简单数据库查询操作时，性能不及Windows Server 2003/ASP.NET/SQL Server 2005的1/4，经过一系列优化之后，能够达到Windows平台的性能的55%左右，然而在此之后，更进一步的优化则很难奏效。事实上，对于多数诸如用户管理之类的简单数据库应用，mySQL足以胜任，与SQL Server相比占有明显的成本优势，但是如果要运行高负载数据库应用，还是SQL Server更加省钱。

根据我们测试的结果，总的来说，SQL Server 2005比SQL Server 2000的性能确有提高，但提高的幅度好像还不足以令所有的用户满意。相比之下，不少用户一定会觉得还是SQL Server 2005在功能上的进步，以及从32位到64位的延伸更具意义。

（计算机世界报 2006年02月13日 第05期 C12、C13）

[test2002]

http://www.microsoft.com/china/sql/prodinfo/compare/sap/sapad.mspx
----------------------------------------------------
再看SQL SERVER2005 和ORACLE9i的比较

SQL Server在四处理器的SAP性能测试中胜出Oracle
发布日期： 2005年06月20日
据SAP的新结果显示，在相似的配置系统中，在Windows Server 2003上运行的SQL Server 2000胜过在HP-UX上运行的Oracle 9i。 每小时的最高完全处理排列项目达到178,000，SAP认证号码是2005017，而Oracle在这项4路处理器性能基准测试的结果是88,670，SAP认证号码是2004030.

--------------------------------------------
等会再找一个SQL SERVER2005 和ORACLE10i的比较

[naile]

搂主选的在linux下的和在Windows下的multi-thread例子不是很妥当，windows下的使用WaitForSingleObject函数，且使用了INFINITE 参数，程序会在运行该函数时发生阻塞；而linux下的pthread_join函数不会发生阻塞，故这两个例子不能表示windows下的thread效率不如linux,建议将windows下的例子的部分代码改为如下：
HANDLE hThread[10000];
for ( i = 0; i < 10000; ++i ) {
hThread[i] = CreateThread( NULL, 0, ThreadFunc, NULL, 0, NULL );
}
::WaitforMultiObject(hThread,10000, ...);
for (i = 0; i < 10000; i ++)
{
CloseHandle(hThread[i]）；
}
这样的话，相对阻塞的时间少些，可能更能够反映windows下的thread程序的效率。（还望大家点评）

看到楼上很多人讨论thread和process的效率和稳定性，我也忍不住发表一些愚见。
thread的效率比process高，特别是在启动时，是不容置疑的，因为thread是共用一个process下的资源，所以process下的主thread（不知这个名称是否对）在创建其他thread时，不需要为其他thread创建和复制资源；而process是有其独立的资源，父process创建子process时，会将父process的所有资源复制给子process，这个复制过程是需要占用不小的时间和资源的（针对thread而言）。
而multi-process的稳定性比multi-thread高，我觉得也是必然的，process有其独立的资源空间，如果一个process出现问题，不会影响到其他process的资源，所以一般的错误不会影响其他process的运行（当然那些很严重的错误就不谈了）；而multi-thread共用一块资源，当一个thread出现错误时，就会使破坏这块共用的资源，其他thread在使用这块共用资源时，也会出错。
以上只是我的一些愚见，由于能力有限，可能会有错误的地方，还望各位大虾指点。

[playmud]

我现在用win2000,刚才写了半天回复，结果ie出错，所有的相关ie窗口全部关闭.shit！！
这就体现了进程的安全性。
进程一定比线程慢吗？慢在那里？值不值得牺牲一些效率，可靠性优先还是效率优先？
能不能不频繁创建销毁进程/线程？是不是设计有问题？
先发这些再看省得又又又关闭了~

[test2002]

我现在用win2000,刚才写了半天回复，结果ie出错，所有的相关ie窗口全部关闭.shit！！
这就体现了进程的安全性。
进程一定比线程慢吗？慢在那里？值不值得牺牲一些效率，可靠性优先还是效率优先？
能不能不频繁创建销毁进程/线程？是不是设计有问题？
先发这些再看省得又又又关闭了~

-------------------------------
ie是可以一个页面一个进程，但这样好吗？

你的内存很大吗？当然你这个建议也不错，前提条件是又要更新硬件了，

等内存动不动搞过10G的就差不多了。

[lurenfu]

有对于linux设计成和unix一个模样不理解的人，最好了解一下什么是POSIX

有很多人对于linux的无知，导致很多错误的认识，废人虽然话说得尖刻了点，但是正确的

[test2002]

lurenfu(我是你的男佣) ( ) 信誉：100 Blog
对于linux设计成和unix一个模样不理解的人，最好了解一下什么是POSIX

有很多人对于linux的无知，导致很多错误的认识，废人虽然话说得尖刻了点，但是正确的

-----------------------------------------------------------------------------
你不得不承认吧，采用多进程来解决问题的人，一般来说要不是设计有问题，要不就是水平的问题。因为说实在的多进程设计要简单些吧，但效率要低一些，是肯定的吧。

看了有个帖子，说unix(linux)解决网络并发时，对每个socket,直接开进程来管理，居然说稳定效率也不低！真太不可想象了。

MSDN中说连线程的频繁的切换，都是要尽量避免（推荐工作线程=2*cpu个数)，以免影响效率。进程之间的切换效率不是更低吗？

所以搞多进程的设计实际是懒汉做法，只觉得省事，不考虑效率。

[awjx]

有请各位帮我解决一点实际的问题，再回来讨论。

http://community.csdn.net/Expert/topic/5231/5231255.xml?temp=.6468317

[firePhoenix1981]

说一下我遇到的情况。上次在实习的时候，用Apache进行如此开发，用到了多线程。在调试的时候，经常出些莫名其妙的问题，上一行还是好好的，输入个next时一下子就不知道跑到哪去了，当然这也可能是gdb的问题，反正是调得很是郁闷。不过当时用的是2.4，能不能仔细介绍一下2.6下新得机制。记得以前看到的是，linux内核并不直接支持线程，得用线程库，线程对于核心的调度机制是不可见的。现在有些什么改变吗？

[Wolf0403]

>> 而linux下的pthread_join函数不会发生阻塞

引用之前我说过的，

>> 人可以无知，但是无知的时候最好选择沉默。

如果 pthread_join 可以不阻塞，或者可以同时等待多个线程，生活会更美的。

[littlebad_boy]

好贴,继续学习!!

[adream99]

mark

[wolala1226]

to:test2002

早什么呀早，linux前身，其实是unix,unix比windows早吗

===================================================================================

不知道是不是test2002的笔误哦。好像unix是1969年出来的。传说中它是世界上第一个操作系统，不知道是不是我搞错了哈。
占个座，好好向各位前辈学习。

[test2002]

呵呵，是windows比unix早吗

[wanghi]

mark 慢慢看！

[neversoft_0x0000000d]

mark

[mikeandmore]

linux2.4是fork
linux2.6就是新的thread算法，不再clone，只是不够成熟。。。
这是我的记忆。。。

[xmoon1983]

mark 学习。

[BlueTrees]

LZ的测试不公平的。

后者没有closeHandle