Интервал опроса BlazeDS установлен на 0: нежелательные побочные эффекты?

Вкратце: Установка интервала опроса на 0 значительно повысила мою производительность, но я беспокоюсь о возможных проблемах в будущем.

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

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

Несколько минут назад я обнаружил, что установка свойства ‹polling-interval-millis> в нашем services-config.xml на 0 приводит к тому, что опубликованные сообщения, даже когда их много, распознаются клиентом почти мгновенно, вместо с 3-секундной задержкой, которая является значением по умолчанию для polling-interval-millis, что, очевидно, оказало огромное влияние.

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

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


java publishing apache-flex blazeds
person biggusjimmus    schedule 05.04.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Уменьшение значения с 3 до 0 означает, что вы получаете новые данные намного быстрее. Если ваш клиент Flex использует эти данные для выполнения сложных вычислений, возможно замедление работы вашего клиента или отображение устаревших данных (это известный шаблон, см. http://help.adobe.com/en_US/).LiveCycleDataServicesES/3,1/Разработка/WS3a1a89e415cd1e5d1a8a18fb122bdc0aad5-8000Update.html»отн=). Вам нужно понять, как обрабатываются данные, и, возможно, провести сравнительный анализ клиентов.

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

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

person Cornel Creanga    schedule 05.04.2011
comment
Я хорошо знал, что мой вопрос был довольно (слишком?) общим, и я любезно благодарю вас за то, что вы дали мне несколько вещей для размышления. - person biggusjimmus; 06.04.2011

arrow_upward
1
arrow_downward

Возможно, вы захотите попробовать длинный опрос. Для наших серверов Weblogic у нас не возникнет никаких проблем, если мы не ограничим запрос на опрос до 5 минут, поэтому мы оставляем его равным 4, а затем даем ему 1-секундную паузу перед повторным запуском. Всего у нас пара сотен пользователей, из них 60-70 на жестком ядре весь день. Следует иметь в виду, что вы в основном превращаете прерывистые запросы пользователей в то, что составляет почти всегда подключенные сеансы telnet. В зависимости от браузера, который используют ваши пользователи, это также может повлиять на это, но в целом мы были очень довольны.

person mezmo    schedule 05.04.2011