CN101091164A - 用于具有自调整线程模型的应用服务器的系统和方法 - Google Patents

Abstract

一种用于具有自调整线程模型的应用服务器的系统和方法。使用服务器队列作为优先级方案，其中包括多个与所接收的请求相关联的条目，并且其允许条目表达优先级或份额值，而不是仅仅线程数目。仍然保留这样的灵活性，即在可能希望其的情况下，以原始数目表达线程，或者表达对要使得可用的线程数目的约束。

Description

用于具有自调整线程模型的应用服务器的系统和方法

技术领域

本发明一般涉及应用服务器和消息传递系统，特别涉及一种用于具有自调整线程模型的应用服务器的系统和方法。

背景技术

在可能存在几百或几千个并发用户(客户端)的典型应用服务器或网络服务器环境中，这些客户端中的每个可以将请求发送到服务器。图1示出了这种环境的示例。现代服务器100可以具有多个处理器以及服务于这些处理器的多个线程102。线程从客户端104、106、108获得请求110、112、114，并且以类似于队列的方式将它们施加到处理器。实际所使用的线程数目对服务器性能及其处理大量用户的能力具有巨大影响。然而，算出线程的最优数目是复杂的处理。

一种对此问题的解决方案是增加甚至更多的线程，从而线程数大大地超过处理器数。这确保了几乎立即将请求供应到线程中，但是不确保这些请求迅速地被处理器处理。一种较新的替代方案是创建线程池，其中运行灵活数目的线程。然后，可以由管理员微调实际的线程数目，以便为具体的运行时间环境提供最佳性能。然而，该处理严重地取决于管理员的技术，因为它在很大程度上是环境相关的并且是静态的，并且大多数仅仅用于测试平台和营销的目的。在现实生活的情形中，环境如此多变以致于该静态方案无法令人满意。

因此，需要一种用于允许服务器基于工作负载的目标预测而自动地确定和实现最优数目的并发线程的装置。由于应用服务器所处位置(在操作系统之上)的限制，因此不能将该线程控制嵌入到操作系统内，而是必须存在于更高级别。因此，应当存在一种用于控制在应用服务器中的线程的数目和供应它们的队列的装置。

发明内容

根据本发明的实施例，提供了一种用于具有自调整线程模型的应用服务器的系统和方法。根据实施例，使用服务器队列作为优先级方案，其中包括多个与所接收的请求相关联的条目，并且其允许条目表达比仅仅线程数目更加自然和更接近于商业用户的优先级。仍然保留灵活性，以在可能希望其的情况下(例如，如果存在除非使得特定数目的线程可用、否则将会死锁的巳知调用序列)以原始数目表达线程，或者基于全系统范围或工作负载而表达对要使得可用的线程数目的约束。

根据实施例，可以将优先级指定为“份额”，其是反映将接收请求的实体之间的相称优先级的抽象概念。由于总数是任意的，并且可能存在大于100的份额，因此尽管份额与百分比线程使用类似，但它们并不相同。份额确定分配给每个实体的线程使用(按照线程数目)。然后，系统(或运行在其上的算法)确保在长期时间内，将根据这些份额分配线程的使用(按照线程时间)。例如使用已经被分配的时间或线程分钟数的两倍的任何实体将受到惩罚，以使相对使用比例回到平衡。

根据实施例，在运行时间期间，该算法还可以用来调整线程池的大小，然后在该池内分配线程。

根据实施例，维护优先级队列。每个请求实体，例如客户端，可以发布进入队列、并且根据相对份额而被分隔开的请求。从而，例如，与用尽了其分配或者具有基于较低时间的分配或份额的另一实体相比，如果该实体没有超过其分配，则可以将其请求放置在队列中的相对高处，并且将立即开始获得线程。

根据实施例，对于最大线程约束，系统可以维护独立的队列，用于将请求保存在优先级队列中、以及最大线程约束队列中。当清除了最大线程约束队列时，将允许执行优先级队列中的任何类似项目(即，用于相同约束的某项目)。

根据实施例，线程池的大小调整可以缩减到递增或递减一个现有池。这是基于周期性地，例如每一秒或两秒执行的。

