Methods, apparatus, systems and articles of manufacture (e.g., physical storage media) to implement and manage software defined silicon products are disclosed. Example semiconductor devices disclosed herein include circuitry configurable to provide one or more features. Disclosed example semiconductor devices also include a license processor to activate or deactivate at least one of the one or more features based on a license received via a network from a first remote enterprise system. Disclosed example semiconductor devices further include an analytics engine to report telemetry data associated with operation of the semiconductor device to at least one of the first remote enterprise system or a second remote enterprise system, the analytics engine to report the telemetry data in response to activation or deactivation of the at least one of the one or more features based on the license.

Techniques are described that enable, in a multi-region cloud environment, information regarding one or more tenancy sessions that a network access program (e.g., a browser) participates in to be efficiently stored in a centralized location. The centrally stored sessions information can then be used for various purposes such as for restricting the number of tenancy sessions using a network access program, sessions cleanup, and other sessions-related tasks. In certain implementations, the centrally stored sessions information is used to prevent the network access program from opening multiple sessions for the same tenancy. In such implementations, for a particular tenancy, the network access program is allowed to have only one active session for the particular tenancy at a time. The centrally stored sessions information facilitates efficient sessions management including session cleanup after a session is closed.

Techniques are provided for automatically resizing applications. In one technique, policy data that indicates an order of multiple policies is stored. The policies include (1) a first policy that corresponds to a first computer resource and a first resizing action and (2) a second policy that is lower in priority than the first policy and that corresponds to a second resizing action and a second computer resource. Resource utilization data is received from at least one application executing in a cloud environment. Based on the order, the first policy is identified. Based on the resource utilization data, it is determined whether criteria associated with the first policy are satisfied with respect to the application. If satisfied, then the first resizing action is performed with respect to the application; otherwise, based on the computer resource utilization data, it is determined whether criteria associated with the second policy are satisfied.

Systems, methods, devices, and other techniques for managing a computing resource shared by a set of online entities. A system can receive a request from a first online entity to reserve capacity of the computing resource. The system determines a relative priority of the first online entity and identifies a reservation zone that corresponds to the relative priority of the first online entity. The system determines whether to satisfy the request based on comparing (i) an amount of the requested capacity of the computing resource and (ii) an amount of the portion of unused capacity of the computing resource designated by the reservation zone that online entities having relative priorities at or below the relative priority of the first online entity are permitted to reserve.

[Problem] When resource reserved in a resource sharing system become unavailable, the reservation is efficiently transferred. [Solution] In a resource sharing system 10, a plurality of users 20 (user terminals) share a plurality of resources 30. A resource reservation management device 42 includes: a reservation setting unit 402 that accepts a reservation request including a usage condition of the plurality of resources 30 from the user 20 and sets a usage reservation according to the usage condition to a first resource predetermined 30 in the resource sharing system 10; and a reservation changing unit 404 that re-sets the usage reservation to a second resource 30 being different from the first resource 30 in the resource sharing system 10 when a reserved resource 30 becomes unavailable. When a resource capacity of the second resource 30 is insufficient for the usage reservation to be re-set, the reservation changing unit 404 changes the usage condition and re-sets the usage reservation to the second resource 30.

A computing resource may be monopolized or dominated by a client, if the client has a large quantity of tasks for execution and/or the tasks from that client take a long time to execute. In some embodiments, each client is associated with a respective counter, and the counter is indicative of how much the computing resource has been recently occupied by the client associated with that counter. In some embodiments, the computing resource refrains from executing new tasks for a client if its counter is within a particular range. In some embodiments, a counter increments when the computing resource is occupied by a client and decrements otherwise based on the passage of time. In some embodiments, different counters may have different rates of incrementing or decrementing, or different particular ranges.

Ensuring the fair utilization of system resources using workload based, time-independent scheduling, including: determining whether an amount of available system resources in the storage system has reached a predetermined reservation threshold; and responsive to determining that the amount of available system resources in the storage system has reached the predetermined reservation threshold: determining whether one or more entities in the storage system have utilized system resources in excess of their fair share by a predetermined threshold during one or more time-independent periods; and responsive to determining that one or more entities in the storage system have utilized system resources in excess of their fair share by the predetermined threshold during the time-independent period, limiting the one or more entities from issuing additional I/O requests to the storage system.

A scaling manager manages deques that track groups of preinitialized instances used to scale respective groups of active compute instances. Various techniques for deque management include a rate-based technique that uses a historical scale-up rate for a particular group and adjusts the size of the deque of preinitialized instances for that group based on the monitored scale-up rate and based on an instance preinitialization time for instances for that group. A total instance quantity may be bounded, in some examples, and an additional “buffer amount” of preinitialized instances may be implemented to provide a safety margin for burst scaling, which can be further enhanced by transferring instances between data structures of different groups of instances in some cases.

Detecting a trend in latency for storage underlying a deduplicated file system includes generating a set of data points by recording when input/output (IO) requests were issued to the storage and recording time required to receive success responses from the storage. Least squares regression is performed on the data points to find a best-fit line through the data points. A slope of the best-fit line is calculated. A determination is made as to whether the slope is positive, a positive slope thereby indicating a trend of increasing latency of the storage. When the slope is determined to be positive, clients accessing the deduplicated file system are throttled.

A system that provides services to clients may receive and service requests, various ones of which may require different amounts of work. The system may determine whether it is operating in an overloaded or underloaded state based on a current work throughput rate, a target work throughput rate, a maximum request rate, or an actual request rate, and may dynamically adjust the maximum request rate in response. For example, if the maximum request rate is being exceeded, the maximum request rate may be raised or lowered, dependent on the current work throughput rate. If the target or committed work throughput rate is being exceeded, but the maximum request rate is not being exceeded, a lower maximum request rate may be proposed. Adjustments to the maximum request rate may be made using multiple incremental adjustments. Service request tokens may be added to a leaky token bucket at the maximum request rate.