Гісторыю пра аварыю ўсе расказваюць аднолькава: дабілі яе паўторы. Сэрвіс замарудзіўся, кожны кліент паспрабаваў яшчэ раз, лішняя нагрузка легла на машыну, якая і так не паспявае. Далей яно не падымаецца, пакуль не выключыш кліентаў. Я верыў у гэта дастаткова, каб паўтарыць на архітэктурным рэўю. І ніводнага разу не бачыў тых самых лікаў з выключанымі паўторамі.
Таму сабраў найменшы стэнд, на якім эфект наогул відаць. Сэрвіс трымае 20 запытаў адначасова па 20 мілісекунд кожны, то бок столь 1000 у секунду. Перад ім чарга на 100. Усё, што прыходзіць на поўную чаргу, адразу атрымлівае 503. Кліент выпускае запыты па раскладзе, а не чакае, пакуль вызваліцца папярэдні, з таймаўтам 100 мілісекунд, бо менавіта так выглядае натоўп карыстальнікаў.
Далей я загнаў нагрузку за столь з выключанымі паўторамі. Гэта і ёсць тая палова доследу, якую я раней не здолеў прагнаць.
Пры 800 у секунду праходзіць усё. Пры 1000 у секунду таксама праходзіць усё, з медыянай 58 мілісекунд. Пры 1200 у секунду, то бок пры нагрузцы на 20 адсоткаў большай, карысны выхад падае з 909 у секунду да 65. Гэта ў 14 разоў горш ад росту ў 1.2 раза. Ніхто нічога не паўтарае.
Сэрвіс пры гэтым не зламаны. За 6.6 секунды прагону ён даводзіць да канца 6067 запытаў, гэта каля 920 у секунду, амаль тая ж столь, што была заўсёды. Проста 5627 з гэтых 6067 завяршэнняў, то бок 93 адсоткі, пішуцца кліентам, якія ўжо здаліся і сышлі. Чарга трымае 100 запытаў, сэрвіс разграбае 1000 у секунду, значыць запыт, які трапіў у хвост чаргі, чакае каля 100 мілісекунд. Роўна столькі, колькі кліент выставіў таймаўтам. Усё, што далей за гэтую кропку, гэта праца ні для кога.
Цяпер уключаем паўторы
Той жа стэнд, тыя ж нагрузкі, кожная адмова паўтараецца да 2 разоў.
Трафік ідзе з 7200 спробаў да 20701, гэта ў 2.88 раза. Пры 1500 пададзеных выходзіць 2.95 раза. Адмовы 503 растуць з 1133 да 14521. А карысны выхад ідзе з 65 у секунду да 76.
Уверх. Не ўніз. Паўторы ў гэтым стэндзе купілі 11 лішніх поспехаў у секунду, патроіўшы трафік, бо чарга і так была поўная. Лішнія спробы адбіваліся на ўваходзе за мікрасекунду кожная, не чапаючы 20 працоўных месцаў. У маёй гісторыі прычына і спадарожнік стаялі наадварот: абвал зрабіла сустрэча таймаўта з чаргой. Шторм паўтораў ехаў зверху і той лік, які важны, не пагоршыў.
Хачу быць акуратным наконт таго, як далёка гэта нясе. Адмова тут таннная, адзін сістэмны выклік і 503, а за ім абмежаваная чарга. У сэрвісе, дзе шлях перапаўнення каштуе сапраўднай працы, злучэння з базай або патоку, той жа патройны трафік ідзе проста ў тое месца, якое і так вузкае. Там я чакаю, што знак перавернецца. Гэтую версію доследу я не прагнаў.
Лік, які я ледзь не прапусціў
Сервер увесь гэты час выглядаў здаровым. Запыты завяршаліся, тэмп завяршэнняў трымаўся ля столі, затрымка ўнутры сэрвісу не мянялася ўвогуле, бо адзінка працы па-ранейшаму займала свае 20 мілісекунд. Праблему я ўбачыў толькі пасля таго, як завёў лічыльнік адказаў, запісаных кліенту, які ўжо адваліўся. Пакуль гэтага лічыльніка не было, графік з боку сэрвісу паказваў 920 у секунду, а графік з боку кліента 65. Абодва былі слушныя.
Чаго я не правяраў
Разнос паўтораў па часе, а гэта відавочнае наступнае плячо: тут паўторы б’юць імгненна, а разносіць іх і ёсць тая парада, якую дае фальклор. Бюджэт паўтораў, які абмяжоўвае спробы доляй ад трафіку, а не лікам на запыт. Закрытую нагрузку, дзе карыстальнікі чакаюць, а не падсыпаюць: адно гэта прыбірае амаль усё ўзмацненне. І сапраўдную сетку паміж дзвюма бакамі, са сваёй чаргой, якую я не мадэляваў ніяк.
Вузкае сцвярджэнне пра тое, за якую ручку хапацца. Калі чарга перад сэрвісам змяшчае больш працы, чым кліент згодны чакаць, сэрвіс правядзе аварыю, дарабляючы запыты для тых, хто сышоў, і будзе рабіць гэта незалежна ад таго, паўтарае хто небудзь ці не.