自调整线程模型的总体结果是服务器的盒外(out-of-the box)性能的大幅度提高。然后，还可以为了适应特定需要而定制线程特征。该特性还允许服务器客户在设置其系统时具有更大的灵活性，并且向他们提供方法来针对具体的商业逻辑或客户需求集等来区分其线程模型的优先级。

附图说明

图1示出了多个客户端使用线程访问服务器的环境的图解。

图2示出了根据本发明实施例的、多个客户端使用线程和优先级队列来访问服务器的环境的图解。

图3示出了根据本发明实施例的用于使用线程访问服务器的处理的流程图。

具体实施方式

目前，应用服务器客户定义新的线程池并配置其大小，以避免死锁并提供不同的服务。这是十分困难的处理。有才能的软件管理团队可能花费几天来仔细考虑用于最优性能的配置。

根据本发明的实施例，自调整服务器动态地调整线程数，以避免死锁并且实现受到并发约束的最优吞吐量。它还满足用于不同服务的目标。这些目标被表述为响应时间目标、份额和优先级。

根据实施例，本系统解决与工作负载管理、执行队列清除、线程计数调整和过载保护相关的要求。可以将服务器中的多个执行队列简化成单个基于优先级的队列。本系统实现基于优先级的工作调度方案，其中在队列中，高优先级工作花费较少的时间。调度考虑了资源约束。主要的焦点是使调度模型可伸缩，并且使管理员能够指定工作负载管理规则。

根据本发明的实施例，提供了一种用于具有自调整线程模型的应用服务器的系统和方法。根据实施例，使用服务器队列作为优先级方案，其中包括多个与所接收的请求相关联的条目，并且其允许这些条目表达比仅仅线程数目更加自然和更接近于商业用户的优先级。仍然保留这样的灵活性，以在可能希望其的情况下(例如，如果存在除非使得特定数目的线程可用否则将会死锁的已知调用序列)以原始数目表达线程，或者基于全系统范围或工作负载而表达对要使得可用的线程数目的约束。

根据实施例，可以将优先级指定为“份额”，反映将接收请求的实体之间的相称的优先级的抽象概念。由于总数是任意的，并且可能存在多于100个份额，因此尽管份额与百分比线程使用类似，但并不相同。份额确定分配给每个实体的线程使用(按照线程数目)。然后，系统(或运行在其上的算法)确保在长期时间内，将根据这些份额分配线程的使用(按照线程时间)。例如，使用了已经被分配的时间或线程分钟数的两倍的任何实体将受到惩罚，以使相对使用比例回到平衡。

根据实施例，在运行时间期间，该算法还可以用来调整线程池的大小，然后在该池内分配线程。

根据实施例，维护优先级队列。每个请求实体例如客户端，可以发布请求，该请求进入队列，并且根据相对份额而被分隔开。从而，例如，与用尽了其分配或者具有较低的基于时间的分配或份额的另一实体相比，如果实体没有超过其分配，则可以将其请求放置在队列中的相对高处，并且将立即开始获得线程。

根据实施例，对于最大线程约束，系统可以维护独立的队列，用于将请求保存在优先级队列以及最大线程约束队列中。当清除了最大线程约束队列时，将允许执行优先级队列中的任何类似项目(即，用于相同约束的某项目)。

根据实施例，线程池的大小调整可以缩减(distill down)为递增或递减一个现有池。这是基于周期性地，例如每一秒或两秒执行的。

自调整线程模型的总体结果是服务器的盒外(out-of-the box)性能的大幅度提高。然后，还可以为了适应特定需要而定制线程特征。该特性还允许服务器客户在设置其系统时具有更大的灵活性，并且向他们提供方法来针对具体的商业逻辑或客户需求集等区分其线程模型的优先级。

图2示出了根据本发明实施例的、多个客户端使用线程和优先级队列来访问服务器的环境的图解。如图2所示，服务器120可以具有多个处理器以及服务于这些处理器的多个线程122。优先级队列124从客户端104、106、108获得请求110、112、114，并且在将这些条目126传递到线程之前，将其排入队列，其中根据任何预先配置的份额值或约束来区分其优先级，然后，线程将它们施加到处理器。

