Как да направя мащаб на ролята на Azure работник, ако нишката е заета и чака?

Надявам се по-долу да обясни проблема ми.

Имам работна роля, която работи в цикъл while(true). Този работник взема съобщения от опашка и ги обработва. Никога не завършва, просто продължава да проверява опашка и да обработва съобщения.

Това работи, докато не получа съобщение, което изисква от мен да направя нещо, което отнема време. Пример може да бъде искане на информация от услуга. Хипотетично нека кажем, че тази заявка отнема 10 секунди. Сега моята работна роля е в средата на цикъла ми while в очакване на този отговор. Междувременно опашката със съобщения се запълва.

Това, което искам, е решение, което или ще спре, или ще смекчи това да се случи.

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

Знам, че трябва да използвам async заявки за услуги, но има и други примери, при които async няма да помогне. Предпочитам да не навлизам в подробности.

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

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

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

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

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

Моето решение има ли смисъл или има алтернативи?


azure c# task-parallel-library azure-worker-roles
person LivingOnACloud    schedule 24.01.2015    source източник
comment
Async IO няма значение тук, тъй като степента на паралелизъм е доста малка (като десетки паралелни съобщения). Не е проблем да имате заседнали конци, стига да има достатъчно конци.   -  person usr    schedule 24.01.2015
comment
Не виждам какъв е проблемът. Не можете ли просто да създадете N нишки/асинхронни задачи, които да изтеглите от опашката? Има ли конкретен проблем с това? Натоварването на процесора изглежда не е проблем за вас. Ако натоварването на процесора не е проблем, не е необходимо да мащабирате към повече процесори.   -  person usr    schedule 24.01.2015
comment
Мисля, че: A. Трябва да публикувате своя код B. Измервайте, измервайте, измервайте.   -  person Yuval Itzchakov    schedule 24.01.2015
comment
@YuvalItzchakov не е възможно да се измери дали една система е добре проектирана и стабилна. Това изглежда е въпрос на архитектура.   -  person usr    schedule 24.01.2015
comment
@usr Точно така. Но мисля да накарам TPL да изпълнява няколко дузини процесори за опашка, работещи на моята едноядрена машина, така че ако някой се върне при продължително асинхронно повикване, ще има други, които да продължат. Не обмислях много тази идея, защото не е решение и не бях сигурен дали ще проработи.   -  person LivingOnACloud    schedule 24.01.2015
comment
Защо това не е решение? Все още не ми е ясно защо този прост подход N нишка/задача не работи във всички отношения. Мога да ви отговоря само ако разбирам проблема, който имате.   -  person usr    schedule 24.01.2015
comment
@usr Стартирането на архитектура с N нишки и измерването на тесните места е единственият начин той да разбере къде всъщност трябва да направи допълнителната миля.   -  person Yuval Itzchakov    schedule 24.01.2015
comment
@YuvalItzchakov Съгласен съм. Засега въпросът е без отговор, защото не се вижда конкретен проблем. Затваряне.   -  person usr    schedule 24.01.2015

Отговори (1)


arrow_upward
2
arrow_downward

Вижте причината, поради която трябва да мащабирате

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

Проблемът не е толкова, че един работник отнема много време, а по-скоро опашката се архивира - точно затова Azure предлага опции за мащабиране, които включват размера на опашката.

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

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

person James    schedule 24.01.2015