Всъщност не успяхме да открием никакви плюсове на "one-out" и "one-in". Накратко, проблемът с този подход е, че когато потребителите са посетители на уебсайтове за електронна търговия, уебсървърът не знае колко едновременни потребители има във всеки един момент от време. Това е проблем. Ето защо.
По-нататък в тази статия ще ви разкажем и как да използвате виртуална стая, базирана на тарифите, за да защитите и своя сайт.
Традиционно сървърите за електронна търговия се настройват така, че да поддържат максимален брой едновременни потребители, и натоварването често се определя по този начин. Съществува проблем при използването на този подход за управление на опашка за уебсайт - проблем, който решаваме с тарифите.
Проблемът възниква, защото посетителите използват уеб сървъра само докато браузърът им зарежда всяка уеб страница.
Например, да кажем, че сайт за електронна търговия продава билети. От началото на пътуването на посетителя до края на пътуването на посетителя (потребителската сесия) има шест страници, тъй като посетителят
Целият процес на транзакция отнема средно пет минути.
Да предположим, че всяка минута пристигат 100 посетители, за да купят билети, а средното време за завършване на процеса е пет минути. Във всеки един момент от време в процеса на транзакция участват едновременно 500 души и сървърът трябва да бъде осигурен за поддръжка на 500 едновременни потребители.
Човек би могъл да си помисли, че може да създаде брояч на текущите потребители, който се увеличава всеки път, когато нов посетител пристигне на началната страница, и се намалява всеки път, когато посетител завърши транзакцията, и че това ще ви покаже колко потребители обработва един сървър във всеки един момент, но това няма да работи.
Това няма да се получи, защото не всеки посетител завършва транзакцията. Хората променят мнението си, разсейват се или си тръгват и се връщат по-късно. Тъй като уебсървърът взаимодейства с посетителите само когато браузърите им зареждат страници, уебсървърът няма как да знае кога се е случило това и на кого.
Вместо това, за да определи, че даден посетител вече не е част от процеса на транзакция, единичният сървър трябва да изчака да види дали няма повече заявки за страници от този посетител и след това да прекрати сесията на посетителя. Времевата пауза винаги трябва да бъде зададена на стойност, която е много по-дълга от средното време на транзакцията (например 20 минути в този пример), тъй като на някои посетители им отнема много повече време, отколкото на други, за да завършат своята транзакция.
Би могло да се добави възможност за намаляване на условния брояч на текущите потребители всеки път, когато сесията на посетителя приключи по този начин, но това дава много лоши резултати.
Ако 10 % от 100-те посетители, които пристигат всяка минута, не завършат своята транзакция, тези, които завършат, ще бъдат активни средно пет минути, а тези, които не завършат, ще се считат за активни поне 20 минути винаги (всъщност времетраенето на сесията плюс средната продължителност на сесията е по-вероятно, когато се разглеждат множество сесии).
Това е 90 * 5 + 10 * 20 = 650 и сървърът ще отчете 650 едновременни потребители, въпреки че всъщност е по-малко натоварен!
Освен това до 10 * 20 = 200 от тези едновременни потребители всъщност не използват сайта и са в процес на прекратяване, което е над 30 % от отчетените едновременни потребители, въпреки че само 10 % от посетителите не успяват да завършат транзакцията.
Сега нека кажем, че някой желае да добави опашка към този уебсайт, контролирана от нашия брояч на едновременно работещи потребители. След като сайтът достигне капацитета си, лицето, което е в началото на опашката, ще бъде допуснато до сайта само след като броячът намалее. Това се нарича "опашка с едно излизане и едно влизане". Това, което ще се случи, е, че в 30 % от времето лицето в началото на опашката ще чака някой, който няма да завърши транзакцията си, да завърши, без да завърши транзакцията си.
Освен това е необходима допълнителна техническа интеграция и натоварване на уебсайта, свързано със създаването и функционирането на брояча, както и със споделянето на тази информация със системата за опашки. Ако механизмът за споделяне или преброяване се повреди или се счупи, опашката закъсва. Още по-лошо, ако единичният сървър е толкова натоварен, че не може да актуализира сървъра на опашката, за да каже на сървъра на опашката да пусне следващия човек, опашката също се задъхва.
Всички тези проблеми се решават лесно и просто, като вместо това посетителите се изпращат от началото на опашката с постоянна, фиксирана скорост - в този случай 100 посетители в минута.
По този начин не е необходимо да се измерва действителният брой на едновременно работещите потребители, не е необходима сложна интеграция с уебсайта за продажба на билети и няма риск опашката да се задръсти.
Ето защо през 2004 г. изобретихме и патентовахме виртуалната чакалня за натоварени уебсайтове, базирана на тарифите.
Невероятен и лесен продукт! Queue-Fair е наистина красив. Толкова е лесно да се задават параметрите в реално време, а също така е толкова лесно да се интегрира. Поддръжката е реактивна и приятелска. Настроих виртуална чакалня за 15 минути, включително настройките! Така че защитавам инфраструктурата си от всички тези пикове на трафика с Queue-Fair.
Вашият софтуер означаваше, че всички се задържат на опашка далеч от нашия сървър и позволяваше плавен поток от купувачи да преминава през системата. Беше страхотно! Всеки онлайн магазин, в който има наплив от клиенти, би намерил това за наистина полезно. Благодарим ви милион пъти и продължавайте да работите добре!
Блестящо! Ние сме много щастливи и удовлетворени от Queue-Fair, прекрасно е да имаме такова ниво на подкрепа. Услугата работи перфектно - продадохме хиляди билети за нула време, а Queue-Fair ни помогна да управляваме трафика по време на високите пикове! Препоръчваме Queue-Fair и на нашите партньори в сферата на услугите. Наистинасъм доволен!
Хората от Queue-Fair излязоха отвъд и ни помогнаха да внедрим тяхната система за опашки в рамките на един ден. При над 25 000 души на опашката те ни помогнаха да управляваме трафика по време на високите пикове. Queue-Fair прави това, за което е създадена - подрежда хора в опашки на конкурентна цена. Доволни сме от системата Queue-Fair и ще продължим да я използваме по време на бъдещи събития.
Queue-Fair беше точно това, от което се нуждаехме, за да управляваме трафика и услугата за поддръжка е страхотна!. Системата работи много добре! Потърсихме няколко компании и без съмнение намерихме най-добрата! Благодаря ви много, Queue-Fair!
Голямо благодаря ви за това, че толкова бързо обърнахте нашето запитване. Изпратихме имейл в 21:00 ч. в сряда, а в 11:00 ч. в четвъртък получихме напълно брандирана страница за опашка, готова за използване. Просто брилянтно! Таблото за управление и функциите са страхотни - наистина интуитивни, наистина изчистени и лесни за използване. Наредихме над 22 000 души на опашка за нашето събитие за пускане на продукта на цена, която беше изключително конкурентна. Благодаря много за всичко! Наистина съм щастлив да дам на Queue-Fair блестящ отзив и бих ги препоръчал на всеки бизнес, който се нуждае от система за опашки за своето събитие или промоция.
Ако знаете колко едновременни потребители обработва уеб сървърът и средното време на транзакцията или продължителността на посещението от първата страница в потока на транзакцията до страницата за потвърждение на поръчката, можете да превърнете това в скорост на опашката, като използвате закона на Литъл, като разделите броя на потребителите на продължителността, както следва:
Скорост на опашката = броя на едновременно работещите потребители / времето на транзакцията
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 ще осигури желания от вас брой посетители в минута с почти пълна точност, което ще доведе до много стабилен брой едновременни потребители на вашия сайт и стабилно натоварване на уеб сървъра, върху което имате пълен контрол.
Ура!
А сега едно предупреждение. Струва си да се отбележи, че стабилността на броя на едновременните потребители на вашия сайт - и следователно стабилността на натоварването на вашия сървър - зависи в голяма степен от това колко точно вашият доставчик на виртуална чакалня ви изпраща броя на посетителите, които искате всяка минута, и следователно това е ключов фактор при избора на платформа за виртуална чакалня. Тъй като ние предоставяме най-точната Виртуална чакалня в света, никой не спира наводняването на вашите сървъри по-добре от 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%.
В останалата част на тази статия са разгледани някои други начини за определяне на скоростта на опашката.
Струва си да се отбележи, че в общоприетата употреба има поне две определения за "едновременни потребители".
Използваме определението " брой на хората, участващи в даден транзакционен поток във всеки един момент". Това е основното число, което трябва да знаете, за да зададете коефициента на опашката. Това е броят на потребителите, които разглеждат сайта ви в момента. Броят на едновременните сесии обикновено е малко по-голям от броя на едновременните връзки или едновременните потребители, тъй като някои от сесиите са в процес на изчерпване на времето, което увеличава средната продължителност на сесията.
Това е сравнение с броя на едновременните заявки, който представлява броят на HTTP заявките, обработвани от уеб сървъра във всеки един момент. Много объркващо е, че много техници имат предвид колко едновременни заявки, когато казват колко едновременни потребители.
След това има "Съпътстващи връзки" (или "Съпътстващи TCP връзки към един и същ порт на сървъра на вашата мрежова карта"), което е броят на TCP/IP сокетите, отворени на порта на вашия сървър или бекенд услуга във всеки един момент. Когато правят заявки за страници, браузърите по подразбиране оставят връзката отворена, в случай че страницата направи допълнителни заявки или потребителят отиде на друга страница. Това намалява броя на заявките в секунда за отваряне на нови TCP/IP връзки, което прави процеса на работа на сървъра по-ефективен. Времевите ограничения за тези едновременни връзки варират в зависимост от браузъра - от 60 секунди до никога не затваряне. Вашият сървър също може автоматично да затваря връзки след период на липса на активност. При уеб сървърите на Linux можете да получите информация за броя на едновременните връзки към един и същ порт на сървъра с тази команда: netstat -aenp | grep ":80 \|:443 " | wc -l
което можете да опитате, ако сте любопитни. Отново, някои хора наричат това и "едновременни потребители", докато всъщност означава едновременни връзки.
Ако поискате от доставчика на хостинг услуги да ви каже максималния брой едновременни потребители, с които работи вашият уеб сървър (колко е пиковият трафик), той вероятно ще ви даде цифра за едновременни сесии, едновременни заявки или едновременни връзки по простата причина, че не знае средното време на транзакцията, броя на страниците в потока на транзакцията или друга информация, която би му позволила да каже колко едновременни потребители работи вашият уеб сървър. Всички тези числа имат различни стойности.
Ако поискате от вашия доставчик на хостинг услуги или технически екип информация за максималните нива на трафика, изключително важно е да уточните дали се има предвид "едновременни потребители", "едновременни сесии", "едновременни заявки" или "едновременни връзки".
Ето защо. Всяка страница е отделна HTTP заявка, но всички изображения, скриптове и други файлове, които идват от вашето уеб приложение и които браузърът използва, за да покаже страницата, също са HTTP заявки.
Да си представим, че техническият екип ви е казал, че сървърът поддържа 500 едновременни потребители, но всъщност е имал предвид 500 едновременни заявки. С вашето 5-минутно време за транзакция, вие използвате горната формула и приемате, че сайтът ви може да поддържа 100 посетители в минута.
Може ли? Не.
Докато хората преминават през потока на транзакциите, те всъщност правят заявки към вашите сървъри само докато всяка страница се зарежда. Това се отразява на това колко трафик в секунда или активни потребители може да обработи вашият сървър. От петте минути време за транзакция това са само няколко секунди за средния потребител. Следователно може да си помислите, че 500 едновременни заявки означава, че можете да обработвате много повече едновременни потребители, но може и да грешите. Виждате ли сега как разбирането на капацитета на вашия уебсайт по отношение на това колко е трафикът или общият брой активни потребители е толкова сложна работа?
За да изчислите максималния брой едновременни потребители от максималния общ брой едновременни заявки, трябва също така да знаете
Вероятно вече знаете 1) и 2) - в нашия пример това са 6 страници и 5 минути. Можете лесно да преброите страниците, които виждате, докато извършвате транзакция. Ако не знаете средното време на транзакцията, Google Analytics може да ви го каже или можете да проверите дневниците на уеб сървъра си.
За 3) и 4) може да помогне браузърът Firefox. Щракнете с десния бутон на мишката върху страница на сайта си, изберете Inspect Element (Проверка на елемента) и раздела Network (Мрежа). След това натиснете CTRL-SHIFT-R, за да опресните напълно страницата. Ще видите времето за зареждане на мрежата за всеки елемент на страницата в списъка. Искате да се уверите, че можете да видите размерите на прехвърляне в колоната Transferred (Прехвърлено), тъй като в противен случай файловете може да се обслужват от кеш, което може да обърка изчисленията ви. Възможно е да видите, че някои скриптове и други ресурси идват от сървъри, различни от вашия сайт, затова можете да въведете името на домейна на сайта си в полето за филтриране вляво. За да видите колоната "Продължителност", щракнете с десния бутон на мишката върху заглавието на която и да е колона и изберете Timings -> Duration (Времетраене -> Продължителност) от изскачащото меню. Екранът ви трябва да изглежда по следния начин:
Мрежовият раздел на 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 едновременни потребители.
Ей, това е страхотно! Мислехме, че можем да имаме само 100 посетители на опашка, но 1 389 / 5 минути = 278 посетители в минута, така че можем да имаме по-висока скорост на опашката!
Е, вероятно не. От една страна, посетителите ви няма да изпращат заявки на интервали от точно половин секунда, както се предполага в горното изчисление. По-важното е, че ще измервате входните си данни, когато сайтът не е натоварен. Влизане на боклук, излизане на боклук.
Когато сайтът е натоварен, сървърът обработва заявките по-дълго - сигурно сте забелязали това в други сайтове, когато работата е натоварена, че чакате по-дълго за страници. Това увеличава средното време, което сървърът ви отделя за обработка на една HTTP заявка (4), което намалява максималната производителност. Затова вземете 278 посетители в минута и ги намалете наполовина. След това го намалете отново наполовина. Вероятно реално ще имате около 70 нови посетители в минута при максимално натоварване.
Други смущаващи фактори са кеширането, което означава, че браузърите на посетителите може да не трябва да правят всяка отделна заявка за всяка отделна страница - това обикновено означава, че сървърът се нуждае от по-малко ресурси и може да увеличи броя на новите посетители в минута, с които сървърът може да се справи. Балансиращите устройства за натоварване, които разпределят натоварването между няколко сървъра, и обслужването на статично съдържание, а не на динамични страници, също могат да ускорят процеса на вашия сървър, тъй като всеки сървър се нуждае от по-малко ресурси.
Освен това ще откриете, че не всички страници отнемат едно и също време, тъй като за създаването и обслужването на някои от тях са необходими по-малко ресурси, отколкото за други. Търсенето в базата данни, заявките за търсене и актуализациите отнемат най-много време, така че някъде в процеса ви ще има тясно място, където хората се трупат, чакайки да бъдат обработени данните на кредитните карти и да бъдат съхранени поръчките или чакайки да бъде проверена наличността. Всеки транзакционен поток има най-бавната стъпка, така че винаги някъде има тясно място и винаги има отговор на въпроса с колко едновременни потребители може да се справи уеб сървърът - и може да има няколко ограничения. В този случай искате да зададете достатъчно ниска скорост на опашката, за да гарантирате, че сървърът ви има капацитет за процесорно време, за да обработи достатъчно хора едновременно за най-бавната стъпка в процеса, така че хората да не се натрупват там. В противен случай уеб сървърът ви може буквално да спре.
Опитът ни показва, че при първата си продажба всички надценяват способността на сървърите си да се справят с големи обеми трафик.
Всички.
Точното определяне на средната продължителност на сесията и производителността на крайния потребител по време на бавен или пиков трафик не е за хора със слаби сърца. Най-доброто нещо, което можете да направите, е да проведете подходящ тест за натоварване, като "фалшивите" клиенти действително преминават през процеса на поръчка по време на теста за натоварване, точно както биха го направили в реалния живот, като правят същите HTTP заявки в същия ред, със същото изчакване между страниците при теста за натоварване, както виждате в реалния живот, и да следите натоварването на процесора, пропускателната способност на IO и времето за отговор, докато увеличавате броя на виртуалните посетители. Можете да използвате Apache JMeter за тази цел (ние също харесваме K6 за по-леки натоварвания или по-бавни машини), но какъвто и инструмент да използвате, имитирането на поведението на всеки отделен потребител по точно определен начин отнема време и е трудно (особено при сложността на кеширането). Дори тогава вземете максималния брой и го намалете наполовина.
При липса на такива данни, предпочитайте да бъдете предпазливи.
Можете лесно да промените скоростта на опашката за всяка опашка на Queue-Fair по всяко време, като използвате портала Queue-Fair. Започнете от 10 посетители в минута или от скоростта на транзакциите в по-нормален ден, вижте как върви това за известно време, след като билетите ви бъдат пуснати в продажба, и ако всичко изглежда добре, натоварването на процесора ви е ниско, базата данни sql е наред и (преди всичко) страниците ви реагират, когато натиснете CTRL-SHIFT-R, увеличете го с не повече от 20 процента, изчакайте малко и повторете. Скоро ще откриете действителната скорост, от която се нуждаете по време на това "балансиране на натоварването" (виждате ли какво направихме?), и не забравяйте, че от гледна точка на клиентското преживяване е добре да повишите скоростта на опашката, тъй като това води до намаляване на очакваното чакане, което клиентите ви в опашката виждат, и всички са доволни да видят време за отговор, което осигурява по-кратко очаквано чакане.
Това, което искате да избегнете, е да зададете твърде висока скорост на опашката, след което да се наложи да я намалите, тъй като това: а) означава, че хората, които използват сайта, се зареждат бавно и б) води до увеличаване на очакваните чакания. Всички хора в опашката ви ще въздъхнат!
Не забравяйте, че някъде в процеса на поръчка ще има тясно място - всяка транзакция има най-бавна стъпка - и там ще се натрупват множество сесии. Това, което не искате да направите, е да стигнете до минута от продажбата на билети, да видите, че натоварването на процесора на сървъра ви е много под максималното число, и да повишите скоростта. Посетителите ви вероятно не са стигнали до бутона "Купи сега". Искате да изчакате, докато sql базата ви данни отчете нови поръчки със същата или подобна скорост като тази на опашката ви, и тогава да направите измерванията и тестовете за отзивчивост. Не забравяйте, че всеки път, когато увеличавате скоростта, на допълнителните посетители ще им отнеме същото време да достигнат до тясното място, така че няма да можете да оцените точно как работи сървърът ви при новата скорост, докато не изтече това време.
Вече обсъдихме как е най-добре да увеличавате скоростта на опашката постепенно, след като опашката ви е отворена. Вероятно сте наясно, че сървърите ви имат лимит, който не може да бъде надхвърлен, без системата да се срине, и може би дори знаете какъв е този лимит - но това, което може би не знаете, е, че когато натоварването наближава този лимит, обикновено има много малко признаци - често само няколко грешки или предупреждения, или натоварване на процесора над 80%.
Когато уеб услугите се провалят, те са склонни да се "счупят" или да спрат да функционират много бързо. Обикновено това се дължи на факта, че след като системата ви вече не може да обработва заявките толкова бързо, колкото те постъпват, се натрупват вътрешни опашки за обработка. След това системата ви трябва да се справи с обработката, управлението и съхранението на вътрешните опашки, както и със заявките, и това е, което преобръща сървърите. Много бързо. След като това се случи, сървърите ви може за известно време да могат да отговорят със страница за грешка, но това не ви помага, защото посетителите, които я видят, веднага ще натиснат Refresh (Обновяване), увеличавайки натоварването.
Дори преди това, ако на посетителите им отнема повече от около секунда, за да видят страниците ви, те натискат бутона Refresh. Когато посетителят натисне "Опресни", вашият уебсървър не знае, че посетителят вече не чака отговор на първоначалната заявка. Ако са получени и първоначалната, и заявката за опресняване, уебсървърът ви ще обработи и двете. Това означава повече работа за уебсървъра, още по-бавни отговори за всички посетители и още повече хора, които натискат бутона за обновяване, което води до порочен кръг, който прекъсва уебсървъра ви, преди още да е започнал да изпраща отговори за грешки.
Затова не натоварвайте сървърите си повече, отколкото е необходимо. Обикновено не си заслужава да рискувате, ако се стремите към последните 20% от капацитета на процесора. Ако размерът на опашката, показан в портала Queue-Fair (жълтата фигура и линия на чакащите в диаграмите), намалява или дори просто се увеличава по-бавно, минута след минута, а показаното време за чакане е 50 минути или по-малко, тогава обработвате поръчките достатъчно бързо и опашката в крайна сметка ще се изпразни и ще спре да показва Страници на опашката автоматично, без да се налага да правите нищо и без да се налага да казвате на шефа си, че сте го натискали твърде много и сте го повредили. В крайна сметка ще стигнете дотам, стига скоростта на фронта на опашката да е по-висока от броя на присъединяванията всяка минута (и двете се показват в портала Queue-Fair) - повратната точка обикновено е поне няколко минути след всяко събитие. Ако продавате продукт с ограничено количество, вероятно ще го продадете, преди да бъде достигната повратната точка.
Добрата новина е, че ако случайно зададете твърде висока скорост на опашката и сървърите ви се сринат, Queue-Fair може да ви помогне да се възстановите бързо - просто поставете опашката в режим на изчакване, докато сървърите ви отново са готови да приемат посетители. В режим на задържане хората в опашката виждат специална страница за задържане, която можете да създадете преди онлайн събитието си. Когато опашката е в режим "Задържане", никой не се пропуска от предната ѝ част, но нови интернет посетители все още могат да се присъединят към опашката отзад, за да бъдат подредени справедливо, след като блокирането бъде отстранено, което ще стане много бързо, защото Queue-Fair защитава сайта ви от търсенето. Страницата за задържане е по-добро потребителско изживяване от задаването на много нисък процент на опашката, особено ако я актуализирате, за да съобщите на посетителите в колко часа очаквате опашката да се отвори отново, което е лесно да се направи с редактора на страницата на портала, дори когато стотици хиляди хора вече са на опашката - а в режим на задържане можете дори да ги пускате един по един с уникалния бутон на Queue-Fair Admit One (Допускане на един), ако се налага, докато системата ви се възстанови от срива.
Така че, ако се наложи сървърите ви да прекъснат работа по време на събитието, страницата "Задържане" е точно това, от което се нуждаете, а освен това ще помогне на сървърите ви да се възстановят по-бързо.
В тази статия обяснихме защо опашката, базирана на скоростта, винаги е най-добрият начин и дадохме два метода за изчисляване на необходимата скорост, но освен ако не сте направили пълно и точно виртуално тестване на натоварването на посетителите за целия поток от транзакции и не сте наистина супер много сигурни в това, нашият съвет винаги е един и същ:
Ако продавате продукт в ограничено количество, не е необходимо да обръщате внимание и на стъпка 7.
Това се отнася за първата опашка, когато не знаете действителната максимална скорост на опашката, която системата ви може да поддържа. За следващите опашки, след като сте измерили скоростта на опашката, с която системата ви действително може да се справи, може би ще можете да използвате отново същата стойност - но само ако нищо не се е променило в системата ви. На практика системата ви вероятно е в процес на постоянно развитие и модификация и може да не знаете как последните промени са повлияли на максималната скорост на опашките - така че защо да не започнете от половината от предишната измерена стойност и да повторите горния процес?
Така че ето как да използвате Queue-Fair, за да направите продажбата си приятна и сигурна, и не забравяйте, че винаги е по-добре да се предпазите, отколкото да съжалявате.
2024 The Fair Queue People Ltd. - Всички права запазени.
Част от фамилията решения за опашки Orderly - OrderlyQ - OrderlyStats - WeQ4U