图3示出了根据本发明实施例的用于使用线程访问服务器的处理的流程图。如图3所示，在步骤130中，将服务器配置成根据份额值在实体之间共享线程资源。这可以通过管理员以数值方式输入份额值的控制台应用程序或通过某种其它类型的设备。在步骤132中，服务器从客户端接收请求。在步骤134中，根据份额值并且基于每个实体已经使用了多少线程时间，将请求排入优先级队列。在步骤136中，从优先级队列获得请求，并且将其提供给线程，以便由处理器处理。

实现细节

性能工程师和应用管理员是这些特性的主要用户。管理员规定应用的调度目标，如公平份额和响应时间目标。如在本章节的上下文内使用的那样，使用下面的定义：

受约束工作集-可以基于工作所共享的资源对它们分组。该工作集中的所有工作的性能受到共享资源的容量的约束。

入口点-例子包括RMI方法描述符、HTTP URI、MDB以及JCA 1.5工作管理器实例。

公平份额-使用线程的权利。当服务类竞争线程时，将与其各自的份额成比例地向它们分配线程。该比例仅仅被实现为服务类竞争的足够长时间段上的平均值。如果没有其它服务类处于活动状态，则可以将全部线程分配给该服务类。

自调整-服务器自动设置低级内核参数的能力。管理员可以定义他们了解的应用要求，例如响应时间目标，并且服务器将相应地调整其低级参数。

响应时间目标-在请求到达服务器中的入口点和发出响应之间可以经过的最大毫秒数的目标。

服务类-服务类对服务器中的工作进行分组。针对服务类而非各个请求来表达和跟踪目标。系统在将请求排入队列之前，应该能够确定其服务类。通过根据：入口点、J2EE模块、事务名称、当前用户、或某指定的工作区域字段来分组，出现一些有用的服务类。

调度策略-基于请求的服务类和来自竞争服务类的请求，确定请求的等待时长。

工作负载管理

该特性描述了服务器如何使用服务类、约束和在服务器中观察到的负载状态来调度工作。对于在优先级队列中排队的各种工作类，服务器准许不同的调度策略。通过用所提交的工作指定服务类，这是可能的。该特性使得即使当高优先级工作更晚到达时，系统也在较不重要的工作之前调度高优先级工作。在竞争期间，服务于给定服务类的线程数取决于它的规定目标。约束定义了在死锁和过载状态期间内核应该如何处理工作。

自动线程计数调整

服务器自动地调整其线程计数，以便争取最大吞吐量，并且实现最小并发保证。不再需要诸如threadsIncrease(线程增加)或threadsMaximum(线程最大值)的参数。

减少在启动时创建的执行队列

在传统的实现中，子系统为了诸如防止死锁、最小线程保证等的各种原因而创建其自己的执行队列。自调整避免了创建多个执行队列的需要，并且使用服务类和约束来满足那些要求。

过载保护

过载保护防止服务器在重负载下的服务降级。在过载状态下，服务器以可配置方式拒绝请求。管理员能够指定阈值队列长度，服务器可以拒绝在其之后的请求。突发的低优先级请求很可能被拒绝。它们还可以为各个服务类指定更具体的阈值。

JCA 1.5工作管理器(WorkManager)

JCA1.5工作管理器API提供了让适配器调度服务器中的工作的方式。该API提供了线程调度功能性。应用程序可以使用工作管理器API来异步地执行工作并且接收关于执行状态的通知。

工作负载管理功能描述

管理员可以定义调度策略来规定特殊目标，并且可以表达约束，如下例所示：

<response-time-dispatch-policy name＝″Shopping″goal-ms＝″2000″/>

<fair-share-dispatch-policy name＝″GuestShare″percent＝″l″/>

<context-dispatch-policy name＝″ContextShopping″>

  <case context＝″subject″value＝″anonymous″policy＝″GuestShare″/>

  <case context＝″role″value＝″BigSpender″policy＝″Shopping″/>

</context-dispatch-policy>

<！--该配置跟踪面对外部网的apache网络服务器的最大处理值-->

<min-threads-constraint name＝″minThreadsForPluginMaxProcesses″

    count＝″10″/>

然后，部署描述符和RMI描述符可以引用诸如ContextShopping和minThreadsForPluginMaxProcesses的名称，以将它们施加到入口点。

