问题描述
使用控制台程序承载WCF，会影响WCF的并发性吗？
解决方案
解决方案二：
并发一般是指服务器，你做个客户端有啥影响。WCF效率很差。并发更差。IIS本身就是为了简单易用而牺牲了相当大的效率。
解决方案三：
和控制台没有关系，都需要考虑并发。
解决方案四：
WCF出性能问题最常见的情况下，你在客户端看到的异常信息是“超时”异常。当然可能有的人说“遇到超时，那么就增加超时等待时间啊！”，这显然是错误的。因为不合理的超时本身就是不可容忍的错误，怎么能用设置更长的超时时间来欺骗自己呢？！从业务处理上来看，比如说同样是处理“查询某聊天室的n序列号以后的聊天信息”，假设它要访问数据库，可能人家的的程序支持每秒5000个事务，而你的程序可能支持20个事务、再多了就服务超时，这种性能低200倍的坑爹程序有可能是所谓的“并发性”相关的问题，但是这不是WCF造成的，而是你的业务处理程序的设计本身（比如说滥用数据库事务功能）造成的。如果你遇到的是这类性能问题，那么你应该首先解决这类问题。解决了这类与通讯效率无关的问题之后，如果你发现服务器的CPU在特定一分钟里很卡、一旦并发数上到不高的某个水平时系统就遇到了并发业务处理的瓶颈，这个时候你才需要通过更轻量级的通讯方式，让服务并发的数量从200提高到5000以上。因此这个问题那些原本就不需要高并发的人也许感觉不到。相对来说，用控制台来承载WCF或许会比IIS+asp.net来承载相比更“轻”一点。因为WCF不论是用什么东西承载，在.net框架中的部分都一定是通用的，关键是底层是不是架得层次太多、中间处理太多。这就好比如说一个小贩去大超市卖水果，他可能把70%的收入都留给大超式了，自己才得20%不到；而如果他自己找到了合理的更轻量的销售方式，可能他70%的收入都留给自己了，这样他就能投入更多的资金去消灭竞争对手。但是我觉得可能控制台承载跟IIS+asp.net承载的WCF的差别也许不太大。WCF太重、太庞大，你最好使用哪些只有几百行代码的轻量级通讯框架，而不要使用那些有几十万行代码的复杂通讯框架。
解决方案五：
WCF的傻瓜化方式（基本上就是让你少写了序列化/反序列化的几行代码）很适合初学者和业余程序员。有时候，我们使用这种“更多中间环节”的方式，就是图操作起来更傻瓜化。就好像把水果送到大超市一样。
解决方案六：
有时候这跟服务设计的“行业背景”也有关系。比如说我们的某些软件，单个客户端在特定的时候（例如刚刚打开一个基于地图引擎的某个重大业务的专题图时），在同一个瞬间不但要开始下载几十片地图瓦片，而且可能要单独下载至少10几个图层上的几千个小图形的相关业务资料（格式各不相同）。3秒钟内同一个客户端会调用几千次的不同的WCF服务，同时客户端又要进行复杂的绘图渲染，又要求在普通的pc、平板电脑上都有很好的用户体验。这时候，你的测试基线就在这个行业业务水平上。而如果你就是每秒钟才调用一次sql查询，每次返回几十条数据，平均只有不足10个终端在同时发出业务请求。那么这种行业软件大概就可以随便找个实习生来做了。因此你对于什么“影响了并发性”的判断的标准可能就是很不一样的。需要在设计程序之前就很具体地去给出合理的数据（夸大并发性并不是好现象），而不是随便开始编程。
解决方案七：
引用1楼zanfeng的回复:
并发一般是指服务器，你做个客户端有啥影响。WCF效率很差。并发更差。IIS本身就是为了简单易用而牺牲了相当大的效率。
我使用控制台程序承载WCF，WCF对外提供一个服务，多个客户端同时访问这个服务，这些同时发起的请求会是并发处理的吗？WCF效率和并发都很差的话,那有什么更好的替代WCF的方案吗？
解决方案八：
引用2楼caozhy的回复:
和控制台没有关系，都需要考虑并发。
并发肯定是需要考虑的，那么在实际开发中这个并发问题又该怎样具体来操作呢？
解决方案九：
引用3楼sp1234的回复:
WCF出性能问题最常见的情况下，你在客户端看到的异常信息是“超时”异常。当然可能有的人说“遇到超时，那么就增加超时等待时间啊！”，这显然是错误的。因为不合理的超时本身就是不可容忍的错误，怎么能用设置更长的超时时间来欺骗自己呢？！从业务处理上来看，比如说同样是处理“查询某聊天室的n序列号以后的聊天信息”，假设它要访问数据库，可能人家的的程序支持每秒5000个事务，而你的程序可能支持20个事务、再多了就服务超时，这种性能低200倍的坑爹程序有可能是所谓的“并发性”相关的问题，但是这不是WCF造成的，而是你的业务处理程序的设计本身（比如说滥用数据库事务功能）造成的。如果你遇到的是这类性能问题，那么你应该首先解决这类问题。解决了这类与通讯效率无关的问题之后，如果你发现服务器的CPU在特定一分钟里很卡、一旦并发数上到不高的某个水平时系统就遇到了并发业务处理的瓶颈，这个时候你才需要通过更轻量级的通讯方式，让服务并发的数量从200提高到5000以上。因此这个问题那些原本就不需要高并发的人也许感觉不到。相对来说，用控制台来承载WCF或许会比IIS+asp.net来承载相比更“轻”一点。因为WCF不论是用什么东西承载，在.net框架中的部分都一定是通用的，关键是底层是不是架得层次太多、中间处理太多。这就好比如说一个小贩去大超市卖水果，他可能把70%的收入都留给大超式了，自己才得20%不到；而如果他自己找到了合理的更轻量的销售方式，可能他70%的收入都留给自己了，这样他就能投入更多的资金去消灭竞争对手。但是我觉得可能控制台承载跟IIS+asp.net承载的WCF的差别也许不太大。WCF太重、太庞大，你最好使用哪些只有几百行代码的轻量级通讯框架，而不要使用那些有几十万行代码的复杂通讯框架。
引用5楼sp1234的回复:
有时候这跟服务设计的“行业背景”也有关系。比如说我们的某些软件，单个客户端在特定的时候（例如刚刚打开一个基于地图引擎的某个重大业务的专题图时），在同一个瞬间不但要开始下载几十片地图瓦片，而且可能要单独下载至少10几个图层上的几千个小图形的相关业务资料（格式各不相同）。3秒钟内同一个客户端会调用几千次的不同的WCF服务，同时客户端又要进行复杂的绘图渲染，又要求在普通的pc、平板电脑上都有很好的用户体验。这时候，你的测试基线就在这个行业业务水平上。而如果你就是每秒钟才调用一次sql查询，每次返回几十条数据，平均只有不足10个终端在同时发出业务请求。那么这种行业软件大概就可以随便找个实习生来做了。因此你对于什么“影响了并发性”的判断的标准可能就是很不一样的。需要在设计程序之前就很具体地去给出合理的数据（夸大并发性并不是好现象），而不是随便开始编程。
只有几百行代码的轻量级通讯框架都有哪些呢？其中适合于分布式环境的解决方案又有哪些呢？