Как използването на нашата онлайн опашка предотвратява срив на сайта и сривове на уебсайтове - с колко едновременни потребители може да се справи един уеб сървър?

Защо да използвате виртуална чакалня, базирана на тарифи?

На базата на тарифите или на принципа "един път навън, един път навътре"? Преценяваме предимствата и недостатъците.

Всъщност не успяхме да открием никакви плюсове на "one-out" и "one-in". Накратко, проблемът с този подход е, че когато потребителите са посетители на уебсайтове за електронна търговия, уебсървърът не знае колко едновременни потребители има във всеки един момент от време. Това е проблем. Ето защо.

По-нататък в тази статия ще ви разкажем и как да използвате виртуална стая, базирана на тарифите, за да защитите и своя сайт.



Най-високо оценената виртуална чакалня в G2

Какво казват нашите клиенти за Queue-Fair


тестване на натоварването http заявки колко заявки може да обработи уеб сървърът без допълнителни ресурси на сървъра

С колко едновременни потребители може да работи един уеб сървър?

Ако знаете колко едновременни потребители обработва уеб сървърът и средното време на транзакцията или продължителността на посещението от първата страница в потока на транзакцията до страницата за потвърждение на поръчката, можете да превърнете това в скорост на опашката, като използвате закона на Литъл, като разделите броя на потребителите на продължителността, както следва:

Скорост на опашката = броя на едновременно работещите потребители / времето на транзакцията

Колко точна е системата за опашки, базирана на скоростта?

Queue-Fair ще доставя посетители на уебсайта ви с определената от вас скорост - разполагаме с най-точния изкуствен интелект на опашката в бизнеса, за да гарантираме, че броят на посетителите, които искате всяка минута, е броят на посетителите, които получавате всяка минута, като автоматично отчитаме хората, които не присъстват, когато им се обадят, както и хората, които се връщат късно.

Как това се отразява на броя на едновременните потребители? Разбира се, не всеки посетител, който стигне до сайта ви, ще се нуждае от точно толкова време, колкото е средното време за извършване на транзакцията, но с Queue-Fair ще получите много постоянен брой едновременни потребители поради закона за големите числа.

Например, да кажем, че имате скорост на опашката от 100 посетители в минута. Ние ще изпращаме по 100 посетители на сайта ви всяка минута в постоянен поток - това е, което правим, и сме зашеметяващо добри в него. Да кажем също, че хората използват вашия уебсайт средно (средно) пет минути, като 70% от тях отделят между 4 и 6 минути от момента, в който преминат през опашката, до момента, в който направят последната си заявка за страница (независимо дали извършват транзакция или не). Това е стандартно отклонение от по една минута от средната стойност. Статистически погледнато, това означава, че за всеки посетител, на когото му отнема пет минути и половина, ще има друг, на когото му отнема четири минути и половина, и следователно тези разлики в продължителността на отделните посещения в рамките на няколко сесии имат тенденция да се неутрализират взаимно, когато по някакъв начин отчитате много от тях. Законът за големите числа гласи, че това анулиране става все по-точно, колкото по-голям е броят на участващите хора.

операционна система максимален брой ресурси на уеб сървъра
изчисление на средната стойност за едновременни потребители с доверителен интервал

Колко точно? Можем да разберем това с помощта на малко статистика. Размерът на извадката е 5 * 100 = 500, което е голямото число в случая. Това е броят на хората, които броите. Това означава, че стандартната грешка в средната стойност за времето на транзакцията е 1 (стандартното отклонение, 1 минута), разделена на квадратния корен от размера на извадката (така че квадратният корен от 500) според статистическата формула за стандартна грешка в средната стойност, което дава стандартна грешка в средната стойност за времето на транзакцията от 0,044 минути или само 2,7 секунди, което е по-малко от един процент.

Това означава, че при скорост на опашката от 100 и време за транзакция от 5 минути плюс минута за всеки отделен посетител трябва да очаквате между 495 и 505 едновременни потребители на сайта си през около 70% от времето, така че математиката показва, че използването на опашка, базирана на скоростта, ще осигури много стабилно натоварване на уеб сървърите ви, както е желателно.

