插件系统中跨域调用的性能和“一个简单的性能计数器”的使用

系统大概的流程如下:从数据中心接收到数据包(1万~3万(个)/秒,使用WCF)可以被不同的应用场景使 用,每个应用场景的业务逻辑各不相同,而每个场景的接收数据包部分的代码是相同的,于是使用一个容 器将所有的"应用场景的dll"通过反射加载,同时容器接收所有的数据包并把他们分发给"应用场景的dll" ,接收数据的功能,自然被抽象成了Interface。透彻一点讲就是一个插件系统,只不过这个插件有点儿 大而已,大到整个系统都是个插件。这个容器我们暂时叫他“引擎”,而这个"场景的dll"我们暂且叫他 “规则”。

我的理想做法是:每一个规则(一个或多个dll)都单独放在一个文件夹下面,并且有自己的配置文件 。当引擎启动的时候,根据引擎的配置为每个规则创建一个新的AppDomain,并且还为该AppDomain设置配 置文件,同时让这个新的AppDomain加载相对应的dll。引擎的CurrentDomain里面保存着每个规则的 MarshalByRefObject,当引擎接收到数据的时候,就把这些数据根据一些条件分发到相对应的规则当中。 俄,引擎看起来有点像一个IIS啊!!!

等等,这么美妙的想法,这么容易就可以实现?! 我是不是忘记了什么??哦 我忘记了那些规则的 MarshalByRefObject每秒钟是否能承受1万~3万次的调用(这里的调用就是传递数据包)。

[下午系统测试得时候,性能技术器显示每秒钟仅仅2千个左右的包被处理,剩下的都丢了。。。。。 。疯狂的郁闷中]

自从上次net技术大会回来,每天都挺忙,好多讲课还没来得及回味,看到老赵和eaglet都CodeTimer 了,惭愧啊,不过刚好拿过来用吧。测试代码如下:

1。FunA() FunB() FunC() FunD() 为测试代码,class RemoterProxy是为了创建远程对象更容易一些 ,不是Proxy模式哦。

 1namespace AppDomainPerformanceDemo
 2{
 3    class Program
 4    {
 5        const int COUNT = 500000;
 6
 7        static void Main( string[] args )
 8        {
 9            FunA();
10            FunB();
11            FunC();
12            FunD();
13
14            Console.ReadLine();
15        }
16
17       
18        static void FunC()
19        {
20            RemoterProxy remoterProxy = new RemoterProxy();
21            CodeTimer.Time( "RemoterProxy:  Same AppDomain", COUNT, remoterProxy.FunTest );
22        }
23
24        static void FunD()
25        {
26            AppDomain domain = AppDomain.CreateDomain( "NewAppDomain" );
27            RemoterProxy remoterProxy = (RemoterProxy) domain.CreateInstanceAndUnwrap( Assembly.GetExecutingAssembly().FullName, "AppDomainPerformanceDemo.RemoterProxy" ); ;
28            CodeTimer.Time( "RemoterProxy:  Across AppDomain", COUNT, remoterProxy.FunTest );
29            AppDomain.Unload( domain );
30        }
31
32        static void FunB()
33        {
34            IInterface inter = new ImplementA();
35            CodeTimer.Time( "ImplementA:  Same AppDomain", COUNT, inter.FunA );
36        }
37
38        static void FunA()
39        {
40            AppDomain domain = AppDomain.CreateDomain( "NewAppDomain" );
41            RemoterProxy remoterProxy = (RemoterProxy) domain.CreateInstanceAndUnwrap( Assembly.GetExecutingAssembly().FullName, "AppDomainPerformanceDemo.RemoterProxy" );;
42            IInterface inter = remoterProxy.CreateInstance( "AppDomainPerformanceDemo.ImplementA", "MyImplement", BindingFlags.CreateInstance, null );
43            CodeTimer.Time( "ImplementA:  Across AppDomain", COUNT, inter.FunA );
44            AppDomain.Unload( domain );
45
46        }
47    }
48
49    public class RemoterProxy : MarshalByRefObject
50    {
51        public IInterface CreateInstance( string typeName, string assemblyName, BindingFlags bindingFlags, object[] constructorParams )
52        {
53            Assembly owningAssembly = Assembly.Load( assemblyName );
54
55            IInterface instanceHandler = owningAssembly.CreateInstance( typeName) as IInterface;//, false, bindingFlags, null, constructorParams, null, null ) as IInterface;
56
57            return instanceHandler;
58        }
59
60        public void FunTest()
61        {
62        }
63    }
64
65
66}
67

时间: 2024-08-04 13:29:38

插件系统中跨域调用的性能和“一个简单的性能计数器”的使用的相关文章

JavaScript中跨域调用Flash的方法_javascript技巧

要做一个页面上短信息的提示音的功能,本来想用HTML5中Audio+IE下的bgsound来实现,可是发现每种浏览器对Audio的解码类型还不一样,顿时有种崩溃的感觉.没办法还是用Flash稳妥一点吧. 相信JavaScript与Flash交互大家都会有所接触或者有所耳闻.其实我也是第一次整这个玩意.具体的方法就不说了,很多资料. 开始的时候功能都做得差不多了,实现和没问题.可是就是到了最后,将swf文件放到资源服务上后再调用时出来问题,我就想肯定又是让人蛋疼的跨域问题(CrossDomain)