在调度逻辑中反映公平份额，从而只要多个服务类竞争，由每个使用的平均线程数就与其公平份额成比例。例如，考虑仅仅存在两个服务类A和B、其分别具有80和20的公平份额的情形。在充分地请求两个服务类期间，假定零考虑时间并且客户端多于线程，线程将代表A或B工作的概率分别趋向于80％或20％。即使当A倾向于使用线程比B更久时，调度逻辑也确保这样。

响应时间目标可以区别服务类。系统不试图满足各个请求的响应时间目标。相反地，它通过减去观察到的平均线程使用时间，为服务类计算容许的等待时间。然后，它可以调度请求，以便每个服务类的平均等待与其容许等待时间成比例。例如，考虑仅仅存在两个服务类A和B，分别具有响应时间目标2000ms和5000ms，其中各个请求使用线程的时间少得多。在充分地请求该两个服务类期间，假定零考虑时间并且客户端多于线程，系统可以调度以使平均响应时间保持为比率2∶5，使得其是规定目标的普通分数或倍数。

理解调度实现对理解调度策略是有帮助的。每个服务类具有增量，并且可以将请求输入到具有以其间隔而分隔开的虚拟时间戳的事件队列中。通过小的增量实现高优先级。可以如下说明调度策略：

响应时间

具有以毫秒为单位的属性goal-ms。增量是

((goal-T)Cr)/R

其中T是平均线程使用时间，R是到达率，以及Cr是使响应时间目标的优先级高于公平份额的系数。

公平份额

具有缺省份额的属性百分比。因此，缺省值为100。增量是Cf/(P R T)

其中P是百分比，R是到达率，T是平均线程使用时间，以及Cf是在优先级上使公平份额低于响应时间目标的系数。

上下文

在多个情况下，将上下文的信息如当前用户或其角色、cookie(应用程序)或工作区域字段映射到命名服务类。

SubordinateStepResponseTime(次级步骤响应时间)

具有属性primary(初级)，其命名PrimaryStepResponseTime。

PrimaryStepResponseTime(初级步骤响应时间)

具有以毫秒为单位的属性goal-ms。与响应时间目标类似地计算增量。使用次级步骤与初级步骤的比率，并且减去次级步骤的多个平均线程使用，以获得容许的等待。对于所有步骤，初级加上次级，将容许的等待除以到达率，并且乘以响应时间系数。

固定增量

具有属性increment(增量)。

公平份额系数被选择为到达率和平均线程使用时间的最大乘积的大约1000倍。响应时间系数被选择为使得响应时间策略的平均增量仅仅是公平份额策略的平均增量的十分之一。

约束

可以定义约束并且将其施加到入口点的集合，在此将其称作受约束工作集。

最大线程数

限制执行来自受约束工作集的请求的并发线程数。缺省是不受限制。例如，考虑约束被定义成最大线程数10并且由3个入口点共享。调度逻辑确保不多于10个线程正在执行来自所组合的三个入口点的请求。

最小线程数

保证服务器将分配给受约束工作集的请求以避免死锁的线程数。缺省值是零。例如，对于从对等者同步调用的复制更新请求，最小线程值1是有用的。

容量

只有当达到容量时，服务器才开始拒绝请求。缺省值是零。注意，容量包括来自受约束工作集的、排队或执行的所有请求。该约束主要是计划用于进行其自己的流量控制的子系统，如JMS。该约束独立于全局队列阈值。

不同的调度策略和约束如下相互作用：

上面说明了通过使用相同的策略将调度与其它工作相关，调度策略可以基于公平份额和响应时间。以有利于响应时间调度的显著偏袒来调度公平份额和响应时间策略的混合。

最小线程数约束不增加公平份额。它仅仅与几乎死锁的服务器有关系。然而，然后在这样的意义上它将被胜过，即，即使其服务类最近获得了多于其的公平份额，系统也调度来自受到最小线程数约束的工作集的请求。

最大线程数约束可能但不一定阻止服务类获得其公平份额或者满足其响应时间目标。一旦达到最大线程数约束，则服务器将不调度该约束类型的请求，直至并发执行数降到该限制之下。然后，服务器将基于公平份额或响应时间目标而调度工作。

