Какие производственные проблемы следует ожидать при развертывании приложения Flex? - PullRequest
4 голосов
/ 17 октября 2008

Моя компания работает над панелью управления Flex, которая отображает финансовую информацию в режиме реального времени. Он будет развернут по корпоративной глобальной сети, возможно, нескольким десяткам пользователей.

Это наш первый проект Flex, и хотя разработка была очень приятной, нас немного беспокоит то, какие производственные проблемы могут возникнуть (пользователи, у которых не установлен нужный Flash-плеер, время загрузки, производительность BlazeDS и т. Д.) ,

Наш стек - RDBMS / Spring / BlazeDS (удаленное взаимодействие и обмен сообщениями) / Flex.

Есть ли у кого-нибудь советы по развертыванию коммерческого приложения Flex?

Ответы [ 3 ]

4 голосов
/ 17 октября 2008

Ваши самые большие проблемы, вероятно, будут:

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

Ничто из этого не является непреодолимым, но вы, вероятно, столкнетесь со всеми из них в первые несколько месяцев.

Я предполагаю, что вы протестировали свое приложение на производительность при разумной нагрузке и уже исправили эти проблемы с масштабируемостью: -)

НТН

2 голосов
/ 18 октября 2008

Если вы говорите о нескольких десятках пользователей, я не думаю, что у вас будет много проблем с производительностью. На мой взгляд, у первого дерева пули Симона будут наиболее вероятные проблемы. У нас есть гибкое бизнес-решение с бэкэндом .NET / WebORB и сервером MS SQL2005.

Размер SWF-файла приложения размером около 1,2 МБ. Если у вас есть широкополосное подключение к Интернету, то время загрузки не является проблемой (так как оно корпоративно развернуто в глобальной сети, думаю, это не проблема). Если нет, то первый раз, когда пользователь загружает SWF, это займет некоторое время, но затем его следует кэшировать. (Кэширование - это еще одна проблема, если у вас часто появляются новые сборки. Лучше всего иметь контекстное меню в вашем SWF, где вы можете увидеть версию сборки. Если у пользователя возникают проблемы с приложением, первое, что я проверяю, является ли он загруженным последняя версия.).

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

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

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

Ливен Кардоен ака Джохлеро

1 голос
/ 18 октября 2008

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

...