负载性能 #5297

WangLeto · 2019-03-04T02:08:18Z

resolve #5279

pull from origin repo

负载性能

xionglong58 · 2019-03-04T02:36:56Z

@fanyijihua 校对认领

fanyijihua · 2019-03-04T02:36:57Z

@xionglong58 好的呢 🍺

sunui · 2019-03-04T02:42:27Z

@fanyijihua 校对认领

fanyijihua · 2019-03-04T02:42:29Z

@sunui 妥妥哒 🍻

xionglong58

@fanyijihua 校对完成
@WangLeto 译者翻译的很完美，值得学习

xionglong58 · 2019-03-04T06:29:59Z

TODO1/performance-under-load.md


-At Netflix we are obsessed with service availability, and we’ve written several blog posts over the years about how we achieve our goals. These techniques include circuit breakers, concurrency limits, chaos testing and more. Today we’re announcing our most recent innovation: adaptive concurrency limits. Adaptive concurrency limits fundamentally improve how an application behaves under extreme load, and allow us to avoid cascading service failures. We have eliminated the arduous task of trying to determine the concurrency limit of a system, while ensuring that latencies remain low. With this announcement, we’re also open-sourcing a simple Java library with integrations for servlets, executors and GRPC.
+在 Netflix，我们沉痴迷于服务可用性的研究，关于如何实现目标这几年也写了几篇博客文章。这些技术包括了[断路器模式](https://zh.m.wikipedia.org/wiki/斷路器設計模式)，并发限制，混沌测试等等。现在我们宣布最近的创新：自适应并发限制。自适应并发限制从根本上提升了应用程序在极端负载下的表现，并使得我们可以避免级联服务故障。我们移除了判定系统并发限制的艰难工作，又保证了延迟保持较低水平。本文发布的同时，我们开源了一个简单的 Java 类库，集成了 servlet，executor 和 GRPC 框架支持。



这些技术包括了断路器模式、并发限制、混沌测试等等。

xionglong58 · 2019-03-04T06:32:47Z

TODO1/performance-under-load.md


-To solve this problem we turned to tried and true TCP congestion control algorithms that seek to determine how many packets may be transmitted concurrently (i.e. congestion window size) without incurring timeouts or increased latency. These algorithms keep track of various metrics to estimate the system’s concurrency limit and constantly adjust the congestion window size.
+为了解决该问题，我们转向尝试真正的TCP拥塞控制算法，不会引起超时或增加延迟就能探明可以同时传输多少个数据包（比如拥塞窗口大小）。这些算法持续跟踪各种指标，以估算系统的并发限制，并持续调节拥塞窗口大小。


为了解决该问题，我们转向尝试真正的 TCP 拥塞控制算法，不会引起超时或增加延迟就能探明可以同时传输多少个数据包（比如拥塞窗口大小）。这些算法持续跟踪各种指标，以估算系统的并发限制，并持续调节拥塞窗口大小。

sunui

@WangLeto @leviding 校对完成，翻译的很好

sunui · 2019-03-04T06:37:27Z

TODO1/performance-under-load.md

-*Adaptive Concurrency Limits @ Netflix*
->  by Eran Landau, William Thurston, Tim Bozarth
+**Netflix 的自适应并发限制**
+> Eran Landau, William Thurston, Tim Bozarth 作


逗号改成顿号

sunui · 2019-03-04T06:38:04Z

TODO1/performance-under-load.md


-At Netflix we are obsessed with service availability, and we’ve written several blog posts over the years about how we achieve our goals. These techniques include circuit breakers, concurrency limits, chaos testing and more. Today we’re announcing our most recent innovation: adaptive concurrency limits. Adaptive concurrency limits fundamentally improve how an application behaves under extreme load, and allow us to avoid cascading service failures. We have eliminated the arduous task of trying to determine the concurrency limit of a system, while ensuring that latencies remain low. With this announcement, we’re also open-sourcing a simple Java library with integrations for servlets, executors and GRPC.
+在 Netflix，我们沉痴迷于服务可用性的研究，关于如何实现目标这几年也写了几篇博客文章。这些技术包括了[断路器模式](https://zh.m.wikipedia.org/wiki/斷路器設計模式)，并发限制，混沌测试等等。现在我们宣布最近的创新：自适应并发限制。自适应并发限制从根本上提升了应用程序在极端负载下的表现，并使得我们可以避免级联服务故障。我们移除了判定系统并发限制的艰难工作，又保证了延迟保持较低水平。本文发布的同时，我们开源了一个简单的 Java 类库，集成了 servlet，executor 和 GRPC 框架支持。


沉痴迷=>沉迷

sunui · 2019-03-04T06:38:27Z

TODO1/performance-under-load.md


-At Netflix we are obsessed with service availability, and we’ve written several blog posts over the years about how we achieve our goals. These techniques include circuit breakers, concurrency limits, chaos testing and more. Today we’re announcing our most recent innovation: adaptive concurrency limits. Adaptive concurrency limits fundamentally improve how an application behaves under extreme load, and allow us to avoid cascading service failures. We have eliminated the arduous task of trying to determine the concurrency limit of a system, while ensuring that latencies remain low. With this announcement, we’re also open-sourcing a simple Java library with integrations for servlets, executors and GRPC.
+在 Netflix，我们沉痴迷于服务可用性的研究，关于如何实现目标这几年也写了几篇博客文章。这些技术包括了[断路器模式](https://zh.m.wikipedia.org/wiki/斷路器設計模式)，并发限制，混沌测试等等。现在我们宣布最近的创新：自适应并发限制。自适应并发限制从根本上提升了应用程序在极端负载下的表现，并使得我们可以避免级联服务故障。我们移除了判定系统并发限制的艰难工作，又保证了延迟保持较低水平。本文发布的同时，我们开源了一个简单的 Java 类库，集成了 servlet，executor 和 GRPC 框架支持。


servlet，executor 逗号改顿号

sunui · 2019-03-04T06:56:36Z

TODO1/performance-under-load.md


-When enabled, adaptive server side limits reject excess RPS and keep latency low, allowing the instance to protect itself and the services it depends on. Without rejecting excess traffic, any sustained increase in RPS or latency previously translated to even worse latencies and ultimately system failure. Services are now able to shed excess load and keep latencies low while other mitigating actions such as auto-scaling kick into action.
+启用后，自适应服务器端并发限制会拒绝过多的 RPS（Request Per Second） 来较低的延迟，从而保护实例自身及其所依赖的服务。如果不拒绝过多的并发请求，RPS 或延迟的任一的持续增加都会转化为更糟糕的延迟并最终导致系统故障。服务现在能够减少过多的负载并保持较低的延迟，而其他缓和措施（如自动扩展）则会起作用。


来较低的延迟？

sunui · 2019-03-04T06:57:51Z

TODO1/performance-under-load.md


-When enabled, adaptive server side limits reject excess RPS and keep latency low, allowing the instance to protect itself and the services it depends on. Without rejecting excess traffic, any sustained increase in RPS or latency previously translated to even worse latencies and ultimately system failure. Services are now able to shed excess load and keep latencies low while other mitigating actions such as auto-scaling kick into action.
+启用后，自适应服务器端并发限制会拒绝过多的 RPS（Request Per Second） 来较低的延迟，从而保护实例自身及其所依赖的服务。如果不拒绝过多的并发请求，RPS 或延迟的任一的持续增加都会转化为更糟糕的延迟并最终导致系统故障。服务现在能够减少过多的负载并保持较低的延迟，而其他缓和措施（如自动扩展）则会起作用。


RPS 或延迟的任一的持续增加 =>RPS 或延迟任一的持续增加

sunui · 2019-03-04T07:07:10Z

TODO1/performance-under-load.md


-We’re excited to share our implementation and common integrations in a small open source library that can be found at [http://github.com/Netflix/concurrency-limits](http://github.com/Netflix/concurrency-limits). Our hope is that anyone interested in shielding their services from cascading failures and load-related latency degradation can take advantage of our code to achieve better availability. We look forward to feedback from the community and are happy to accept pull requests with new algorithms or integrations.
+我们很高兴在一个小型开源库中分享我们的思路实现和常见框架集成：http://github.com/Netflix/concurrency-limits。 我们希望，任何想要保护其服务免于级联故障和与负载引起的延迟降级的人，都可以利用我们的代码来实现更好的可用性。 我们期待社区的反馈，并乐意接受新算法或框架集成的提交请求（Pull Request）。


Pull Request 可以不翻译

WangLeto · 2019-03-04T14:05:21Z

修改了校对反馈的问题；两位过奖了 (⌒_⌒;)

sunui · 2019-03-05T05:07:09Z

TODO1/performance-under-load.md

@@ -2,69 +2,70 @@
 > * 原文作者：[Netflix Technology Blog Netflix Technology Blog](https://medium.com/@NetflixTechBlog)
 > * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
 > * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/TODO1/performance-under-load.md](https://github.com/xitu/gold-miner/blob/master/TODO1/performance-under-load.md)
-> * 译者：
+> * 译者：[WangLeto](https://github.com/WangLeto)
 > * 校对者：


校对者加一下

WangLeto · 2019-03-06T02:02:28Z

@leviding 你好，校对修改完成~

xionglong58 · 2019-03-06T02:46:24Z

@fanyijihua

leviding · 2019-03-06T11:08:35Z

@WangLeto 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。

掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。
专栏地址：https://zhuanlan.zhihu.com/juejinfanyi

xionglong58 · 2019-03-06T14:31:35Z

https://juejin.im/post/5c7faa955188251bdd53ebd2 @fanyijihua 已经发布

WangLeto added 2 commits March 3, 2019 22:37

Merge pull request #1 from xitu/master

e17b38d

pull from origin repo

负载性能

392fe4f

负载性能

fanyijihua added the 校对认领 label Mar 4, 2019

fanyijihua mentioned this pull request Mar 4, 2019

performance-under-load #5275

Merged

fanyijihua added the 正在校对 label Mar 4, 2019

leviding added the 后端 label Mar 4, 2019

Fengziyin1234 mentioned this pull request Mar 4, 2019

负载性能 #5279

Closed

fanyijihua removed the 校对认领 label Mar 4, 2019

xionglong58 reviewed Mar 4, 2019

View reviewed changes

sunui reviewed Mar 4, 2019

View reviewed changes

leviding added the enhancement 等待译者修改 label Mar 4, 2019

根据校对反馈修改

a6e05c8

sunui reviewed Mar 5, 2019

View reviewed changes

补充校对者信息

ac4813a

leviding added 标注待管理员 Review and removed enhancement 等待译者修改 labels Mar 5, 2019

Update performance-under-load.md

4515a20

leviding approved these changes Mar 6, 2019

View reviewed changes

leviding merged commit bda3982 into xitu:master Mar 6, 2019

leviding added 翻译完成 and removed 标注待管理员 Review 正在校对 labels Mar 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

负载性能 #5297

负载性能 #5297

WangLeto commented Mar 4, 2019 •

edited

Loading

xionglong58 commented Mar 4, 2019

fanyijihua commented Mar 4, 2019

sunui commented Mar 4, 2019

fanyijihua commented Mar 4, 2019

xionglong58 left a comment

xionglong58 Mar 4, 2019

xionglong58 Mar 4, 2019

sunui left a comment

sunui Mar 4, 2019

sunui Mar 4, 2019

sunui Mar 4, 2019

sunui Mar 4, 2019

sunui Mar 4, 2019

sunui Mar 4, 2019

WangLeto commented Mar 4, 2019 •

edited

Loading

sunui Mar 5, 2019

WangLeto commented Mar 6, 2019

xionglong58 commented Mar 6, 2019

leviding commented Mar 6, 2019

xionglong58 commented Mar 6, 2019


		At Netflix we are obsessed with service availability, and we’ve written several blog posts over the years about how we achieve our goals. These techniques include circuit breakers, concurrency limits, chaos testing and more. Today we’re announcing our most recent innovation: adaptive concurrency limits. Adaptive concurrency limits fundamentally improve how an application behaves under extreme load, and allow us to avoid cascading service failures. We have eliminated the arduous task of trying to determine the concurrency limit of a system, while ensuring that latencies remain low. With this announcement, we’re also open-sourcing a simple Java library with integrations for servlets, executors and GRPC.
		在 Netflix，我们沉痴迷于服务可用性的研究，关于如何实现目标这几年也写了几篇博客文章。这些技术包括了[断路器模式](https://zh.m.wikipedia.org/wiki/斷路器設計模式)，并发限制，混沌测试等等。现在我们宣布最近的创新：自适应并发限制。自适应并发限制从根本上提升了应用程序在极端负载下的表现，并使得我们可以避免级联服务故障。我们移除了判定系统并发限制的艰难工作，又保证了延迟保持较低水平。本文发布的同时，我们开源了一个简单的 Java 类库，集成了 servlet，executor 和 GRPC 框架支持。


		To solve this problem we turned to tried and true TCP congestion control algorithms that seek to determine how many packets may be transmitted concurrently (i.e. congestion window size) without incurring timeouts or increased latency. These algorithms keep track of various metrics to estimate the system’s concurrency limit and constantly adjust the congestion window size.
		为了解决该问题，我们转向尝试真正的TCP拥塞控制算法，不会引起超时或增加延迟就能探明可以同时传输多少个数据包（比如拥塞窗口大小）。这些算法持续跟踪各种指标，以估算系统的并发限制，并持续调节拥塞窗口大小。


		When enabled, adaptive server side limits reject excess RPS and keep latency low, allowing the instance to protect itself and the services it depends on. Without rejecting excess traffic, any sustained increase in RPS or latency previously translated to even worse latencies and ultimately system failure. Services are now able to shed excess load and keep latencies low while other mitigating actions such as auto-scaling kick into action.
		启用后，自适应服务器端并发限制会拒绝过多的 RPS（Request Per Second）来较低的延迟，从而保护实例自身及其所依赖的服务。如果不拒绝过多的并发请求，RPS 或延迟的任一的持续增加都会转化为更糟糕的延迟并最终导致系统故障。服务现在能够减少过多的负载并保持较低的延迟，而其他缓和措施（如自动扩展）则会起作用。


		We’re excited to share our implementation and common integrations in a small open source library that can be found at [http://github.com/Netflix/concurrency-limits](http://github.com/Netflix/concurrency-limits). Our hope is that anyone interested in shielding their services from cascading failures and load-related latency degradation can take advantage of our code to achieve better availability. We look forward to feedback from the community and are happy to accept pull requests with new algorithms or integrations.
		我们很高兴在一个小型开源库中分享我们的思路实现和常见框架集成：http://github.com/Netflix/concurrency-limits。我们希望，任何想要保护其服务免于级联故障和与负载引起的延迟降级的人，都可以利用我们的代码来实现更好的可用性。我们期待社区的反馈，并乐意接受新算法或框架集成的提交请求（Pull Request）。

负载性能 #5297

负载性能 #5297

Conversation

WangLeto commented Mar 4, 2019 • edited Loading

xionglong58 commented Mar 4, 2019

fanyijihua commented Mar 4, 2019

sunui commented Mar 4, 2019

fanyijihua commented Mar 4, 2019

xionglong58 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sunui left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WangLeto commented Mar 4, 2019 • edited Loading

Choose a reason for hiding this comment

WangLeto commented Mar 6, 2019

xionglong58 commented Mar 6, 2019

leviding commented Mar 6, 2019

xionglong58 commented Mar 6, 2019

WangLeto commented Mar 4, 2019 •

edited

Loading

WangLeto commented Mar 4, 2019 •

edited

Loading