Source: https://patents.google.com/patent/US9529626B2/en
Timestamp: 2019-07-16 07:36:15
Document Index: 551726239

Matched Legal Cases: ['Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'in fine']

US9529626B2 - Facilitating equitable distribution of thread resources for job types associated with tenants in a multi-tenant on-demand services environment - Google Patents
Facilitating equitable distribution of thread resources for job types associated with tenants in a multi-tenant on-demand services environment Download PDF
US9529626B2
US9529626B2 US13/841,417 US201313841417A US9529626B2 US 9529626 B2 US9529626 B2 US 9529626B2 US 201313841417 A US201313841417 A US 201313841417A US 9529626 B2 US9529626 B2 US 9529626B2
US13/841,417
US20140075030A1 (en
Vijayanth Devadhar
2012-09-12 Priority to US201261700037P priority Critical
2012-09-12 Priority to US201261700032P priority
2012-10-01 Priority to US201261708283P priority
2012-10-03 Priority to US201261709263P priority
2012-10-10 Priority to US201261711837P priority
2013-03-15 Assigned to SALESFORCE.COM, INC. reassignment SALESFORCE.COM, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DEVADHAR, VIJAYANTH, MURUGESAN, Praveen, WANG, XIAODAN
2013-03-15 Priority to US13/841,417 priority patent/US9529626B2/en
2013-03-15 Application filed by salesforce com Inc filed Critical salesforce com Inc
2014-03-13 Publication of US20140075030A1 publication Critical patent/US20140075030A1/en
2016-12-27 Publication of US9529626B2 publication Critical patent/US9529626B2/en
In accordance with embodiments, there are provided mechanisms and methods for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment in an on-demand services environment. In one embodiment and by way of example, a method includes tracking resource usage associated with a plurality of messages performed and completed in response to requests placed by a user via a user interface at a computing device, where the tracking includes recording an amount of resources consumed by each completed message. The method may further include classifying the plurality of messages into job types based on the tracked resource usage associated with the plurality of messages, and enforcing, based on the classification of the messages, a message selection process to ensure equitable distribution of resources to subsequently received messages.
This application claims the benefit of U.S. Provisional Patent Application No. 61/708,283, entitled “System and Method for Allocation of Resources in an On-Demand System” by Xiaodan Wang, et al., filed Oct. 1, 2012, U.S. Provisional Patent Application No. 61/711,837, entitled “System and Method for Auction-Based Multi-Tenant Resource Sharing” by Xiaodan Wang, filed Oct. 10, 2012, U.S. Provisional Patent Application No. 61/709,263, entitled “System and Method for Quorum-Based Coordination of Broker Health” by Xiaodan Wang, et al., filed Oct. 3, 2012, U.S. Provisional Patent Application No. 61/700,032, entitled “Adaptive, Tiered, and Multi-Tenant Routing Framework for Workload Scheduling” by Xiaodan Wang, et al., filed Sep. 12, 2012, U.S. Provisional Patent Application No. 61/700,037, entitled “Sliding Window Resource Tracking in Message Queue” by Xiaodan Wang, et al., filed Sep. 12, 2012, the entire contents of which are incorporated herein by reference and priority is claimed thereof, the entire contents of which are incorporated herein by reference and priority is claimed thereof.
One or more implementations relate generally to data management and, more specifically, to a mechanism for facilitating management and allocation of thread resources for message queues in an on-demand services environment.
Large-scale cloud platform vendors and service providers receive millions of asynchronous and resource-intensive customer requests each day that make for extremely cumbersome resource allocation and scalability requirements for the service providers. Most customers get frustrated waiting for their request to be fulfilled because none of the conventional techniques provide for any real-time guarantees in responding to such requests. Moreover, multi-tenancy means that multiple users compete for a limited pool of resources, making it even more complex to ensure proper scheduling of resources in a manner that is consistent with customer expectations.
Distributing point of delivery resources, such as application server thread time, equitably among different types of messages has been a challenge, particularly in a multi-tenant on-demand system. A message refers to a unit of work that is performed on an application server. Messages can be grouped into any number of types, such as roughly 300 types, ranging from user facing work such as refreshing a report on the dashboard to internal work, such as deleting unused files. As such, messages exhibit wide variability in the amount of resources they consume including thread time. This can lead to starvation by long running messages, which deprive short messages from receiving their fair share of thread time. When this impacts customer-facing work, such as a dashboard, customers are likely to dislike and complain when faced with performance degradation.
FIG. 1 illustrates a computing device employing a thread resource management mechanism according to one embodiment;
FIG. 2 illustrates a thread resource management mechanism according to one embodiment;
FIG. 3A illustrates a fair allocation and usage of thread resources using sliding window maintenance as provided by the thread resource management mechanism of FIG. 1 according to one embodiment;
FIG. 3A-3B illustrate a fair allocation and usage of thread resources using sliding window maintenance as provided by the thread resource management mechanism of FIG. 1 according to one embodiment;
FIG. 3C illustrates architecture for facilitating a fair allocation and usage of thread resources using sliding window maintenance as provided by thread resource management mechanism of FIG. 1 according to one embodiment;
FIG. 4A-4B illustrate methods for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment;
FIGS. 4C-4D illustrates transaction sequences for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment;
Methods and systems are provided for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment in an on-demand services environment. In one embodiment and by way of example, a method includes tracking resource usage associated with a plurality of messages performed and completed in response to requests placed by a user via a user interface at a computing device, where the tracking includes recording an amount of resources consumed by each completed message. The method may further include classifying the plurality of messages into job types based on the tracked resource usage associated with the plurality of messages, and enforcing, based on the classification of the messages, a message selection process to ensure equitable distribution of resources to subsequently received messages.
Large-scale cloud platform vendors and service providers receive millions of asynchronous and resource-intensive customer requests each day that make for extremely cumbersome resource utilization and continued scalability for the service providers. Moreover, multi-tenancy means that multiple users compete for a limited pool of resources, making it even more complex to ensure proper scheduling of resources in a manner that is consistent of customer expectations. Embodiments provide for a novel mechanism having a novel scheduling framework for: 1) differentiating customer requests based on latency of tasks, such that low latency tasks are performed after long running background tasks; and 2) isolating tasks based on their resource requirement and/or customer affiliation so that a task requested by one customer may not occupy the entire system and starve off other tasks requested by other customers. Embodiments further provide for the mechanism to utilize resources efficiently to ensure high throughput even when contention is high, such as any available resources may not remain idle if tasks are waiting to be scheduled.
Embodiments disclosed herein relate to providing a novel mechanism including a scheduling framework in a message queue (“MQ”) to facilitate fair allocation of thread resources among competing message types at a point of delivery (“POD”).
Next, mechanisms and methods for facilitating mechanism for facilitating allocation of thread resources in an on-demand services environment will be described with reference to example embodiments.
FIG. 1 illustrates a computing device 100 employing a thread resource management mechanism 110 according to one embodiment. In one embodiment, computing device 100 serves as a host machine employing a thread resource management mechanism (“resource mechanism”) 110 for message queues for facilitating dynamic management of application server thread resources facilitating fair and efficient management of thread resources and their corresponding messages, including their tracking, allocation, routing, etc., for providing better management of system resources as well as promoting user-control and customization of various services typically desired or necessitated by a user (e.g., a company, a corporation, an organization, a business, an agency, an institution, etc.). The user refers to a customer of a service provider (e.g., Salesforce.com) that provides and manages resource mechanism 110 at a host machine, such as computing device 100.
Computing device 100 includes an operating system (OS) 106 serving as an interface between any hardware or physical resources of the computing device 100 and a user. Computing device 100 further includes one or more processors 102, memory devices 104, network devices, drivers, or the like, as well as input/output (I/O) sources 108, such as touchscreens, touch panels, touch pads, virtual or regular keyboards, virtual or regular mice, etc. It is to be noted that terms like “node”, “computing node”, “client”, “client device”, “server”, “server device”, “cloud computer”, “cloud server”, “cloud server computer”, “machine”, “host machine”, “device”, “computing device”, “computer”, “computing system”, “multi-tenant on-demand data system”, and the like, may be used interchangeably throughout this document. It is to be further noted that terms like “application”, “software application”, “program”, “software program”, “package”, and “software package” may be used interchangeably throughout this document. Moreover, terms like “job”, “request” and “message” may be used interchangeably throughout this document.
FIG. 2 illustrates a thread resource management mechanism 110 according to one embodiment. In one embodiment, resource mechanism 110 provides a novel scheduling framework for message queue management to facilitate fair allocation of thread resources among competing message types at a point of delivery.
In the illustrated embodiment, resource mechanism 110 may include various components, such as administrative framework 200 including request reception and authentication logic 202, analyzer 204, communication/access logic 206, and compatibility logic 208. Resource mechanism 110 includes additional components, such as processing framework 210 having resource allocation logic 212, auction-based resource sharing logic 232, quorum-based broker health logic 252, workload scheduling routing logic 262, and sliding window maintenance logic 272. In one embodiment, resource allocation logic 212 may include identification module 214, measurement and computation module 216, job scheduler 218 including fair usage intervention trigger 220 and job execution engine 222, resource utilization tracker 224 including sliding window digest 226 and fair usage monitor 228, and enforcement module 230.
It is contemplated that any number and type of components may be added to and/or removed from resource mechanism 110 to facilitate various embodiments including adding, removing, and/or enhancing certain features. For brevity, clarity, and ease of understanding of resource mechanism 110, many of the standard and/or known components, such as those of a computing device, are not shown or discussed here. It is contemplated that embodiments are not limited to any particular technology, topology, system, architecture, and/or standard and are dynamic enough to adopt and adapt to any future changes.
In some embodiments, resource mechanism 110 may be in communication with database 280 to store data, metadata, tables, reports, etc., relating to messaging queues, etc. Resource mechanism 110 may be further in communication with any number and type of client computing devices, such as client computing device 290 over network 285. Throughout this document, the term “logic” may be interchangeably referred to as “framework” or “component” or “module” and may include, by way of example, software, hardware, and/or any combination of software and hardware, such as firmware. This combination of components provided through resource mechanism 110 facilitates user-based control and manipulation of particular data products/software applications (e.g., social websites, business websites, word processing, spreadsheets, database products, etc.) to be manipulated, shared, communicated, and displayed in any number and type of formats as desired or necessitated by user and communicated through user interface 294 at client computing device 292 and over network 290.
It is contemplated that a user may include an administrative user or an end-user. An administrative user may include an authorized and/or trained user, such as a system administrator, a software developer, a computer programmer, etc. In contrast, an end-user may be any user that can access a client computing device, such as via a software application or an Internet browser. In one embodiment, a user, via user interface 294 at client computing device 290, may manipulate or request data as well as view the data and any related metadata in a particular format (e.g., table, spreadsheet, etc.) as desired or necessitated by the user. Examples of users may include, but are not limited to, customers (e.g., end-user) or employees (e.g., administrative user) relating to organizations, such as organizational customers (e.g., small and large businesses, companies, corporations, academic institutions, government agencies, non-profit organizations, etc.) of a service provider (e.g., Salesforece.com). It is to be noted that terms like “user”, “customer”, “organization”, “business”, “company”, etc., may be used interchangeably throughout this document.
In one embodiment, resource mechanism 110 may be employed at a server computing system, such as computing device 100 of FIG. 1, and may be in communication with one or more client computing devices, such as client computing device 290, over a network, such as network 285 (e.g., a cloud-based network, the Internet, etc.). As aforementioned, a user may include an organization or organizational customer, such as a company, a business, etc., that is a customer to a provider (e.g., Salesforce.com) that provides access to resource mechanism 110 (such as via client computer 290). Similarly, a user may further include an individual or a small business, etc., that is a customer of the organization/organizational customer and accesses resource mechanism 110 via another client computing device. Client computing device 290 may be the same as or similar to computing device 100 of FIG. 1 and include a mobile computing device (e.g., smartphones, tablet computers, etc.) or larger computers (e.g., desktop computers, server computers, etc.).
In one embodiment, resource mechanism 110 facilitates fair and efficient management of message routing and queues for efficient management of system resources, such as application servers, etc., and providing better customer service, where the users may accessing these services via user interface 294 provided through any number and type of software applications (e.g., websites, etc.) employing social and business networking products, such as Chatter® by Salesforce.com, Facebook®, LinkedIn®, etc.
In one embodiment, request reception and authentication logic 202 may be used to receive a request (e.g., print a document, move a document, merge documents, run a report, display data, etc.) placed by a user via client computing device 290 over network 285. Further, request reception and authentication logic 202 may be used to authenticate the received request as well as to authenticate the user (and/or the corresponding customer) and/or computing device 290 before the user is allowed to place the request. It is contemplated that in some embodiments, the authentication process may be a one-time process conducted when computing device 290 is first allowed access to resource mechanism 110 or, in some embodiments, authentication may be a recurring process that is performed each time a request is received by request reception and authentication logic 202 at resource mechanism 110 at the cloud-based server computing device via network 285.
Once the authentication process is concluded, the request is sent to analyzer 204 to analysis and based on the results of the analysis, the request is forwarded on to processing framework 210 for proper processing by one or more components 212, 232, 252, 262, 272 and their sub-components 214-230. Communication/access logic 206 facilitates communication between the server computing device hosting resource mechanism 110 and other computing devices including computing device 290 and other client computing devices (capable of being accessed by any number of users/customers) as well as other server computing devices. Compatibility logic 208 facilitates dynamic compatibility between computing devices (e.g., computing device 290), networks (e.g., network 285), any number and type of software packages (e.g., websites, social networking sites, etc.).
In one embodiment, resource mechanism 110 and its resource allocation logic 212 allows for minimizing the chances of starvation between message types by closely tracking resource usage in production and automatically adapting the message selection process to ensure that thread time is distributed equitably. In one implementation, the technology disclosed herein may include real-time tracking of thread usage using a sliding window, computing fairness based on usage and queuing time, adaptive intervention that is tunable via configurable thresholds, novel techniques for selection of messages by usage, supporting message types with user-defined limits on number of concurrent threads, supporting message types that are throttled due to resource constraints, and supporting messages with extremely long running times or short queuing times.
For example, in one implementation, the technology disclosed herein can include thread resources in MQ that are distributed equitably among competing message types. “Fairness” is measured by total thread time to accommodate message types of various sizes and ensure fair selection (e.g., equal chance of being picked) as well as fair allocation of usage (e.g., equal usage of thread time).
In one embodiment, the technology disclosed herein may include tracking usage in a sliding window, dividing time into windows (e.g., 5 minute windows) with maximum look back (e.g., look back of 30 minutes), aggregating usage within the same window for each message type, computing fair usage for each message type, estimating how long a message types has been waiting for threads by, for example, using a snapshot of the longest waiting messages which may be obtained using any number and type of system and performance monitoring tools, such as NAGIOS®, etc. NAGIOS refers to an open source application used for monitoring of system resources, network resources, system infrastructure, remotely-run scripts, etc. This is further referenced and described below, such as with reference to Measuring Latency and Fair Expected Usage. It may also include computation from when at least two message types are competing for threads and for each window it may compute expected usage for each message type, such as per the following function: 1) total thread time used by all message types during that window as thread capacity can vary over time; 2) fraction of time message type spent waiting for threads; 3) fairness is the difference between actual and expected usage; 4) partition message types by usage and latency; 5) latency victims: >20 minutes delay experienced; 6) usage victims: actual usage is below expected by 50%; 7) usage offenders: actual usage is above expected by 50%; 8) intervene if intersection of latency victims and usage victims is non-empty; 9) order message types by fair usage in listen list; and 10) exclusively victims use selective boosting of messages to provide additional MQ capacity.
In one embodiment, an intervention technique is employed by having identification and intervention modules 214, 215 to address the problem of identifying, via identification module 214, and whether and when to intervene, via fair usage intervention trigger (also referred to as “intervention module” or simply “intervention trigger”) 220. For example, usage-based fairness is enforced when two conditions are satisfied: 1) high system load as measured by one or more messages types experiencing extremely high latency (e.g., queuing times); and 2) heavily skewed usage toward a handful of message types (e.g., there is a problem that we need to correct). The aforementioned two conditions may be identified and described, via identification module 214, and then the solution for intervention is outlined and applied, via intervention trigger 220.
High latency may refer to any message type in which the queuing time of the oldest message is greater than a defined amount of time, such as 20 minutes which serves as a configurable latency threshold. For example, of the aforementioned message types, those types that are not receiving their fair share of processing time on MQ thread are identified via identification module 214, which have either caused or exacerbated the latency experienced by their messages. Let latency victims be defined as any message type Mi with latency greater than 20 minutes. This is the set of potential victims that could trigger an intervention. Specifically, they may satisfy the two conditions above: experiencing high latency and deprived of their fair share of MQ thread time.
In one embodiment, the set of latency victims may be defined as those message types having a latency above the mean latency. Specifically, measurement and computation module 216 computes the mean latency of all message types that are experiencing high latency and identify, as victims, types whose latency is, for example, 50% above the mean. The intuition being that the focus is on messages whose latency is impacted most by system contention. While this approach is more conservative in identifying victims, it may result in false negatives such that intervention is warranted and applied, via intervention trigger 220, for a message type that is not included among the set of latency victims.
Consider the following scenario: message type M1 floods the queue at time 0. (here, the flood indicates that a large number of messages are enqueued at the same time). Subsequently, type M2 floods the queue at the 20-minute mark and type M3 floods the queue at the 40-minute mark. Then, at the one-hour mark, the corresponding latencies for M1, M2, and M3 are 60, 40, and 20 minutes, respectively. Let us also assume that from a usage perspective, M1 received more and M3 received less than its fair share of MQ thread time (M2 received exactly its fair share). In this case, the actual victim, M3, is below the mean latency because of when it was queued. For example, while latency measures wait time, it is also a function of when a message was queued. Thus, when the system is highly loaded, latency becomes more a measure of when a message was queued rather than a measure of the delay caused by competing message types.
Accordingly, in one embodiment, measurement and computation module 216 may measure latency for the age of the oldest message for each message type by relying on snapshots from, for example, NAGIOS for, for example, every 5 minutes. Exploiting measurements that are readily available in NAGIOS allow for minimizing the overhead of enforcing fair usage. This technique is novel and better than conventional techniques that incur significant overhead by updating latency on a more frequent basis or obtaining an exact count of the number of messages queued for each type and this is because conventional techniques do not offer efficient mechanisms to query for queue state and, as such, frequent database calls to determine what is present in the queue adversely impact overall system throughput.
In some embodiments, memcached is relied upon to distribute latency measurements from NAGIOS to various application servers in the dequeue cluster. For example, latency measurements may be obtained when NAGIOS pings one application server by calling a method/page (e.g., message QueueLongestWaiters.jsp). The corresponding application server may query for latency measurements, while the dequeue master thread on the remaining application servers may then launch a service every defined interval (e.g., 5 minutes) to detect when usage-based intervention may be triggered. This service may attempt to retrieve the most recent latency measurements from memcached and use this as an input to the intervention algorithm supported by intervention trigger 220, as referenced below with respect to the section Intervention.
In one embodiment, fair usage monitor (also referred to as “usage tracking module” or simply “monitor”) 228 may be used to track and measure a message type's usage referring to the aggregate amount of time that the type occupied MQ threads for processing (e.g., sum of the processing time over all messages of that type). The fair expected usage is defined as the amount of usage that is considered fair for a given message type over a specific period of time. It is contemplated that this is not necessarily an even fraction of the total usage over all message types, because various types may be queued at different times and, therefore, exhibit different latencies. For instance, a message type Mi that has been waiting on the queue for a long time should not be penalized for usage incurred prior to the arrival of messages for type Mj.
Furthermore, messages may be segregated into three groups based on their usage, such as usage victims, fair users, and usage offenders. In a nutshell, usage victims refer to any messages types in which the actual measured usage is 50% below its fair expected usage over a given time window. Similarly, usage offenders are types whose MQ thread time exceeds 50% fair expected usage. Fair users are the remaining types. In one embodiment, 50% may be chosen as a threshold to prevent over-reaction due to small variances in usage during normal operation, although this threshold may be raised or lowered to relax or tighten fairness guarantees. Fair usage monitor 228 may be used for computing fair expected usage and the list of usage victims/offenders.
As aforementioned, intervention trigger 220 may be used to decide whether and when to intervene based on two factors: 1) extremely high latency; and 2) heavily skewed usage. Latency victims (“LV”) may include a set of latency victims (e.g., those types experiencing a delay of greater than a threshold time period, such as 20 minutes), where usage victims (“UV”) may include a set of usage victims (e.g., that reach less than a threshold fair expected usage, such as 50% of the fair expected usage). The victim set may be computed, via measurement and computation module 216, as an intersection of LV with UV, where the victim set contains types of messages that experience both high latency and are deprived of their fair share of usage. If the victim set is not empty, then intervention is required and performed my intervention trigger 220. Further, a proof may be sketched as to the victim set contains neither false positives nor false negatives based on the definition. A false positive means that a victim type is either not experiencing high latency (not in LV) or receiving its fair expected usage (not in UV). This case may be excluded by the set intersection property. A false negative may mean that an actual victim is not in the victim set, whereas, by definition, the actual victim may be present in both LV and UV.
If no types experience high latency, no intervention may be needed. If only a single type experiences high latency, then no intervention may be needed. If two or more type experience high latency, then intervention may be needed if at least one type falls below 50% of fair expected usage. If subsets of types experience high latency, intervention based on all types with messages in the queue may be needed. Specifically, types with latency greater than 20 minutes and types with latency less than 20 minutes but greater than 0. A latency victim may be computed from the former types while usage victims may be computed based on both types.
Similarly, subset of types are experiencing high latency but message types that have zero or low latency may be regarded as grossly exceeding its fair expected usage. For example, this may occur for long running types that queue one message at regular intervals (as opposed to queuing a group of messages at one time) and finish within a threshold period of time, such as 5 minutes (e.g., it does not show up in NAGIOS). For example, consider the case in which M1 are short dashboard requests that flood the queue at time 0 and each message takes 30 seconds to complete. M2 are long-running asynchronous application programming interface (API) messages that take another time period, such as 4.5 minutes, to run, but only a single asynchronous API message is submitted every five minutes.
With a single MQ thread, each of one dashboard and an asynchronous API message may run every 5 minutes; however, when the latency is measured, M2 may return zero because all its messages may complete within the 5-minute window. If M2 is not accounted for, when computing the usage victims, then intervention may not be needed even if M1 is experiencing high latency and is receiving less than 20% of its fair expected usage (10% usage when it should have received 50% usage). Further, message types may be included with zero or low latency in the usage calculation if they exceed the fair expected usage of high latency message types. Similarly, subsets of types are experiencing high latency but message types that have zero or low latency are below its fair expected usage. Since these messages are experiencing low latency, no intervention may be needed.
Set Difference Intervention
The computing of the victim set as a set difference between LV and UO (UO is the list of usage offenders as defined above) means subtracting the message types which are hogging MQ thread resources from high latency types to compute the set of messages that, if not empty, indicate that intervention is necessary. One technique is to subtract usage offenders and fair users from the latency victims set, which is equivalent to the intersection between latency victims and usage victims (since latency victims contains the high latency types, which is a subset of the union of usage offenders, fair users, and usage victims).
Sliding Window Maintenance
As will be further illustrated in this document with respect to the subsequent figures, MQ thread time usage is tracked by fair usage monitor 228 by maintaining counters for the total-processing time consumed by each message type. In one embodiment, this is accomplished by tallying, for each completed message, the processing time for the corresponding message type using measurement and computation module 216. To implement this, sliding window digest (also referred to as “sliding window module”) 226 is used to employ a configurable sliding window to work with measurement and computation module 216 to take coarse-grained usage measurements within each window such that 1) to ensure that intervention decisions are based on the most recent usage pattern, 2) to smooth out temporary fluctuations in usage across a span of time for long running message types, and 3) to identify message types that exceed its fair expected usage on a chronic basis over a sufficiently large time range. The coarse-grained measurements may be obtained by aggregating usage statistics within each window to minimize the overhead of maintaining a large number of measurements for the sliding window in memory.
In one embodiment, the sliding window technique includes partitioning time into disjoint and equi-sized (with respect to time) windows in which each window is a segment in time with a beginning and end. For example, let Wi be the window in which beg(Wi) denotes the start of time and end(Wi) denotes the end time for the window. Next, let the window extent be the size of the sliding window in terms of the number of windows that make up the sliding window. Although it is contemplated that the time may be sliced into any number of intervals and the sliding window may consist of any number and size of windows, for the sake of brevity and ease of understanding, let us suppose the time is partitioned into 5-minute intervals and for a window extent of 6, the sliding window may consist of 6 windows (an ordered list of windows W1 through W6) that span the last 30 minutes in time. For example, if the current time is 5:00 PM, then window W1 covers 4:30 PM-4:35 PM, while W6 covers 4:55 PM-5:00 PM. In general, a sliding window with size m (W1 through Wm) covers that last end(Wm)−beg (W1) minutes in time where end(Wi)<=beg(Wj) for all i<j. Similarly, another example is illustrated with respect to FIG. 3A.
In this section is described how to compute the fair expected usage for each message type using latency snapshots from NAGIOS and sliding window usage measurements, and then how to determine the set of usage offenders, usage victims, and fair users.
Fair Expected Usage
Fair expected usage is the amount of MQ thread time that is allocated to a message type given the amount of competition for resources from other types and the amount of available MQ threads. It is contemplated that the definition of fairness may vary by message type. For example, if only messages from type M1 are pending in the queue, then fair expected usage for M1 may be 100% of the available MQ threads. In contrast, if messages from both M1 and M2 are waiting in the queue, then the fair expected usage for M1 may be 50%. Fair usage may also depend on the amount of MQ threads available (via addition or removal of application servers or threads), such as if M1's fair expected usage is 10 minutes during one usage window, but the number of MQ threads is halved during the next window, then M1's fair expected usage changes accordingly.
To approximate the fair expected usage, one or more of factors may be considered and taken into account. First, messages are enqueued at different times and so the message types may not be penalized for waiting longer on the queue; for example, consider the case in which type M1 floods the queue at time 0. Over the next 20 minutes, messages from M1 slowly drain from the queue and accumulate usage. If another message type M2 floods the queue at the 20-minute mark, M1 may not be penalized for usage incurred during the first 20 minutes. Second, message types that are waiting on the queue based on the usage of types that no longer have pending messages may not be penalized; for example, consider the case in which type M1 used 90% of the MQ thread time during the previous window while type M2 used only 10%. When the latency snapshot is retrieved, M2 may no longer have pending messages and in this case, M1 may not be penalized because, without messages, M2 may not be starved going forward. To add to the previous observation, the fair expected usage may be based on those types that have messages pending on the queue. Further, using intervention trigger 220, an appropriate and timely fair usage intervention is performed and to ensure that an equitable distribution of MQ thread time among these message types is performed using enforcement module 230 which is responsible for prioritization, distribution, and enforcement. In one embodiment, the fair usage is based on the interaction between the types with pending messages as opposed to the types without any pending messages as this distinction may be considered and used when calculating the usage for the sliding window.
Time Span of Interest
In one embodiment, a recent subset (referred to as “time span of interest”) of the usage measurements within the sliding window may be relevant to computing the fair expected usage. This time span of interest may be computed based on latency snapshots from NAGIOS using the usage monitoring and tracking tool referred to as fair usage monitor 228. The technique primarily focuses on the fair usage for messages waiting on the message queue, which means that for a given message type, tracking the usage since the enqueue time of its oldest message (bounded by the size of our sliding window) may be sufficient and since latency measures the amount of time a message have spent waiting for MQ thread resources, the enqueue time may be derived from the known latency.
Let us suppose Ti denotes the enqueue time of the oldest message for type Mi and if Ti is less than the lower bound on our sliding window (Ti<beg(W1)), then the usage for Mi is tracked over the entire sliding window; otherwise, the usage tracking starts for window Wi satisfying beg (Wi)<=Ti<=end(Wi). The time span of interest may be narrowed even further, such as if only the messages for a single type are pending in the queue, then no intervention may be necessary, and thus, the technique starts tracking usage when the oldest message for at least two types are pending during the same window. To compute the fair expected usage and actual usage for each message type, measurement and computation module 216 may sum up the individual values for each window (within the time span of interest) as follows: for M1, actual(UI)=25+20+15+15=75 min, expected(UI)=19+15+11+7.5=52.5 min, while similar calculations are performed for M2, M3, M4 and so forth.
Usage Victims, Usage Offenders, Fair Users
As aforementioned, a set of usage victims, usage offenders, and fair users may be computed. The set of latency victims may include any type with latency greater than a threshold time period, such as 20 minutes, where the set may contain {M1, M2}. For example, the usage victims may include any type Mi in which the actual usage is 50% below its fair expected usage ((expected(Ui)−actual(Ui))/expected(Ui)>50%). Next, the starvation fraction is computed such that each type in the above example is experience with respect to usage, such as M1: (52.5−75)/52.5=−43% and so on for M2, M3, M4, etc. If starvation is equal to 0, then the message type is using its fair share of MQ thread time. For values greater than zero, the messages from that type are below their fair share, while values less than zero indicate above fair share usage. Given our 50% threshold, our usage victims, usage offenders, and fair users are {M2}, { }, and {M1, M3, M4}, respectively. Note that in this particular example, there are no usage offenders but there are victims. This is because the combined effect of multiple messages types (notably M1 and M4) exceeding their fair expected usage deprived M2 of its fair share of MQ thread time.
When considering fair use intervention, intervention trigger 220 working with other components (such as measurement and computation module 216, fair usage monitor 228, etc.) starts by determining when to intervene, which is illustrated by the pseudo-code below (for example):
ListenList_Intervention(LatencyByType, SlidingWindowUsage)
Latency_Victims = { }
foreach type in LatencyByType
if LatencyByType(type) > 20 minutes
Latency_Victims = Latency_Victims U type
Actual_Usage = computeActual(LatencyByType,
SlidingWindowUsage)
Expected_Usaged = computeExpected(LatencyByType,
foreach type in Latency_Victims
if (Expected_Usage(type) − Actual_Usage(type)) /
Expected_Usage(type) > 50%
Intervention = TRUE
Intervention = FALSE
The above decision may be re-evaluated, such as every 5 minutes, following the most recent latency snapshot obtained from NAGIOS. The inputs are the latency for the list of types with non-zero latencies and the usage measurements that are maintained over the sliding window. The process begins with initializing the latency victims set to null and then, for each type with greater than a threshold time period, such as 20 minutes, in latency, they are added to the latency victims set. Then, the actual and fair expected usage for each message type are calculated based on the available latency information and the sliding window usage measurements, where for each message with greater than 20 minute latency, if a usage victim is found, then the intervention is triggered. Once intervention is triggered, enforcement module 230 may consider a combination of two methods or processes for enforcing fair usage: such as 1) listen list shuffling; and 2) selective boosting.
Listen List Shuffling
Once intervention has been triggered by intervention trigger 220, a listen list (e.g., advance queue (AQ) listen list by Oracle®) may be sorted as follows: for types with zero latency, their random shuffling is performed and their placed at the beginning of the listen list. For all other message types, the usage starvation fraction ((expected(Ui)−actual(Ui))/expected(Ui)) is computed and ordered in decreasing starvation order. For example, the pseudo-code for ordering the listen list on each listen call may be as follows:
Order_ListenList(MessageTypes, LatencyByType, SlidingWindowUsage)
If Intervention == FALSE
return shuffle(MessageTypes)
Usage_Starvation = { }
Zero_Latency = { }
Expected_Usage = computeExpected(LatencyByType,
foreach type in MessageTypes
If LatencyByType(type) > 0
Starvation = (Expected_Usage(type) −
Actual_Usage(type)) / Expected_Usage(type)
Usage_Starvation = Usage_Starvation U (type,
Zero_Latency = Zero_Latency U type
ListenList = shuffle(Zero_Latency)
Sorted_Usage =
SortByStarvationDecreasing(Usage_Starvation)
return ListenList.append(SortedUsage)
The aforementioned may take the list of message types to listen for, latency snapshot, and sliding window usage measurements as input and return an ordered list of message types. If intervention is not triggered, then a random shuffle is performed. Otherwise, the types are separated into non-zero latency and zero latency groups. For the zero latency types, a random shuffle is applied and the latency types are place at the beginning of the listen list. For all other types, usage starvation fractions computed, and the remaining types are sorted by decreasing starvation order and appended to the end of the listen list. Further, the intervention logic may be local to each dequeue thread; namely, each dequeue thread may maintain its own sliding window usage measurements. This way, no cross application server coordination is needed to share the state between multiple dequeue threads; instead, each dequeue thread may make an intervention and apply listen list shuffling decisions independently by tracking the usage locally.
Selective Boosting
In one embodiment, a second method for intervention includes modification of the existing boosting logic that dynamically adds or removes certain threads when specific message types may experience increased latency. Specifically, more dequeue threads may be added to relieve these types by assigning booster permits (such as types with higher delay are assigned more permits). When the listen list is constructed, those types that are assigned booster permits may be positioned at the front of the list and thus have a higher likelihood of being serviced.
Once intervention is triggered, the boosting may run counter to the goal of achieving fair usage across all types. For example, consider the case in which a usage offender is also a latency victim such that booster permits are assigned to this offender. By virtue of being a usage offender, it should be ordered at the bottom of the listen list; however, any booster permits superseding any listen lists to ensure that this usage offender is moved to the front of the listen list, thus continuing to starve other types. Using this technique, booster permits are issued as before and, at the application server level, booster permits are ignored in constructing the listen list if the permits belong to usage offenders. This also ensures that fair usage intervention does not interfere with the addition of more servers in the dequeue cluster when incoming messages are experiencing high latency.
For example, consider the case on CS0 with an asynchronous API messages starving dashboard and other requests. In this case, a flood of asynchronous API messages increases latency for all messages in the queue and, as such, both asynchronous API and dashboard messages receive boosting permits. While there is increased capacity, dashboards continue to be deprived of the additional MQ thread time from boosting. However, if booster permits for asynchronous API (e.g., the usage offender) are ignored when constructing the listen list, then the additional threads may be relied upon to increase the MQ thread time made available to dashboard requests. By not changing how booster permits are issued, and instead, selectively ignoring permits at application servers, MQ thread capacity may be increased (since the number of outstanding permits dictate the number of additional threads made available) and quickly made available to the usage victims. Further, the boosting code may be augmented with additional logic to enforce fair usage, when intervened, by filtering out usage offenders. Here, for example, permits are not filtered if intervention has not been triggered; otherwise, whether the message type for the corresponding permit is a usage offender based on actual and expected usage is computed. If a permit corresponds to a usage offender, then the permit is ignored when constructing the listen list.
A pseudo-code is presented below (for example):
BoosterPermit permit = getNextPermit( )
if permit != null AND isNotUsageOffender(permit.messageType) then
listenList.remove(permit.messageType)
listList.add(boosterPosition, permit.messageType
Concurrency Controlled Message Types
In one embodiment, concurrency controlled message types include single threaded messages including types with explicit (e.g., org-based) concurrency controls, and types with resource constrained filters that prevent them from making use of all available MQ threads. Since these types intentionally limit their concurrency, the usage metric (e.g., MQ thread time used) may disproportionately favor these messages. Consider a single threaded type that can only execute one after another, the messages waiting on the queue that cannot run due to the single thread requirements (rather than not having enough MQ threads) accrue high latency. This, combined with low usage, consistently results in single threaded messages being treated as usage victims even though they are not starved. However, in this case, nothing is done as these messages are automatically removed from the listener list due to concurrency control.
Ordering of the listen list during intervention may include concurrency control and thread capacity as a parameter, because the tighter the concurrency control limits, the less likely that a type is marked as a latency victim. For example, assuming 5 minutes being the threshold for latency victims, if there are 16 threads available for a message type on a node, but the message type has a concurrency limit of 8, then the latency victims threshold for that type is set to 5×16/8, whereas for the types with no concurrency limits or in which concurrency is equal to the number of threads available, the 5 minute latency threshold remains unchanged
Furthermore, a logging technique may be employed for maintain a log of various activities, such as logging every time a message type is suspended for any reason (e.g., resource constrained filter, concurrency limits, single thread, etc.). In one embodiment, the logging technique may include a lazy message queue technique that indicates every event (e.g., too many requests at a database, the host running out of memory, the host central processing unit (CPU) utilization is too high, etc.) in which a worker host detects a resource issue and if and when one of these event occurs, the worker host may stop processing any number and type of messages or jobs from the queue. The events may be termed as lazy message queue events. This way, the number of times that a particular message type appears in the log is parsed, while the expected usage is adjusted based on its log frequency. This technique handles the concurrency controlled types naturally by adjusting the usage calculations and without having to rely on fixed latency or usage thresholds, which may vary by production instance. The first approach may favor concurrency-controlled types in listen list and the issuance of booster permits, whereas the second approach relies on fixed latency and capacity thresholds that can be brittle in production.
In calculating the usage for concurrency controlled types, it is ensured that the low usage by these types does not penalize other, non-concurrency controlled types. To accomplish this, each time a dequeued message cannot be processed, it triggers the log. The number of times this occurs for each message type (e.g., deferral count), the usage for a concurrency controlled message type Mi is tallied during window Wj, while the total number of messages processed versus the number of messages deferred is accounted. For example, 10 messages are dequeued for Mi, but only 2 messages are processed while the remaining 8 are suspended due to concurrency-controlled reasons. Stated differently, dequeue threads give Mi opportunity to process 10 messages, but it only processed 2, which means choosing to use only 20% of its allocated resources. In this case, even if Mi used fewer resources than other types, the expected usage for Mi is safely adjusted downward by setting its fraction (e.g., amount of time spent competing for resources) f(Mi, Wj) to 0.2, reducing the fair expected usage of Mi without adversely effecting other types. When contention is low, suspension of Mi messages may occur more frequently and its expected usage will be adjusted downward more aggressively. However, during high load, when many messages are competing, Mi may not encounter suspension at all, and in turn, its expected usage may not be adjusted.
Adjusting usage in this manner may mark concurrency-controlled types as usage offenders in some cases. For example, logs may be triggered more frequently when system load is low and the stand-by delay specified by the message handler is low. Thus, if the concurrency controller type is using more than its expected usage, then no adjustment may be necessary. If the message type is a usage victim, then the usage using the technique above (e.g., account for number of the logs) is adjusted. If the type's actual usage is more than the new, adjusted expected usage, then this may indicate that the log is too conservative (e.g., underestimates the amount of resources used by the message type) and, as such, the fraction, such the concurrency controlled type's expected usage matches its actual usage, is revised. To summarize, when a concurrency controlled type is a usage victim, its expected usage is revised downward so that it is less likely to be a usage victim. However, the revision does not change the type, such from a usage victim to a usage offender. During intervention, single threaded types may not be consistently ordered at the front of the listen list as it is less likely to become a usage victim given that its expected usage is likely to be much lower compared to the other types. With regard to the issuance of booster permits, both usage offenders and concurrency controlled types (e.g., types that experienced message suspension) are excluded from receiving boosters.
Conditions for Filtering Types
In one embodiment, message types may be filtered out of the listen list for additional reasons irrelevant to user-specified concurrency limits, such as: 1) resource constrained filters such as database central processing unit (CPU) becoming overloaded; 2) piggy backing behavior for POD-wide single threaded types (e.g., usage_log_search type) in which a thread holds the lock for the corresponding type and remove the type from the listen list of competing threads; 3) peek and browse the behavior in which a dequeued type may not be processed because no unexpired messages are found in the cache; and 4) user-specified POD or a node-based suspension rules that prevent any messages of a given type from being dequeued. The scenarios may be addressed in the same manner in which concurrency controlled message types are handled, such as via the logs. Specifically, each of the listed conditions may generate a corresponding log line for the effect message type, where each Mlog line is tallied in the sliding window by incrementing the frequency in which the dequeued messages are not to be processed. This count is used, in turn, to adjust the usage of the filtered types so that they are not falsely identified as usage victims.
Starvation by Low Latency Types
In some embodiments, types that submit a small number of messages on a continuous and periodic basis and grossly exceed its fair expected usage are accounted for, where, as mentioned above, types without any messages queued in the fair usage calculation may not be accounted, so that the focus remains on types with high latency messages (as opposed to those messages that are already completed). In some embodiments, in a case where a zero latency type starves a type experiencing high latency, booster permits may prevent this problem by being allocated to only the types experiencing high latency. However, with respect to listen lists where zero latency messages may be consistently ordered in the front and their usage is not accounted for, the usage measurements from zero latency types (that incurred recent usage) may be included in ordering the listen list. The recent usage may be defined as any zero-latency type that incurred usage in the current or previous window (e.g., a span of two windows) and to compute this list, the zero latency types are iterated and their actual usage is measured starting from the current and previous time window.
A couple of factors may be considered when accounting for zero latency types, such as 1) the usage of zero latency types that exceed its fair share, but 2) do not penalize non-zero latency types for zero latency types that rarely submit messages and have negligible impact on overall usage. In one embodiment, a set of potential usage offenders is constructed from zero latency types with non-zero usage in the two most recent windows, where for each type from this list, its usage from earlier windows (up to the beginning of the time span of interest) is included if the usage for that type is consecutively non-zero. In another embodiment, the usage from earlier windows is included if up to that point, usage incurred by the zero-latency type exceeds its expected fair usage. For example, considering the decision to add usage from window Wi in computing a zero-latency type Mj's usage, if the cumulative usage from window W0 to Wi exceeds the expected usage (as calculated earlier) of a non-zero latency type whose oldest message was enqueued at window Wi, then Wi is included in Mj's usage. For example, for each window Wi, the expected fair usage of non-zero latency types is computed whose oldest message was enqueued at Wi. Given the fSum(Wi) is the fair fraction over window Wi, and uSum(Wi) is the total usage for non-zero latency types, the expected fair usage over the entire window is represented by uSum(Wi)/fSum(Wi). The sum is calculated over all windows in which we measure actual usage for zero latency types. Subtracting fair usage from actual usage for zero latency types yields the starvation factor. A negative starvation factor means that a zero latency type used more MQ thread time relative to a type with non-zero latencies. For these zero latency types, their usage is included in the computation of fSum(Wi) and uSum(Wi) as this adjusts the fair expected usage of non-zero latency types upward such that the additional non-zero latency types may now be marked as usage victims.
Moreover, in case where the zero latency types are usage offenders, the expected usage of high latency types may be adjusted accordingly. For example, the expected usage for non-zero latency types may be computed, as aforementioned, except here, the usage for zero latency types (relative to non-zero latency types) is also computed. The zero latency types that exceed their expected usage are marked as potential usage offenders, where the expected usage for non-zero latency types is revised by taking into account the potential usage offenders from the zero latency groups. If a zero latency type is using more than its fair share of MQ thread time, then this adjusts the expected usage of non-zero latency types upward and increases the likelihood that a given type is identified as a usage victim. The revised expected usage is then used to compute the usage victims. The revised pseudo-code includes (for example):
Zero_Latency_Starvation =
computeZeroLatencyStarvation(LatencyByType,
Zero_Latency_Offenders = { }
foreach type in Zero_Latency_Starvation
if Zero_Latency_Starvation(type) < 0
Zero_Latency_Offenders = Zero_Latency_Offenders U type
If Zero_Latency_Offenders is not NULL
Expected_Usage = computeExpectedRevised(LatencyByType,
SlidingWindowUsage, Zero_Latency_Offenders)
Expected_Usage(type) 50%
Consider two scenarios. In one M1 floods the queue at 0 minutes. Type M2 submits one message every few minutes but never incurs a backlog and, hence, returns zero latency from NAGIOS. Now imagine that at time 20 minutes, M1 used 2 minutes of the MQ thread time during the last 20 minutes while M2 used the remaining 18 minutes. Using the revised algorithm, the expected usage of M1 is computed as 2 minutes. Moreover, if M2 (zero latency type) are used more than the expected usage of M1 (non-zero latency type), both M1 and M2 are combined in the usage calculation which yields an expected usage of 10 minutes for both M1 and M2, which then triggers intervention by intervention trigger 220. Now consider the reverse scenario in which at the end of 20 minutes, M1 has used 18 minutes while M2 has used the other 2 minutes. Here, since it is not known how long M2 messages have spent waiting on the queue, M1 is not penalized for it and given that M2 is below Ml's expected usage, intervention is not triggered.
In some embodiment, the longest waiter latency measurements may be exposed to any number of application servers by caching the results in memcached. Further, the intervention may be passive, merely logging problems with usage when intervention is triggered in production. In one embodiment, a dashboard page may be designed to monitor for past and current intervention decisions by mining for data from splunk, which allows for monitoring of intervention in production and fine tune parameters to reduce noise as necessary. Interventions may be further implement through selective boosting of message types or by reordering types within the listen list. Further a central hub page may be included to enable/disable fair usage intervention on a per POD or node basis.
Suspension of Fair Use
In one embodiment, a blacktab page is created that allows for suspensions of fair usage intervention and usage tracking on, for example, a per-rac node basis, where each rac node is listed separately with an option to “suspend” along with the reason for suspension. When a rac node is marked for suspension, a corresponding suspend rule is inserted into a (e.g., BASS.message_queue_suspend_data table) with certain attributes, such as a) suspend mode (rac_fair_usage), b) rac node, c) suspend reason, d) suspend date, e) org, and f) user identification (Id).
When a suspension rule is removed, the corresponding row is deleted from the table (e.g., message_queue_suspend_data table), which means that metadata associated with the change (e.g., suspend date, reason, org, and user Id) is lost along with the suspension rule. Accordingly, using the above, valuable computation time may be saved and allow for embodiments to be well-suited to be used with 1) devices with a small form factor, limited interactive capability, limited display size, limited memory or storage capacity, limited processing power and short battery life; 2) networks that are not consistently available, slow data transfer rates, erratic data transfer services, no consistent standards; 3) data having massive quantity and that is not organized for mobile users; 4) users that have short attention spans, little or no patience, on the move, and routinely in awkward or limited usage situations; and 5) managers who have security concerns and where applications, devices, and users require a new management layer.
FIG. 3A illustrates a fair allocation and usage of thread resources using sliding window maintenance as provided by the thread resource management mechanism 110 of FIG. 1 according to one embodiment. In the illustrated embodiment, time sequence 300 is divided into several windows a window extent 312 of fives windows 302-310 is adopted, where each window is based on a period of 5 minutes, such as W1 302 over minutes 20-25, and so forth. Table 320 reflects the distribution of user-placed jobs/requests/messages, M1-M3, where M1 runs from the 23rd minute of W1 302 until the 29th minute of W2 304 as shown in columns 312A and 314A. Similarly, timespans of messages M2 and M3 are shown in columns 316A-320A corresponding to windows W4 306-W5 310. Table 325 shows a cumulative timespan of messages M1-M3, such as M1 consumes 3 minutes in W1 302 as shown in column 312B and another 2 minutes in W3 302 as shown in column 314B. Similarly, cumulative timespans of messages M2 and M3 are shown in columns 316A-320A corresponding to windows W4 306-W5 310.
Referring now to FIG. 3B, it illustrates the use of a sliding window 330 including 5 windows, W1 302-W5 310, which corresponds to size over which window extent 312 is maintained in FIG. 3A. Further, as shown in FIG. 3A, the initial point in time is shown at the 23rd minute, while the current time is shown to be at the 43rd minute; similarly, here, time span of interest 332 is shown to represent that time period between the 23rd and the 43rd minute and is further shown to be moving to the right. Windows that fall outside this range are discarded for the purposes of the sliding window technique. It is contemplated that embodiments are not limited to this illustrated example and that the use of technology disclosed herein should not be taken as limiting or preferred. This example sufficiently illustrates the technology disclosed without being overly complicated. It is not intended to illustrate all of the technologies disclosed.
To track the usage for a given message type, for each window, the processing time used by all messages of that type is summed. Further, the span of each window is reduced to obtain finer grained usage measurements if necessary. Now, let WiUj denote the total processing time used by all messages of type Mj whose completion time t satisfies beg(Wi)<=t<end(Wi). To make the example concrete, consider the processing time of three messages, M1 334, M2 336 and M3 338, over five time windows, W1 302-W5 310. The first number denotes the processing time in minutes while the number in parenthesis denotes the wall clock time of when the message completed.
To implement the sliding window technology, a fixed sized circular array of time span of interest 332 is employed with the earliest window, W1 302, as the head and the most recent window, W5 310, as the tail window. Within each window 302-310, the total processing time is tracked for each message type using a hash structure using fair usage monitor 228 and sliding window digest 226. When sliding window 330 is advanced, the previous head (e.g., the earliest window, W1 302) is overwritten, while the head and tail pointers are advanced accordingly. The corresponding tables 340, 345, 350 illustrate the numbers that represent fair usage distribution as facilitated through sliding window 330.
For example, table 340 shows the actual usage tracking by minutes, such as column 312C shows M1 334 occupying 30 minutes, while column 314C shows M1 334 further occupying 25 minutes and M2 336 occupying 5 minutes. Similarly, columns 316C, 318C, 320C shows the actual usage of minutes corresponding to other messages, such as M2 336, M3 338 and M4 corresponding to windows, W3 306-W5 310. Table 345 includes columns 312D-320D that further illustrate fair usage fraction by percentage for each of the aforementioned messages, M1 334, M2 336, M3 338, M4-M5, and windows, W1302-W5 310, such as M1 334 at 100% in W1 302 in column 312D, M1 334 at 62.5% and M2 336 at 37.5% in W2 304 in columns 314D. Table 350 includes columns 312E-320E illustrates the fair expected usage by window 302-310 in terms of minutes that corresponds to the percentages of table 345, such as M1 334 at 30 minutes in W1 302 of column 312E, M1 334 19 minutes and M2 336 11 minutes in W2 304 in column 314E, etc.
FIG. 3C illustrates architecture 355 for facilitating a fair allocation and usage of thread resources using sliding window maintenance as provided by thread resource management mechanism 110 of FIG. 1 according to one embodiment. In the illustrated embodiment, in architecture 355, jobs or message may be placed by users via user interface 294 provided by a client computing device in communication with a server computing device hosting the thread resource management mechanism 110 of FIG. 1. In one embodiment, messages/jobs received at job scheduler 218 are tracked by fair usage intervention trigger 220, where the jobs/messages are then prioritized into a prioritized list of job types that are then executed by job execution engine 222 of FIG. 2. The information, including the feedback for resources used by job type, is forwarded on to resource utilization tracker 224 of FIG. 2.
In one embodiment, at resource utilization tracker 224, sliding window digest 226 as powered by sliding window maintenance logic 252 of FIG. 2, provides the maintenance and use of sliding windows, such as sliding window 360, as illustrated with respect to FIG. 3B, in combination with the fair usage statistics as obtained by fair usage monitor 228, generates a report having aggregated resources consumed by job/message type. Using the aggregated resource consumed by job/message type, job/message type victims are identified and reported out to job scheduler 218 so that proper intervention may be triggered by fair usage intervention trigger 220 and job/message may be performed using job execution engine 222 using the prioritized list of job/message types.
FIG. 4A illustrates a method 400 for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment. Method 400 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 400 may be performed by thread resource management mechanism 110 of FIG. 1.
Method 400 relates to and describes a resource utilization tracker transaction involving resource utilization tracker 224 of FIG. 2. Method 400 begins at block 402 with resource utilization tracker 224 of FIG. 2 receiving feedback on host resource consumed by a completed job/message. At block 404, resources consumed for or by a specific job type are aggregated using a sliding window that run across a defined time period threshold, such as 5 minutes. At block 406, the time spent waiting for the job type is estimated by querying the oldest job in the queue. At block 408, the actual and expected fair usage for the job type from resources is computed from and using resources consumed and the age of the oldest job. At block 410, a determination is made as to whether the job type is a victim. If the job type is not a victim, at block 412, no special handling is required and the process continues normally. If, however, the job type is determined to be a victim, at block 414, job scheduler 218 of FIG. 2 is notified of the starvation factor for that particular job type.
FIG. 4B illustrates a method 420 for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment. Method 420 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method 420 may be performed by the thread resource management mechanism 110 of FIG. 1.
Method 420 relates to and describes a job scheduler transaction involving job scheduler 218 of FIG. 2. Method 420 begins at block 422 with job scheduler 218 of FIG. 2 receiving a report/list identifying the victim job/message types and the starvation factor. At block 424, a decision is made as to whether there is at least one victim job type in the list. If not, at block 426, no change is made to the existing job type priority. If yes, at block 428, a fair usage intervention decision is triggered. At block 430, the list of job types is reordered to dequeue by decreasing the starvation factor. At block 432, any victims are prioritized by adding work hosts to boost the processing of victim job types.
FIG. 4C illustrates a transaction sequence 440 for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment. Method 440 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, transaction sequence 440 may be performed by the thread resource management mechanism 110 of FIG. 1.
Transaction sequence 440 relates to and describes a resource utilization tracker transaction. In one embodiment, job scheduler 218 communicates notification of a completed job/message of a particular type 442 to fair usage monitor 228 which then tallies the resources consumed for performing or completing the job 444. At sliding window digest 226, the resources consumed by the job type in a defined time period (e.g., 5 minutes) are aggregated 446. The resources consumed from or by all job types over a defined time period interval (e.g., 30-minute interval) are received 448 at fair usage monitor 228 from sliding window digest 226. At fair usage monitor 228, ages of all job types on the queue is determined including the age of the oldest job on the queue for each job type is queried 450. Further, at fair usage monitor 228, calculation for the starvation factor from actual and expected fair usage for each job type is performed 452. The starvation factor greater than 50% with the delay of less than 20 minutes for any of the victim job types is gathered 454 at fair usage monitor 228 and communicated on to job scheduler 218.
FIG. 4D illustrates a transaction sequence 460 for facilitating a fair allocation and usage of thread resources for user messages according to one embodiment. Method 460 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, transaction sequence 460 may be performed by the thread resource management mechanism 110 of FIG. 1.
Transaction sequence 460 relates to and describes a job scheduler transaction. Transaction 460 begins with fair usage intervention trigger 220 receiving a request to process a job 462 from a user via user interface 294 at a client computing device. At fair usage intervention trigger 220, the job is checked against all the victim job types in the victim job types list 464. Then, if the job is regarded as a victim job type (such as matched with a victim job type in the list), an increase in the cluster of worker hosts is requested 466 from job execution engine 222. In response to the request, at job execution engine 222, more worker nodes are added to the cluster if the capacity is available 468. At fair usage intervention trigger 220, the next job is dequeued in the order of decreasing starvation factor 470, while the job is submitted for execution 472 to job execution engine 222. At job execution engine 222, the job is processed on a worker host 474. The user may access the result obtained from the job execution 476 via user interface 294.
FIG. 5 illustrates a diagrammatic representation of a machine 500 in the exemplary form of a computer system, in accordance with one embodiment, within which a set of instructions, for causing the machine 500 to perform any one or more of the methodologies discussed herein, may be executed. Machine 500 is the same as or similar to computing device 100 and computing device 290 of FIG. 1 and FIG. 2, respectively. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a network (such as host machine 100 of FIG. 1 connected with client machine 290 over network 285 of FIG. 2), such as a cloud-based network, a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a Personal Area Network (PAN), an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment or as a server or series of servers within an on-demand service environment, including an on-demand environment providing multi-tenant database storage services. Certain embodiments of the machine may be in the form of a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, computing system, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
Processor 502 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 502 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processor 502 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processor 502 is configured to execute the processing logic 526 for performing the operations and functionality of thread resource management mechanism 110 as described with reference to FIG. 1 and other figures discussed herein.
The secondary memory 518 may include a machine-readable storage medium (or more specifically a machine-accessible storage medium) 531 on which is stored one or more sets of instructions (e.g., software 522) embodying any one or more of the methodologies or functions of thread resource management mechanism 110 as described with reference to FIG. 1 and other figures described herein. The software 522 may also reside, completely or at least partially, within the main memory 504 and/or within the processor 502 during execution thereof by the computer system 500, the main memory 504 and the processor 502 also constituting machine-readable storage media. The software 522 may further be transmitted or received over a network 520 via the network interface card 508. The machine-readable storage medium 531 may include transitory or non-transitory machine-readable storage media.
The techniques shown in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., an end station, a network element). Such electronic devices store and communicate (internally and/or with other electronic devices over a network) code and data using computer-readable media, such as non-transitory computer-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and transitory computer—readable transmission media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals). In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers). Thus, the storage device of a given electronic device typically stores code and/or data for execution on the set of one or more processors of that electronic device. Of course, one or more parts of an embodiment may be implemented using different combinations of software, firmware, and/or hardware.
Several elements in the system shown in FIG. 6 include conventional, well-known elements that are explained only briefly here. For example, each user system 612 could include a desktop personal computer, workstation, laptop, PDA, cell phone, or any wireless access protocol (WAP) enabled device or any other computing device capable of interfacing directly or indirectly to the Internet or other network connection. User system 612 typically runs an HTTP client, e.g., a browsing program, such as Microsoft's Internet Explorer browser, Netscape's Navigator browser, Opera's browser, or a WAP-enabled browser in the case of a cell phone, PDA or other wireless device, or the like, allowing a user (e.g., subscriber of the multi-tenant database system) of user system 612 to access, process and view information, pages and applications available to it from system 616 over network 614. User system 612 further includes Mobile OS (e.g., iOS® by Apple®, Android, WebOS® by Palm®, etc.). Each user system 612 also typically includes one or more user interface devices, such as a keyboard, a mouse, trackball, touch pad, touch screen, pen or the like, for interacting with a graphical user interface (GUI) provided by the browser on a display (e.g., a monitor screen, LCD display, etc.) in conjunction with pages, forms, applications and other information provided by system 616 or other systems or servers. For example, the user interface device can be used to access data and applications hosted by system 616, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user. As discussed above, embodiments are suitable for use with the Internet, which refers to a specific global internetwork of networks. However, it should be understood that other networks can be used instead of the Internet, such as an intranet, an extranet, a virtual private network (VPN), a non-TCP/IP based network, any LAN or WAN or the like.
According to one embodiment, each user system 612 and all of its components are operator configurable using applications, such as a browser, including computer code run using a central processing unit such as an Intel Core® processors or the like. Similarly, system 616 (and additional instances of an MTS, where more than one is present) and all of their components might be operator configurable using application(s) including computer code to run using a central processing unit such as processor system 617, which may include an Intel Pentium® processor or the like, and/or multiple processor units. A computer program product embodiment includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein. Computer code for operating and configuring system 616 to intercommunicate and to process webpages, applications and other data and media content as described herein are preferably downloaded and stored on a hard disk, but the entire program code, or portions thereof, may also be stored in any other volatile or non-volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of storing program code, such as any type of rotating media including floppy disks, optical discs, digital versatile disk (DVD), compact disk (CD), microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Additionally, the entire program code, or portions thereof, may be transmitted and downloaded from a software source over a transmission medium, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known. It will also be appreciated that computer code for implementing embodiments can be implemented in any programming language that can be executed on a client system and/or server or server system such as, for example, C, C++, HTML, any other markup language, Java™ JavaScript, ActiveX, any other scripting language, such as VBScript, and many other programming languages as are well known may be used. (Java™ is a trademark of Sun Microsystems, Inc.).
1. A database system-implemented method, comprising:
tracking, by the database system, resource usage associated with a plurality of job types requested by one or more tenants in a multi-tenant environment;
calculating, by the database system, a deficiency factor suffered by a job type associated with a tenant, wherein the deficiency factor is based on an actual usage and an expected usage of resources by the job type, wherein the deficiency factor indicates deficiency in usage of the resources by the job type such that the deficiency corresponds to the actual usage of the resources by the job type being lower than the expected usage assigned to the job type by measuring the usage over multiple predetermined segments of time, wherein the deficiency being temporary deficiency or chronic deficiency based on high latency in queuing time or high usage of the resources by one or more of the plurality of job types; and
enforcing, by the database system, an equitable distribution of the resources for the plurality of job types by adjusting a current distribution representing an inequitable distribution, wherein adjusting includes selectively lowering the high usage of the resources by the one or more job types until the deficiency factor is inconsequential such that the actual usage by the job type has increased to match the expected usage.
2. The method of claim 1, wherein calculating further comprises:
computing the actual usage by the job type and one or more actual usages representing the high usage by the one or more job types; and
computing the expected usage associated with the job type and one or more expected usages associated with the one or more job types.
3. The method of claim 1, wherein enforcing comprises triggering fair usage to ensure the equitable distribution of the resources for the plurality of job types.
4. The method of claim 3, wherein triggering comprises prioritizing one or more work hosts associated with the job type to boost processing of tasks associated with the job type, wherein prioritizing is performed over the multiple predetermined segments of time.
5. The method of claim 1, further comprising receiving a job request to perform the job type, wherein the job request is placed at a computing device associated with the tenant in the multi-tenant environment, wherein the job request is placed by a user having access to the computing device.
6. The method of claim 1, wherein the resource usage comprises usage of thread resources, wherein the thread resources are accessed via a plurality of message queues.
7. The method of claim 1, wherein selectively lowering the high usage comprises: minimizing the deficiency factor by automatically adapting a selection process for selection of the plurality of job types; and real-time tracking of the resource usage based on at least one of a sliding window scale, fairness usage, queuing time, and adaptive intervention via configurable threshold, wherein the sliding window scale to facilitate the multiple predetermined segments of time.
8. A system comprising a computing device having a memory device to store instructions, and a processing device to execute the instructions to facilitate a mechanism to perform operations comprising:
tracking, resource usage associated with a plurality of job types requested by one or more tenants in a multi-tenant environment;
calculating, a deficiency factor suffered by a job type associated with a tenant, wherein the deficiency factor is based on an actual usage and an expected usage of resources by the job type, wherein the deficiency factor indicates deficiency in usage of the resources by the job type such that the deficiency corresponds to the actual usage of the resources by the job type being lower than the expected usage assigned to the job type by measuring the usage over multiple predetermined segments of time, wherein the deficiency being temporary deficiency or chronic deficiency based on high latency in queuing time or high usage of the resources by one or more of the plurality of job types; and
enforcing an equitable distribution of the resources for the plurality of job types by adjusting a current distribution representing an inequitable distribution, wherein adjusting includes selectively lowering the high usage of the resources by the one or more job types until the deficiency factor is inconsequential such that the actual usage by the job type has increased to match the expected usage.
9. The system of claim 8, wherein the calculating comprises:
10. The system of claim 8, wherein enforcing comprise triggering fair usage to ensure the equitable distribution of the resources for the plurality of job types.
11. The system of claim 10, wherein triggering comprises prioritizing one or more work hosts associated with the job type to boost processing of tasks associated with the job type, wherein prioritizing is performed over the multiple predetermined segments of time.
12. The system of claim 8, wherein the operations further comprise receiving a job request to perform the job type, wherein the job request is placed at a computing device associated with the tenant in the multi-tenant environment, wherein the job request is placed by a user having access to the computing device.
13. The system of claim 8, wherein the resource usage comprises usage of thread resources, wherein the thread resources are accessed via a plurality of message queues.
14. The system of claim 8, wherein selectively lowering the high usage comprises:
minimizing the deficiency factor by automatically adapting a selection process for selection of the plurality of job types; and
real-time tracking of the resource usage based on at least one of a sliding window scale, fairness usage, queuing time, and adaptive intervention via configurable threshold, wherein the sliding window scale to facilitate the multiple predetermined segments of time.
15. A non-transitory machine-readable medium having stored thereon instructions which, when executed by a machine, cause the machine to perform operations comprising:
tracking resource usage associated with a plurality of job types requested by one or more tenants in a multi-tenant environment;
calculating a deficiency factor suffered by a job type associated with a tenant, wherein the deficiency factor is based on an actual usage and an expected usage of resources by the job type, wherein the deficiency factor indicates deficiency in usage of the resources by the job type such that the deficiency corresponds to the actual usage of the resources by the job type being lower than the expected usage assigned to the job type by measuring the usage over multiple predetermined segments of time, wherein the deficiency being temporary deficiency or chronic deficiency based on high latency in queuing time or high usage of the resources by one or more of the plurality of job types; and
16. The non-transitory machine-readable medium of claim 15, wherein the calculating comprises:
17. The non-transitory machine-readable medium of claim 15, wherein enforcing comprise triggering fair usage to ensure the equitable distribution of the resources for the plurality of job types.
18. The non-transitory machine-readable medium of claim 17, wherein triggering comprises prioritizing one or more work hosts associated with the job type to boost processing of tasks associated with the job type, wherein prioritizing is performed over the multiple predetermined segments of time.
19. The non-transitory machine-readable medium of claim 15, wherein the operations further comprise receiving a job request to perform the job type, wherein the job request is placed at a computing device associated with the tenant in the multi-tenant environment, wherein the job request is placed by a user having access to the computing device.
20. The non-transitory machine-readable medium of claim 15, wherein the resource usage comprises usage of thread resources, wherein the thread resources are accessed via a plurality of message queues.
21. The non-transitory machine-readable medium of claim 15, wherein selectively lowering the high usage comprises:
US13/841,417 2012-09-12 2013-03-15 Facilitating equitable distribution of thread resources for job types associated with tenants in a multi-tenant on-demand services environment Active 2034-01-26 US9529626B2 (en)
US201261700037P true 2012-09-12 2012-09-12
US201261700032P true 2012-09-12 2012-09-12
US201261708283P true 2012-10-01 2012-10-01
US201261709263P true 2012-10-03 2012-10-03
US201261711837P true 2012-10-10 2012-10-10
US13/841,417 US9529626B2 (en) 2012-09-12 2013-03-15 Facilitating equitable distribution of thread resources for job types associated with tenants in a multi-tenant on-demand services environment
US20140075030A1 US20140075030A1 (en) 2014-03-13
US9529626B2 true US9529626B2 (en) 2016-12-27
ID=50234309
US13/841,649 Active 2034-02-27 US9348648B2 (en) 2012-09-12 2013-03-15 Providing a routing framework for facilitating dynamic workload scheduling and routing of message queues for fair management of resources for application servers in an on-demand services environment
US13/841,588 Pending US20140075017A1 (en) 2012-09-12 2013-03-15 Mechanism for facilitating a quorum-based coordination of booker health for management of resources for application servers in an on-demand services enviroment
US13/841,713 Active 2033-11-10 US9268605B2 (en) 2012-09-12 2013-03-15 Mechanism for facilitating sliding window resource tracking in message queues for fair management of resources for application servers in an on-demand services environment
US13/841,417 Active 2034-01-26 US9529626B2 (en) 2012-09-12 2013-03-15 Facilitating equitable distribution of thread resources for job types associated with tenants in a multi-tenant on-demand services environment
US13/841,489 Active 2035-01-31 US10140153B2 (en) 2012-09-12 2013-03-15 System, method, and medium for facilitating auction-based resource sharing for message queues in an on-demand services environment
US16/175,132 Pending US20190095249A1 (en) 2012-09-12 2018-10-30 System, method, and medium for facilitating auction-based resource sharing for message queues in an on-demand services environment
US (6) US9348648B2 (en)
EP (1) EP2895954A1 (en)
JP (2) JP6423344B2 (en)
CN (2) CN104737132B (en)
CA (1) CA2883883A1 (en)
WO (2) WO2014042729A1 (en)
US10027595B2 (en) * 2014-06-23 2018-07-17 Oracle International Corporation System and method for providing a work manager in a multitenant application server environment
US9397905B1 (en) * 2014-01-24 2016-07-19 Amazon Technologies, Inc. Aggregated health check of a multi-tenant service container
US10148738B2 (en) * 2014-11-12 2018-12-04 Zuora, Inc. System and method for equitable processing of asynchronous messages in a multi-tenant platform
US9424077B2 (en) 2014-11-14 2016-08-23 Successfactors, Inc. Throttle control on cloud-based computing tasks utilizing enqueue and dequeue counters
US20160217410A1 (en) * 2015-01-23 2016-07-28 Hewlett-Packard Development Company, L.P. Worker Task Assignment Based on Correlation and Capacity Information
US10027596B1 (en) * 2016-04-27 2018-07-17 EMC IP Holding Company LLC Hierarchical mapping of applications, services and resources for enhanced orchestration in converged infrastructure
US10275325B2 (en) * 2016-06-17 2019-04-30 Weixu Technology Co., Ltd. Method of site isolation protection, electronic device and system using the same method
US20180034904A1 (en) * 2016-07-27 2018-02-01 Salesforce.Com, Inc. Dynamic allocation of stateful nodes for healing and load balancing
CN106453557B (en) * 2016-10-13 2019-04-09 内蒙古工业大学 Multiple time scale model user dynamic bid and Resource Management Algorithm in a kind of IaaS service
US10218813B2 (en) * 2017-01-31 2019-02-26 Salesforce.Com, Inc. Automatic surge protection of system resources
US5937205A (en) 1995-12-06 1999-08-10 International Business Machines Corporation Dynamic queue prioritization by modifying priority value based on queue's level and serving less than a maximum number of requests per queue
EP1510917A1 (en) 2003-08-27 2005-03-02 France Telecom Method of allocating a resource among a plurality of users in real time using an auction mechanism
US20060122927A1 (en) 2004-12-06 2006-06-08 Bernardo Huberman System and method for allocating resources in a distributed computational system using proportional share auctions
US20070091841A1 (en) * 1999-05-24 2007-04-26 Qualcomm, Incorporated Method and System for Scheduling Data Transmission in Communication Systems
US20080178187A1 (en) 2007-01-22 2008-07-24 Yaniv Altshuler Method and computer program product for job selection and resource alolocation of a massively parallel processor
US20090119080A1 (en) 2004-08-27 2009-05-07 Gray Leonard J Computational simulation systems and methods using boundary integral equations
US20090164635A1 (en) 2007-08-07 2009-06-25 Dennis Denker Systems and methods for providing resource allocation in a networked environment
US20090177356A1 (en) 2008-01-08 2009-07-09 Daniel Walter Plawecki Methods and systems for vital bus architecture
US20090265205A1 (en) 2008-03-11 2009-10-22 Incentalign, Inc. Pricing, Allocating, accounting and distributing internal resources using a market mechanism
US7640339B1 (en) 2005-02-14 2009-12-29 Sun Microsystems, Inc. Method and apparatus for monitoring a node in a distributed system
US20100049570A1 (en) * 2008-08-19 2010-02-25 Xin Hui Li Method and system for determining resource usage of each tenant in a multi-tenant architecture
US20110131645A1 (en) 2009-11-30 2011-06-02 Johnson Robert A Load balancing and failover of gateway devices
US20120192194A1 (en) 2011-01-21 2012-07-26 Raymond Richardson Lock Free Acquisition and Release of a Semaphore in a Multi-Core Processor Environment
US20130024496A1 (en) 2011-07-21 2013-01-24 Yahoo! Inc Method and system for building an elastic cloud web server farm
US20130111031A1 (en) 2011-10-26 2013-05-02 Sap Ag Adjustment of end user response times according to user expectations for server applications under load
US20130262931A1 (en) 2012-03-28 2013-10-03 Software Ag Systems and/or methods for testing client reactions to simulated disruptions
US20140068620A1 (en) 2012-08-30 2014-03-06 International Business Machines Corporation Task execution & management in a clustered computing environment
US20140075017A1 (en) 2012-09-12 2014-03-13 salesforce.com,inc. Mechanism for facilitating a quorum-based coordination of booker health for management of resources for application servers in an on-demand services enviroment
US20140289418A1 (en) * 2011-10-10 2014-09-25 Ira Cohen Methods and systems for planning execution of an application in a cloud computing system
JPH0816410B2 (en) 1990-02-22 1996-02-21 株式会社大林組 Air jet snow removal equipment
JP3215264B2 (en) * 1994-06-29 2001-10-02 富士通株式会社 Schedule control apparatus and method
EP2259493B1 (en) * 2000-07-31 2012-01-25 The Boeing Company Distributed game system
JP2004050550A (en) 2002-07-18 2004-02-19 Fuji Xerox Co Ltd Printer
US7363346B2 (en) 2002-09-07 2008-04-22 Appistry, Inc. Reliably storing information across multiple computers such as in a hive of computers
US8527473B1 (en) 2005-10-20 2013-09-03 Teradata Us, Inc. Identifying database request sources in multi-database systems
US8458715B1 (en) 2007-02-23 2013-06-04 Hrl Laboratories, Llc System for allocating resources to optimize transition from a current state to a desired state
US20080244607A1 (en) 2007-03-27 2008-10-02 Vladislav Rysin Economic allocation and management of resources via a virtual resource market
JP5104871B2 (en) 2007-09-26 2012-12-19 富士通株式会社 Resource allocation management program, method resource allocation manager and resource allocation management
US20090287592A1 (en) 2008-05-15 2009-11-19 Worthybids Llc System and method for conferring a benefit to a thrid party from the sale of leads
US20130060834A1 (en) 2011-09-07 2013-03-07 Microsoft Corportion Distributed messaging system connectivity and resource management
2013-03-15 US US13/841,649 patent/US9348648B2/en active Active
2013-03-15 US US13/841,588 patent/US20140075017A1/en active Pending
2013-03-15 US US13/841,713 patent/US9268605B2/en active Active
2013-03-15 US US13/841,417 patent/US9529626B2/en active Active
2013-03-15 US US13/841,489 patent/US10140153B2/en active Active
2013-06-12 WO PCT/US2013/045509 patent/WO2014042729A1/en active Application Filing
2013-06-12 CA CA2883883A patent/CA2883883A1/en active Pending
2013-06-12 JP JP2015531916A patent/JP6423344B2/en active Active
2013-06-12 CN CN201380047246.8A patent/CN104737132B/en active IP Right Grant
2013-06-12 EP EP13731595.8A patent/EP2895954A1/en active Pending
2013-06-12 WO PCT/US2013/045511 patent/WO2014042730A1/en active Application Filing
2013-06-12 CN CN201811091855.4A patent/CN109324900A/en active Search and Examination
2018-10-18 JP JP2018196455A patent/JP2019040613A/en active Pending
2018-10-30 US US16/175,132 patent/US20190095249A1/en active Pending
US20140075445A1 (en) 2012-09-12 2014-03-13 salesforce.com,inc. Mechanism for providing a routing framework for facilitating dynamic workload scheduling and routing of message queues for fair management of resources for application sercers in an on-demand services environment
Lee, Juong-Sik, Recurrent auctions in e-commerce, Rensslaer Polytechnic Institute, ProQuest Dissertations Publishing 2007, 3299458, 2 pages, downloaded from ProQuestDirect on the Internet on Sep. 21, 2015.
PCT International Preliminary Report on Patentability and Written Opinion of the International Searching Authority, International Application No. PCT/US2013/045509 Mailed Mar. 17, 2015, 5 pgs.
PCT/US2013/045509, Notification of Transmittal of the International Searching Report and the Written Opinion of the International Searching Authority, Mailed Oct. 9, 2013.
PCT/US2013/045511, Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority Mailed Oct. 9, 2013, 8 pgs.
U.S. Appl. No. 13/841,417 Non-Final Office Action mailed Dec. 24, 2015, 13 pages.
WO2014042729A1 (en) 2014-03-20
US20140075445A1 (en) 2014-03-13
CN109324900A (en) 2019-02-12
JP2015535975A (en) 2015-12-17
JP6423344B2 (en) 2018-11-14
CN104737132A (en) 2015-06-24
CA2883883A1 (en) 2014-03-20
US20190095249A1 (en) 2019-03-28
US10140153B2 (en) 2018-11-27
EP2895954A1 (en) 2015-07-22
US9268605B2 (en) 2016-02-23
US20140075446A1 (en) 2014-03-13
CN104737132B (en) 2018-10-30
US9348648B2 (en) 2016-05-24
US20140074641A1 (en) 2014-03-13
JP2019040613A (en) 2019-03-14
US20140075030A1 (en) 2014-03-13
WO2014042730A1 (en) 2014-03-20
US20140075017A1 (en) 2014-03-13
US8949270B2 (en) 2015-02-03 Methods and systems for processing social media data
US20160217008A1 (en) 2016-07-28 Resource health based scheduling of workload tasks
JP6423344B2 (en) 2018-11-14 Auction resource sharing based on the order of the message queue in the on-demand service environment
WO2013082119A1 (en) 2013-06-06 Cloud provisioning accelerator
US20110126154A1 (en) 2011-05-26 Intelligent command prediction
US10216821B2 (en) 2019-02-26 Methods and systems for bulk uploading of data in an on-demand service environment
US8856193B2 (en) 2014-10-07 Merge monitor for table delta partitions
US20130007049A1 (en) 2013-01-03 Computer implemented systems and methods for providing a mobile social enterprise interface
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WANG, XIAODAN;DEVADHAR, VIJAYANTH;MURUGESAN, PRAVEEN;REEL/FRAME:030022/0216