Но дали математиката е точна? Тук има някои тънкости - например размерът на извадката, който весело разчитаме на квадрат, не винаги е точно 500 всеки път, когато се броят едновременните потребители (т.е. във всеки един момент от време), а също така нормалното (Гаусово) разпределение може да даде отрицателни времена на транзакциите, които не се случват в реалния живот. Затова използваме симулатор за измерване на посетител по посетител, секунда по секунда, за да проверим тези видове изчисления, и той ни казва, че с горните цифри трябва да очаквате между 493 и 507 посетители в 70% от случаите, така че математиката се държи забележително добре! Измерването на данните също така ни казва, че сайтът ви ще има 500 ± 15 едновременни потребители поне в 95% от времето.

Това вероятно е по-стабилно от точността, с която вашият уеб сървър може да измери броя на хората, използващи сайта ви! Още по-хубавото е, че дори и да нямате представа какво е средното време за транзакция или стандартното отклонение за посетителите ви, тези математически величини съществуват, независимо дали ги знаете, или не, и вие така или иначе ще получите стабилно натоварване.

Резултатът е, че Queue-Fair ще осигури желания от вас брой посетители в минута с почти пълна точност, което ще доведе до много стабилен брой едновременни потребители на вашия сайт и стабилно натоварване на уеб сървъра, върху което имате пълен контрол.

Ура!


servers capacity can be exceeced with inaccurate queues А сега едно предупреждение. Струва си да се отбележи, че стабилността на броя на едновременните потребители на вашия сайт - и следователно стабилността на натоварването на вашия сървър - зависи в голяма степен от това колко точно вашият доставчик на виртуална чакалня ви изпраща броя на посетителите, които искате всяка минута, и следователно това е ключов фактор при избора на платформа за виртуална чакалня. Тъй като ние предоставяме най-точната Виртуална чакалня в света, никой не спира наводняването на вашите сървъри по-добре от Queue-Fair.

Лесен начин за изчисляване на скоростта на опашката

Какво да правите, ако не знаете колко едновременни потребители може да обслужва сървърът или колко е времето за транзакция? Можете да погледнете страницата, която вероятно ще бъде тясното ви място - обикновено тази, която е резултат от натискане на бутона "Купи сега". Използвайте Google Analytics, за да откриете месечните уникални посетители на тази страница, или пребройте месечните си поръчки. Разделете това на 30 * 24 * 60 = 43 200, което е броят на минутите за един месец (приблизително). Това са вашите средни посетители на минута за целия месец. Умножете това по три. Това са вашите средни посетители в минута през работното време (приблизително). Удвоете това. Това вероятно е сигурна стойност за използване на показателя "Скорост на опашката".

Например, да кажем, че обработвате 100 000 поръчки на месец - това са 100 000 кликвания върху бутона "Купи сега". Това е 100 000 / 43 200 = 2,31 поръчки в минута. Бихте очаквали повечето от тези поръчки да са през деня, а сървърите ви да са по-тихи през нощта, така че умножете това по 3 и ще получите 7 поръчки в минута като приблизителна оценка на това колко натоварен е сървърът ви през работното време. Ако получената цифра е по-малка от 50: ще има пикове и спадове в търсенето, така че ако сървърът ви не е забележимо бавен в пиковите часове, умножете това по 2, за да получите 14 активни потребители в минута. Ако цифрата е повече от 50: пиковете и спадовете от минута на минута ще бъдат по-малки в сравнение с тях и не е безопасно да удвоявате тази стойност. Числото, което в крайна сметка получавате, вероятно е безопасна цифра за Queue Rate (Скорост на опашката) за начало и съответства на това колко заявки в секунда можете безопасно да управлявате; винаги можете да го увеличите, ако установите, че системите ви все още реагират на работата на крайните потребители при тази скорост.

изчисляване на максималните нива на активни потребители за вашето уеб приложение

