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

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

2 голосов
/ 13 сентября 2010

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

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

  • Одна рабочая роль (издатель), которая помещает сообщения (сообщение, являющееся json твита) в очередь.

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

Что приводит кмного вопросов:

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

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

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

Ответы [ 3 ]

3 голосов
/ 14 февраля 2011

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

1 голос
/ 14 сентября 2010
Можно ли считать рабочую роль агентом?

Да, определенно.

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

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

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

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

0 голосов
/ 13 сентября 2010

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

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

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

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

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

Вам нужно посмотреть, что делает ваш процесс, и решить, является ли он связанным с вводом-выводом или с процессором. Как правило, связанные с вводом-выводом процессы будут иметь увеличение производительности за счет добавления большего числа агентов. Если вы используете ThreadPool для своих агентов, работа будет достаточно хорошо сбалансирована даже для процессов, связанных с процессором, но вы достигнете предела. При этом не бойтесь возиться с вашей архитектурой и MEASURE результатами каждого прогона. Это лучший способ сбалансировать количество используемых агентов.

...