本发明中的名词解释如下：
XML，eXtensible Markup Language，可扩展标记语言；
DOM，Document Object Model，XML文档对象模型；
LRU，Least Recently Used，最近最久未使用置换算法；
HashTable，哈希表，一种根据对象的特征进行定位的数据结构；
Double Linked List，双向链表，数据结构链表的一种，它的每个数据结点中都有两个指针，分别指向直接后继和直接前驱；
AddRef and Release，引用计数，一种共享资源时的计数方法；
Jeff Bonwick’s slab allocator，杰夫瑞·邦维克著分层式内存分配算法，一种性能优越的分层形式的内存分配算法。出自“TheSlab Allocator：An Object-Caching Kernel Memory Allocator(1994)”Jeff Bonwick最初的论文；
XML(eXtensible Markup Language)又称可扩展标记语言，是从标准通用置标语言中简化修改出来的。它是一种置标语言。置标指计算机所能理解的信息符号，通过此种标记，计算机之间可以处理包含各种信息的内容。其特点之一是可以用程序解析成DOM(DocumentObject Model)对象，该对象是XML文档作为树结构来查看，能够通过DOM树来访问所有节点，可以修改或删除元素的内容，并创建新的元素及其属性。此外XML还有XML Schema用于描述XML文档的结构，可以用一个指定的XML Schema(通常以xsd扩展名结尾)来验证某个XML文档，以检查该XML文档是否符合其要求。通过它用户可以根据不同的特定领域，可通过XML schema对XML脚本进行更严格的约束。这样用户根据XML语法规范，可以自定义组成XML脚本的标记集，并描述包括表达无循环、可嵌套的处理过程在内的各种逻辑。
电信业务有其特有的逻辑特性，例如转移过程是无循环过程，号码判断过滤以及流量控制策略是可嵌套的处理过程等等。这些都符合XML语言自身的特点，通过定义相关语义和逻辑可以用基于XML的脚本来描述电信业务逻辑，控制电信业务的运行。这种方式可以改变原有电信业务流程完全由程序编写，不具备灵活的修改配置改变电信业务流程的能力。进而突破因原有问题导致的在多样化需求的情况下产品的开发维护代价不断提高的问题。用XML描述业务逻辑的另一优势是使业务逻辑直观化，并能够描述业务间融合的情况，进而有效的加速推动业务的演化。
使用XML语言来完成电信业务服务器，带来上面提到的优势以外同样也带来了一些问题，主要表现为：首先，由于逻辑和控制在代码层面实现了分离，导致业务逻辑的获取访问时间的增加；其次，由于XML语言本身解释性的特点，所有业务逻辑都必须通过对XML脚本的分析交互获得，必然需要更多的分析处理过程，这样就反过来也对产品的性能的带来了影响，表现为即使能够不断提高硬件平台处理性能，产品本身性能提升的幅度却呈现极大的滞后性。故随着工程规模在不断的扩大，要求降低单位产品成本的呼声不断，而对性能要求又不断提高的情况中，上述的矛盾更加显著，甚至会由此导致无法满足实际工程需要的情形出现。

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于内存的XML脚本缓存容器，要解决的技术问题是基于XML脚本控制业务流程的电信业务服务器由于其脚本解析控制导致的性能难以提高的瓶颈问题。
为达到以上目的，本发明采取的技术方案是：
一种基于内存的XML脚本缓存容器，其特征在于包括：缓存访问接口、XML解析接口和核心缓存，
缓存访问接口、XML解析接口和核心缓存为同一进程内的不同线程，且通过进程内部消息和共享内存的方式交换信息，
核心缓存内包括由3个不同的类功能模块实现的缓存算法处理单元、节点管理单元以及公共控制单元，三个单元均由核心缓存对应线程调用，核心缓存完成从缓存容器访问信息和向缓存容器存储信息的操作，
所述公共控制单元对应的类功能模块由核心缓存对应线程直接调用，公共控制单元负责缓存算法具体执行过程中依据JeffBonwick’s slab allocator实现的对内存的优化操作，同时再由其协调调用缓存算法处理单元、节点管理单元实现缓存算法，
所述缓存算法处理单元对应的类功能模块实现缓存算法中的访问和存储过程中与缓存整体相关的LRU算法的功能，
所述节点管理单元对应的类功能模块实现缓存算法中与节点内部相关的引用计数相关的功能。
在上述技术方案的基础上，所述缓存算法包括以下用于实现缓存算法的内存数据结构，此数据结构供核心缓存中缓存算法处理单元和节点管理单元所使用：
缓存整体的哈希表，提供缓存的高速查询，充当缓存算法中的索引数据结构；
缓存节点单元，是缓存信息的集合体，包含解析后存储的XML脚本的DOM对象、DOM对象各单元映射结果的散列表以及缓存节点引用对象的索引链表；
缓存双向链表，记录缓存节点的引用次序，充当缓存算法中的排序数据结构，其配合缓存整体的哈希表完成LRU算法。
在上述技术方案的基础上，所述DOM对象是存储访问的具体内容，所述DOM对象各单元映射结果的散列表提供DOM对象的高可用备份与恢复工作，所述缓存节点引用对象的索引链表提供了对节点引用计数的功能，并提供反向索引能力。
在上述技术方案的基础上，当核心缓存需要从缓存容器访问信息时，包括以下步骤：
S10、接收访问请求，
公共控制单元解析这个访问请求，分析出请求的类型和待访问信息的索引值，
S20、搜索缓存数据，
公共控制单元调用缓存算法处理单元，缓存算法处理单元根据待访问信息的索引值查询缓存中的节点，查询时使用缓存整体的哈希表数据结构，以保证查询的程序段时间复杂度小于O(log2n)，或查询时使用时间复杂度为O(log2n)的平衡二叉树结构，若查询到所需节点则进入记录节点引用和调整缓存结构的流程S30，否则直接转到S40反馈未找到的结果，
S30、引用记录及缓存调整，
公共控制单元调用节点管理单元，进入查找到的节点，
当请求是获取信息，则在节点中记录下信息的访问者的引用，引用计数加一，
当请求是使用完毕要求释放信息，则公共控制单元调用节点管理单元删除此节点内部的引用链表中访问者的引用，引用计数减一，
当引用计数为零时表示该节点未被任何访问者使用，同时缓存算法处理单元管理的缓存双向链表不做改变，
这样的调整保证在缓存算法处理单元管理的缓存双向链表表首部区域存放的都是最近请求获取信息的节点，而链表尾部区域保存的是最近最久未被请求获取信息的节点，同时使用双向链表是为了使链表调整的时间复杂度为常数级别与存储数量n无关，
S40、结果反馈，
公共控制单元将从缓存搜寻到的节点中获取DOM对象和相关信息反馈给访问者。
在上述技术方案的基础上，当请求是获取信息，其具体实现如下：
在节点内部的引用对象索引链表中添加记录，同时公共控制单元调用缓存算法处理单元，调整缓存双向链表，将访问的节点调整到链表首部，其余节点按原顺序顺延。
在上述技术方案的基础上，当核心缓存需要向缓存容器存储信息时，包括以下步骤：
S100、待存信息预处理，
公共控制单元将收到的待处理的信息初步解析出XML脚本内容及其附带信息，若信息合乎要求则进入缓存存储上限的判断S200，否则进入异常流程处理S800，所述附带信息包括要求缓存动态恢复某缓存数据时附带的引用信息和游标信息，
S200、存储上限判断，
公共控制单元调用缓存算法处理单元对当前缓存情况进行判断，首先判断请求是否是已经存储节点的更新，若是则直接进入淘汰旧节点流程S300，执行更新旧节点，其次确定是否已经达到设定的存储上限，若达到上限则需要进入淘汰旧节点的流程S300，否则直接进入解析XML脚本S400，
S300、淘汰缓存中的旧节点，
当情况是更新旧节点，则公共控制单元调用缓存算法处理单元通过缓存整体哈希表搜索到该节点淘汰，淘汰的具体操作是：缓存算法处理单元删除缓存整体哈希表中的该纪录，切断缓存双向链表中的该纪录并直接连接该纪录的前驱节点和后继节点；然后节点管理单元清除节点内部记录，最后公共控制单元根据Jeff Bonwick’s slaballocator策略回收释放节点内存以及DOM对象内存；
当情况是达到存储上限，则公共控制单元调用缓存算法处理单元判断目前缓存中最近最久且未被使用的节点进行淘汰；判断方法是公共控制单元调用缓存算法处理单元从缓存双向链表尾检索起，寻找第一个引用计数为零的节点，从缓存双向链表和缓存哈希表中去除，并淘汰对象，此过程和S600中对缓存双向链表和缓存哈希表的操作共同组成LRU算法的具体实现，
以上过程若成功淘汰旧节点，则进入解析XML脚本的流程S400，否则当缓存容器收到消息且未要求强制淘汰时给出告警和反馈信息S700，最后进入异常处理S800，
若此时收到消息要求强制淘汰，则公共控制单元调用节点管理单元依据节点中的引用对象索引链表，由公共控制单元通过缓存访问接口给出反馈通知，接着进入XML脚本DOM对象化流程S400，同时进行该节点的淘汰，并在公共控制单元单元中启动等待事件，待淘汰完毕后，才能进入节点缓存存储的流程S600，
S400、XML脚本DOM对象化，
核心缓存中公共控制单元将收到的文本形式的XML脚本通过XML解析接口调用外部XML解析器，解析成树型结构存储的DOM对象，并通过Jeff Bonwick’s slab allocator策略对此对象分配内存存储，
S500、构造新缓存节点，
公共控制单元调用节点管理单元，首先构建节点存储DOM对象，添加节点初始化管理记录，记录主要包括节点创建时间、节点访问频率、节点被访问的记录，然后根据遍历DOM对象其上的单元进行映射，并将映射结果散列存储于节点管理信息中；所述的DOM遍历采用策略是指深度优先或广度优先之一，其映射过程是将DOM上的单元根据遍历的次序进行编号，再同单元一起配对，通过哈希算法散列存储于本节点内部的散列表中，最后根据附加的引用信息和游标信息配合映射结果，创建并恢复对节点单元的引用记录链表，存储于节点管理信息中，最后的过程单独由公共控制单元之间调用就实现了电信业务中高可用的恢复功能，满足了动态恢复的需要，
S600、节点缓存存储，
公共控制单元调用缓存算法处理单元，将由节点管理单元新构造的节点，整体以索引的方式散列存储于缓存整体的哈希表中，同时将节点索引追加于缓存双向链表表首，这样最近最新存入的节点也保存与缓存双向链表首部，符合LRU算法最新涉及节点访问概率更大的假设，
S700、告警信息和管理反馈，
公共控制单元通过此过程反馈信息，可以让管理者或管理程序了解到缓存器的实时状态，当缓存淘汰过于频繁或者缓存全部节点都被使用无法置换新节点时能够进行适当的调整，
S800、异常流程处理，
公共控制单元抛弃此次异常请求，并将异常的原因反馈给访问请求者。
在上述技术方案的基础上，S100中所述信息合乎要求是指：判断XML脚本信息是否符合XML规范，附带的引用信息和游标信息是否完整。
本发明所述的基于内存的XML脚本缓存容器，用软件的方式实现安装于通用服务器上的程序，此程序利用服务器提供的内存和通信接口，为需要使用XML脚本的其他设备或本服务器上的其他程序提供缓存服务，作为原有系统的新增部分，来提高原系统整体的性能。本发明与现有技术中由内存实现的缓存容器相比，其特点是：提供嵌入自身内部的XML解析器的接口，缓存的内容不再是单纯的XML脚本文本，而是XML脚本的DOM对象，而且提供了对DOM对象的跟踪、重入、淘汰、动态备份与恢复以及更新的特性。此外配合外部XML解析器实现对象的流化与结构化可以完全复原以往内存缓存容器含有的功能。
附图说明
本发明有如下附图：
图1为本发明中基于内存的XML脚本缓存容器结构示意图；
图2为本发明中从缓存容器访问信息的流程图；
图3为本发明中向缓存容器存储信息的流程图；
图4为本发明中用于实现算法的内存数据结构示意图。