Ако поръчките ви са маркирани с времеви отпечатък, можете също така да разгледате максималния брой поръчки, които сте направили за една минута през последния месец - но използвайте внимателно, тъй като няма да знаете колко поръчки може да са отпаднали през тази минута поради забавяне на сървърите ви, затова намалете тази стойност с 20%.

В останалата част на тази статия са разгледани някои други начини за определяне на скоростта на опашката.

объркване по отношение на едновременните потребители едновременните връзки едновременните сесии и средната продължителност на сесията

Имам предвид #1: Едновременни потребители vs Едновременни заявки vs Едновременни връзки vs Едновременни сесии

Струва си да се отбележи, че в общоприетата употреба има поне две определения за "едновременни потребители".

Използваме определението " брой на хората, участващи в даден транзакционен поток във всеки един момент". Това е основното число, което трябва да знаете, за да зададете коефициента на опашката. Това е броят на потребителите, които разглеждат сайта ви в момента. Броят на едновременните сесии обикновено е малко по-голям от броя на едновременните връзки или едновременните потребители, тъй като някои от сесиите са в процес на изчерпване на времето, което увеличава средната продължителност на сесията.

Това е сравнение с броя на едновременните заявки, който представлява броят на HTTP заявките, обработвани от уеб сървъра във всеки един момент. Много объркващо е, че много техници имат предвид колко едновременни заявки, когато казват колко едновременни потребители.

След това има "Съпътстващи връзки" (или "Съпътстващи TCP връзки към един и същ порт на сървъра на вашата мрежова карта"), което е броят на TCP/IP сокетите, отворени на порта на вашия сървър или бекенд услуга във всеки един момент. Когато правят заявки за страници, браузърите по подразбиране оставят връзката отворена, в случай че страницата направи допълнителни заявки или потребителят отиде на друга страница. Това намалява броя на заявките в секунда за отваряне на нови TCP/IP връзки, което прави процеса на работа на сървъра по-ефективен. Времевите ограничения за тези едновременни връзки варират в зависимост от браузъра - от 60 секунди до никога не затваряне. Вашият сървър също може автоматично да затваря връзки след период на липса на активност. При уеб сървърите на Linux можете да получите информация за броя на едновременните връзки към един и същ порт на сървъра с тази команда:

netstat -aenp | grep ":80 \|:443 " | wc -l

което можете да опитате, ако сте любопитни. Отново, някои хора наричат това и "едновременни потребители", докато всъщност означава едновременни връзки.

Ако поискате от доставчика на хостинг услуги да ви каже максималния брой едновременни потребители, с които работи вашият уеб сървър (колко е пиковият трафик), той вероятно ще ви даде цифра за едновременни сесии, едновременни заявки или едновременни връзки по простата причина, че не знае средното време на транзакцията, броя на страниците в потока на транзакцията или друга информация, която би му позволила да каже колко едновременни потребители работи вашият уеб сървър. Всички тези числа имат различни стойности.

Ако поискате от вашия доставчик на хостинг услуги или технически екип информация за максималните нива на трафика, изключително важно е да уточните дали се има предвид "едновременни потребители", "едновременни сесии", "едновременни заявки" или "едновременни връзки".

Ако сбъркате, това може да доведе до срив на уебсайта ви!

Ето защо. Всяка страница е отделна HTTP заявка, но всички изображения, скриптове и други файлове, които идват от вашето уеб приложение и които браузърът използва, за да покаже страницата, също са HTTP заявки.

Да си представим, че техническият екип ви е казал, че сървърът поддържа 500 едновременни потребители, но всъщност е имал предвид 500 едновременни заявки. С вашето 5-минутно време за транзакция, вие използвате горната формула и приемате, че сайтът ви може да поддържа 100 посетители в минута.

Може ли? Не.

Докато хората преминават през потока на транзакциите, те всъщност правят заявки към вашите сървъри само докато всяка страница се зарежда. Това се отразява на това колко трафик в секунда или активни потребители може да обработи вашият сървър. От петте минути време за транзакция това са само няколко секунди за средния потребител. Следователно може да си помислите, че 500 едновременни заявки означава, че можете да обработвате много повече едновременни потребители, но може и да грешите. Виждате ли сега как разбирането на капацитета на вашия уебсайт по отношение на това колко е трафикът или общият брой активни потребители е толкова сложна работа?

