Я не уверен, что я точно правильно понял вашу задачу.
Я бы сделал так:
Сервер, который получает запрос и ставит его в очередь, указывая время валидности. У амазона есть aws.amazon.com/sqs/ — Simple Queue Service, использую и полностью им счастлив.
Сервер(а) обрабатывающие запросы из очереди, которые проверяют, не истек ли срок годности запроса.
Для хранению пользовательских файлов мы используем S3.
На EBS хранится только OS, Файлы приложения (~40MB), и MS SQL Server. Пока это не проблема.
Все что можно — CSS, картинки, пользовательские файлы — отдается через cloudfront; сервер отдает только сгенерированный html и JS (который на самом деле один и тот же и хранится в кэше).
Скорость копирования примерно 2MB/sec, 1.5MB/s когда мелкие файлы
Для теста, скопировал по сети с EBS одного инстанса на другой папку (8000 файлов, 350 мегабайт) — заняло ~2,5 минуты.
Пока проект не открыт официально и посещаемость там небольшая «орда» микро инстансов пока не используется. Это была подготовка к релизу, который планируется в ближайшую неделю-две.
Если Вы используете Amazon могу поделиться AMI — вы скопируете туда собственное приложение и проверите, как оно живет.
Спасибо за напоминание о незаполненном профиле — я так обрадовался инвайту что забыл об этом… чуть заполнил, о себе напишу в течении нескольких дней
Когда произошёл глюк хост сервера только через 4 рабочих дня мне создали новый виртуальный бокс, а данные восстановить так и не смогли (у меня был бакап так что это было не критично).
Micro проработал в load balancing всю ночь, за это время зарегистрировано 17 страниц, которые рендерились дольше 7 секунд (в первую очередь по причине DB). Пока он не засыпал
По логгируемому моим кодом (от begin request до end request) времени выполнения страницы, micro тратит столько же времени, сколько и small.
Я накинул 33% чтобы снизить вероятность возможного подвисания, упомянутого miolini.
Действительно, я часто наблюдал такой эффект на 32х битной Windows Server 2008 на Микро инстансе. Однако, там был и MS SQL и ASP.NET приложение.
Сервер гарантировано подвисал на примерно 10 минут после запуска loadimpact. Тестирование показывает, что в данной конфигурации сервер принципиально более живучий.
Ну а если таки подвиснет, load balancer его уже через 12 секунд объявит unhealthy и исключит.
Меня настораживает у Azure платить за каждую базу данных, причем довольно ощутимую сумму — $49.95 per database up to 5GB per month.
Я бы сделал так:
Сервер, который получает запрос и ставит его в очередь, указывая время валидности. У амазона есть aws.amazon.com/sqs/ — Simple Queue Service, использую и полностью им счастлив.
Сервер(а) обрабатывающие запросы из очереди, которые проверяют, не истек ли срок годности запроса.
На EBS хранится только OS, Файлы приложения (~40MB), и MS SQL Server. Пока это не проблема.
Все что можно — CSS, картинки, пользовательские файлы — отдается через cloudfront; сервер отдает только сгенерированный html и JS (который на самом деле один и тот же и хранится в кэше).
Скорость копирования примерно 2MB/sec, 1.5MB/s когда мелкие файлы
Для теста, скопировал по сети с EBS одного инстанса на другой папку (8000 файлов, 350 мегабайт) — заняло ~2,5 минуты.
Забегая наперед, боюсь в Core режиме не получится поставить Php, так что для php/mysql наверняка *nix действительно лучше, да и дешевле
База данных стояла на этом же сервере?
Если будут дохнуть — я сделаю обновление этому посту, чтобы не вводит никого в заблуждение
PS: Вообще я очень рад что столько людей с хаббра использует Amazon Web Services
Если Вы используете Amazon могу поделиться AMI — вы скопируете туда собственное приложение и проверите, как оно живет.
Спасибо за напоминание о незаполненном профиле — я так обрадовался инвайту что забыл об этом… чуть заполнил, о себе напишу в течении нескольких дней
Когда произошёл глюк хост сервера только через 4 рабочих дня мне создали новый виртуальный бокс, а данные восстановить так и не смогли (у меня был бакап так что это было не критично).
Micro проработал в load balancing всю ночь, за это время зарегистрировано 17 страниц, которые рендерились дольше 7 секунд (в первую очередь по причине DB). Пока он не засыпал
Я накинул 33% чтобы снизить вероятность возможного подвисания, упомянутого miolini.
Сервер гарантировано подвисал на примерно 10 минут после запуска loadimpact. Тестирование показывает, что в данной конфигурации сервер принципиально более живучий.
Ну а если таки подвиснет, load balancer его уже через 12 секунд объявит unhealthy и исключит.