IP Library Granted Patent US 9,825,882
Granted Patent B2
US 9,825,882 · App. 14/828,811 · Granted Nov 21, 2017

Methods for an automatic scaling of data consumers and apparatuses using the same

Inventors: Hsing-Wei Lin (New Taipei, TW); Jung-Hsuan Fan (New Taipei, TW)
Assignee: ACER INCORPORATED
H04L47/827H04L43/0882H04L47/127H04L47/30H04L67/02H04L67/22
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,825,882
App. No.
14/828,811
Granted
Nov 21, 2017
Kind
B2
Abstract

The invention introduces a method for an automatic scaling of data consumers, performed by a processing unit of a data-consumer server, which contains at least the following steps. State-update requests are received from data consumers, where each state-update request includes a busy state or an idle state and the busy state indicates that the data consumer reads data from a queue and processes the read data. A first quantity of data consumers, a second quantity of busy states and a third quantity of idle states are calculated. A fourth quantity of data consumers to be produced is estimated according to the first, second and third quantities. Data consumers of the fourth quantity are produced.

Claims (33)

1. A method for an automatic scaling of data consumers, performed by a processing unit of a data-consumer server, comprising:

receiving a plurality of state-update requests from a plurality of data consumers, wherein each state-update request comprises a busy state or an idle state and the busy state indicates that the data consumer reads data from a queue and processes the read data;

calculating a first quantity indicating a total number of the state-update requests received from the data consumers, a second quantity indicating a total number of busy states included in the state-update requests and a third quantity indicating a total number of idle states included in the state-update requests;

estimating a fourth quantity of data consumers according to the first, second and third quantities; and

increasing or decreasing data consumers according to the fourth quantity.

2. The method of claim 1 , wherein the step for calculating a first quantity indicating a total number of the state-update requests received from the data consumers, a second quantity indicating a total number of busy states included in the state-update requests and a third quantity indicating a total number of idle states included in the state-update requests further comprises:

after receiving each state-update request, increasing the first quantity by one and determining whether the state-update request comprises a busy state or an idle state;

when the state-update request comprises the busy state, increasing the second quantity by one; and

when the state-update request comprises the idle state, increasing the third quantity by one.

3. The method of claim 1 , wherein the step for estimating a fourth quantity of data consumers according to the first, second and third quantities further comprises:

after receiving a monitoring-trigger request from a load-monitoring module, estimating the fourth quantity of data consumers according to the first, second and third quantities.

4. The method of claim 3 , further comprising:

obtaining a fifth quantity indicating an upper limit of data consumers;

determining whether the fourth quantity plus the first quantity exceeds the fifth quantity;

if so, replying with a first message indicating an over-loading to the load-monitoring module; and

otherwise, replying with a second message indicating a normal state to the load-monitoring module.

5. The method of claim 4 , wherein the load-monitoring module determines whether to add an available data-consumer server to a server cluster according to reception of the first message and the second message.

6. The method of claim 4 , wherein the method is performed by a Web server and communicates with the load-monitoring module using an HTTP (HyperText Transfer Protocol) or an HTTPS (HTTP Secure).

7. The method of claim 1 , wherein the method is performed by a Web server and communicates with the load-monitoring module using an HTTP (HyperText Transfer Protocol) or an HTTPS (HTTP Secure).

8. The method of claim 1 , wherein each data consumer is implemented in a thread and the threads do not share a context.

9. The method of claim 1 , wherein the step for calculating a first quantity indicating a total number of the state-update requests received from the data consumers, a second quantity indicating a total number of busy states included in the state-update requests and a third quantity indicating a total number of idle states included in the state-update requests further comprises:

not querying the queue a total amount of data buffered in the queue.

10. An apparatus for an automatic scaling of data consumers, comprising:

a memory configured to store data in execution; and

a processing unit, coupled to the memory, receiving a plurality of state-update requests from a plurality of data consumers, wherein each state-update request comprises a busy state or an idle state and the busy state indicates that the data consumer reads data from a queue and processes the read data; calculating a first quantity indicating a total number of the state-update requests received from the data consumers, a second quantity indicating a total number of busy states included in the state-update requests and a third quantity indicating a total number of idle states included in the state-update requests; estimating a fourth quantity of data consumers according to the first, second and third quantities; and increasing or decreasing data consumers according to the fourth quantity.

11. The apparatus of claim 10 , wherein the processing unit, after receiving each state-update request, increases the first quantity by one and determines whether the state-update request comprises a busy state or an idle state; when the state-update request comprises the busy state, increases the second quantity by one; and when the state-update request comprises the idle state, increases the third quantity by one.

12. The apparatus of claim 10 , wherein the processing unit, after receiving a monitoring-trigger request from a load-monitoring module, estimates the fourth quantity of data consumers according to the first, second and third quantities.

13. The apparatus of claim 12 , wherein the processing unit obtains a fifth quantity indicating an upper limit of data consumers; determines whether the fourth quantity plus the first quantity exceeds the fifth quantity; if so, replies with a first message indicating an over-loading to the load-monitoring module; and otherwise, replies with a second message indicating a normal state to the load-monitoring module.

14. The apparatus of claim 13 , wherein the load-monitoring module determines whether to add an available data-consumer server to a server cluster according to reception of the first message and the second message.

15. The apparatus of claim 14 , wherein the processing unit communicates with the load-monitoring module using an HTTP (HyperText Transfer Protocol) or an HTTPS (HTTP Secure).

16. The apparatus of claim 10 , wherein the processing unit communicates with the load-monitoring module using an HTTP (HyperText Transfer Protocol) or an HTTPS (HTTP Secure).

17. The apparatus of claim 10 , wherein each data consumer is implemented in a thread and the threads do not share a context.

18. The apparatus of claim 10 , wherein the processing unit does not query the queue a total amount of data buffered in the queue.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 18, 2015
From: LIN, HSING-WEI; FAN, JUNG-HSUAN
To: ACER INCORPORATED
Reel/Frame 036348/0129 →
Priority Claims (1)
TW 104116933 A · May 27, 2015 · national
Continuity (1)
Related Publication 20160352649A1 · Dec 1, 2016