本发明提供了一种基于内存的XML脚本缓存容器及其实现方法。充分利用电信业务和程序访问中的局部性原理，根据Amdahl’s Law(阿姆达定理)提升程序整体的速度，突破系统中XML脚本访问解析的瓶颈问题。
以下结合附图对本发明作进一步详细说明。
本发明所述的基于内存的XML脚本缓存容器，可以用软件的方式实现安装于通用服务器上的程序，此程序利用服务器提供的内存和通信接口，为需要使用XML脚本的其他设备或本服务器上的其他程序提供缓存服务，作为原有系统的新增部分，来提高原系统整体的性能。
本发明所述基于内存的XML脚本缓存容器内部包含有XML解析接口，可以调用外部的XML解析器。存储于缓存内部的核心信息不再是文本形式的XML脚本，而是XML脚本经过解析后的DOM对象。缓存容器本身含有一种缓存算法，保证其可以在限定容积大小的前提下，依然能够高速访问，而且能够动态淘汰存储的陈旧信息。本发明所述基于内存的XML脚本缓存容器的具体工作过程从整体层面看是由缓存访问接口获取外部程序的存储和访问请求，并传递给核心缓存处理，最后将处理结果再通过缓存访问接口反馈给使用者。在核心缓存的处理过程中需要通过XML解析接口调用外部XML解析器进行解析工作。所述被调用的外部XML解析器需要具备将XML解析成为DOM对象的能力，且支持对DOM对象的遍历操作。
图1为基于内存的XML脚本缓存容器结构示意图，缓存访问接口、XML解析接口和核心缓存3个组成部分用同一进程内的不同线程异步运行实现，3个部分间通过进程内部消息和共享内存的方式交换信息，核心缓存的各组成部分是核心缓存对应线程调用3个不同的类功能模块实现缓存算法处理单元、节点管理单元以及公共控制单元的划分。
所述缓存访问接口为外部程序向缓存存储信息或访问获取信息的通道；
所述XML解析接口是提供核心缓存访问外部XML解析器的内部接口，允许XML信息在内部的DOM对象化以及对DOM对象的遍历访问功能；
所述核心缓存完成具体XML信息的缓存和提供信息的高速访问的功能，包括缓存算法处理单元、节点管理单元和公共控制单元。
缓存算法处理单元提供容器内部缓存算法的实现，能够使缓存容器外部程序通过缓存访问接口利用哈希表的高效索引来存储访问缓存容器内部的信息，包含有LRU置换算法，能够控制缓存的容量同时本发明中的缓存算法中允许信息的动态更新，此外还提供缓存内部的管理统计包括访问命中率、平均查询耗时统计、最近访问排序、缓存剩余空间统计。
节点管理单元提供每个已经存储在内的信息单元的管理，提供引用计数机制允许对信息单元的共享，控制保存了引用链表、游标，进行反向记录，同时提供节点的管理信息如创建时间、节点访问频率、节点被访问的记录信息。
公共控制单元提供缓存算法处理单元和节点管理单元对系统的操作，包括内存基于Jeff Bonwick’s slab allocator访问机制的内存分配，以及提供缓存访问接口的请求在缓存算法处理单元和节点管理单元的协同工作以提供对XML信息DOM对象的散列化处理，同时配合引用游标来实现电信等业务要求的高可用功能所需要的动态备份和恢复的功能。
其中核心缓存的工作过程将依据图2、图3，结合图4在后续详细说明。
所述公共控制单元对应的类功能模块由核心缓存对应线程直接调用，公共控制单元负责缓存算法具体执行过程中依据JeffBonwick’s slab allocator实现的对内存的优化操作，同时再由其协调调用缓存算法处理单元、节点管理单元实现缓存算法。
所述缓存算法处理单元对应的类功能模块实现缓存算法中的访问和存储过程中与缓存整体相关的LRU算法的功能。
所述节点管理单元对应的类功能模块实现缓存算法中与节点内部相关的引用计数相关的功能。
本发明所述缓存算法包括LRU算法和引用计数的综合运用。图4为本发明中用于实现缓存算法的内存数据结构示意图，对应于图1中的核心缓存中缓存算法处理单元和节点管理单元所使用的数据结构(注：图4数据结构中“缓存算法中的索引数据结构”存在多种选择的可能，由于算法的数据结构实现可以多种多样，图4仅仅是可行的实现方式之一，以便于阐述本发明的功能实现和验证本发明对系统性能的提升效果)，如图4所示，用于实现缓存算法的内存数据结构包括：缓存整体的哈希表、缓存节点单元和缓存双向链表，所述缓存整体的哈希表提供缓存的高速查询，充当缓存算法中的索引数据结构(注：索引数据结构性能直接影响缓存容器的整体性能，要保证查询操作时间复杂度不大于O(log2n)，可选择如哈希表、平衡二叉树、Map或B树，图4和最后的试验数据中采用的都是哈希表，而采用B树会更优但复杂度增大，用平衡二叉树或Map则性能稍次。)；所述缓存双向链表记录缓存节点的引用次序，充当缓存算法中的排序数据结构，其配合缓存整体的哈希表完成LRU算法；所述缓存节点单元是缓存信息的集合体，包含解析后存储的XML脚本的DOM对象、DOM对象各单元映射结果的散列表以及缓存节点引用对象的索引链表；其中所述DOM对象是存储访问的具体内容；所述DOM对象各单元映射结果的散列表提供DOM对象的高可用备份与恢复工作；所述缓存节点引用对象的索引链表提供了对节点引用计数的功能，并提供反向索引能力。
核心缓存的工作过程，归纳起来分为从缓存容器访问信息和向缓存容器存储信息两个方向的操作，以下分别根据图2、图3流程结合图4的结构阐述其实现过程。其中向缓存容器存储信息的步骤除了常规存储，还包含了强制淘汰和动态恢复两种特殊情况。
图2为本发明中含有LRU与引用计数相结合的缓存算法从缓存容器访问信息的步骤，下面按照图2所述从缓存容器访问信息的步骤，结合图4的数据结构，详述核心缓存3个功能模块(缓存算法处理单元、节点管理单元以及公共控制单元)的逻辑实现。
S10、接收访问请求。
公共控制单元解析这个访问请求，分析出请求的类型和待访问信息的索引值。
S20、搜索缓存数据。
公共控制单元调用缓存算法处理单元。缓存算法处理单元根据待访问信息的索引值查询缓存中的节点。查询时使用缓存整体的哈希表数据结构，保证查询的程序段时间复杂度小于O(log2n)(若无较好的哈希结构也可使用时间复杂度为O(log2n)的平衡二叉树结构)。若查询到所需节点则进入记录节点引用和调整缓存结构的流程S30，否则直接转到S40反馈未找到的结果。
S30、引用记录及缓存调整。
公共控制单元调用节点管理单元，进入查找到的节点。
当请求是获取信息，则在节点中记录下信息的访问者的引用，引用计数加一；具体实现是在节点内部的引用对象索引链表中添加记录。同时公共控制单元调用缓存算法处理单元，调整缓存双向链表，将访问的节点调整到链表首部，其余节点按原顺序顺延。
当请求是使用完毕要求释放信息，则公共控制单元调用节点管理单元删除此节点内部的引用链表中访问者的引用，引用计数减一。当引用计数为零时表示该节点未被任何访问者使用，同时缓存算法处理单元管理的缓存双向链表不做改变。这样的调整保证在缓存算法处理单元管理的缓存双向链表表首部区域存放的都是最近请求获取信息的节点，而链表尾部区域保存的是最近最久未被请求获取信息的节点，同时使用双向链表是为了使链表调整的时间复杂度为常数级别与存储数量n无关。
S40、结果反馈。
公共控制单元将从缓存搜寻到的节点中获取DOM对象和相关信息反馈给访问者。
图3为本发明中含有LRU与引用计数相结合的缓存算法向缓存容器存储信息的步骤，下面按照图3所述向缓存容器存储信息的步骤，结合图4的数据结构，详述核心缓存3个功能模块(缓存算法处理单元、节点管理单元以及公共控制单元)的逻辑实现。
S100、待存信息预处理。
公共控制单元将收到的待处理的信息初步解析出XML脚本内容及其附带信息，若信息合乎要求(此要求至少包括：XML脚本信息是否符合XML规范，附带的引用信息和游标信息是否完整，若附带的引用信息和游标信息非空，则每个引用信息记录都有对应的游标信息记录，此时则认为附带的引用信息和游标信息是完整的)则进入缓存存储上限的判断S200，否则进入异常流程处理S800。所述附带信息包括要求缓存动态恢复某缓存数据时附带的引用信息和游标信息。
S200、存储上限判断。
公共控制单元调用缓存算法处理单元对当前缓存情况进行判断，首先判断请求是否是已经存储节点的更新，若是则直接进入淘汰旧节点流程S300，执行更新旧节点。其次确定是否已经达到设定的存储上限。若达到上限则需要进入淘汰旧节点的流程S300，否则直接进入解析XML脚本S400。
S300、淘汰缓存中的旧节点。
当情况是更新旧节点，则公共控制单元调用缓存算法处理单元通过缓存整体哈希表搜索到该节点淘汰，淘汰的具体操作是：缓存算法处理单元删除缓存整体哈希表中的该纪录，切断缓存双向链表中的该纪录并直接连接该纪录的前驱节点和后继节点；然后节点管理单元清除节点内部记录，最后公共控制单元根据Jeff Bonwick’s slaballocator策略回收释放节点内存以及DOM对象内存；
当情况是达到存储上限，则公共控制单元调用缓存算法处理单元判断目前缓存中最近最久且未被使用的节点进行淘汰；判断方法是公共控制单元调用缓存算法处理单元从缓存双向链表尾检索起，寻找第一个引用计数为零的节点，从缓存双向链表和缓存哈希表中去除，并淘汰对象(注：此过程和S600中对缓存双向链表和缓存哈希表的操作共同组成LRU算法的具体实现)。以上过程若成功淘汰旧节点，则进入解析XML脚本的流程S400，否则当缓存容器收到消息且未要求强制淘汰时给出告警和反馈信息S700，最后进入异常处理S800；但若此时收到消息要求强制淘汰，则公共控制单元调用节点管理单元依据节点中的引用对象索引链表，由公共控制单元通过缓存访问接口给出反馈通知，接着进入XML脚本DOM对象化流程S400，同时进行该节点的淘汰，并在公共控制单元单元中启动等待事件，待淘汰完毕后，才能进入节点缓存存储的流程S600。
S400、XML脚本DOM对象化。
核心缓存中公共控制单元将收到的文本形式的XML脚本通过XML解析接口调用外部XML解析器，解析成树型结构存储的DOM对象，并通过Jeff Bonwick’s slab allocator策略对此对象分配内存存储。
S500、构造新缓存节点。
公共控制单元调用节点管理单元，首先构建节点存储DOM对象，添加节点初始化管理记录，记录主要包括节点创建时间、节点访问频率、节点被访问的记录。然后根据遍历DOM对象其上的单元进行映射，并将映射结果散列存储于节点管理信息中。所述的DOM遍历采用策略是指深度优先或广度优先之一，其映射过程是将DOM上的单元根据遍历的次序进行编号，再同单元一起配对，通过哈希算法散列存储于本节点内部的散列表中。最后根据附加的引用信息和游标信息配合映射结果，创建并恢复对节点单元的引用记录链表，存储于节点管理信息中。最后的过程单独由公共控制单元之间调用就实现了电信业务中高可用的恢复功能，满足了动态恢复的需要。
S600、节点缓存存储。
公共控制单元调用缓存算法处理单元，将由节点管理单元新构造的节点，整体以索引的方式散列存储于缓存整体的哈希表中，同时将节点索引追加于缓存双向链表表首，这样最近最新存入的节点也保存与缓存双向链表首部，符合LRU算法最新涉及节点访问概率更大的假设。
S700、告警信息和管理反馈。
公共控制单元通过此过程反馈信息，可以让管理者或管理程序了解到缓存器的实时状态，当缓存淘汰过于频繁或者缓存全部节点都被使用无法置换新节点时能够进行适当的调整。
S800、异常流程处理。
公共控制单元抛弃此次异常请求，并将异常的原因反馈给访问请求者。
以下为本发明给出一个简单的实例测试数据，实验环境3GHZ双核X86处理器。所述实例所有步骤采用流水的方式执行，统计并计算使用缓存容器后全部命中的情况和原来的未使用缓存前的区别。
当访问的数量只有1时，从请求获取XML脚本到解析成为DOM对象提供系统使用，未使用缓存前耗时8秒左右，而使用缓存容器命中的情况耗时小于1毫秒(统计工具精度最小1毫秒)，保守估计两者速度差距在3个数量级或更多。
当访问数量达到103时，平均每次从请求获取XML脚本到解析成为DOM对象提供系统使用，未使用缓存前耗时600毫秒左右，而使用缓存容器命中的情况耗时0.18毫秒左右。比较两者速度差距为3个数量级。分析未使用缓存速度提升的原因是在较多数量访问时流水方式提高了各个步骤的利用率从而提高了效率，同时大量XML脚本的请求在查询和传输中的优化也起到了提高速度的作用。
当访问数量达到106时，平均每次从请求获取XML脚本到解析成为DOM对象提供系统使用，未使用缓存前耗时400毫秒左右，而使用缓存容器命中的情况耗时0.12毫秒左右。比较两者速度差距仍为3个数量级。而且分析速度提升比例基本一致，该少量提升应为流水方式的作用。
结合到整体系统下，一般在基于XML脚本控制流程的电信业务服务器中其脚本解析控制的时间开销占总流程时间开销的40％左右，同时此部分功能处理的CPU占用也要维持在30％。根据上述实验分析得到的加速比，根据阿姆达定理可以算出使用该缓存全命中的情况下系统整体的加速比约为167％，而实测于一套基于XML脚本控制流程的电信业务服务器后，发现在硬件条件相同的情况下，原未使用缓存的系统能够稳定处理的最大能力是每秒220个左右的请求，而使用缓存容器后在85％左右的命中率的情况下系统能够稳定处理的最大能力达到350个左右的请求，加速比接近160％非常接近理论值。