一直很迷惑的问题 本帖最后由 liangpei2008 于 2010-01-21 14:34:27 编辑 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 本帖最后由 liangpei2008 于 2010-01-25 17:54:36 编辑 线程的数量不要太多，和cpu的逻辑核心数对应就可以了，这个问题可以用队列解决，就是所有待处理的任务全都放到队列里去，处理一个取出一个，不应该每个任务都建立一个线程，很幼稚的做法，应该是个初学者做的。希望楼主多给点分。 另外没有必要的话不要频繁的加载和卸载dll，纯粹是看计算机太闲了太会那么做， 还是没说到问题的关键，如何解决高并发量的访问！我以前也是用任务队列做的，不过本质一样，也是把资源串行化(DLL)调用，根本起不到应有的作用，我在征集一下有没有其它的架构可以绕开这个问题 那您说一下做为一个业务插件应该如何做，才能使之不频繁加载与卸载dll 运行一个调度程序，它可以开n个线程，分别调用dll这样，就相当于有n个并发的通道了——相当于n个短连接的交易系统 嗯，谢谢:)不过在并发时，还是要进行对DLL内的对象进行同步的，这时DLL调用的瓶颈问题就又出现了。我在想把业务对象放在DLL中会不会是一种错误！ASP.NET好像是将业务代码做成DLL的(对ASP.NET不太熟),人家的并发性怎么搞的，不清楚！ 梁子对。net的并发很满意吗，至少我们现在的系统跟你的模型类似，每个模块都是dll(.net的dll）需要时就加载进来，但不卸载，因为需要多次调用，否则还要重新加载，但是这种模式给我的感觉很不爽 我認為可以定義一個結構，用于記錄常用業務插件。待到加載dll時，搜尋此dll使用狀況（如次數），較頻繁的話，可以適當增加一個引用計數，這樣可避免，一個業務插件使用完之后，就被卸載掉。 应该是我的能力问题,没看得太明白. 哈哈你的消耗是在加载DLL的话， 那 sz_haitao 的方案是可行． 有点想起我在ＪＡＶＡ中做的池． 当然不能完全说一样． 这个方案你解决掉同步的问题，线程间的同步你应该可以搞定的． 用了串行的队列与线程间的同步，你可以测试下效果． 不同的业务我觉得结论不一定能相同． 小弟愚见． 听各位老师继续讲课． 梁子对。net的并发很满意吗，至少我们现在的系统跟你的模型类似，每个模块都是dll(.net的dll）需要时就加载进来，但不卸载，因为需要多次调用，否则还要重新加载，但是这种模式给我的感觉很不爽------------为什么不爽? 因为处理者（1个或n个）肯定是比请求者（100个）少，所以肯定有一个并行转串行的过程只是多个线程（n=5），相当于是100个并行转为5个并行，比原来的100个并行转为1个“并”行 要效率高至于每个dll的处理会互相影响，那应该可以通过互斥避免，如果完全无法避免，那的确还是1个“并”行了，与n无关了 1.我认为DLL插件可以换成service application，这样即可实时监控用户请求。并在Service application根据业务类型分成不同线程处理。2.除了改为service外，我觉得还应该加入MQ，这样你的并发处理速度还会提高，每个部件要异步工作。 COM+在需要时才会激活，并且不需要时，应该及时“去活”。既然线程排队等待现象严重。所以会导致COM+对象不能释放。 COM+对象“去活”不了，对象池什么就不能充分利用。 另外。COM+对象不知道是不是支持事务的，如果带事务，可能导致事务被“传递”到另一个COM+对象，不能及时的“去活”，资源或许会被锁定，并且不能及时释放。 根据你所展示的结构图，我建议你目前还是不要做接近底层的工作，你那样的设计思路做上层应用都有点勉强。服务类的系统由于注重响应速度，需要根据特定的目的专门定向设计，其耦合性一般就较高，设计难度也大，设计人员必须具备底层平台的专业知识，且能准确理解业务的特殊性，方能设计出匹配的高效方案。而应用类的系统较注重业务扩展性和灵活性，所以一般要求耦合性较松散，设计也就更人性化。不过虽然人性化程度有了一定提高，也不能完全放弃性能的考量，保证灵活性的同时以合理的体系架构获取基本的性能也是至关重要的。而我感觉你的整个设计完全按照自己的主观想法，未遵循起码的体系规范，居然出现不停加载同样的DLL情况，简直不能想象，直观上看就是临时在拼凑一个应用，何况是在做服务端。所以你要说如何优化，我无从下手，完全不相关的东西没有改正空间的。 如果对象的创建比较耗费时间，对象池是很有用的。否则没什么意义。如果数据处理比较耗时，还是用一种“分开”处理的方式比较好。图片前面的COM+对象还看不出具体的意义。 １.不明白为什么要在COM+对象内用多线程？２.XML数据有多大？处理XML数据的可能是瓶颈。３.有时候效率和软件的扩展是相互制约，相互矛盾的。构架的复杂化会影响效率。效率优秀，构架越简单越好。４. “，还要去proxy层把DLL中的对象反序列化，生成SQL，再给DATABROKER，来执行SQL,会不会是这个过程太复杂了 ”： 如果数据多的话，反序列化也是耗费时间的地方。 另个。生成SQL的功能是不是用一个单独的COM+对象来生成。也就是处理数据和根据数据来生成SQL分别对应不同的业务对象。 5个线程，它们的dll应该加载后一直被线程持续使用的，避免释放和重新加载的开销线程或dll如果需要数据库操作，应该也建一个数据库连接池，预先连好，每次拿空闲的来使用，用完设为空闲，也避免断开和重新连接的开销线程池和数据库连接池，关键都是池成员之间的独立，互不干涉现在，后台应用服务，我一般直接做成isapi，直接由iis来调用；客户端是win32或浏览器，全部通过http来请求少了很多通信的实现工作，iis本身对isapi也有一定的管理机制 DLL插件那个功能多，需要更细的拆分，举个例子，就好象超市一样，你那个DLL又管收货，又管把货物摆到货架上，完成了整个处理，拆分更细一点：DLL插件只管收消息，其它的DLL进行消息处理。类似接收队列、处理队列等，多队列能加快处理速度，另外IO操作也可以单独出来。配合多线程、数据缓存、DLL静态加载在提高数据吞吐量上会比较明显。单独使用一种措施是不行的，需要多种措施配合起来用。从结构示意图上推理不出细节，需要根据细节做优化处理 拜见高人.建议楼主抛弃设计,从main()开始编码,系统上线后分析瓶颈,酬情重构. 你的DLL业务组件每次都要重新生成待执行的SQL语句的话，效率当然不高。建议把动态生成的SQL转为数据库服务器上存储过程，你的DLL只用从提交的xml中提取出业务对应的存储过程需要的输入数据。原始的T-SQL语句相当于高级语言编写的程序代码，而存储过程相当于已经编译通过的可执行脚本，在高并发的情况下后者的执行效率可以提高不少。另外，我个人并不喜欢使用xml来跨平台传输数据，越大的系统,越多的并发数,越不看好它的性能。因为xml里面荣誉的数据太多，而且每次解析xml都要花费额外的cpu开销.最后，如果业务规则很多的话，强烈建议不要只用一个DLL来实现所有的业务规则。建议把业务规则按耦合度分开成几个模块，耦合度高的业务规则共用一个DLL，把你结构图中的一个大的DLL分解成多个相互独立的小DLL，一个业务请求过来只用到其中的某个或某几个小DLL即可。 我是一直反对xml的，不仅仅是冗余，而且它的结构决定了它的解释是一件开销不可忽略的事情了（生成xml反倒不算太痛苦）一直建议以ini取得xml（变通的ini可以描述xml能描述的一切，而解释ini是非常低开销的） 谢谢sz_haitao以后尝试着使用INI 關于返回值是對象的問題 用登陆窗口进去之后调用主窗口,然后主窗口再调用另一个窗口Show 关于fastreport的问题 单元初始化代码什么时候被执行的？（initialization） 读取文件以后如何显示？ 图像与文字的叠加 请问：wm_nextdlgctrl编译通不过，为什么？？ 各路神仙，千万过来看看！ 我第一次做多层数据库的开发。有个问题不明白？象请教高手！一定给分！ 第十期的程序员出了吗? 给出一个文件的Url地址，下载到指定目录，不要有下载对话框 如何让打开的文件显示乱码?
这个问题可以用队列解决，就是所有待处理的任务全都放到队列里去，处理一个取出一个，不应该每个任务都建立一个线程，很幼稚的做法，应该是个初学者做的。
希望楼主多给点分。
我以前也是用任务队列做的，不过本质一样，也是把资源串行化(DLL)调用，根本起不到应有的作用，我在征集一下有没有其它的架构可以绕开这个问题
这样，就相当于有n个并发的通道了——相当于n个短连接的交易系统
不过在并发时，还是要进行对DLL内的对象进行同步的，这时DLL调用的瓶颈问题就又出现了。我在想把业务对象放在DLL中会不会是一种错误！
ASP.NET好像是将业务代码做成DLL的(对ASP.NET不太熟),人家的并发性怎么搞的，不清楚！
------------为什么不爽?
只是多个线程（n=5），相当于是100个并行转为5个并行，比原来的100个并行转为1个“并”行 要效率高
至于每个dll的处理会互相影响，那应该可以通过互斥避免，如果完全无法避免，那的确还是1个“并”行了，与n无关了
2.除了改为service外，我觉得还应该加入MQ，这样你的并发处理速度还会提高，每个部件要异步工作。
服务类的系统由于注重响应速度，需要根据特定的目的专门定向设计，其耦合性一般就较高，设计难度也大，设计人员必须具备底层平台的专业知识，且能准确理解业务的特殊性，方能设计出匹配的高效方案。而应用类的系统较注重业务扩展性和灵活性，所以一般要求耦合性较松散，设计也就更人性化。不过虽然人性化程度有了一定提高，也不能完全放弃性能的考量，保证灵活性的同时以合理的体系架构获取基本的性能也是至关重要的。
而我感觉你的整个设计完全按照自己的主观想法，未遵循起码的体系规范，居然出现不停加载同样的DLL情况，简直不能想象，直观上看就是临时在拼凑一个应用，何况是在做服务端。所以你要说如何优化，我无从下手，完全不相关的东西没有改正空间的。
２.XML数据有多大？处理XML数据的可能是瓶颈。
３.有时候效率和软件的扩展是相互制约，相互矛盾的。构架的复杂化会影响效率。效率优秀，构架越简单越好。
４. “，还要去proxy层把DLL中的对象反序列化，生成SQL，再给DATABROKER，来执行SQL,会不会是这个过程太复杂了 ”： 如果数据多的话，反序列化也是耗费时间的地方。 另个。生成SQL的功能是不是用一个单独的COM+对象来生成。也就是处理数据和根据数据来生成SQL分别对应不同的业务对象。
线程或dll如果需要数据库操作，应该也建一个数据库连接池，预先连好，每次拿空闲的来使用，用完设为空闲，也避免断开和重新连接的开销线程池和数据库连接池，关键都是池成员之间的独立，互不干涉现在，后台应用服务，我一般直接做成isapi，直接由iis来调用；客户端是win32或浏览器，全部通过http来请求
少了很多通信的实现工作，iis本身对isapi也有一定的管理机制
拜见高人.
建议楼主抛弃设计,从main()开始编码,系统上线后分析瓶颈,酬情重构.
我是一直反对xml的，不仅仅是冗余，而且它的结构决定了它的解释是一件开销不可忽略的事情了（生成xml反倒不算太痛苦）
一直建议以ini取得xml（变通的ini可以描述xml能描述的一切，而解释ini是非常低开销的）
以后尝试着使用INI