първо се погрижете за ресурсите на сървъра си, когато преценявате колко заявки могат да получат вашите уеб страници, за да осигурите добро преживяване за всеки потребител.

Преобразуване на едновременни заявки в едновременни потребители

За да изчислите максималния брой едновременни потребители от максималния общ брой едновременни заявки, трябва също така да знаете

  1. Броят на страниците в потока на транзакциите
  2. Средното време за транзакция на посетителя от първата до последната страница на вашия поток
  3. Колко заявки средно съставляват всяка страница
  4. Средното време, което сървърът ви отделя за обработка на една HTTP заявка

Вероятно вече знаете 1) и 2) - в нашия пример това са 6 страници и 5 минути. Можете лесно да преброите страниците, които виждате, докато извършвате транзакция. Ако не знаете средното време на транзакцията, Google Analytics може да ви го каже или можете да проверите дневниците на уеб сървъра си.

За 3) и 4) може да помогне браузърът Firefox. Щракнете с десния бутон на мишката върху страница на сайта си, изберете Inspect Element (Проверка на елемента) и раздела Network (Мрежа). След това натиснете CTRL-SHIFT-R, за да опресните напълно страницата. Ще видите времето за зареждане на мрежата за всеки елемент на страницата в списъка. Искате да се уверите, че можете да видите размерите на прехвърляне в колоната Transferred (Прехвърлено), тъй като в противен случай файловете може да се обслужват от кеш, което може да обърка изчисленията ви. Възможно е да видите, че някои скриптове и други ресурси идват от сървъри, различни от вашия сайт, затова можете да въведете името на домейна на сайта си в полето за филтриране вляво. За да видите колоната "Продължителност", щракнете с десния бутон на мишката върху заглавието на която и да е колона и изберете Timings -> Duration (Времетраене -> Продължителност) от изскачащото меню. Екранът ви трябва да изглежда по следния начин:

Google обработва правилно конфигуриран nginx с Google Analytics за качване на снимки

Мрежовият раздел на Firefox за тази страница, показващ продължителността и броя на заявките от queue-fair.com

Файловете, използвани при показването на страниците ви, могат да идват от различни сайтове, така че е добре да използвате филтъра в горния ляв ъгъл, за да показвате само тези от вашия сайт, но само ако сте сигурни, че тези файлове от други сайтове не са причина за бавното зареждане на страниците или част от пречките.

Firefox преброява заявките в долния ляв ъгъл на дисплея и показва 36 HTTP заявки само за тази една страница.

Трябва да направите това за всяка страница от потока на транзакциите - пребройте общия брой и го разделете на броя на страниците, за да откриете средния брой HTTP заявки за всяка страница, номер 3) в нашия списък. Сега можете да видите защо броят на детските заявки за всяка HTML страница е толкова ключов фактор за това с какъв трафик може да се справи вашият уеб сървър.

За номер 4) трябва да разгледате колоната "Продължителност" и да намерите средната стойност за всички HTTP заявки за всички ваши страници. Ако не сте сигурни, приемете, че е половин секунда - така или иначе има много несигурност в това отношение (вж. по-долу).

извършване на математически изчисления за определяне на броя на сесиите по едно и също време, броя на потребителите и броя на заявките в секунда за вашето уеб приложение, независимо дали е с един сървър или със статично съдържание.

Изчисляване на математиката

Нека дадем няколко примерни числа. Вече казахме, че в процесния поток на примерния сървър има шест динамични страници, което е 1), и че средното време на транзакцията е пет минути, което е 2). Нека приемем 36 HTTP заявки на страница за 3) и половин секунда за времето за обработка на сървъра за всяка HTTP заявка, което е 4).

С тези цифри сървър, който може да обработва 500 едновременни заявки, може да обработва 500 / (0,5 секунди) = 1000 HTTP заявки в секунда, което е 60 000 HTTP заявки в минута, когато е напълно натоварен.