可以通过最小线程数约束和缺省公平份额来解决admin_rmi和admin_html队列要求。还通过最小线程数约束满足系统队列要求。通过设置最大线程数等于最小线程数等于1，来满足多点传送(multicast)队列要求。这确保了仅仅存在一个处理多点传送请求的线程，从而保证有序。

功能要求

可以以三个级别定义分派策略和约束：全局地在config.xml中，针对每个应用在weblogic-application.xml中，或者针对特定J2EE模块在weblogic部署描述符weblogic-ejb-jar.xml和weblogic.xml中。可以根据对应的标签dispatch-policy(分派策略)、max-threads(最大线程数)和min-threads(最小线程数)来使用这些名称。max-threads和min-threads标签取这样的值，即分别地，max-threads-constraint或min-threads-constraint的名称、或者数。在weblogic-application.xml中，这些标签指定应用范围的缺省值。在weblogic.xml和weblogic-ejb-jar.xml中，它们在顶层指定组件范围的缺省值。在weblogic.xml中，允许与web.xml的过滤映射相似的映射，其中针对url模式或servlet(小服务器程序)名称，映射命名dispatch-policy、max-threads或min-threads。max-threads-mapping和min-threads-mapping也容许数值。在weblogic-ejb-jar.xml中，在weblogic-enterprise-bean下的现有dispatch-policy标签值可以是命名的dispatch-policy。为了向后的兼容性，它还可以命名ExecuteQueue(执行队列)。另外，该系统可以类似于目前的isolation-level(隔离级别)标签而允许dispatch-policy、max-threads和min-threads为一组方法指定命名(或具有用于约束的数值而未命名)的策略和约束。

下面是来自weblogic-application.xml的示例：

<weblogic-application>

…

<response-time-dispatch-policy>

  <name>TradeExecution</name>

  <goal-ms>3000</goal-ms>

 </response-time-dispatch-policy>

 <fair-share-dispatch-policy>

   <name>Enquiry</name>

   <percent>30</percent>

 </fair-share-dispatch-policy>

 …

 <max-threads-constraint>

   <name>TradeDB</name>

   <count>db.pool.trade</count>

 </max-threads-constraint>

 <max-threads-constraint>

   <name>CustomerInfoDB</name>

   <count>db.pool.crm</count>

 </max-threads-constraint>

</weblogic-application>

下面是来自RMI描述符的示例，其定义了在部件级别的服务类：

<method name＝″getStockQuote(String)″

       transactional＝″false″

       dispatch-policy＝″Enquiry″

       max-threads＝″10″>

</method>

<method

  name＝″sellStock(String，int)″

  dispatch-policy＝″TradeExecution″

  max-threads＝″TradeDB″

  transactional＝″true″>

</method>

<method

  name＝″getHomePhone(int)″

  dispatch-policy＝″Enquiry″

  max-threads＝″CustomerInfoDB″

  transactional＝″false″>

</method>

max-threads值可以是数、命名的max-threads-constraint(最大线程数约束)或命名的连接池(JDBC或JCA)。如果资源大小是动态的，则相关联的最小或最大线程数约束也将是动态的，并且随着资源大小的改变而改变。

自动线程计数调整功能描述

服务于优先级队列的线程池自动地改变其大小，以便最大化吞吐量。管理员不再需要指定诸如threadsIncrease(线程数增加)和threadsMaximum(线程数最大)的ExecuteQueueMBean(执行队列豆)属性。优先级队列每2秒监测吞吐量，并且使用所收集数据来确定是否需要改变线程计数。例如，如果在过去，较多线程给出较好的吞吐量，则服务器将增加线程计数。类似地，如果在过去，较少线程数给出相同的吞吐量，则服务器将减少线程计数。

功能要求

用户输入不是必要的。服务器将线程计数完全地基于吞吐量历史记录和队列大小。

减少在启动时创建的执行队列的功能描述

将不同的执行队列简化成单个优先级队列。在过去，必须创建不同的执行队列，以便防止死锁(admin_rmi、无阻塞)，区分工作(系统)的优先级，以及实现有序(多点传送)。通过将服务类与排队的工作相关联来满足这些要求。可以将全部工作提交到优先级队列，并且线程使用时间基于出现在队列中的服务类的类型。

