Мобильное приложение, являющееся тонким клиентом. Вся логика по обработке данных на сервере естественно. Видео/аудио-стриминг не является проблемой, да и использовать его пока не планируется, только текстовый чаттинг с парой фишечек. Больше похоже на онлайн-игру.
в любом случае сначала следует понять где узкое место. и вот это узкое место масштабировать. если проблема с хранилищем данных — значит делать шардинг. Если все правильно сделано сначала, то это не приведет к существенным изменениям в приложении. Если узкое место это сама вебная часть — то правильное решение поднять несколько вебсерверов и их балансировать через nginx UpStream, как вы и отметили. Но всё опять же зависит от того, где узкое место, что это за приложение и какие задачи оно выполняет.
Если задача «проверить масштабируемость моего приложения», то предстоит опять же ответить на вопрос: какое место в обозримом будущем может стать узким и как скоро. Если приложение не требовательное к update/insert в базе, то база станет узким местом не так-то скоро. Если есть сомнения — провести нагрузочный тест и, кстати, многое для себя узнать об архитектуре своего сервиса. Когда повалят странные ошибки, окажется что неправильно настроено логирование и так далее. Пофиксить эти проблемы сейчас — значит подойти к технической возможности осуществления масштабирования.
Коряво написал :( Подключаете кодбазу, подключаете хостинг, а сервис подцепляет ваш код и доставляет его в production окружение. Heroku насколько мне известно предоставляют базовый репозиторий + возможность подключения различных фреймворков, т.е. дают вам уже инфраструктуру
В отличие от Heroku они не предоставляют хостинга вообще. То есть это просто сервис, в котором вы настраиваете параметры деплоя и пользуетесь потом постоянно. Он умеет уже работать с Amazon и Rackspace. А на чем вы пишите?
Эх как я прогнал! Можно же просто их насоздавать и надобавлять заранее. Тогда нет проблемы и с тулом для создания UI, и нет проблемы с производительностью :) щас заимплеменчу! Спасибо огромное!
Это вариант, но тогда не удобно с интерфейсом работать в дизайнере UI в IDEA :) Поэтому я и отложил этот вариант. Дело в том, что там таких состояний 6 штук. И такую толстую xml layout'а не очень комфортно поддерживать.
Попробую последовать вашему совету. Просто сейчас у меня все очень декомпозированно и стройно получается, но тормозит.
А вьюхи-то заранее создаются все. Они просто добавляются и удаляются из иерархии. Я думал это быстро происходит. Видимо нет :(
а частицы, например, имеют разный размер или одинаковый? нельзя ли тут принцип неопределенности использовать если имеют разный. Иными словами разная ли пропускная способность туннеля для разного типа частиц, допустим?
