Запись и обработка Twitter Streaming API с использованием Windows Azure и F#

Is it okay to think of a worker role as an agent?

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

In practice the message can be larger than 8 KB so I am going to need to use a blob storage and pass as message the reference to the blob (or is there another way?), will that impact performance ?

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

Is it correct to say that if needed I can increase the number of instances of the Processor worker role, and the queue will magically be processed faster ?

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

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

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

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

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

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

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

Вам нужно посмотреть, что делает ваш процесс, и решить, связан ли он с вводом-выводом или процессором. Обычно процессы, связанные с вводом-выводом, повышают производительность за счет добавления дополнительных агентов. Если вы используете ThreadPool для своих агентов, работа будет достаточно хорошо сбалансирована даже для процессов, привязанных к ЦП, но вы достигнете предела. При этом не бойтесь экспериментировать со своей архитектурой и ИЗМЕРЯЙТЕ результаты каждого запуска. Это лучший способ сбалансировать количество используемых агентов.