За петминутното време на транзакцията тя може да обработи 5 * 60 000 = 300 000 HTTP заявки. Изглежда много, нали?

Но за всеки посетител има шест страници със средно 36 HTTP заявки всяка, така че това са 6 * 36 = 216 заявки.

Така че капацитетът от 300 000 HTTP заявки теоретично може да обслужва 300 000 / 216 = 1 389 едновременни потребители.

Имам предвид #2: Уеб сървърите стават по-бавни при натоварване

Ей, това е страхотно! Мислехме, че можем да имаме само 100 посетители на опашка, но 1 389 / 5 минути = 278 посетители в минута, така че можем да имаме по-висока скорост на опашката!

Е, вероятно не. От една страна, посетителите ви няма да изпращат заявки на интервали от точно половин секунда, както се предполага в горното изчисление. По-важното е, че ще измервате входните си данни, когато сайтът не е натоварен. Влизане на боклук, излизане на боклук.

Когато сайтът е натоварен, сървърът обработва заявките по-дълго - сигурно сте забелязали това в други сайтове, когато работата е натоварена, че чакате по-дълго за страници. Това увеличава средното време, което сървърът ви отделя за обработка на една HTTP заявка (4), което намалява максималната производителност. Затова вземете 278 посетители в минута и ги намалете наполовина. След това го намалете отново наполовина. Вероятно реално ще имате около 70 нови посетители в минута при максимално натоварване.

колкото по-тежко е натоварването от трафика, толкова по-бавни стават машините

Други смущаващи фактори са кеширането, което означава, че браузърите на посетителите може да не трябва да правят всяка отделна заявка за всяка отделна страница - това обикновено означава, че сървърът се нуждае от по-малко ресурси и може да увеличи броя на новите посетители в минута, с които сървърът може да се справи. Балансиращите устройства за натоварване, които разпределят натоварването между няколко сървъра, и обслужването на статично съдържание, а не на динамични страници, също могат да ускорят процеса на вашия сървър, тъй като всеки сървър се нуждае от по-малко ресурси.

Освен това ще откриете, че не всички страници отнемат едно и също време, тъй като за създаването и обслужването на някои от тях са необходими по-малко ресурси, отколкото за други. Търсенето в базата данни, заявките за търсене и актуализациите отнемат най-много време, така че някъде в процеса ви ще има тясно място, където хората се трупат, чакайки да бъдат обработени данните на кредитните карти и да бъдат съхранени поръчките или чакайки да бъде проверена наличността. Всеки транзакционен поток има най-бавната стъпка, така че винаги някъде има тясно място и винаги има отговор на въпроса с колко едновременни потребители може да се справи уеб сървърът - и може да има няколко ограничения. В този случай искате да зададете достатъчно ниска скорост на опашката, за да гарантирате, че сървърът ви има капацитет за процесорно време, за да обработи достатъчно хора едновременно за най-бавната стъпка в процеса, така че хората да не се натрупват там. В противен случай уеб сървърът ви може буквално да спре.

несигурно как да се оцени капацитетът на сървърите за всеки отделен потребител

И какво да направя?

Опитът ни показва, че при първата си продажба всички надценяват способността на сървърите си да се справят с големи обеми трафик.

Всички.

Точното определяне на средната продължителност на сесията и производителността на крайния потребител по време на бавен или пиков трафик не е за хора със слаби сърца. Най-доброто нещо, което можете да направите, е да проведете подходящ тест за натоварване, като "фалшивите" клиенти действително преминават през процеса на поръчка по време на теста за натоварване, точно както биха го направили в реалния живот, като правят същите HTTP заявки в същия ред, със същото изчакване между страниците при теста за натоварване, както виждате в реалния живот, и да следите натоварването на процесора, пропускателната способност на IO и времето за отговор, докато увеличавате броя на виртуалните посетители. За целта можете да използвате Apache JMeter (ние харесваме и K6 за по-леки натоварвания или по-бавни машини), но какъвто и инструмент да използвате, имитирането на поведението на всеки отделен потребител по точно определен начин отнема време и е трудно (особено при сложността на кеширането). Дори тогава вземете максималния брой и го намалете наполовина.

