Abstract: The load level on a server system is regulated by determining time-to-live (TTL) values to provide to requesting devices that request a content resource from the server system, thereby affecting the frequency of subsequent requests. This dynamic determination of TTL values may provide resilience to system load, for example by using longer TTL values when the system is under greater load to reduce the rate at which subsequent requests are received. A dynamic TTL service may calculate a TTL value based on one or more factors, such as overall system load, resource load, hardware load, and/or software load.

Abstract: Techniques are described for automatically managing shared computing environments, such as a shared computing environment made available by a provider entity for simultaneous use by multiple third-party clients in exchange for fees. The functionality provided by a shared computing environment may have various forms, including in some situations to enable a client to execute a client-provided software program within the shared computing environment. The managing of shared computing environments may include performing various automated operations, including monitoring operational performance of particular shared computing environments and the use of shared computing environments by particular clients, and using information from the monitoring to provide additional functionality to the clients and/or to the providers of the shared computing environments.

Abstract: Time to live (“TTL”) values are determined based on one or more factors. The TTL values may be included in responses to requests for resources, thereby affecting the frequency of subsequent requests. This dynamic determination of TTL values may provide resilience to system load, for example by using longer TTL values when the system is under greater load in order to reduce the rate at which subsequent requests are received. A dynamic TTL service may calculate a TTL value based on one or more factors, such as overall system load, resource load, hardware load, and/or software load. In various embodiments, a dynamic TTL service may act natively within a service, within a system framework, as a proxy, as a cluster, and/or as a broker.

Abstract: Disclosed are various embodiments for prioritizing service requests. A load associated with a service is determined. A request destined for processing by the service is received. One or more client-specified parameters are determined from the request. The client-specified parameters include one or more of: a droppability parameter indicating whether the request is droppable, or a deadline parameter indicating a deadline for completion of processing of the request. When the load meets a threshold, a prioritization is assigned to the request based at least in part on the client-specified parameter.

Abstract: Disclosed are various embodiments for prioritizing service requests. A service request destined for processing by a service provider is obtained in at least one computing device. The service provider is configured to provide a service. The service request includes at least one client-specified parameter indicating a priority of the service request. A load associated with the service is determined. The service request is prioritized for an initial processing stage of the service provider when the load meets at least one threshold. The prioritizing for the initial processing stage is based at least in part on the at least one client-specified parameter. The service request is prioritized for an additional processing stage of the service provider when the load meets the at least one threshold. The prioritizing for the additional processing stage is based at least in part on the at least one client-specified parameter and a result of the initial processing stage.

Abstract: Disclosed are various embodiments for prioritizing service requests. A service request destined for processing by a service provider is obtained in at least one computing device. The service provider is configured to provide a service. The service request includes at least one client-specified parameter indicating a priority of the service request. A load associated with the service is determined. The service request is prioritized for an initial processing stage of the service provider when the load meets at least one threshold. The prioritizing for the initial processing stage is based at least in part on the at least one client-specified parameter. The service request is prioritized for an additional processing stage of the service provider when the load meets the at least one threshold. The prioritizing for the additional processing stage is based at least in part on the at least one client-specified parameter and a result of the initial processing stage.

Abstract: A system that provides services to clients may receive and service requests, various ones of which may require different amounts of work. An admission control mechanism may manage requests based on tokens, each of which represents a fixed amount of work. The tokens may be added to a token bucket at rate that is dependent on a target work throughput rate while the number of tokens in the bucket does not exceed its maximum capacity. If at least a pre-determined minimum number of tokens is present in the bucket when a service request is received, it may be serviced. Servicing a request may include deducting an initial number of tokens from the bucket, determining that the amount of work performed in servicing the request is different than that represented by the initially deducted tokens, and deducting additional tokens from or replacing tokens in the bucket to reflect the difference.

Abstract: 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.

Abstract: Disclosed are various embodiments for facilitating the purchase of excess items. In one embodiment, customer information and inventory data are retrieved from a merchant client. A determination is made on whether excess items exist. A list of target purchasers is generated based on data associated with a user account, and offers are generated and sent by electronic communication to the list of target purchasers.

Abstract: Disclosed are various embodiments for facilitating the purchase of excess items. In one embodiment, customer information and inventory data are retrieved from a merchant client. A determination is made on whether excess items exist. A list of target purchasers is generated based on data associated with a user account, and offers are generated and sent by electronic communication to the list of target purchasers.