CN103516536B - 基于线程数量限制的服务器业务请求并行处理方法及系统 - Google Patents
基于线程数量限制的服务器业务请求并行处理方法及系统 Download PDFInfo
- Publication number
- CN103516536B CN103516536B CN201210212637.8A CN201210212637A CN103516536B CN 103516536 B CN103516536 B CN 103516536B CN 201210212637 A CN201210212637 A CN 201210212637A CN 103516536 B CN103516536 B CN 103516536B
- Authority
- CN
- China
- Prior art keywords
- service request
- server
- request
- parallel processing
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种基于线程数量限制的服务器业务请求并行处理方法和系统,该业务请求并行处理方法和系统采用了根据处理时长不同而对业务请求加以分类处理的控制方案,对服务器调用于并行处理每一类别业务请求的线程数量的上限加以限制,以避免长处理时长业务请求对服务器线程的“垄断占用”的情况,确保服务器中总有部分线程被用于并行处理短处理时长的业务请求,使得服务器业务请求处理线程的分配平衡性得以增强,从而提升了服务器整体的业务请求处理执行效率和用户服务效率,同时也降低了服务器对大量运算复杂的长处理时长业务请求进行并行处理导致长时间对服务器系统资源形成“垄断占用”的可能性,从而改善了服务器的系统资源分配合理性能。
Description
技术领域
本发明涉及计算机通信网络技术和服务器技术领域,具体涉及一种基于线程数量限制的服务器业务请求并行处理方法及系统。
背景技术
服务器,是指在计算机通信网络中的一个管理资源对外提供业务服务的高性能计算机。服务器类型有很多,例如数据服务器、文件服务器、网页服务器、流媒体服务器、搜索服务器等,它们侦听计算机通信网络中来自计算机客户端或移动通信客户端的业务请求,并对业务请求进行响应和处理,进而为计算机客户端或移动通信客户端提供各种不同的业务服务,丰富了网络应用。计算机通信网络中的服务器随时都面临着数量庞大的业务请求需要执行处理,服务器对业务请求的处理能力自然也成为其业务服务质量的一项重要衡量标准,快速、高效的业务服务更能够提升用户的业务体验以及对业务服务产品的忠诚度。
为了提升服务器业务服务质量,目前服务器都普遍采用了多线程并行处理业务请求的多线程并发处理模式,使得多个业务请求能够在同一时段内得以处理,以增强服务器的业务请求处理能力。即便是对于同一服务业务而言,都存在多种不同的业务请求,不同业务请求的处理时长也不尽相同,不同业务请求的处理时长可能相差数倍;更何况,有很多服务器还同时运行有多项服务业务,因此服务器可能接收和处理的业务请求更加多样化,不同业务请求处理时长的差别也可能更大;本文所述业务请求的处理时长,是指服务器调用线程对业务请求进行处理直至处理完成得到请求处理结果所持续的时长。而目前的服务器通常采用的是一种比较简单的多线程并发处理模式,即对于服务器接收到的各种业务请求不加区分地进行统一排队,形成一个单一的请求队列,再根据请求队列中各业务请求的排队顺序,分别调用多个线程依次对请求队列中尚未处理的业务请求进行并行处理,每个线程在业务请求处理完成后得以释放并能够再次被调用,以执行后续的业务请求处理。
但由于受到服务器系统处理性能和系统资源的限制,服务器能够用于执行业务请求并行处理的线程的总数是有限的,并且服务器接收到的业务请求具有很强的随机性,因此服务器采用这种简单的多线程并发处理模式很可能时常出现这样的情况:在某个时间段单一请求队列中排队靠前的都是处理时长较长的业务请求,使得服务器几乎所有能够用于执行业务请求并行处理的线程都被调用执行这些处理时长较长的业务请求。这种情况的发生将主要带来两方面的不利影响:①、如果能够先对短处理时长的业务请求进行处理后、再对长处理时长的业务请求进行处理,不仅使得短处理时长业务请求所对应的用户能够迅速获得请求处理结果,对于长处理时长业务请求所对应的用户而言,其获得请求处理结果的等待时间也并没有大幅超出预期,因此使得不同用户均能获得较好的业务服务体验感;然而,由于服务器所有能够用于执行业务请求并行处理的线程都被处理时长较长的业务请求所“垄断占用”,使得短处理时长的业务请求也必须排队等待有线程完成业务请求处理得以释放后才能够得到处理,这样虽然没有影响长处理时长业务请求所对应的用户对业务服务的体验感,但却大大增加了短处理时长业务请求所对应的用户获得请求处理结果的等待时间,并且其等待时长大幅超出预期,因此很可能严重影响这些用户的业务服务体验感;并且,如果长处理时长业务请求的处理时间是短处理时长业务请求的数倍,那么意味着,这种情况发生的过程中,虽然确保了一定数量的长处理时长业务请求所对应用户的业务服务体验感,但却是以大幅降低数倍数量的短处理时长业务请求所对应用户的业务服务体验感作为代价的,因此从整体而言,实际上降低了服务器的业务请求处理执行效率以及用户服务效率。②、业务请求的处理时长越长,通常意味着该业务请求对应的处理运算越复杂,需要占用的服务器系统资源也越多;如果服务器所有能够用于执行业务请求并行处理的线程都被调用执行处理时长较长的业务请求,那么意味着服务器的大量系统资源将在较长时间内被这些执行业务请求并行处理的线程所占用,甚至可能在这段较长的时间内对服务器系统资源形成“垄断占用”,使得服务器执行其它任务处理的运行效率骤然降低甚至终止运行,进而发生网络服务中断、服务器系统任务崩溃等严重后果。
发明内容
针对现有技术中存在的上述不足,本发明的目的在于提供一种基于线程数量限制的服务器业务请求并行处理方法,以提升服务器整体的业务请求处理执行效率和用户服务效率,改善服务器的系统资源分配合理性能,解决现有技术中服务器存在的业务请求处理执行效率和用户服务效率难以保证、时常可能出现网络服务中断或服务器系统任务崩溃的问题。
为实现上述目的,本发明采用了如下技术手段:
基于线程数量限制的服务器业务请求并行处理方法,其特征在于,预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数;服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列,且服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理。
上述的服务器业务请求并行处理方法中,作为进一步优选方案,所述“预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量”具体为:
a1)预先统计服务器处理各不同业务请求的处理时长,获得其中的最短处理时长和最长处理时长;
a2)将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;
a3)分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。
上述的服务器业务请求并行处理方法中,作为进一步优选方案,所述“服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列”具体为:
b1)预先分别设置各类别业务请求的队列存储空间,用于分别存储各类别业务请求相应的请求队列;
b2)在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间;
b3)将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。
上述的服务器业务请求并行处理方法中,作为进一步优选方案,所述“服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理”具体为:
对每一个类别的业务请求,按如下步骤分别进行多线程并行处理的线程调用控制:
c1)检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求;若存在,则执行步骤c2);若不存在,则执行步骤c4);
c2)检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量;若已达到,则执行步骤c4);若尚未达到,则执行步骤c3);
c3)调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即返回步骤c1);
c4)延时Δt时长,然后返回步骤c1)。
上述的服务器业务请求并行处理方法中,作为进一步优选方案,所述Δt时长的取值范围为50~500ms。
上述的服务器业务请求并行处理方法中,作为进一步优选方案,所述各类别业务请求对应的并行处理线程上限数量中,平均处理时长越长的业务请求类别对应的并行处理线程上限数量的值越小。
相应地,本发明还提供了一种能够实现上述服务器业务请求并行处理方法的基于线程数量限制的服务器业务请求并行处理系统;为此,本发明采用了如下的技术手段:
基于线程数量限制的服务器业务请求并行处理系统,其特征在于,包括分类处理模块、排队处理模块和数个线程调用模块;所述分类处理模块用于预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数;所述排队处理模块用于接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列;所述数个线程调用模块分别用于对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理。
上述的服务器业务请求并行处理系统中,作为进一步优选方案,所述分类处理模块主要由处理时长统计单元、业务请求分类单元和并行处理线程上限数量设置单元构成;所述处理时长统计单元用于预先统计服务器处理各不同业务请求的处理时长,获得其中的最长处理时长和最短处理时长;所述业务请求分类单元用于将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;所述并行处理线程上限数量设置单元用于分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。
上述的服务器业务请求并行处理系统中,作为进一步优选方案,所述排队处理模块主要由队列存储设置单元、类别识别单元和排队执行单元构成;所述队列存储设置单元用于分别设置各类别业务请求的队列存储空间,以分别存储各类别业务请求相应的请求队列;所述类别识别单元用于在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间;所述排队执行单元用于将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。
上述的服务器业务请求并行处理系统中,作为进一步优选方案,每一个所述线程调用模块用于对一个类别的业务请求进行多线程并行处理的线程调用控制;每一个线程调用模块均主要由请求队列检测单元、线程数量控制单元、线程调用执行单元和延迟处理单元构成;所述请求队列检测单元用于检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求;若存在,则触发运行线程数量控制单元;若不存在,则触发运行延迟处理单元;所述线程数量控制单元用于检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量;若已达到,则触发运行延迟处理单元;若尚未达到,则触发运行线程调用执行单元;所述线程调用执行单元用于调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即触发运行请求队列检测单元;所述延迟处理单元用于延时Δt时长,然后触发运行请求队列检测单元。
相比于现有技术,本发明具有如下有益效果:
1、本发明的基于线程数量限制的服务器业务请求并行处理方法和系统,采用了根据处理时长不同而对业务请求加以分类处理的控制方案,对服务器调用于并行处理每一类别业务请求的线程数量的上限加以限制,以避免长处理时长业务请求对服务器线程的“垄断占用”的情况,确保服务器中总有部分线程被用于并行处理短处理时长的业务请求,使得服务器业务请求处理线程的分配平衡性得以增强,从而提升了服务器整体的业务请求处理执行效率和用户服务效率。
2、本发明的基于线程数量限制的服务器业务请求并行处理方法和系统,也降低了服务器对大量运算复杂的长处理时长业务请求进行并行处理导致长时间对服务器系统资源形成“垄断占用”的可能性,从而改善了服务器的系统资源分配合理性能。
3、本发明的基于线程数量限制的服务器业务请求并行处理方法和系统,可以广泛应用于各种业务的服务器当中,让服务器为用户提供更加快速、高效的业务服务,提升用户的业务体验以及对业务服务产品的忠诚度。
附图说明
图1为本发明基于线程数量限制的服务器业务请求并行处理方法的流程框图;
图2为本发明基于线程数量限制的服务器业务请求并行处理方法中一种分类处理优选方案的流程框图;
图3为本发明基于线程数量限制的服务器业务请求并行处理方法中一种分类列队优选方案的流程框图;
图4为本发明基于线程数量限制的服务器业务请求并行处理方法中一种线程调用控制优选方案的流程框图;
图5为本发明基于线程数量限制的服务器业务请求并行处理系统的系统框架图。
具体实施方式
针对现有的服务器对业务请求处理所采用的多线程并发处理模式难以保证业务请求处理执行效率和用户服务效率、时常可能出现网络服务中断或服务器系统任务崩溃等多方面的缺陷,究其原因,是现有技术中服务器所采用的多线程并发处理模式对业务请求不加区分、对并行处理各种业务请求的线程数量不加限制而造成的。基于此,本发明方法提出一种基于线程数量限制的服务器业务请求并行处理方法,与现有技术中简单的多线程并发处理模式不同,本发明方法预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数;服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列,且服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理。
本发明通过这种根据处理时长不同而对业务请求加以分类处理的控制方案,对服务器调用于并行处理每一类别业务请求的线程数量的上限加以限制,以避免长处理时长业务请求对服务器线程的“垄断占用”的情况,确保服务器中总有部分线程被用于并行处理短处理时长的业务请求,使得服务器业务请求处理线程的分配平衡性得以增强,从而提升了服务器整体的业务请求处理执行效率和用户服务效率,同时也降低了服务器对大量运算复杂的长处理时长业务请求进行并行处理导致长时间对服务器系统资源形成“垄断占用”的可能性,从而改善了服务器的系统资源分配合理性能。需要说明的是,本文所述的“长处理时长业务请求”和“短处理时长业务请求”是针对同一业务服务器而言的一组相对概念,即在同一服务器中,处理时长较长的业务请求被称为“长处理时长业务请求”,相反,处理时长较短的业务请求被称为“短处理时长业务请求”,而并非以某一固定的时长值作为区分界限而划分出所谓的“长处理时长业务请求”和“短处理时长业务请求”。
下面通过实施例对本发明的效果做进一步说明。
实施例一:
本实施例以一对外提供文献资料数据搜索业务的文献搜索服务器为例,利用本发明的基于线程数量限制的服务器业务请求并行处理方法执行该文献搜索服务器的相关业务请求处理,借以说明本发明方法的具体应用以及有益效果。
该文献搜索服务器能够用于执行业务请求并行处理的线程的总数为3000个,能够对文献搜索服务器接收到的3000个业务请求同时进行并行处理;若文献搜索服务器在同一时间段接收和排队的业务请求数量超过3000个,则超出3000个的部分则需要等候3000个执行业务请求并行处理的线程中有线程完成处理并得以释放后,再依次调用被释放的线程进行处理。该文献搜索服务器需要接收和处理的业务请求主要有页面跳转处理请求、文献检索处理请求、文献阅读处理请求等;页面跳转处理请求有多种,例如请求跳转至首页、用户登录页面、文献检索页面等相应的页面跳转处理请求,服务器对于页面跳转处理请求的处理过程是根据请求的指定调取服务器中已存储的网页数据发送给用户,处理过程比较简单,因此服务器对页面跳转处理请求的处理时长通常在0.05~0.2秒之间;文献检索处理请求也有多种,例如根据专业分类检索、根据作者分类检索、根据文献名称检索、根据关键字检索等相应的文献检索处理请求,服务器对文献检索处理请求的处理过程是根据文献检索条件从服务器的文献数据库中检索出相匹配的所有文献并将检索结果的链接列表发送给用户,由于文献数据库中需要与文献检索条件进行匹配对比的文献文件数量众多,处理过程稍显复杂,因此服务器对文献检索处理请求的处理时长通常会超过0.2秒,有时处理时长甚至达到1秒;服务器对文献阅读处理请求的处理过程是根据请求所指定的文献从文献数据库中提取相应的文献文件数据并调用阅读播放器对调取的文献文件数据加以显示处理,由于文献文件数据通常具有较大的数据量,数据提取操作的时间较长,加之还需要调用阅读播放器对调取的文献文件数据加以显示处理,处理过程较为复杂,因此服务器对文献阅读处理请求的处理时长通常会超过1秒,约在1~5秒之间。
在实际应用中,由于每个用户进入文献搜索服务器所提供的文献搜索业务,都不可避免的要进行进入业务首页、用户登录、文件检索等操作,这些操作通常都需要发送数次的页面跳转处理请求和文献检索处理请求而得以完成,当用户获得检索结果列表后才有可能通过发送文献阅读处理请求获得文件文件数据显示后进行相应的阅读浏览操作,因此该文献搜索服务器接收和处理页面跳转处理请求和文献检索处理请求的数量通常都是大于文献阅读处理请求的数量的;然而由于该文献搜索服务器所提供的文献搜索业务时刻都面向数以万计的互联网络用户,因此很有可能在某一个时间段内,有3000个甚至更多的已经登录并检索获得检索结果列表的用户几乎同时需要阅读其各自制定的文献文件,从而文献搜索服务器一下子接收到了来自这3000个甚至更多用户的文献阅读处理请求并需要处理,与此同时,当然还有来自其他众多用户的页面跳转处理请求和文献检索处理请求需要处理;若采用现有技术中的多线程并发处理模式,对不同的业务请求都家区分地排队调用线程进行并行处理,则可能导致这3000个甚至更多的文献阅读处理请求占用了服务器全部的用于执行业务请求并行处理的线程,并且由于服务器对文献阅读处理请求的处理时长比较长,通常在1~5秒之间,从而使得自其他众多用户原本仅需零点几秒处理完成并获得结果的的页面跳转处理请求和文献检索处理请求,只得在数秒之后能够得以处理,影响了服务器整体的业务请求处理执行效率和用户服务效率,并且给其他众多用户带来了页面跳转、文献检索响应迟钝的业务体验感,对用户的业务产品忠诚度带来负面影响。
针对该文献搜索服务器目前的情况,该文献搜索服务器利用本发明基于线程数量限制的服务器业务请求并行处理方法,对其相关的业务请求进行分类区分处理和控制,其处理流程如图1所示,包括如下步骤:
S1)预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量;
S2)服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列;
S3)服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理。
其中,步骤S1用于为业务请求的分类区分处理和控制提供分类基础以及服务器对各类别业务请求进行并行处理的线程数量调用限制基础。考虑到结合服务器执行业务请求并行处理的具体应用环境以及服务器整体运行的可操作性,可以采用如下所述的分类处理方法作为优选的分类方案,其处理流程如图2所示:
s11)预先统计服务器处理各不同业务请求的处理时长,获得其中的最短处理时长和最长处理时长;
s12)将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;
s13)分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。
在该作为优选的分类方案中,由于服务器对业务请求的处理时长,与服务器的硬件处理性能、服务器操作系统的处理调用性能、服务器所提供的服务业务类型等因素都有密切关联,因此不同应用环境的服务器对各种业务请求进行处理的最长处理时长和最短处理时长不尽相同;同时,不同的业务服务对服务器整体的业务请求处理管理需求不尽相同,因此所需要采用的具体分类方式不相同,即意味着对最短处理时长至最长处理时长之间的时长空间的时长区间划分方式也是不同相同的,这些都需要需要根据实际应用情况以及管理需求而定。在具体应用过程中,时长区间划分得越多,则相应地对业务请求类别的划分也就越多,则越有利于细致化管理,但相应地因分类控制条件也随分类数量的增多而增加致使业务请求分类处理的控制压力也增大。
而限制各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数,一方面是通过该限制确保并行处理每一类别业务请求的线程数量的上限均不能完全占用服务器能够用于执行业务请求并行处理的线程的总数,从而避免长处理时长业务请求“垄断占用”服务器的全部线程资源,另一方面是即便出现各个类别业务请求对应的并行处理线程均达到上限的情况下,也不至于超出服务器的线程负荷,并且也使得服务器能够用于执行业务请求并行处理的全部线程尽可能得以充分利用。但通常情况下,服务器接收的处理的长处理时长业务请求的数量往往是少于短处理时长业务请求的,由此出发考虑服务器整体的线程分配平衡性以及系统资源分配合理性等因素,各类别业务请求对应的并行处理线程上限数量的设置,最很好是平均处理时长越长的业务请求类别(即所在时长区间的值越大的业务请求类别)对应的并行处理线程上限数量的值越小。
对于本实施例而言,例如,首先通过统计获知该文献搜索服务器对各种页面跳转处理请求、文献检索处理请求、文献阅读处理请求的处理时长在0.05~5秒之间,其最长处理时长和最短处理时长则分别为5秒和0.05秒;之后,考虑到该文献搜索服务器对页面跳转处理请求、文献检索处理请求、文献阅读处理请求的各自处理特点即处理时长情况,可以在所述最短处理时长0.05秒与最长处理时长5秒之间的时长空间[0.05秒,5秒]内设置两个时长分界值,分别为1秒和0.2秒,以该两个时长分界值作为划分时长区间的分界点,并将时长分界值自身划分在较小值区间,从而将时长空间[0.05秒,5秒]划分为依次相邻的三个时长区间,分别为[0.05秒,0.2秒]、(0.2秒,1秒]和(1秒,5秒],从而页面跳转处理请求、文献检索处理请求、文献阅读处理请求则被分别划归为不同的三类别业务请求;为表述方便,后文将[0.05秒,0.2秒]、(0.2秒,1秒]和(1秒,5秒]三个时长区间对应的三类别业务请求分别称为第一类别业务请求、第二类别业务请求、第三类别业务请求;最后,考虑到该文献搜索服务器接收和处理的页面跳转处理请求(第一类别业务请求)和文献检索处理请求(第二类别业务请求)数量都大于文献阅读处理请求(第三类别业务请求)的数量这一服务器实际应用情况,故三个类别业务请求对应的并行处理线程上限数量采用5:3:2的分配比例,即预设置第一类别业务请求对应的并行处理线程上限数量为1500个、第二类别业务请求对应的并行处理线程上限数量为900个、第三类别业务请求对应的并行处理线程上限数量为600个。至此,对业务请求的分类处理以及并行处理线程上限数量的设置即完成。
采用上述步骤s11~s13作为优选方案实现步骤S1,优势在于,对于服务器系统设计人员而言,只需要设定统计服务器处理各不同业务请求的处理时长的统计方案,再根据服务器具体应用的服务业务以及管理需求设定时长区间的分界点作为设计参数,并设置好各个类别业务请求并行处理线程上限数量的分配比例,即可通过在服务器系统中编程设计自运行程序,由服务器自运行执行上述分类及并行处理线程上限数量的设置处理步骤,即便服务器相关的业务请求种数有增减或变动也不会影响分类处理的运行,具有良好的鲁棒性能;同时该优选方案针对于不同应用环境的服务器,只需要根据实际应用情况相应调整设计参数即可得以应用,具有很好的适应性和可移植性。当然,除了该优选方案之外,本领域技术人员也可以根据其已有知识和实际的服务器业务应用领域情况,采用其它方案实现步骤S1。
步骤S2用于对服务器接收的不同类别业务请求分别列队,便于后期针对不同类别的请求列队对不同类别的业务请求进行分类处理。考虑到服务器执行业务请求并行处理的特点,可以采用如下所述的列队处理方法作为优选的分类列队方案,其处理流程如图3所示:
s21)预先分别设置各类别业务请求的队列存储空间,用于分别存储各类别业务请求相应的请求队列。
s22)在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间。
s23)将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。
为了实现业务请求的分类处理和控制,需要对不同类别业务请求分别排队,使得各类别业务请求按相应请求列队的排队顺序得以处理;而针对不同类别业务请求的请求队列分别设置队列存储空间,便则于不同类别业务请求的请求队列的查询操作。对于本实施例而言,针对前述的第一类别业务请求、第二类别业务请求、第三类别业务请求,在服务器内分别设置了队列存储空间A1、队列存储空间A2、队列存储空间A3,该三个队列存储空间各自具有不同的存储地址;在服务器接收到业务请求时,例如,若接收到一个页面跳转处理请求,即识别其属于第一类别业务请求,查找到其相应类别的队列存储空间为队列存储空间A1,从而将该接收到的页面跳转处理请求作为第一类别的请求队列中当前排队最靠后的一个存入队列存储空间A1;若接收到其它类别的业务请求,也执行相应处理,从而分别形成各类别业务请求相应的请求队列。
采用上述步骤s21~s23作为优选方案实现步骤S2,优势在于,对于服务器系统设计人员而言,只需要设定各类别业务请求的队列存储空间在服务器中对应的存储地址所在位置,即可通过在服务器系统中编程设计自运行程序,由服务器自运行执行上述的分类列队处理步骤,为后续对业务请求的分类处理提供了列队区分的基础。当然,除了该优选方案之外,本领域技术人员也可以根据其已有知识和实际的服务器业务应用领域情况,采用其它方案实现步骤S2。
步骤S3用于根据上述的分类和列队基础,分别对并行处理每一类别业务请求的线程数量的上限加以限制,实现服务器对业务请求的分类区分处理和控制,进而达到增强服务器业务请求处理线程的分配平衡性、避免长初始时长业务请求对服务器全部线程资源的垄断占用的目的。考虑到结合服务器执行业务请求并行处理的具体应用环境以及服务器整体运行的可操作性,对每一个类别的业务请求,可以按如下步骤分别进行多线程并行处理的线程调用控制,其处理流程如图4所示:
s31)检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求;若存在,则执行步骤s32);若不存在,则执行步骤s34);
s32)检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量;若已达到,则执行步骤s34);若尚未达到,则执行步骤s33);
s33)调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即返回步骤s31);
s34)延时Δt时长,然后返回步骤s31)。
通过上述的线程调用控制处理过程可以看到,在对服务器的业务请求进行分类处理控制的过程中,如果一个类别业务请求相应的请求队列中存在尚未处理的业务请求且对该类别业务请求执行并行处理的线程数量未达到该类别业务请求对应的并行处理线程上限数量的情况下,服务器将逐次调用待用线程按照该类别业务请求相应的请求队列的排队顺序对其中尚未处理的业务请求进行处理,保证数据业务请求处理的及时执行;而当对该类别业务请求执行并行处理的线程数量达到该类别业务请求对应的并行处理线程上限数量后,且该类别业务请求相应的请求队列中依然存在尚未处理的业务请求的情况下,则只能循环延时Δt时长,等候有处理该类别业务请求的线程处理完成并得以释放、对该类别业务请求执行并行处理的线程数量减少至该类别业务请求对应的并行处理线程上限数量以下之后,服务器才会继续调用线程对该类别业务请求进行处理;针对每一个类别的业务请求都按照上述步骤s31~s34执行线程调用控制操作,由此对并行处理每一个类别业务请求的线程数量的上限加以限制。
对于本实施例而言,例如,若在某一时间段,第一类别业务请求、第二类别业务请求、第三类别业务请求对应的请求队列中分别有9000个页面跳转处理请求、4500个文献检索处理请求以及3000个文献阅读处理请求尚未处理,无论这些业务请求的整体排序顺序如何,服务器都将调用1500个线程(即第一类别业务请求对应的并行处理线程上限数量)并行处理1500个页面跳转处理请求(处理时长在0.05~0.2秒之间,可看作第一类别业务请求的一个并行处理周期)、调用900个线程(即第二类别业务请求对应的并行处理线程上限数量)并行处理900个文献检索处理请求(处理时长在0.2~1秒之间,可看作第二类别业务请求的一个并行处理周期)、调用600个线程(即第三类别业务请求对应的并行处理线程上限数量)并行处理600个文献阅读处理请求(处理时长在1~5秒之间,可看作第三类别业务请求的一个并行处理周期),其余各类尚未处理的业务请求都将在各自相应的请求列队中排队等候,直至第一类别业务请求执行6个并行处理周期(不超过1.2秒)、第二类别业务请求执行5个并行处理周期(不超过5秒)、第三类别业务请求执行5个并行处理周期(不超过25秒),则完成对9000个页面跳转处理请求、4500个文献检索处理请求以及3000个文献阅读处理请求的全部处理;由此,采用本发明的业务请求并行处理方法对该文献搜索服务器进行业务请求处理,不会如同现有的多线程并发处理模式那样,导致服务器3000个线程全部被处理时长较长的文献阅读处理请求长时间占用,避免了长处理时长业务请求对服务器线程的“垄断占用”的情况,确保服务器中总有部分线程被用于并行处理短处理时长的业务请求;虽然本发明的业务请求并行处理方法会导致部分长处理时长业务请求所对应的用户等待时间增加,影响了他们对业务服务的体验感,但相比于现有多线程并发处理模式消耗5秒钟并行处理3000个文献阅读处理请求而言,采用本发明的业务请求并行处理方法能够在5秒钟以内能够并发完成37500个以上的页面跳转处理请求、4500个以上的文献检索处理请求以及600个以上文献阅读处理请求的并行处理,使得服务器业务请求处理线程的分配平衡性得以增强,5秒内并行处理业务请求的总数超过42600个,可见服务器整体的业务请求处理执行效率得以大幅增加,也使得更多用户的业务请求得以及时处理,提升了服务器整体的用户服务效率,因此在能够在整体上提升用户群的业务体验以及对业务服务产品的忠诚度;同时,也降低了服务器对大量运算复杂的长处理时长业务请求进行并行处理导致长时间对服务器系统资源形成“垄断占用”的可能性,从而改善了服务器的系统资源分配合理性能。
上述步骤s31~s34所述的线程调用控制处理方法,可通过对服务器编程后由服务器自运行执行,其自身也是一个多线程处理方案,针对每一类别业务请求的处理和控制操作均可分配一个独立线程执行,保证个各类别业务请求的处理和控制操作互不干扰;该作为优选分类控制方案的线程数量限制处理方法,也不会受到的业务请求种数有增减或变动的影响,并且也适用于不同应用环境的服务器,同样具备良好的鲁棒性能以及良好的适应性和可移植性。至于上述步骤s334中涉及的延迟Δt时长,是为了避免在针对每一类别业务请求的处理和控制过程中,在不存在尚未处理的该类别业务请求或者并行处理该类别业务请求的线程数量已达到上限的情况下过于频繁的执行判断操作,不必要的增加服务器处理任务的负担,当然Δt时长的值也不应当过大,否则会影响并行处理该类别业务请求的效率;这些因素考虑,Δt时长的取值范围在50~500ms之间较为适宜。当然,除了该优选方案之外,本领域技术人员也可以根据其已有知识和实际的服务器业务应用领域情况,采用其它方案实现步骤S3。
实施例二:
对应的,本发明还提供了一种基于线程数量限制的服务器业务请求并行处理系统,该系统可以集成于服务器中,也可以作为服务器外的独立装置;依然以实施例一所述的文献搜索服务器为例,由文献搜索服务器结合本发明的业务请求并行处理系统,使得该文献搜索服务器能够自运行实现实施例一所述的业务请求并行处理方法。
该业务请求并行处理系统的结构如图5所示,主要包括分类处理模块10、排队处理模块20和线程调用模块30,且线程调用模块30为数个;分类处理模块10用于预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数;排队处理模块20用于接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列;线程调用模块30用于对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理。这些模块均可以由本领域技术人员利用其掌握的编程技术通过编程得以实现。
其中,具体而言,分类处理模块10可以包括处理时长统计单元、业务请求分类单元和并行处理线程上限数量设置单元;处理时长统计单元用于预先统计服务器处理各不同业务请求的处理时长,获得其中的最长处理时长和最短处理时长;业务请求分类单元用于将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;并行处理线程上限数量设置单元用于分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。由此编程构建实现分类处理模块,编程技术人员只需要设定统计服务器处理各不同业务请求的处理时长的统计方案,再根据服务器具体应用的服务业务以及管理需求设定时长区间的分界点作为设计参数,并设置好各个类别业务请求并行处理线程上限数量的分配比例,即可让服务器系统自运行执行实施例一中所述的优选分类处理方案,并确保了分类处理模块具备良好鲁棒性能以及良好的的适应性和可移植性。
排队处理模块20可以包括队列存储设置单元、类别识别单元和排队执行单元;队列存储设置单元用于分别设置各类别业务请求的队列存储空间,以分别存储各类别业务请求相应的请求队列;类别识别单元用于在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间;排队执行单元用于将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。由此编程构建实现排队处理模块,即可让服务器系统自运行执行实施例一中所述的优选分类列队方案,为后续对业务请求的分类处理提供了列队区分的基础。
系统中的每一个所述线程调用模块用于对一个类别的业务请求进行多线程并行处理的线程调用控制。每一个线程调用模块30均主要由请求队列检测单元、线程数量控制单元、线程调用执行单元和延迟处理单元构成。在每一个线程调用模块30中,请求队列检测单元用于检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求,若存在,则触发运行线程数量控制单元,若不存在,则触发运行延迟处理单元;线程数量控制单元用于检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量,若已达到,则触发运行延迟处理单元,若尚未达到,则触发运行线程调用执行单元;线程调用执行单元用于调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即触发运行请求队列检测单元;延迟处理单元用于延时Δt时长,然后触发运行请求队列检测单元。由此编程构建实现线程调用模块,即可让服务器系统自运行执行实施例一中所述的优选线程调用控制方案,有效提升了服务器整体的业务请求处理执行效率和用户服务效率。考虑到通常情况下,服务器接收的处理的长处理时长业务请求的数量往往少于短处理时长业务请求,针对各类别业务请求对应的并行处理线程上限数量的设置,最很好也是平均处理时长越长的业务请求类别(即所在时长区间的值越大的业务请求类别)对应的并行处理线程上限数量的值越小,以更进一步提高服务器整体的线程分配平衡性以及系统资源分配合理性。
综合上述两个实施例的举例说明,可以看到,本发明的基于线程数量限制的服务器业务请求并行处理方法及系统,采用了根据处理时长不同而对业务请求加以分类处理的控制方案,对服务器调用于并行处理每一类别业务请求的线程数量的上限加以限制,以避免长处理时长业务请求对服务器线程的“垄断占用”的情况,确保服务器中总有部分线程被用于并行处理短处理时长的业务请求,使得服务器业务请求处理线程的分配平衡性得以增强,从而提升了服务器整体的业务请求处理执行效率和用户服务效率;同时也降低了服务器对大量运算复杂的长处理时长业务请求进行并行处理导致长时间对服务器系统资源形成“垄断占用”的可能性,从而改善了服务器的系统资源分配合理性能。本发明基于线程数量限制的服务器业务请求并行处理方法及系统,不仅仅可以应用于实施例中涉及的文献搜索服务器,在本发明的基于线程数量限制的服务器业务请求并行处理方法和系统的应用过程中,本领域技术人员可以通过编程,让服务器自运行执行对业务请求分类处理和控制,并可以通过根据具体应用场合调整服务器设计参数的方式,使其广泛应用于各种业务的服务器当中,让服务器提供更加快速、高效的业务服务,从整体上提升用户的业务体验以及对业务服务产品的忠诚度。
最后说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明技术方案的宗旨和范围,其均应涵盖在本发明的权利要求范围当中。
Claims (8)
1.基于线程数量限制的服务器业务请求并行处理方法,其特征在于,预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量;服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列,且服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理;
所述预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量具体为:
a1)预先统计服务器处理各不同业务请求的处理时长,获得其中的最短处理时长和最长处理时长;
a2)将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;
a3)分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。
2.根据权利要求1所述的服务器业务请求并行处理方法,其特征在于,所述服务器接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列具体为:
b1)预先分别设置各类别业务请求的队列存储空间,用于分别存储各类别业务请求相应的请求队列;
b2)在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间;
b3)将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。
3.根据权利要求1所述的服务器业务请求并行处理方法,其特征在于,所述服务器分别对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理具体为:
对每一个类别的业务请求,按如下步骤分别进行多线程并行处理的线程调用控制:
c1)检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求;若存在,则执行步骤c2);若不存在,则执行步骤c4);
c2)检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量;若已达到,则执行步骤c4);若尚未达到,则执行步骤c3);
c3)调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即返回步骤c1);
c4)延时Δt时长,然后返回步骤c1)。
4.根据权利要求3所述的服务器业务请求并行处理方法,其特征在于,所述Δt时长的取值范围为50~500ms。
5.根据权利要求1所述的服务器业务请求并行处理方法,其特征在于,所述各类别业务请求对应的并行处理线程上限数量中,平均处理时长越长的业务请求类别对应的并行处理线程上限数量的值越小。
6.基于线程数量限制的服务器业务请求并行处理系统,其特征在于,包括分类处理模块、排队处理模块和数个线程调用模块;
所述分类处理模块用于预先根据服务器对业务请求处理时长的长短将业务请求分为数个类别,并分别设置各类别业务请求对应的并行处理线程上限数量;
所述排队处理模块用于接收业务请求并进行类别识别,对不同类别业务请求分别排队,形成各类别业务请求相应的请求队列;
所述数个线程调用模块分别用于对每一个类别的请求队列中尚未处理的业务请求调用不超过相应类别业务请求对应的并行处理线程上限数量的线程进行多线程并行处理;
所述分类处理模块由处理时长统计单元、业务请求分类单元和并行处理线程上限数量设置单元构成;
所述处理时长统计单元用于预先统计服务器处理各不同业务请求的处理时长,获得其中的最长处理时长和最短处理时长;
所述业务请求分类单元用于将所述最短处理时长至所述最长处理时长之间的时长空间划分为依次相邻的数个时长区间,将预先统计的处理时长在同一时长区间的业务请求归为一类,从而根据预先统计的各不同业务请求的处理时长所在的时长区间,将业务请求对应的分为数个类别;
所述并行处理线程上限数量设置单元用于分别设置各类别业务请求对应的并行处理线程上限数量,各类别业务请求对应的并行处理线程上限数量的总和等于服务器能够用于执行业务请求并行处理的线程的总数。
7.根据权利要求6所述的服务器业务请求并行处理系统,其特征在于,所述排队处理模块由队列存储设置单元、类别识别单元和排队执行单元构成;
所述队列存储设置单元用于分别设置各类别业务请求的队列存储空间,以分别存储各类别业务请求相应的请求队列;
所述类别识别单元用于在服务器接收到业务请求时,识别接收到的业务请求所属的类别,查找到相应类别业务请求的队列存储空间;
所述排队执行单元用于将接收到的业务请求作为其相应类别的请求队列中当前排队最靠后的一个存入相应类别业务请求的队列存储空间。
8.根据权利要求6所述的服务器业务请求并行处理系统,其特征在于,每一个所述线程调用模块用于对一个类别的业务请求进行多线程并行处理的线程调用控制;每一个线程调用模块均由请求队列检测单元、线程数量控制单元、线程调用执行单元和延迟处理单元构成;
所述请求队列检测单元用于检测该类别业务请求相应的请求队列中当前是否存在尚未处理的业务请求;若存在,则触发运行线程数量控制单元;若不存在,则触发运行延迟处理单元;
所述线程数量控制单元用于检测当前对该类别业务请求执行并行处理的线程数量,判断当前对该类别业务请求执行并行处理的线程数量是否已达到该类别业务请求对应的并行处理线程上限数量;若已达到,则触发运行延迟处理单元;若尚未达到,则触发运行线程调用执行单元;
所述线程调用执行单元用于调用一个线程对该类别的请求队列中当前排队最靠前的一个尚未处理的业务请求进行处理,然后立即触发运行请求队列检测单元;
所述延迟处理单元用于延时Δt时长,然后触发运行请求队列检测单元。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210212637.8A CN103516536B (zh) | 2012-06-26 | 2012-06-26 | 基于线程数量限制的服务器业务请求并行处理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210212637.8A CN103516536B (zh) | 2012-06-26 | 2012-06-26 | 基于线程数量限制的服务器业务请求并行处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103516536A CN103516536A (zh) | 2014-01-15 |
CN103516536B true CN103516536B (zh) | 2017-02-22 |
Family
ID=49898617
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210212637.8A Active CN103516536B (zh) | 2012-06-26 | 2012-06-26 | 基于线程数量限制的服务器业务请求并行处理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103516536B (zh) |
Families Citing this family (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104133724B (zh) * | 2014-04-03 | 2015-08-19 | 腾讯科技(深圳)有限公司 | 并发任务调度方法及装置 |
CN104980468B (zh) * | 2014-04-09 | 2019-05-14 | 深圳市腾讯计算机系统有限公司 | 处理业务请求的方法、装置及系统 |
CN105335231B (zh) * | 2014-08-15 | 2020-01-31 | 阿里巴巴集团控股有限公司 | 一种服务端线程的动态分配方法和设备 |
CN104270362B (zh) * | 2014-09-29 | 2017-10-10 | 广州华多网络科技有限公司 | 请求处理方法和装置 |
CN105589748A (zh) * | 2014-10-22 | 2016-05-18 | 阿里巴巴集团控股有限公司 | 一种业务请求处理方法及装置 |
CN106209666B (zh) * | 2015-05-07 | 2020-06-02 | 中兴通讯股份有限公司 | 一种基于负载均衡器的链路复用方法及系统 |
CN106302570A (zh) * | 2015-05-14 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 一种请求处理方法及装置 |
CN106470169A (zh) * | 2015-08-19 | 2017-03-01 | 阿里巴巴集团控股有限公司 | 一种业务请求调整方法及设备 |
CN105389617A (zh) * | 2015-11-19 | 2016-03-09 | 上海携程商务有限公司 | 自动化的订单处理方法及系统 |
CN106936784B (zh) * | 2015-12-30 | 2020-12-29 | 青岛海信宽带多媒体技术有限公司 | Sip注册方法、终端及系统 |
CN105590253A (zh) * | 2016-01-12 | 2016-05-18 | 上海携程商务有限公司 | 基于多线程的并行财务流水生成方法及系统 |
CN105930216A (zh) * | 2016-04-15 | 2016-09-07 | 平安科技(深圳)有限公司 | 电子签名系统自动排配方法、系统及服务器 |
CN106354493B (zh) * | 2016-08-24 | 2019-08-13 | 广州高专资讯科技有限公司 | 一种解决传统软件开发痛点的开发模式的实现方法 |
CN106302809A (zh) * | 2016-09-20 | 2017-01-04 | 天津海量信息技术股份有限公司 | 一种服务器性能优化方法及系统 |
CN106550019B (zh) * | 2016-10-20 | 2020-01-31 | 福建天泉教育科技有限公司 | 浏览器请求处理方法及系统 |
CN108073580A (zh) * | 2016-11-08 | 2018-05-25 | 北京国双科技有限公司 | 一种基于页面并发请求的处理方法及装置 |
CN107682391B (zh) * | 2017-08-04 | 2020-06-30 | 平安科技(深圳)有限公司 | 电子装置、服务器分配控制方法和计算机可读存储介质 |
CN107666513A (zh) * | 2017-09-07 | 2018-02-06 | 深圳市普天宜通技术股份有限公司 | 突发请求的处理方法、终端及计算机可读存储介质 |
CN107800768B (zh) * | 2017-09-13 | 2020-01-10 | 平安科技(深圳)有限公司 | 开放平台控制方法和系统 |
CN108270693A (zh) * | 2017-12-29 | 2018-07-10 | 珠海国芯云科技有限公司 | 网站访问的自适应优化疏导方法及装置 |
CN108681481B (zh) * | 2018-03-13 | 2021-10-15 | 创新先进技术有限公司 | 业务请求的处理方法及装置 |
CN110545481B (zh) | 2018-05-29 | 2021-12-14 | 北京字节跳动网络技术有限公司 | 一种媒体播放过程中连接分配方法、装置及存储介质 |
CN109508243A (zh) * | 2018-07-27 | 2019-03-22 | 江西贪玩信息技术有限公司 | 业务请求处理方法、装置、计算机设备和存储介质 |
WO2020057229A1 (zh) | 2018-09-21 | 2020-03-26 | 华为技术有限公司 | 数据检索方法及装置 |
CN109561133A (zh) * | 2018-10-23 | 2019-04-02 | 深圳壹账通智能科技有限公司 | 业务处理方法、装置、设备及计算机可读存储介质 |
CN109639594A (zh) * | 2018-12-04 | 2019-04-16 | 杭州迪普科技股份有限公司 | 基于框式网络设备的限速方法和装置 |
CN110187957B (zh) * | 2019-05-27 | 2022-06-03 | 北京奇艺世纪科技有限公司 | 一种下载任务的排队方法、装置及电子设备 |
CN112579305A (zh) * | 2019-09-27 | 2021-03-30 | 北京国双科技有限公司 | 任务处理方法及装置、非易失性存储介质和设备 |
US11184278B2 (en) * | 2019-12-30 | 2021-11-23 | Avago Technologies International Sales Pte. Limited | Hyperscalar packet processing |
CN111610977B (zh) * | 2020-05-19 | 2024-06-25 | 腾讯科技(深圳)有限公司 | 一种编译方法和相关装置 |
CN111831436B (zh) * | 2020-07-01 | 2024-07-30 | Oppo广东移动通信有限公司 | Io请求的调度方法、装置、存储介质及电子设备 |
CN112015450B (zh) * | 2020-08-25 | 2024-01-19 | 深圳Tcl新技术有限公司 | 加载智能设备控制页面的方法、装置和存储介质 |
CN113515424A (zh) * | 2021-04-25 | 2021-10-19 | 广东邦盛北斗技术服务有限公司 | 队列堵塞判断方法和存储介质 |
CN113127208B (zh) * | 2021-05-06 | 2023-08-04 | 杭州天宽科技有限公司 | 一种基于线程限制用户访问服务的方法 |
CN113467933B (zh) * | 2021-06-15 | 2024-02-27 | 济南浪潮数据技术有限公司 | 分布式文件系统线程池优化方法、系统、终端及存储介质 |
CN116795514B (zh) * | 2023-06-30 | 2024-07-30 | 荣耀终端有限公司 | 应用程序的线程标识方法、电子设备以及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1805365A (zh) * | 2005-01-12 | 2006-07-19 | 北京航空航天大学 | Web服务分级服务质量处理器及处理方法 |
CN101167054A (zh) * | 2005-05-27 | 2008-04-23 | 国际商业机器公司 | 用于在多个数据中心之间选择性卸载工作负荷的方法和装置 |
CN101174318A (zh) * | 2006-10-30 | 2008-05-07 | 索尼爱立信移动通讯有限公司 | 排队装置、排队系统和排队方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090055831A1 (en) * | 2007-08-24 | 2009-02-26 | Bauman Ellen M | Allocating Network Adapter Resources Among Logical Partitions |
-
2012
- 2012-06-26 CN CN201210212637.8A patent/CN103516536B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1805365A (zh) * | 2005-01-12 | 2006-07-19 | 北京航空航天大学 | Web服务分级服务质量处理器及处理方法 |
CN101167054A (zh) * | 2005-05-27 | 2008-04-23 | 国际商业机器公司 | 用于在多个数据中心之间选择性卸载工作负荷的方法和装置 |
CN101174318A (zh) * | 2006-10-30 | 2008-05-07 | 索尼爱立信移动通讯有限公司 | 排队装置、排队系统和排队方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103516536A (zh) | 2014-01-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103516536B (zh) | 基于线程数量限制的服务器业务请求并行处理方法及系统 | |
Sriraman et al. | μ suite: a benchmark suite for microservices | |
CN112162865B (zh) | 服务器的调度方法、装置和服务器 | |
US9417935B2 (en) | Many-core process scheduling to maximize cache usage | |
US10484236B2 (en) | Performance of multi-processor computer systems | |
US20100153963A1 (en) | Workload management in a parallel database system | |
US9448864B2 (en) | Method and apparatus for processing message between processors | |
US20120222043A1 (en) | Process Scheduling Using Scheduling Graph to Minimize Managed Elements | |
Chatzistergiou et al. | Fast heuristics for near-optimal task allocation in data stream processing over clusters | |
WO2017097124A1 (zh) | 基于分库分表的任务传输方法、装置及系统 | |
CN102779075A (zh) | 一种在多处理器核系统中进行调度的方法、装置及系统 | |
CN107273200B (zh) | 一种针对异构存储的任务调度方法 | |
CN104199739B (zh) | 一种基于负载均衡的推测式Hadoop调度方法 | |
CN109992366A (zh) | 任务调度方法及调度装置 | |
CN108549574A (zh) | 线程调度管理方法、装置、计算机设备和存储介质 | |
JP2008152618A (ja) | ジョブ割当プログラム、方法及び装置 | |
Mohamed et al. | Hadoop-MapReduce job scheduling algorithms survey | |
CN113391913A (zh) | 一种基于预测的分布式调度方法和装置 | |
Maroulis et al. | A holistic energy-efficient real-time scheduler for mixed stream and batch processing workloads | |
US8510273B2 (en) | System, method, and computer-readable medium to facilitate application of arrival rate qualifications to missed throughput server level goals | |
CN108255595A (zh) | 一种数据任务的调度方法、装置、设备及可读存储介质 | |
CN105550025B (zh) | 分布式基础设施即服务(IaaS)调度方法及系统 | |
CN109582467A (zh) | 一种存储系统中io请求的处理方法、系统及相关装置 | |
GB2504812A (en) | Load balancing in a SAP (RTM) system for processors allocated to data intervals based on system load | |
Guo et al. | Handling data skew at reduce stage in Spark by ReducePartition |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right |
Effective date of registration: 20200605 Address after: Room 502-1, floor 5, building 2, courtyard 10, KEGU 1st Street, economic development zone, Daxing District, Beijing 100081 Patentee after: Singularity Xinyuan International Technology Development (Beijing) Co.,Ltd. Address before: The 401121 northern New District of Chongqing municipality Mount Huangshan Road 5 south of Mercury Technology Building 1 floor office No. 3 Patentee before: A-MEDIA COMMUNICATION TECH Co.,Ltd. |
|
TR01 | Transfer of patent right |