При липса на такива данни, предпочитайте да бъдете предпазливи.

Можете лесно да промените скоростта на опашката за всяка опашка на Queue-Fair по всяко време, като използвате портала Queue-Fair. Започнете с 10 посетители в минута или с вашата скорост на транзакциите в по-нормален ден, вижте как ще се развие това за малко след пускането на билетите в продажба и ако всичко изглежда добре, натоварването на процесора ви е ниско, базата данни sql е наред и (преди всичко) страниците ви реагират бързо, когато натиснете CTRL-SHIFT-R, удвоете го, изчакайте малко и повторете. Скоро ще откриете действителната скорост, от която се нуждаете по време на това "балансиране на натоварването" (виждате ли какво направихме?), и не забравяйте, че от гледна точка на клиентското преживяване е добре да увеличите скоростта на опашката, тъй като това води до намаляване на очакваното чакане, което клиентите ви на опашката виждат, и всички са доволни да видят време за отговор, което осигурява по-кратко очаквано чакане.

Това, което искате да избегнете, е да зададете твърде висока скорост на опашката, след което да се наложи да я намалите, тъй като това: а) означава, че хората, които използват сайта, се зареждат бавно и б) води до увеличаване на очакваните чакания. Всички хора в опашката ви ще въздъхнат!

Имам предвид #3: Увеличаване на скоростта твърде бързо след отваряне на опашка

Не забравяйте, че някъде в процеса на поръчка ще има тясно място - всяка транзакция има най-бавна стъпка - и там ще се натрупват множество сесии. Това, което не искате да направите, е да стигнете до минута от продажбата на билети, да видите, че натоварването на процесора на сървъра ви е много под максималното число, и да повишите скоростта. Посетителите ви вероятно не са стигнали до бутона "Купи сега". Искате да изчакате, докато sql базата ви данни отчете нови поръчки със същата или подобна скорост като тази на опашката ви, и тогава да направите измерванията и тестовете за отзивчивост. Не забравяйте, че всеки път, когато увеличавате скоростта, на допълнителните посетители ще им отнеме същото време да достигнат до тясното място, така че няма да можете да оцените точно как работи сървърът ви при новата скорост, докато не изтече това време.

забавяне на решението за използване на ресурсите на сървъра.
щракване на сървърите при превишаване на капацитета на сървърите

Имам предвид #4: Снимане на вашите сървъри

Вече обсъдихме как е най-добре да увеличавате скоростта на опашката постепенно, след като опашката ви е отворена. Вероятно сте наясно, че сървърите ви имат лимит, който не може да бъде надхвърлен, без системата да се срине, и може би дори знаете какъв е този лимит - но това, което може би не знаете, е, че когато натоварването наближава този лимит, обикновено има много малко признаци - често само няколко грешки или предупреждения, или натоварване на процесора над 80%.

Когато уеб услугите се провалят, те са склонни да се "счупят" или да спрат да функционират много бързо. Обикновено това се дължи на факта, че след като системата ви вече не може да обработва заявките толкова бързо, колкото те постъпват, се натрупват вътрешни опашки за обработка. След това системата ви трябва да се справи с обработката, управлението и съхранението на вътрешните опашки, както и със заявките, и това е, което преобръща сървърите. Много бързо. След като това се случи, сървърите ви може за известно време да могат да отговорят със страница за грешка, но това не ви помага, защото посетителите, които я видят, веднага ще натиснат Refresh (Обновяване), увеличавайки натоварването.

