4 ms·
With shares you're going to experience worse latency if all the containers on the system size their thread pool to the maximum that's available during idle peri
by the8472 3y ago
With shares you're going to experience worse latency if all the containers on the system size their thread pool to the maximum that's available during idle periods and then constantly context-switch due to oversubscription under load.
With quotas you can do fixed resource allocation and the runtimes (not Go apparently) can fit themselves into that and not try to service more requests than they can currently execute given those resources.
- dilyevsky 3y agoAnd how is that different from worse latency due to cpu throttling from your users’ perspective?
- the8472 3y agoFixed queue, so it'll only take as many as it can process and reject the rest, which can be used to do scaling, if you have a cluster. With shares it would think it has all the CPU cores available and oversize the queue.
- dilyevsky 3y agoDoesn’t answer my q really. At least in kubernetes scaling is done by measuring usage against the request (shares) not the limit (quota)
- eightnoteight 3y agothis is a predictable worse latency due to CPU throttling, i.e nothing is suddenly introduced in the system. but the other case is worse i.e a non critical microservice can cause outage on your critical microservice. imagine some non critical system like blog-service suddenly causing 2-3% new order creation failures