US20210044497A1 - Hybrid approach for rate limiting in distributed systems - Google Patents
Hybrid approach for rate limiting in distributed systems Download PDFInfo
- Publication number
- US20210044497A1 US20210044497A1 US16/537,409 US201916537409A US2021044497A1 US 20210044497 A1 US20210044497 A1 US 20210044497A1 US 201916537409 A US201916537409 A US 201916537409A US 2021044497 A1 US2021044497 A1 US 2021044497A1
- Authority
- US
- United States
- Prior art keywords
- request
- parameters
- controller
- servers
- determining
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5058—Service discovery by the service manager
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/781—Centralised allocation of resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
Definitions
- Embodiments discussed herein generally relate to resource provisioning and balancing.
- Web service providers for various industries have frequently used distributed network configurations to provide services to users around the global to achieve efficiency in managing resources and convenience in delivering services to the users. Most of the services are responded relatively quickly (e.g., serving web pages to page requests from users). For more intensive resource needs, such as web services that provide data access and storage for web site customers, web service providers may dedicate certain groups or clusters of servers for these web site customers. In addition, web service providers may use a manager or a controller to schedule and manage the requests and therefore resources in serving the customers.
- the central approach involves when a node in the distributed computer network receives a request from a requester, the node reports the request to a central service such as a manager or a controller.
- the central service reviews the request against the number of requests from all nodes to decide if the request is over a certain threshold or limit.
- This approach has the advantage of having the central service know the accuracy of request loads and thus avoid overloading or not meeting the completion requirements of a given request.
- This approach adds more latency and complexity to the management.
- the other common approach is a local approach: when a node in the distributed computer network receives a request, the node checks against the number of requests it has received to see if the number exceeds the total rate limit policy divided by the number of nodes.
- the advantage is that there would be no latency.
- the disadvantage is that the accuracy of the rate limit or threshold is poor because the number of nodes available for processing the requests can change at moment's notice and that the distribution of requests may not be evenly.
- Embodiments create a technical solution to the above challenges by modifying or updating the existing approaches.
- Aspects of embodiments enable an improved capability to enforce the rate limiting policies and the SLAs.
- the central approach may be employed to limit CPU, Memory and I/O intensive requests.
- the local approach may be employed to protect the system from high rate of quests.
- aspects of embodiments may address the accuracy issues (e.g., due to change of number of nodes) by discovering service status at each node so that each node may know how many nodes are currently active and local rate limit may be calculated dynamically.
- aspects of embodiments enable switching or changing thresholds as defined by rate or SLA requirements.
- FIG. 1 is a system diagram for flexible managing or controlling of resource usage according to one embodiment.
- FIG. 2 is a flowchart illustrating a computerized method according to one embodiment.
- FIG. 3 is a diagram illustrating one or more parameters for responding to a service request according to one embodiment.
- FIG. 4 is a diagram illustrating a portable computing device according to one embodiment.
- FIG. 5 is a diagram illustrating a computing device according to one embodiment.
- Embodiments may now be described more fully with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments which may be practiced. These illustrations and exemplary embodiments may be presented with the understanding that the present disclosure is an exemplification of the principles of one or more embodiments and may not be intended to limit any one of the embodiments illustrated. Embodiments may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure may be thorough and complete, and may fully convey the scope of embodiments to those skilled in the art. Among other things, the present invention may be embodied as methods, systems, computer readable media, apparatuses, or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. The following detailed description may, therefore, not to be taken in a limiting sense.
- Embodiments create a dynamic and flexible controlling or management of resource usage.
- the central approach may be employed to limit CPU, Memory and I/O intensive requests.
- the local approach may be employed to protect the system from high rate of quests.
- aspects of embodiments may address the accuracy issues (e.g., due to change of number of nodes) by discovering service status at each node so that each node may know how many nodes are currently active and local rate limit may be calculated dynamically.
- aspects of embodiments enable switching or changing thresholds as defined by rate or SLA requirements.
- the system 100 may be include a cluster of servers comprising computing devices such as a computing device 841 illustrated in FIG. 5 .
- the cluster of computing devices may be arranged in a distributed manner across a computer network 102 .
- the system 100 may also include database servers 104 that store data or provide storage needs for the system 100 .
- the clusters of servers in the system 100 may be arranged in a number of ways.
- the system 100 may arrange one or more nodes 106 as a front end nodes that receive requests from requesters 108 .
- the nodes 106 may be server endpoints of the system 100 .
- the requesters 108 - 1 , 108 - 2 , and 108 - 3 may be computing devices communicating directly with the system 100 .
- the requesters 108 may employ proxy servers or aggregator services that send requests to the system 100 .
- the requesters 108 may request services from the system 100 .
- the requesters 108 may be server endpoints and not client nodes.
- the system 100 may be part of a payment processing network, and the system 100 may provide a variety of services to the requesters 108 , such as payment transaction processing, payment data analysis, and payment data enhancement services.
- the system 100 with the cluster of servers, may utilize all the resources from the cluster of servers and the database servers 104 .
- the system 100 may include additional servers 110 that may be considered as nodes for the back end processing.
- the nodes 106 and 110 may be used interchangeably without departing from the scope and spirit of aspects of embodiments. In other words, the nodes 106 may perform backend processing while the nodes 110 may perform front end request handling as well.
- the system 100 may employ artificial intelligence (AI) as part of the services to the requesters 108 .
- AI artificial intelligence
- an AI engine may be installed in the system 100 to more efficiently configure the nodes 106 and 110 .
- the AI engine may study the past SLA or rate limiting policies by using them as training models so that the AI engine may suggest to the cluster of servers about how to configure or set the rate limits in the rate limiting policy or the SLA.
- the AI engine may also configure the identifying of the potential level of the request from the requesters 108 .
- the AI engine may suggest to the system 100 that a particular requester 108 may likely send requests with low rate limit or long SLA at a given period so that the system 100 may adaptively adjust its resources to accommodate to the requester's request.
- the requesters 108 may establish a service level agreement (SLA) with the system 100 to establish a relationship and expectation between the requesters 108 and the system 100 , a service provider.
- SLA service level agreement
- the SLA may describe the system 100 's commitments for uptime of its servers and connectivity between the various components and devices within the system 100 as provided by its hardware devices.
- the hardware devices may include the cluster or clusters of servers, database servers, network equipment, central processing unit (CPU), graphics processing unit (GPU), memory units, etc.
- the SLA may define further granularity to requests at the level of applications that request the services.
- the requesters 108 may request the services from the system 100 via application programming interface (API), such as via API calls.
- API application programming interface
- the system 100 may need to control or manage the requests efficiently so as to provide timely responses to the requesters 108 but also maintain acceptable loads on the resources.
- the system 100 may define or configure a rate limiting policy or rate limiting policies 114 based on a SLA, such as SLA 112 with the requesters 108 .
- the rate limiting policy 114 may restrict a number of requests by an application from of the requesters 108 (e.g., the requester 108 - 1 ).
- the rate limiting policy 114 may be client-ID based such that requests from a client-ID may be restricted based on the rate limiting policy 114 .
- the system 100 may assign a client-ID to a requester and provide token credentials in a form of query parameters.
- the system 100 may employ a request handler, controller, or manager 116 (hereinafter “controller” for short) to control or manage the requests.
- the controller 116 may be an application executable by the cluster of servers 106 .
- the controller 116 may be a dedicated server with application software designed to handle the task of controlling or managing the requests.
- the controller 116 may be a cluster of servers in a distributed network, such as the network 118 .
- the nodes 106 may first receive a request 122 from the requester 108 - 1 request a service from the system 100 at 202 .
- the nodes 106 and the requesters 108 may have a one-to-one relationship so that the nodes 106 may be configured to handle requests from the requesters 108 more efficiently.
- the system 100 may assign one or more nodes 116 to handle specific requesters 108 .
- the node Upon receiving the request 122 , the node (e.g., 106 - 1 ) may forward to the request 122 to the controller 116 for management.
- the controller 116 may first identify a rate limit policy (e.g., the rate policy 114 ) or the SLA 112 to determine the resource availability at 204 .
- the controller 116 may review the databases 104 to identify any parameters from the rate limiting policy 114 or the SLA 112 for the particular kind of request or the requests from the requesters 108 .
- the request 122 may include parameters such as client ID or token authentication assigned to the particular requester.
- the rate limiting policy 114 may identify that the limit is low.
- a low rate limit may indicate that the request may consume higher amount of resources, so to limit overloading of the resources, the rate limit may be low.
- the rate limiting 114 may also be determined by the number of nodes available for processing the request. For example, a number of node parameters may be available for the controller 116 to review before determining or calculating the rate limiting from the rate limiting policy 114 .
- the SLA 112 may be “long” or extensive, which may indicate that more complicated tasks or workloads are required.
- the SLA 112 may also include a timing parameter, which may specify how much time the system 100 has to complete the request.
- the SLA 112 may be set as automatic, meaning that all requests are approved. As such, the controller 116 may configure a rate limit for such kind of SLA 112 at high due to the need for less intensive loads.
- controller 116 may configure parameters such as location, node ID, etc., to further manage the request responses.
- the controller 116 may determine whether the parameters identified exceed a threshold. For example, the controller 116 may compare the rate limit value of the rate limiting policy 114 or the length of the SLA 112 with the threshold. In one embodiment, if the controller 116 determines that the rate limit value or the length of the SLA 112 does not exceed the threshold (e.g., rate limit is low or the SLA is long), at 208 , the controller 116 may compare the request with other requests received by all nodes, such as nodes 106 and 110 , in the system 100 to accept the request 122 .
- the controller 116 may compare the request with other requests received by all nodes, such as nodes 106 and 110 , in the system 100 to accept the request 122 .
- Such approach may provide better accuracy of the execution even though it introduces some latency due to the fact that the controller 116 may need time to determine the acceptance based on the comparison.
- the need to ensure that the request is performed according to the rate limiting policy and the SLA is of a higher priority.
- the controller 116 may compare the request 122 with a number of requests as a function of a total rate limit policy values divided by the number of nodes before accepting the request.
- the controller 116 may profile the request 122 based on AI algorithms. For example, the controller 116 may review historical data from the databases 104 to determine that requester 108 - 3 typically may send high frequency but low intensity requests. As such, the controller 116 may dynamically adjust the rate limit value high or threshold low so as to be able to accept the request without issues. On the other hand, if the controller 116 has identified a certain node (e.g., node 106 - 2 ) typically sends that tasks or loads that require fast turnaround time and long SLA, the controller 116 may dynamically adjust the rate limit value to ensure the other tasks from other requesters' may not interfere with the completion of the request from the node 106 - 2 .
- a certain node e.g., node 106 - 2
- the controller 116 may dynamically adjust the rate limit value to ensure the other tasks from other requesters' may not interfere with the completion of the request from the node 106 - 2 .
- the controller 116 further maintain a profile or profiles of requests to better manage or enforce the rate limit and the SLAs to safeguard resources of the system 100 .
- the controller 116 may dynamically configure or modify the rate limit based on the number of nodes available in the system to process and execute the request 122 . Such approach provides flexibility but also balancing accuracy and latency in accepting the request while rejecting others.
- FIG. 4 may be a high level illustration of a portable computing device 801 communicating with a remote computing device 841 in FIG. 5 but the application may be stored and accessed in a variety of ways.
- the application may be obtained in a variety of ways such as from an app store, from a web site, from a store Wi-Fi system, etc.
- There may be various versions of the application to take advantage of the benefits of different computing devices, different languages and different API platforms.
- a portable computing device 801 may be a mobile device 108 that operates using a portable power source 855 such as a battery.
- the portable computing device 801 may also have a display 802 which may or may not be a touch sensitive display. More specifically, the display 802 may have a capacitance sensor, for example, that may be used to provide input data to the portable computing device 801 .
- an input pad 804 such as arrows, scroll wheels, keyboards, etc., may be used to provide inputs to the portable computing device 801 .
- the portable computing device 801 may have a microphone 806 which may accept and store verbal data, a camera 808 to accept images and a speaker 810 to communicate sounds.
- the portable computing device 801 may be able to communicate with a computing device 841 or a plurality of computing devices 841 that make up a cloud of computing devices 811 .
- the portable computing device 801 may be able to communicate in a variety of ways.
- the communication may be wired such as through an Ethernet cable, a USB cable or RJ6 cable.
- the communication may be wireless such as through Wi-Fi® (802.11 standard), BLUETOOTH, cellular communication or near field communication devices.
- the communication may be direct to the computing device 841 or may be through a communication network 102 such as cellular service, through the Internet, through a private network, through BLUETOOTH, etc.
- FIG. 4 may be a simplified illustration of the physical elements that make up a portable computing device 801
- FIG. 5 may be a simplified illustration of the physical elements that make up a server type computing device 841 .
- FIG. 4 may be a sample portable computing device 801 that is physically configured according to be part of the system.
- the portable computing device 801 may have a processor 850 that is physically configured according to computer executable instructions. It may have a portable power supply 855 such as a battery which may be rechargeable. It may also have a sound and video module 860 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life.
- the portable computing device 801 may also have non-volatile memory 865 and volatile memory 870 . It may have GPS capabilities 880 that may be a separate circuit or may be part of the processor 850 .
- an input/output bus 875 that shuttles data to and from the various user input devices such as the microphone 806 , the camera 808 and other inputs, such as the input pad 804 , the display 802 , and the speakers 810 , etc., It also may control of communicating with the networks, either through wireless or wired devices.
- the portable computing device 801 this is just one embodiment of the portable computing device 801 and the number and types of portable computing devices 801 is limited only by the imagination.
- the system is more than just speeding a process but uses a computing system to achieve a better outcome.
- the computing device 841 may include a digital storage such as a magnetic disk, an optical disk, flash storage, non-volatile storage, etc. Structured data may be stored in the digital storage such as in a database.
- the server 841 may have a processor 1000 that is physically configured according to computer executable instructions. It may also have a sound and video module 1005 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life.
- the server 841 may also have volatile memory 1010 and non-volatile memory 1015 .
- the database 1025 may be stored in the memory 1010 or 1015 or may be separate.
- the database 1025 may also be part of a cloud of computing device 841 and may be stored in a distributed manner across a plurality of computing devices 841 .
- the input/output bus 1020 also may control of communicating with the networks, either through wireless or wired devices.
- the application may be on the local computing device 801 and in other embodiments, the application may be remote 841 . Of course, this is just one embodiment of the server 841 and the number and types of portable computing devices 841 is limited only by the imagination.
- the user devices, computers and servers described herein may be computers that may have, among other elements, a microprocessor (such as from the Intel® Corporation, AMD®, ARM®, Qualcomm®, or MediaTek®); volatile and non-volatile memory; one or more mass storage devices (e.g., a hard drive); various user input devices, such as a mouse, a keyboard, or a microphone; and a video display system.
- the user devices, computers and servers described herein may be running on any one of many operating systems including, but not limited to WINDOWS®, UNIX®, LINUX®, MAC® OS®, iOS®, or Android®. It is contemplated, however, that any suitable operating system may be used for the present invention.
- the servers may be a cluster of web servers, which may each be LINUX® based and supported by a load balancer that decides which of the cluster of web servers should process a request based upon the current request-load of the available server(s).
- the user devices, computers and servers described herein may communicate via networks, including the Internet, wide area network (WAN), local area network (LAN), Wi-Fi®, other computer networks (now known or invented in the future), and/or any combination of the foregoing.
- networks may connect the various components over any combination of wired and wireless conduits, including copper, fiber optic, microwaves, and other forms of radio frequency, electrical and/or optical communication techniques.
- any network may be connected to any other network in a different manner.
- the interconnections between computers and servers in system are examples. Any device described herein may communicate with any other device via one or more networks.
- the example embodiments may include additional devices and networks beyond those shown. Further, the functionality described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device, which may perform the functionality of the combined devices.
- Any of the software components or functions described in this application may be implemented as software code or computer readable instructions that may be executed by at least one processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques.
- the software code may be stored as a series of instructions or commands on a non-transitory computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM.
- a non-transitory computer readable medium such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM.
- RAM random access memory
- ROM read only memory
- magnetic medium such as a hard-drive or a floppy disk
- an optical medium such as a CD-ROM.
- One or more of the elements of the present system may be claimed as means for accomplishing a particular function. Where such means-plus-function elements are used to describe certain elements of a claimed system it may be understood by those of ordinary skill in the art having the present specification, figures and claims before them, that the corresponding structure includes a computer, processor, or microprocessor (as the case may be) programmed to perform the particularly recited function using functionality found in a computer after special programming and/or by implementing one or more algorithms to achieve the recited functionality as recited in the claims or steps described above.
- the present disclosure provides a solution to the long-felt need described above.
- the systems and methods overcome challenges dealing with the inability to update the latest encryption or cryptographic content associated with a third-party hosted resource.
- aspects of embodiments maintain the URL syntax without disturbing established protocol. Instead, embodiments change the flow of accessing the resource so that the content authors may send to the requester the latest version of the resource with the updated encryption or cryptographic content.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Databases & Information Systems (AREA)
- Evolutionary Computation (AREA)
- Medical Informatics (AREA)
- Software Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
- Embodiments discussed herein generally relate to resource provisioning and balancing.
- Web service providers for various industries have frequently used distributed network configurations to provide services to users around the global to achieve efficiency in managing resources and convenience in delivering services to the users. Most of the services are responded relatively quickly (e.g., serving web pages to page requests from users). For more intensive resource needs, such as web services that provide data access and storage for web site customers, web service providers may dedicate certain groups or clusters of servers for these web site customers. In addition, web service providers may use a manager or a controller to schedule and manage the requests and therefore resources in serving the customers.
- At times, however, there may be different needs from customers that may complicate the requests and therefore the reallocation of resources for web service providers. These complications involve geographic locations, nature of the requests and sometimes service level agreements (SLAs) between the providers and customers.
- For example, existing practices take a local approach and a central approach in handling and processing of resource requests. In one example, the central approach involves when a node in the distributed computer network receives a request from a requester, the node reports the request to a central service such as a manager or a controller. The central service reviews the request against the number of requests from all nodes to decide if the request is over a certain threshold or limit. This approach has the advantage of having the central service know the accuracy of request loads and thus avoid overloading or not meeting the completion requirements of a given request. The disadvantage is that this approach adds more latency and complexity to the management.
- The other common approach is a local approach: when a node in the distributed computer network receives a request, the node checks against the number of requests it has received to see if the number exceeds the total rate limit policy divided by the number of nodes. The advantage is that there would be no latency. However, the disadvantage is that the accuracy of the rate limit or threshold is poor because the number of nodes available for processing the requests can change at moment's notice and that the distribution of requests may not be evenly.
- Therefore, embodiments attempt to create a technical solution to address the deficiencies of the challenges above.
- Embodiments create a technical solution to the above challenges by modifying or updating the existing approaches. Aspects of embodiments enable an improved capability to enforce the rate limiting policies and the SLAs. In one embodiment, when a rate limit is low or the SLA is long, the central approach may be employed to limit CPU, Memory and I/O intensive requests. In another embodiment, when the rate limit is high or the SLA is short, the local approach may be employed to protect the system from high rate of quests. Moreover, aspects of embodiments may address the accuracy issues (e.g., due to change of number of nodes) by discovering service status at each node so that each node may know how many nodes are currently active and local rate limit may be calculated dynamically. Moreover, aspects of embodiments enable switching or changing thresholds as defined by rate or SLA requirements.
- Persons of ordinary skill in the art may appreciate that elements in the figures are illustrated for simplicity and clarity so not all connections and options have been shown. For example, common but well-understood elements that are useful or necessary in a commercially feasible embodiment may often not be depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure. It may be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art may understand that such specificity with respect to sequence is not actually required. It may also be understood that the terms and expressions used herein may be defined with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.
-
FIG. 1 is a system diagram for flexible managing or controlling of resource usage according to one embodiment. -
FIG. 2 is a flowchart illustrating a computerized method according to one embodiment. -
FIG. 3 is a diagram illustrating one or more parameters for responding to a service request according to one embodiment. -
FIG. 4 is a diagram illustrating a portable computing device according to one embodiment. -
FIG. 5 is a diagram illustrating a computing device according to one embodiment. - Embodiments may now be described more fully with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments which may be practiced. These illustrations and exemplary embodiments may be presented with the understanding that the present disclosure is an exemplification of the principles of one or more embodiments and may not be intended to limit any one of the embodiments illustrated. Embodiments may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure may be thorough and complete, and may fully convey the scope of embodiments to those skilled in the art. Among other things, the present invention may be embodied as methods, systems, computer readable media, apparatuses, or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. The following detailed description may, therefore, not to be taken in a limiting sense.
- Embodiments create a dynamic and flexible controlling or management of resource usage. When a rate limit is low or the SLA is long, the central approach may be employed to limit CPU, Memory and I/O intensive requests. In another embodiment, when the rate limit is high or the SLA is short, the local approach may be employed to protect the system from high rate of quests. Moreover, aspects of embodiments may address the accuracy issues (e.g., due to change of number of nodes) by discovering service status at each node so that each node may know how many nodes are currently active and local rate limit may be calculated dynamically. Moreover, aspects of embodiments enable switching or changing thresholds as defined by rate or SLA requirements.
- Referring now to
FIG. 1 , a diagram illustrates asystem 100 for flexible managing or controlling of resource usage according to one embodiment. In one embodiment, thesystem 100 may be include a cluster of servers comprising computing devices such as acomputing device 841 illustrated inFIG. 5 . In another embodiment, the cluster of computing devices may be arranged in a distributed manner across a computer network 102. For example, the cluster of computing devices may be spread across geographic regions. In another embodiment, thesystem 100 may also includedatabase servers 104 that store data or provide storage needs for thesystem 100. - The clusters of servers in the
system 100 may be arranged in a number of ways. For illustrative purposes and not as a limitation, thesystem 100 may arrange one ormore nodes 106 as a front end nodes that receive requests from requesters 108. In one embodiment, thenodes 106 may be server endpoints of thesystem 100. In another embodiment, the requesters 108-1, 108-2, and 108-3 may be computing devices communicating directly with thesystem 100. In another embodiment, the requesters 108 may employ proxy servers or aggregator services that send requests to thesystem 100. In one example, the requesters 108 may request services from thesystem 100. In another example, the requesters 108 may be server endpoints and not client nodes. For example, thesystem 100 may be part of a payment processing network, and thesystem 100 may provide a variety of services to the requesters 108, such as payment transaction processing, payment data analysis, and payment data enhancement services. As such, thesystem 100, with the cluster of servers, may utilize all the resources from the cluster of servers and thedatabase servers 104. In addition, thesystem 100 may include additional servers 110 that may be considered as nodes for the back end processing. However, it is to be understood that thenodes 106 and 110 may be used interchangeably without departing from the scope and spirit of aspects of embodiments. In other words, thenodes 106 may perform backend processing while the nodes 110 may perform front end request handling as well. - In one embodiment, the
system 100 may employ artificial intelligence (AI) as part of the services to the requesters 108. In one embodiment, an AI engine may be installed in thesystem 100 to more efficiently configure thenodes 106 and 110. For example, the AI engine may study the past SLA or rate limiting policies by using them as training models so that the AI engine may suggest to the cluster of servers about how to configure or set the rate limits in the rate limiting policy or the SLA. In another embodiment, the AI engine may also configure the identifying of the potential level of the request from the requesters 108. For example, the AI engine may suggest to thesystem 100 that a particular requester 108 may likely send requests with low rate limit or long SLA at a given period so that thesystem 100 may adaptively adjust its resources to accommodate to the requester's request. - According to one aspect, the requesters 108 may establish a service level agreement (SLA) with the
system 100 to establish a relationship and expectation between the requesters 108 and thesystem 100, a service provider. For example, the SLA may describe thesystem 100's commitments for uptime of its servers and connectivity between the various components and devices within thesystem 100 as provided by its hardware devices. In one example, the hardware devices may include the cluster or clusters of servers, database servers, network equipment, central processing unit (CPU), graphics processing unit (GPU), memory units, etc. In another embodiment, the SLA may define further granularity to requests at the level of applications that request the services. - In another embodiment, the requesters 108 may request the services from the
system 100 via application programming interface (API), such as via API calls. To satisfy the needs of the requesters 108 per SLA, thesystem 100 may need to control or manage the requests efficiently so as to provide timely responses to the requesters 108 but also maintain acceptable loads on the resources. - In one embodiment, the
system 100 may define or configure a rate limiting policy orrate limiting policies 114 based on a SLA, such asSLA 112 with the requesters 108. In one embodiment, therate limiting policy 114 may restrict a number of requests by an application from of the requesters 108 (e.g., the requester 108-1). In another embodiment, therate limiting policy 114 may be client-ID based such that requests from a client-ID may be restricted based on therate limiting policy 114. For example, thesystem 100 may assign a client-ID to a requester and provide token credentials in a form of query parameters. - Given the limited resources the
system 100 has, thesystem 100 may employ a request handler, controller, or manager 116 (hereinafter “controller” for short) to control or manage the requests. Thecontroller 116 may be an application executable by the cluster ofservers 106. In another embodiment, thecontroller 116 may be a dedicated server with application software designed to handle the task of controlling or managing the requests. In a further embodiment, thecontroller 116 may be a cluster of servers in a distributed network, such as thenetwork 118. - Referring now to
FIG. 2 , a flow chart illustrates a computer-implement method of aspects of embodiments. In one embodiment, thenodes 106 may first receive arequest 122 from the requester 108-1 request a service from thesystem 100 at 202. In one embodiment, thenodes 106 and the requesters 108 may have a one-to-one relationship so that thenodes 106 may be configured to handle requests from the requesters 108 more efficiently. As discussed with theSLA 112 above, thesystem 100 may assign one ormore nodes 116 to handle specific requesters 108. - Upon receiving the
request 122, the node (e.g., 106-1) may forward to therequest 122 to thecontroller 116 for management. In one embodiment, thecontroller 116 may first identify a rate limit policy (e.g., the rate policy 114) or theSLA 112 to determine the resource availability at 204. For example, thecontroller 116 may review thedatabases 104 to identify any parameters from therate limiting policy 114 or theSLA 112 for the particular kind of request or the requests from the requesters 108. In one embodiment, therequest 122 may include parameters such as client ID or token authentication assigned to the particular requester. In another embodiment, therate limiting policy 114 may identify that the limit is low. For example, a low rate limit may indicate that the request may consume higher amount of resources, so to limit overloading of the resources, the rate limit may be low. In another embodiment, the rate limiting 114 may also be determined by the number of nodes available for processing the request. For example, a number of node parameters may be available for thecontroller 116 to review before determining or calculating the rate limiting from therate limiting policy 114. - In another embodiment, the
SLA 112 may be “long” or extensive, which may indicate that more complicated tasks or workloads are required. In a further embodiment, theSLA 112 may also include a timing parameter, which may specify how much time thesystem 100 has to complete the request. In another embodiment, theSLA 112 may be set as automatic, meaning that all requests are approved. As such, thecontroller 116 may configure a rate limit for such kind ofSLA 112 at high due to the need for less intensive loads. - It is to be understood that one or more parameters other than those shown in
FIG. 3 may be included without departing from the scope and spirit of aspects of embodiments. For the example, thecontroller 116 may configure parameters such as location, node ID, etc., to further manage the request responses. - At 206, in response to identifying the parameters, the
controller 116 may determine whether the parameters identified exceed a threshold. For example, thecontroller 116 may compare the rate limit value of therate limiting policy 114 or the length of theSLA 112 with the threshold. In one embodiment, if thecontroller 116 determines that the rate limit value or the length of theSLA 112 does not exceed the threshold (e.g., rate limit is low or the SLA is long), at 208, thecontroller 116 may compare the request with other requests received by all nodes, such asnodes 106 and 110, in thesystem 100 to accept therequest 122. Such approach may provide better accuracy of the execution even though it introduces some latency due to the fact that thecontroller 116 may need time to determine the acceptance based on the comparison. However, due to the complexity involved with the request, the need to ensure that the request is performed according to the rate limiting policy and the SLA is of a higher priority. - On the other hand, if the rate limit value or the length of
SLA 112 exceeds the threshold (e.g., rate limit is high or the SLA is short), at 210 thecontroller 116 may compare therequest 122 with a number of requests as a function of a total rate limit policy values divided by the number of nodes before accepting the request. - In another aspect, the
controller 116 may profile therequest 122 based on AI algorithms. For example, thecontroller 116 may review historical data from thedatabases 104 to determine that requester 108-3 typically may send high frequency but low intensity requests. As such, thecontroller 116 may dynamically adjust the rate limit value high or threshold low so as to be able to accept the request without issues. On the other hand, if thecontroller 116 has identified a certain node (e.g., node 106-2) typically sends that tasks or loads that require fast turnaround time and long SLA, thecontroller 116 may dynamically adjust the rate limit value to ensure the other tasks from other requesters' may not interfere with the completion of the request from the node 106-2. - In a further embodiment, the
controller 116 further maintain a profile or profiles of requests to better manage or enforce the rate limit and the SLAs to safeguard resources of thesystem 100. Thecontroller 116 may dynamically configure or modify the rate limit based on the number of nodes available in the system to process and execute therequest 122. Such approach provides flexibility but also balancing accuracy and latency in accepting the request while rejecting others. -
FIG. 4 may be a high level illustration of aportable computing device 801 communicating with aremote computing device 841 inFIG. 5 but the application may be stored and accessed in a variety of ways. In addition, the application may be obtained in a variety of ways such as from an app store, from a web site, from a store Wi-Fi system, etc. There may be various versions of the application to take advantage of the benefits of different computing devices, different languages and different API platforms. - In one embodiment, a
portable computing device 801 may be a mobile device 108 that operates using aportable power source 855 such as a battery. Theportable computing device 801 may also have adisplay 802 which may or may not be a touch sensitive display. More specifically, thedisplay 802 may have a capacitance sensor, for example, that may be used to provide input data to theportable computing device 801. In other embodiments, aninput pad 804 such as arrows, scroll wheels, keyboards, etc., may be used to provide inputs to theportable computing device 801. In addition, theportable computing device 801 may have amicrophone 806 which may accept and store verbal data, acamera 808 to accept images and aspeaker 810 to communicate sounds. - The
portable computing device 801 may be able to communicate with acomputing device 841 or a plurality ofcomputing devices 841 that make up a cloud of computing devices 811. Theportable computing device 801 may be able to communicate in a variety of ways. In some embodiments, the communication may be wired such as through an Ethernet cable, a USB cable or RJ6 cable. In other embodiments, the communication may be wireless such as through Wi-Fi® (802.11 standard), BLUETOOTH, cellular communication or near field communication devices. The communication may be direct to thecomputing device 841 or may be through a communication network 102 such as cellular service, through the Internet, through a private network, through BLUETOOTH, etc.,FIG. 4 may be a simplified illustration of the physical elements that make up aportable computing device 801 andFIG. 5 may be a simplified illustration of the physical elements that make up a servertype computing device 841. -
FIG. 4 may be a sampleportable computing device 801 that is physically configured according to be part of the system. Theportable computing device 801 may have aprocessor 850 that is physically configured according to computer executable instructions. It may have aportable power supply 855 such as a battery which may be rechargeable. It may also have a sound andvideo module 860 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. Theportable computing device 801 may also havenon-volatile memory 865 andvolatile memory 870. It may haveGPS capabilities 880 that may be a separate circuit or may be part of theprocessor 850. There also may be an input/output bus 875 that shuttles data to and from the various user input devices such as themicrophone 806, thecamera 808 and other inputs, such as theinput pad 804, thedisplay 802, and thespeakers 810, etc., It also may control of communicating with the networks, either through wireless or wired devices. Of course, this is just one embodiment of theportable computing device 801 and the number and types ofportable computing devices 801 is limited only by the imagination. - As a result of the system, better information may be provided to a user at a point of sale. The information may be user specific and may be required to be over a threshold of relevance. As a result, users may make better informed decisions. The system is more than just speeding a process but uses a computing system to achieve a better outcome.
- The physical elements that make up the
remote computing device 841 may be further illustrated inFIG. 5 . At a high level, thecomputing device 841 may include a digital storage such as a magnetic disk, an optical disk, flash storage, non-volatile storage, etc. Structured data may be stored in the digital storage such as in a database. Theserver 841 may have aprocessor 1000 that is physically configured according to computer executable instructions. It may also have a sound andvideo module 1005 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. Theserver 841 may also havevolatile memory 1010 andnon-volatile memory 1015. - The
database 1025 may be stored in thememory database 1025 may also be part of a cloud ofcomputing device 841 and may be stored in a distributed manner across a plurality ofcomputing devices 841. There also may be an input/output bus 1020 that shuttles data to and from the various user input devices such as themicrophone 806, thecamera 808, the inputs such as theinput pad 804, thedisplay 802, and thespeakers 810, etc., The input/output bus 1020 also may control of communicating with the networks, either through wireless or wired devices. In some embodiments, the application may be on thelocal computing device 801 and in other embodiments, the application may be remote 841. Of course, this is just one embodiment of theserver 841 and the number and types ofportable computing devices 841 is limited only by the imagination. - The user devices, computers and servers described herein may be computers that may have, among other elements, a microprocessor (such as from the Intel® Corporation, AMD®, ARM®, Qualcomm®, or MediaTek®); volatile and non-volatile memory; one or more mass storage devices (e.g., a hard drive); various user input devices, such as a mouse, a keyboard, or a microphone; and a video display system. The user devices, computers and servers described herein may be running on any one of many operating systems including, but not limited to WINDOWS®, UNIX®, LINUX®, MAC® OS®, iOS®, or Android®. It is contemplated, however, that any suitable operating system may be used for the present invention. The servers may be a cluster of web servers, which may each be LINUX® based and supported by a load balancer that decides which of the cluster of web servers should process a request based upon the current request-load of the available server(s).
- The user devices, computers and servers described herein may communicate via networks, including the Internet, wide area network (WAN), local area network (LAN), Wi-Fi®, other computer networks (now known or invented in the future), and/or any combination of the foregoing. It should be understood by those of ordinary skill in the art having the present specification, drawings, and claims before them that networks may connect the various components over any combination of wired and wireless conduits, including copper, fiber optic, microwaves, and other forms of radio frequency, electrical and/or optical communication techniques. It should also be understood that any network may be connected to any other network in a different manner. The interconnections between computers and servers in system are examples. Any device described herein may communicate with any other device via one or more networks.
- The example embodiments may include additional devices and networks beyond those shown. Further, the functionality described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device, which may perform the functionality of the combined devices.
- The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described Figures, including any servers, user devices, or databases, may use any suitable number of subsystems to facilitate the functions described herein.
- Any of the software components or functions described in this application, may be implemented as software code or computer readable instructions that may be executed by at least one processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques.
- The software code may be stored as a series of instructions or commands on a non-transitory computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus and may be present on or within different computational apparatuses within a system or network.
- It may be understood that the present invention as described above may be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art may know and appreciate other ways and/or methods to implement the present invention using hardware, software, or a combination of hardware and software.
- The above description is illustrative and is not restrictive. Many variations of embodiments may become apparent to those skilled in the art upon review of the disclosure. The scope embodiments should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
- One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope embodiments. A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. Recitation of “and/or” is intended to represent the most inclusive sense of the term unless specifically indicated to the contrary.
- One or more of the elements of the present system may be claimed as means for accomplishing a particular function. Where such means-plus-function elements are used to describe certain elements of a claimed system it may be understood by those of ordinary skill in the art having the present specification, figures and claims before them, that the corresponding structure includes a computer, processor, or microprocessor (as the case may be) programmed to perform the particularly recited function using functionality found in a computer after special programming and/or by implementing one or more algorithms to achieve the recited functionality as recited in the claims or steps described above. As would be understood by those of ordinary skill in the art that algorithm may be expressed within this disclosure as a mathematical formula, a flow chart, a narrative, and/or in any other manner that provides sufficient structure for those of ordinary skill in the art to implement the recited process and its equivalents.
- While the present disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one embodiments to the embodiments illustrated.
- The present disclosure provides a solution to the long-felt need described above. In particular, the systems and methods overcome challenges dealing with the inability to update the latest encryption or cryptographic content associated with a third-party hosted resource. However, aspects of embodiments maintain the URL syntax without disturbing established protocol. Instead, embodiments change the flow of accessing the resource so that the content authors may send to the requester the latest version of the resource with the updated encryption or cryptographic content.
- Further advantages and modifications of the above described system and method may readily occur to those skilled in the art.
- The disclosure, in its broader aspects, is therefore not limited to the specific details, representative system and methods, and illustrative examples shown and described above. Various modifications and variations may be made to the above specification without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure covers all such modifications and variations provided they come within the scope of the following claims and their equivalents.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/537,409 US20210044497A1 (en) | 2019-08-09 | 2019-08-09 | Hybrid approach for rate limiting in distributed systems |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/537,409 US20210044497A1 (en) | 2019-08-09 | 2019-08-09 | Hybrid approach for rate limiting in distributed systems |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210044497A1 true US20210044497A1 (en) | 2021-02-11 |
Family
ID=74499407
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/537,409 Abandoned US20210044497A1 (en) | 2019-08-09 | 2019-08-09 | Hybrid approach for rate limiting in distributed systems |
Country Status (1)
Country | Link |
---|---|
US (1) | US20210044497A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11115284B1 (en) * | 2020-03-31 | 2021-09-07 | Atlassian Pty Ltd. | Techniques for dynamic rate-limiting |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130060933A1 (en) * | 2011-09-07 | 2013-03-07 | Teresa Tung | Cloud service monitoring system |
US20140289391A1 (en) * | 2013-03-19 | 2014-09-25 | Cognizant Technology Solutions India Pvt. Ltd. | Framework for facilitating implementation of multi-tenant saas architecture |
US20140359113A1 (en) * | 2013-05-30 | 2014-12-04 | Sap Ag | Application level based resource management in multi-tenant applications |
US20170324620A1 (en) * | 2016-05-04 | 2017-11-09 | Alcatel-Lucent Canada Inc. | Infrastructure resource states |
US20180101214A1 (en) * | 2016-10-10 | 2018-04-12 | International Business Machines Corporation | Sla-based power management in disaggregated computing systems |
US20190004863A1 (en) * | 2017-06-30 | 2019-01-03 | Microsoft Technology Licensing, Llc | Hash-based partitioning system |
US20190123973A1 (en) * | 2017-10-24 | 2019-04-25 | Cisco Technology, Inc. | Inter-tenant workload performance correlation and recommendation |
US20200036593A1 (en) * | 2018-07-26 | 2020-01-30 | Cisco Technology, Inc. | Synthesis of models for networks using automated boolean learning |
US10616078B1 (en) * | 2014-03-20 | 2020-04-07 | Amazon Technologies, Inc. | Detecting deviating resources in a virtual environment |
US20210152658A1 (en) * | 2016-02-29 | 2021-05-20 | Red Hat, Inc. | Quality of service in a distributed system |
-
2019
- 2019-08-09 US US16/537,409 patent/US20210044497A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130060933A1 (en) * | 2011-09-07 | 2013-03-07 | Teresa Tung | Cloud service monitoring system |
US20140289391A1 (en) * | 2013-03-19 | 2014-09-25 | Cognizant Technology Solutions India Pvt. Ltd. | Framework for facilitating implementation of multi-tenant saas architecture |
US20140359113A1 (en) * | 2013-05-30 | 2014-12-04 | Sap Ag | Application level based resource management in multi-tenant applications |
US10616078B1 (en) * | 2014-03-20 | 2020-04-07 | Amazon Technologies, Inc. | Detecting deviating resources in a virtual environment |
US20210152658A1 (en) * | 2016-02-29 | 2021-05-20 | Red Hat, Inc. | Quality of service in a distributed system |
US20170324620A1 (en) * | 2016-05-04 | 2017-11-09 | Alcatel-Lucent Canada Inc. | Infrastructure resource states |
US20180101214A1 (en) * | 2016-10-10 | 2018-04-12 | International Business Machines Corporation | Sla-based power management in disaggregated computing systems |
US20190004863A1 (en) * | 2017-06-30 | 2019-01-03 | Microsoft Technology Licensing, Llc | Hash-based partitioning system |
US20190123973A1 (en) * | 2017-10-24 | 2019-04-25 | Cisco Technology, Inc. | Inter-tenant workload performance correlation and recommendation |
US20200036593A1 (en) * | 2018-07-26 | 2020-01-30 | Cisco Technology, Inc. | Synthesis of models for networks using automated boolean learning |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11115284B1 (en) * | 2020-03-31 | 2021-09-07 | Atlassian Pty Ltd. | Techniques for dynamic rate-limiting |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110545246B (en) | Token bucket-based current limiting method, device and computer readable medium | |
US10055239B2 (en) | Resource optimization recommendations | |
RU2699397C2 (en) | Opportunistic connection of private computing resources with external services | |
US8595722B2 (en) | Preprovisioning virtual machines based on request frequency and current network configuration | |
US9081610B2 (en) | Method and apparatus to maximize return on investment in hybrid cloud environment | |
US20170235585A1 (en) | Management of IoT Devices in a Virtualized Network | |
US10609118B2 (en) | Adaptive communication control device | |
US20150172204A1 (en) | Dynamically Change Cloud Environment Configurations Based on Moving Workloads | |
US11609796B2 (en) | Dynamic capacity optimization for shared computing resources segmented into reservation zones | |
WO2017016113A1 (en) | Method and device for monitoring network traffic | |
US11245748B1 (en) | Proxied nodes in a container orchestration environment for scalable resource allocation | |
Pourghaffari et al. | An efficient method for allocating resources in a cloud computing environment with a load balancing approach | |
CN112600761B (en) | Resource allocation method, device and storage medium | |
US11949737B1 (en) | Allocation of server resources in remote-access computing environments | |
US9703597B2 (en) | Dynamic timeout period adjustment of service requests | |
Shruthi et al. | The resource allocation using weighted greedy knapsack based algorithm in an educational fog computing environment | |
Kanbar et al. | Region aware dynamic task scheduling and resource virtualization for load balancing in IoT–fog multi-cloud environment | |
Chunlin et al. | Distributed QoS-aware scheduling optimization for resource-intensive mobile application in hybrid cloud | |
Sulimani et al. | Reinforcement optimization for decentralized service placement policy in IoT‐centric fog environment | |
US20210044497A1 (en) | Hybrid approach for rate limiting in distributed systems | |
US20220269537A1 (en) | Artificial intelligence (ai) workload sharing system and method of using the same | |
CN114765613A (en) | Client-driven cloud network access system and method | |
US10887381B1 (en) | Management of allocated computing resources in networked environment | |
US11233847B1 (en) | Management of allocated computing resources in networked environment | |
Nir | Scalable resource augmentation for mobile devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LU, RANGLIN;REEL/FRAME:050472/0807 Effective date: 20190903 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |