您別無選擇–基礎系統（此處的JVM將為您完成此選擇）。

我仍然記得2013年夏天，當時我正在運行一個項目，整個應用程序中只有1個URL使服務器癱瘓。 問題很簡單-機器人決定以很高的速率索引我們的網站，并且該機器人正在創建數百萬個URL組合，這些組合繞過了我所有的緩存層，并且都擊中了我的應用程序服務器。 好吧，我們在應用程序中的緩存率非常高（大約95％），并且應用程序服務器層并不是為高負載而設計的（這是Adobe AEM 5.6，執行搜索和制作頁面的邏輯在計算上非常繁瑣）。 那年早些時候，我們想處理Dog-Pile效應的案例，并且我們談到要進行某種限制。 在對話開始時，每個人都對節制相同的想法不滿意（2個人除外）。

在2012年秋天， Ravi Pal建議采取適當的錯誤處理措施，使系統不僅應該掉在頭上，而且應優雅地降級。 當我們在2013年遇到這個問題時，我才意識到他建議的嚴重性。

現在，我正在另一個平臺上工作，當我提出節流的想法時，它又一次被皺了皺眉。 一個人在一次會議上實際上嘲笑我。 另一個人建議我們要通過“自動縮放”處理場景，而不是限制場景。 我們在AWS Cloud上擁有基礎架構，但我不是專家，但是專家告訴我，服務器可以在大約10分鐘內原樣復制（我們將 證明 對此進行基準測試）。

我是一位雄心勃勃的建筑師，盡管我控制了進入我網站的流量。 我不再生活在那種幻想中。

這可能是一系列的帖子，但是今天在這里我開始向您展示您沒有選擇的余地，無論您是否喜歡它，系統都會為您限制流量。

基準概述

• 使用Spring Boot構建的簡單Web應用程序
• 一個Spring MVC REST控制器 ，它將接受一些HTTP請求并在誘發的延遲后發送回OK響應
• jMeter模擬負載
• 一個自定義插件 （向這些家伙大喊大叫的插件）可生成逐步加載并捕獲自定義增強圖
• 托管網站的Tomcat 8.x –使用Spring Boot在內存中啟動。 未完成自定義

第一組–好人

測試計劃

該線程組將模擬對我們的應用程序服務器的一致請求流。 一個典型的情況經常發生。

服務器性能

如預期的那樣？ 是。

如下圖所示，該圖表顯示應用程序服務器的行為正常。 15分鐘內的所有請求都與“單用戶模型”（也就是1秒請求響應時間）一致。

第二組-突發的高流量

測試計劃

該測試計劃是一種分步實施的方法，它試圖模擬一種情況，即廣告活動將在短時間內開始到達某個頁面（或一組頁面）。 在我們的網站向全世界開放的行業中，我們經常看到這種用例。

這個線程組不是OOTB，我下載了一個插件

服務器性能

那么，我們期望發生什么呢？ 根據我的服務器有多少果汁（線程，cpu循環等），我的服務器可能會或可能無法處理請求。 鑒于我正在本地筆記本電腦上運行所有程序，如果我的本地機器可以處理600個線程，那將很有趣。

而且我們發現我的筆記本電腦無法真正處理600線程。 那么，tomcat是做什么的呢？

它節流

好人變化的表現

測試計劃

我運行第一個測試計劃，并遵循高流量計劃（引入30秒的延遲）。

影響力

下圖顯示了好人如何受到影響。 盡管The Good One的訪問量沒有變化，但仍然受到影響，因為其他因素導致了峰值。

請告訴JVM您不喜歡節流

下一個是什么

您實際上有3個選擇（我們將在單獨的文章中詳細介紹以下各項）

自動縮放應用程序服務器，并希望新服務器能及時準備就緒以處理負載，或者

在節流和控制自己的命運方面做些什么 - 如果 高流量不是好收入來源，好人卻是收入來源呢？

繼續皺著眉頭

翻譯自: https://www.javacodegeeks.com/2015/08/dont-like-throttling.html

總結

以上是生活随笔為你收集整理的不喜欢节流吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。