功能要求

下表说明可以如何将现有的执行队列映射到服务类和约束。

Execute queue fair-share(1-100)response-time-goal min-threads

  max-threads

weblogic.kemel.System 50 None 5 No restriction

weblogic.admin.HTTP 50 None 2 No restriction

weblogic.admin.RMI 50 None 3 No restriction

weblogic.kemel.Non-Blocking 50 None 5 No restriction

JmsDispatcher 50 None 15 No restriction

Multicast 80 None 11

过载保护功能描述

管理员可以配置过载阈值，服务器在其之后开始节制(throttling)请求。如下进行节制：

服务器拒绝从未设置最小线程数约束集合的较低次序的公平份额开始的请求。仍然接受具有高优先级的服务类或具有最小线程数约束的服务类。

如果过载状态继续占上风，则由于服务器不能从过载状态恢复，因此也将拒绝较高优先级的请求。将仍然接受具有最小线程数约束的请求和管理请求。

如果工作被拒绝，则发送良好定义的错误响应。对于HTTP发送“503：服务器忙”错误，并且对于RMI，抛出远程异常，这将使得群集能够使客户端知道要进行故障恢复。

功能要求

可以在全局级别或针对每个工作类指定队列限制。可以用KernelMBean属性表示全局阈值。

工作类可以使用约束中的capacity(容量)元素来定义阈值。这里是关于如何设置capacity元素的示例：

  <weblogic-application>

  …

   <capacity-constraint>

     <name>myConstraint</name>

     <treshold>5000</treshold>

   </capacity-constraint>

  </weblogic-application>

  <method

   name＝″*″

   constraints＝″myConstraint″

   transactional＝″false″>

 </method>

容量约束覆盖全局阈值。这意味着，即使当达到全局阈值时，服务器也将继续接受请求。仅仅在达到容量约束的情况下，才将拒绝工作。这对于执行其自己的流量控制并且不能使用全局队列阈值的子系统是有用的。

HTTP过载操作

如果服务器在群集中，则系统将发送503错误代码。这将允许插件进行故障恢复。如果服务器不属于群集，则系统可以允许客户配置将被用作过载响应的出错JSP。通过将重定向指定为过载操作，客户还可以在过载期间将请求重定向到另一服务器。

RMI过载操作

如果服务器在群集中，则系统抛出ServerOverloadedException(服务器过载异常)，其是RemoteException(远程异常)的子类。客户端将把此解释成可恢复的异常，并且故障恢复到另一群集节点。在非群集化的情景中，客户可以指定用于重定向的备用服务器。过载期间的RMI请求将被重定向到该备用服务器。

服务器将不使用读线程将拒绝响应发送出去。写响应涉及可能较慢的I/O。使用读线程写响应将会阻塞所有读线程，从而防止进入的套接字混乱。

子系统可以向内核登记过载通知。当超过全局队列阈值时，内核将通知其监听者。该通知可被用于在子系统级别节制住(throttle back)工作。

功能要求

工作管理器可以是应用范围的或全局的。可以在weblogic-application.xml中如下定义应用范围的工作管理器：

  <weblogic-application>

  …

   <workmanager name＝″myWM″>

    <fair-share>30</fair-share>

    <min-threads>5</min-threads>

    <max-threads>25</max-threads>

    <capacity>5000</capacity>

  </workmanager>

  …

</weblogic-application>

为了从应用程序访问工作管理器，将在局部环境(java:comp/env)中查询其名称。例如：

javax.resource.spi.work.WorkManager wm＝

   (javax.resource.spi.work.WorkManager)

ctx.lookup(″java:comp/env/myWM″)；

wm.doWork(work)；

系统不为每个工作管理器定义创建线程组。所有工作管理器实例共享缺省队列。它们基于其公平份额或响应时间目标而获得优先级。

可以使用根据本公开内容的教导而编程的传统通用或专用数字计算机或者微处理器，方便地实现本发明。基于本公开内容的教导，熟练的程序员可以容易地准备适当的软件编码，这对于软件领域的技术人员而言将是显而易见的。

