Нужен совет по архитектуре приложения GPS-логгера на базе Azure

Привет, я работаю над приложением GPS-логгера на базе Azure.

Функциональность включает в себя обновление местоположения в режиме реального времени на картах Google в веб-браузере и создание отчетов.

Я решил использовать WorkerRole для получения входящих данных TCP GPS и размещения их в таблице (для будущего создания отчетов) и в очереди (для отображения карты с последними координатами через WebRole).

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

Я ожидаю, что данные будут поступать каждые 10 секунд, всего несколько часов в день, случайным образом.

Есть ли альтернатива проверке ввода данных и запуску рабочей роли? Или возможно какое-то расписание?

Как оптимизировать приложение.

С уважением, Анил


person Anil Maddala    schedule 22.03.2012    source источник


Ответы (3)


Мне нужно больше узнать о вашем приложении; но есть несколько вещей, которые я мог бы бросить вам в начале, чтобы вы начали.

Насколько «в реальном времени» вам нужна обработка?

1) вы можете запустить экземпляр XS, который ничего не делает, кроме как пробуждает большие рабочие роли. все еще работает, когда в этом нет необходимости, но XS почти ничего не стоит.

2) проверьте очередь с помощью локального просмотра и разверните рабочую роль. но это потребует 15-минутной задержки для развертывания роли каждый раз. поскольку вы платите за час, отключать его через 15 минут только для того, чтобы снова включить его через 15 минут, было бы бессмысленно, вы также можете оставить его включенным на целый час.

3) запланированное локальное задание для развертывания вашей рабочей роли каждую ночь, чтение сообщений из очереди, которая накопилась за день, выполнение работы, завершение развертывания.

Я бы сказал, что решение 3 было бы вашим лучшим решением, если бы обработка не должна была быть «в реальном времени».

Надеюсь, это поможет. в противном случае свяжитесь со мной, и я буду рад пообщаться на более глубоком уровне или указать вам кого-нибудь из наших выездных групп, чтобы помочь вам больше.

Найдите меня в Twitter, LinkedIn и т. д.

person ryancrawcour    schedule 22.03.2012
comment
Есть ли какое-нибудь руководство по использованию локально? Как установить планировщик и убить развертывание? - person Anil Maddala; 22.03.2012
comment
Обработка отображения в реальном времени на картах Google не должна превышать 10 сек. Создание отчета может занять некоторое время. - person Anil Maddala; 22.03.2012
comment
На мой взгляд, наличие планировщика в помещении побеждает высокую доступность лазури. Ваш вариант экземпляра xs для запуска более крупных рабочих звучит как лучший вариант для меня. - person Mike Goodwin; 23.03.2012
comment
@MikeGoodwin Привет, не могли бы вы объяснить или указать, как это можно сделать? сколько времени потребуется, чтобы роль XS запустила или инициировала более крупную рабочую роль? - person Anil Maddala; 25.03.2012

На мой взгляд, лучший способ сделать это — запустить процесс мониторинга локально, и когда он обнаружит данные, он сможет развернуть ваше приложение в Azure для его обработки. И когда это будет сделано, удалите приложение. Для этого вы можете использовать командлеты Azure Powershell, взгляните на:

http://wappowershell.codeplex.com/

person Tom    schedule 22.03.2012

Я не думаю, что запуск и остановка вашего сервиса действительно будет практичным для того, что вы хотите сделать. По сути, вы хотите, чтобы ваши услуги были доступны все время, но не хотите платить за них.

Если вас беспокоит стоимость, единственное, что я могу предложить, это если ваша рабочая роль работает на порту, отличном от 80, запускайте ее в своей веб-роли. Под этим я подразумеваю взять все, что вы сейчас делаете в RoleEntryPoint вашей рабочей роли, и поместить это в RoleEntryPoint веб-роли. Он должен работать без каких-либо изменений кода. Таким образом, вы платите только за один набор инстансов, а не за два.

person knightpfhor    schedule 22.03.2012