Twitter потоковую API записи и обработку с помощью Windows Azure и F #

Question

Месяц назад я пытался использовать агенты F # для обработки и записи Twitter StreamingAppi данных здесь. Отказ Как небольшое упражнение, я пытаюсь перенести код в Windows Azure.

Пока у меня есть две роли:

• Роль одной рабочей силы (издатель), который ставит сообщения (сообщение - JSON Tweet) в очередь.

• Один роль работника (процессор), который читает сообщения из очереди, декодирует JSON и сбрасывает данные в облачную таблицу.

Что приводит к большому количеству вопросов:

• Можно ли думать о рабочей роли как агента?
• На практике сообщение может быть больше 8 КБ, поэтому мне нужно будет использовать хранение и пропуск BLOB, как сообщено ссылку на BLOB (или есть другой способ?), Будет ли эта производительность?
• Правильно ли сказать, что при необходимости я могу увеличить количество экземпляров роли рабочей силы процессора, а очередь будет волшебным образом обрабатываться быстрее?

Извините за стуча всех этих вопросов, надеюсь, вы не возражаете,

Большое спасибо!

Answer 1

Можно ли думать о рабочей роли как агента?

Да, безусловно.

На практике сообщение может быть больше 8 КБ, поэтому мне нужно будет использовать хранение и пропуск BLOB, как сообщено ссылку на BLOB (или есть другой способ?), Будет ли эта производительность?

Да, используя технику, о которой вы говорите (сохранение JSON для хранения BLOB с именем «JSONMessage-1», а затем отправка сообщения в очередь с содержимым «JSONMessage-1»), похоже, является стандартным способом Проходящие сообщения в Azure, которые больше 8 КБ. По мере того, как вы делаете 4 вызова на Azure Storage, а не 2 (1, чтобы получить сообщение очереди, 1, чтобы получить содержимое BLOB, 1, чтобы удалить из очереди, 1, чтобы удалить BLOB), он будет медленнее. Будет ли оно заметно медленнее? Возможно нет. Если хорошее количество сообщений будет меньше 8 КБ, когда кодируется Base64 (это GOTCHA в библиотеке StorageClient), то вы можете поставить в какую-то логику, чтобы определить, как отправить его.

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

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

Answer 2

Есть библиотека OpenSource по имени Lokad.Cloud, которая может обрабатывать большое сообщение прозрачно, вы можете проверить это на http://code.google.com/p/lokad-cloud/

Answer 3

Можно ли думать о рабочей роли как агента?

Это идеальный способ думать об этом. Представьте себе работников в Макдональдс. У каждого работника есть определенные задачи, и они общаются друг с другом через сообщения (говорят).

На практике сообщение может быть больше 8 КБ, поэтому мне нужно будет использовать хранение и пропуск BLOB, как сообщено ссылку на BLOB (или есть другой способ?), Будет ли эта производительность?

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

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

Вам нужно посмотреть, на что делает ваш процесс и решает, если это связано с IO или CPU. Обычно связанные с IO-связанными процессами будут увеличить производительность, добавив больше агентов. Если вы используете ThreadPool Для ваших агентов работа будет сбалансирована довольно хорошо даже для процессов CPU, но вы получите предел. Это, как говорят, не бойтесь беспокоиться со своей архитектурой и МЕРА Результаты каждого прогона. Это лучший способ сбалансировать количество агентов для использования.