RDS, scalr с EC2 или xeround для базы данных на 40 ГБ
Необходимо обновить исходный вопрос включать информацию, такую как AWS, Apache HTTPD и Пассажир Mod_Rails/Phusion.
Для ответа на вопрос необходимо считать Apache Пассажира Phusion документация HTTPD относительно настроек Spawn.
http://www.modrails.com/documentation/Users%20guide%20Apache.html#RailsSpawnMethod
Это кажется, что Вы находитесь в консервативном нерестящемся режиме, и дополнительно, первый узел не порожден, пока первый запрос не выполнен на сайт. Таким образом, я не удивлен, что требуется 7 секунд для полной среды направляющих, которая будет загружена из диска, введенного в рубин vm и установку.
Необходимо также посмотреть на RailsAppSpawnerIdleTime и удостовериться, что это подходящее высокий, таким образом, порожденные экземпляры направляющих не становятся переработанными. Я предполагаю, что это - специализированный экземпляр AWS для специальной цели разместить этот сайт, таким образом, это должно, скорее всего, быть установлено на 0 (для отключения) с макс. количеством узлов, которые могут быть порождены.
Движение к Облаку является действительно очень хорошим вариантом - самая твердая часть в масштабировании Вашего "облачного" приложения масштабирует базу данных. Не запутывайтесь, MySQL имеет решения для обработки отказа (сколько времени он берет …), который может поддерживать несколько копий для обработки чтений. Scalr и RDS являются очень соответствующими опциями, если Вы будете знать то, что ограничения являются … С Scalr то - они будут масштабировать Ваш DB путем настройки ведомых устройств базы данных, ведущих устройств, и конфигурирования репликации данных. В то время как автонастройка действительно упрощает, и репликация действительно предусматривает некоторое средство, имеет в виду, что добавление репликаций чтения не зафиксирует записи OLTP …, и при этом это не обработает истинную линейную эластичность по запросу. Каждый раз, когда Вы добавляете копию чтения, это, вероятно, будет сервисное событие.
Для HA Scalr использует EBS. Если последний AWS EBS очень долгое время простоя имеет какой-либо признак.., удостоверьтесь, что Вашими данными/устройством хранения данных является также HA …
Масштабируемое решение должно быть линейным и эластичным (масштабируйте горизонтально, в, вниз), по требованию без любого времени простоя. "Облачные" приложения нужны в собственном истинном HA – несколько чтений выполнения копий и пишут все время, не обработка отказа. RDS докажут тот же "предварительно сконфигурированный MySQL" установка и таким образом иметь те же ограничения. Наконец, что не менее важно, удостоверьтесь, что нет никакой единой точки отказа и что влияние на Ваших разработчиков является … каждый раз, когда Вы вносите изменение в приложение. В Xeround наша цель дизайна состояла в том, чтобы решить эти проблемы. Наши Телекоммуникационные гены класса и решение, разработанное со дня один как виртуальные для облачные операции, позволяют нам предложить эластичному, супер масштабируемому и высоконадежному "беспокойству по запросу свободный" облачный DB.
Мы выполнили годовую бету с тысячами пользователей многие из который точно как Вы.
Мы - теперь GA - регистрируйтесь для 30 бесплатных демонстрационных версий (никакая требуемая кредитная карта) и проверьте это для себя.
Razi Sharir (Xeround).
Я могу рассказать вам о своем опыте работы с большой дб .. но намного больше, чем у вас около 90 гигов.
Мы использовали RDS, и по крайней мере 3-4 раза в день мы получали ужасную задержку при запросах. Как и запросы, которые занимают секунду, будут длиться 10-20 секунд. Мы перешли на их самый крупный инстанс, поддерживаемый рейдовой EBS, и производительность была примерно такой же, но мы не достигли этих действительно сильных всплесков задержки.