javascript ajax脚本跨域调用详解

今天终于有点时间研究了一下javsscript ajax 脚本跨域调用的问题,先在网上随便搜了一下找到一些解 决的办法,但是都比较复杂.由是转到jquery.chm用户手册当中找到一些代码片段关于ajax跨域调用的问题. 代码片段如下: crossDomain   mapV1.5 默认: 同域请求为false 跨域请求为true如果你想强制跨域请 求(如JSONP形式)同一域,设置crossDomain为true.这使得例如,服务器端重定向到另一个域. 这 里强调如是ajax的跨域调用,data

一个简单的 Chrome 插件

之前做秒杀器的时候,使用的是 WPF 客户端,借助 HttpWebRequest 来实现远程调用. 后来看到别人抢火车票的软件是一个 Chrome 插件,发现这样写起来要简单太多了.一直想搞一个插件. 今天比较闲,做了一个简单的插件,用于一次性打开多个连续的连接地址,例如这个网页: 它一共有 15 页.一页一页点实在太累,这时,可以使用这个插件,点击一下,弹出以下窗口: Url 已经根据当前的连接地址修改好了,调整部分系数,点打开,即在 chrome 里面打开了所有的网页,看完一个关一个就好了:

NET插件系统之一,开头:MEF的一些疑问和相关思考

      实现可扩展的软件系统是我一直的目标和想法.可扩展性显然属于动态编程的范畴.因此,几个月来我在业余时间会抽空学习插件系统.   我参考了博客园的几篇插件式系统的文章.知道了实现插件系统有以下的核心流程:       1. 定义插件接口,并在各个功能组件中实现这些接口 2. 在主程序中,通过遍历所需目录下的dll文件,查询实现该接口的type,从而通过createInstance方法实现其动态创建,并加入到主程序插件列表.下面的代码展示了该功能. public void GetAllPl

转 解析Nutch插件系统

一. 在Nutch的插件体系架构下,有些术语需要解释    1.扩展点(ExtensionPoint )       扩展点是系统中可以被再次扩展的类或者接口,通过扩展点的定义,可以使得系统的执行过程变得可插入,可任意变化.     2.扩展 ( Extension )       扩展式插件内部的一个属性,一个扩展是针对某个扩展点的一个实现,每个扩展都可以有自己的额外属性,用于在同一个扩展点实现之间进行区分.扩展必须在插件内部进行定义.    3.插件 ( Plugin )       插件实

.NET实现之自己动手写高内聚插件系统

今天跟大家分享一下本人在.NET简谈构件系统开发模式一文中提到的软件架构设计思路的具体实现细节. 大家看了我这篇文章后,总问我为什么要起个这么怪异的名字构件而不用插件.其实这个名字在我脑子漂浮了很久,一直找不到合适的场合用它. 在一本书上是这样解释构件的:构件是可以更换的部件,并且这个部件是由一系列很小的部件组成,同样这些小的部件由更小的部件组成:我为什么要区分插件与构件主要原因是这两个名字所表达的思想不同.插件是可插.可卸的过程,没有强调无限极的递归实现子插件的意思,所以本人将其区分开来:当然

.NET插件系统之二——不实例化获取插件信息和可视化方法

 面临的问题       在开发插件系统中,我们通常会面临这样的问题:        一些功能并不是在开启时就要被使用的,例如VS中的大量功能对一个大部分程序员来说用不着,但框架本身却应该向用户提供该插件的相应信息?        在可视化的插件功能列表中,我们不仅希望提供简单的插件名称信息,更希望能以图片,或动画等形式展示其功能特性,便于用户选择.        插入辅助类来解决上一个问题? 想法虽好,但破坏了"插件"的精髓,它应该是独立可插拔的,如果存在其之外的辅助类,那真是得不偿

Windows平台下C++插件系统实现的几个关键技术问题及其解决思路

根据我的实践,在Windows平台下设计并实现一个C++插件系统,需要解决几个关键技术问题.下面我谈谈需要解决的几个关键技术问题以及我想到的简单的解决思路.由于我主要专注于Windows平台C++程序的开发,这里假设以VS为编译环境,MFC界面库来说明. 1. 主程序和插件的关系问题      插件架构一般可以用下面的图来表示:   (注:此图来自李先静的博客文章:http://blog.csdn.net/absurd/archive/2006/07/04/877063.aspx ,略有修改,特

NET插件系统之四——提升系统搜索插件和启动速度的思考

一. 面临的问题 开发插件系统的主要优势是扩展性,我们不需要为系统模块的集成再多费脑筋,但这也带来了额外的问题.通常,系统需要在每次启动时搜索固定目录下的符合要求的插件.但是,当系统变得越来越庞大,所引用的dll文件越来越多时,就会出现很严重的问题:开启时间慢,性能差,用户体验降低,尤其是在调试程序时,会浪费大量宝贵的时间. 我确确实实的面临了这样的问题,有兴趣的读者可以看看我的插件系列文章的前几篇,这两天痛定思痛,决心提升系统搜索插件的性能. 我们先看一段普通的搜索插件的代码: public