在一些实施例中，本发明包括计算机程序产品，其是在其上或其中存储有指令的存储介质(介质)，该指令可以用于将计算机编程成执行本发明的任何处理。存储介质可以包括但不限于：任何类型的盘，包括软盘、光盘、DVD、CD-ROM、微驱动器、和磁光盘，ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存设备、磁或光卡、纳米系统(包括分子存储器IC)、或者任何类型的适于存储指令和/或数据的介质或设备。

本发明的上述描述是为了说明和描述的目的而提供的。它不意欲是穷尽性的或者将本发明限制为所公开的确切形式。选择和描述这些实施例是为了最佳地说明本发明的原理及其实际应用，从而使本领域的其它技术人员能够理解本发明，以便获得适于预期特定应用的各种实施例和各种变型。本发明的范围意欲由所附权利要求及其等价物限定。

版权通告

本专利文献公开内容的一部分包含受到版权保护的材料。当本专利文献或者本专利公开内容以专利商标局专利文件或者记录形式出现时，版权所有者不反对任何人对它的传真复制，但在其它方面却无论如何都保留全部版权。

要求优先权：

由Anno Langen和Naresh Revanuru于2004年5月20日提交的、申请号为60/572,938、标题为SYSTEM AND METHOD FOR APPLICATION SERVERWITH SELF-TUNED THREADING MODEL的美国临时专利申请(律师事务所案号：BEAS-01560US0)，在此并入引作参考。

由Anno Langen和Naresh Revanuru于2005年5月19日提交的、申请号为________、标题为SYSTEM AND METHOD FOR APPLICATION SERVERWITH SELF-TUNED THREADING MODEL的美国专利申请(律师事务所案号：BEAS-01560US1)，在此并入引作参考。

Claims (18)

1.一种用于应用服务器中的自调整线程模型的系统，包括：

服务器，包括一个或更多处理器；

一个或更多线程，用于从客户端接收请求并将这些请求传递到处理器；以及

优先级队列，用于根据份额值将线程分配给多个请求，以优化线程的性能。

2.如权利要求1所述的系统，其中所述服务器包括多个处理器。

3.如权利要求1所述的系统，其中根据按比例时间值，将条目排入优先级队列。

4.如权利要求3所述的系统，其中与时间值相比较，根据计算出的已经使用的线程使用时间，将条目排入队列。

5.如权利要求1所述的系统，其中可以根据附加配置的约束而将条目排入队列。

6.如权利要求5所述的系统，其中通过将条目排入附加约束队列来确定约束。

7.一种用于应用服务器中的自调整线程模型的方法，包括以下步骤：

将服务器配置成根据份额值在实体之间共享线程资源；

在服务器处从客户端接收请求；

根据份额值、并基于每个实体已经使用了多少线程时间，将请求排入优先级队列；以及

从优先级队列获得请求，并将它们提供给线程，以便由处理器处理。

8.如权利要求7所述的方法，其中所述服务器包括多个处理器。

9.如权利要求7所述的方法，其中根据按比例时间值，将条目排入优先级队列。

10.如权利要求9所述的方法，其中与时间值相比较，根据计算出的已经使用的线程使用时间，将条目排入队列。

11.如权利要求7所述的方法，其中可以根据附加配置的约束而将条目排入队列。

12.如权利要求11所述的方法，其中通过将条目排入附加约束队列来确定约束。

13.一种计算机可读介质，在其上包括在执行时使计算机执行以下步骤的指令：

将服务器配置成根据份额值在实体之间共享线程资源；

在服务器处从客户端接收请求；

根据份额值、并基于每个实体已经使用了多少线程时间，将请求排入优先级队列；以及

从优先级队列获得请求，并将它们提供给线程，以便由处理器处理。

14.如权利要求13所述的计算机可读介质，其中所述服务器包括多个处理器。

15.如权利要求13所述的计算机可读介质，其中根据按比例时间值，将条目排入优先级队列。

16.如权利要求15所述的计算机可读介质，其中与时间值相比较，根据计算出的已经使用的线程使用时间，将条目排入队列。

17.如权利要求13所述的计算机可读介质，其中可以根据附加配置的约束而将条目排入队列。

18.如权利要求17所述的计算机可读介质，其中通过将条目排入附加约束队列来确定约束。

Images