Затова не натоварвайте сървърите си повече, отколкото е необходимо. Обикновено не си заслужава да рискувате, ако се стремите към последните 20% от капацитета на процесора. Ако размерът на опашката, показан в портала Queue-Fair (жълтата фигура и линия на чакащите в диаграмите), намалява или дори просто се увеличава по-бавно, минута след минута, а показаното време за чакане е 50 минути или по-малко, тогава обработвате поръчките достатъчно бързо и опашката в крайна сметка ще се изпразни и ще спре да показва Страници на опашката автоматично, без да се налага да правите нищо и без да се налага да казвате на шефа си, че сте го натискали твърде много и сте го повредили. В крайна сметка ще стигнете дотам, стига скоростта на фронта на опашката да е по-висока от броя на присъединяванията всяка минута (и двете се показват в портала Queue-Fair) - повратната точка обикновено е поне няколко минути след всяко събитие. Ако продавате продукт с ограничено количество, вероятно ще го продадете, преди да бъде достигната повратната точка.

Добрата новина е, че ако случайно зададете твърде висока скорост на опашката и сървърите ви се сринат, Queue-Fair може да ви помогне да се възстановите бързо - просто поставете опашката в режим на изчакване, докато сървърите ви отново са готови да приемат посетители. В режим на задържане хората в опашката виждат специална страница за задържане, която можете да създадете преди онлайн събитието си. Когато опашката е в режим "Задържане", никой не се пропуска от предната ѝ част, но нови интернет посетители все още могат да се присъединят към опашката отзад, за да бъдат подредени справедливо, след като блокирането бъде отстранено, което ще стане много бързо, защото Queue-Fair защитава сайта ви от търсенето. Страницата за задържане е по-добро потребителско изживяване от задаването на много нисък процент на опашката, особено ако я актуализирате, за да съобщите на посетителите в колко часа очаквате опашката да се отвори отново, което е лесно да се направи с редактора на страницата на портала, дори когато стотици хиляди хора вече са на опашката - а в режим на задържане можете дори да ги пускате един по един с уникалния бутон на Queue-Fair Admit One (Допускане на един), ако се налага, докато системата ви се възстанови от срива.

Така че, ако се наложи сървърите ви да прекъснат работа по време на събитието, страницата "Задържане" е точно това, от което се нуждаете, а освен това ще помогне на сървърите ви да се възстановят по-бързо.

Заключение

В тази статия обяснихме защо опашката, базирана на скоростта, винаги е най-добрият начин и дадохме два метода за изчисляване на необходимата скорост, но освен ако не сте направили пълно и точно виртуално тестване на натоварването на посетителите за целия поток от транзакции и не сте наистина супер много сигурни в това, нашият съвет винаги е един и същ:

  1. Започнете със скорост на опашката, зададена на 10, или с вашата скорост на транзакциите в по-обикновен ден.
  2. Наблюдавайте натоварването на процесора и други показатели за производителност.
  3. Изчакайте, докато новите поръчки се записват в базата данни sql със същата или подобна скорост като тази на опашката.
  4. Натиснете CTRL-SHIFT-R на страниците си, за да проверите отзивчивостта.
  5. Увеличете скоростта на опашката с не повече от 20%.
  6. Върнете се към стъпка 2 и изчакайте отново.
  7. След като размерът на опашката намалее или се увеличава постоянно с по-малко темпове всяка минута, а показаното време за изчакване е по-малко от 50 минути, не е необходимо да се ускорява.
  8. Седнете удобно и се отпуснете! Queue-Fair се погрижи за вас.

Ако продавате продукт в ограничено количество, не е необходимо да обръщате внимание и на стъпка 7.

Това се отнася за първата опашка, когато не знаете действителната максимална скорост на опашката, която системата ви може да поддържа. За следващите опашки, след като сте измерили скоростта на опашката, с която системата ви действително може да се справи, може би ще можете да използвате отново същата стойност - но само ако нищо не се е променило в системата ви. На практика системата ви вероятно е в процес на постоянно развитие и модификация и може да не знаете как последните промени са повлияли на максималната скорост на опашките - така че защо да не започнете от половината от предишната измерена стойност и да повторите горния процес?

Не забравяйте, че винаги е по-добре да се предпазите, отколкото да съжалявате.


Стотици водещи организации се доверяват на нашите
решения за опашки

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

Простото решение на проблема с нарастването на интернет трафика

Започнете