Я начал делать некоторую работу для товарища, использующего Apache2 и PHP на Ubuntu, и процессор работает на пределе. Что мне действительно нужно, так это совет относительно того, является ли использование экземпляра Micro хорошей идеей для производственного / общедоступного веб-сайта. Мне кажется, что нет, и что использование экземпляра Standard или High было бы лучше, но поскольку я только начал экспериментировать с AWS, я просто хотел посмотреть, что сделали другие люди.
Теперь он запускает некоторые из этих Load Balanced, но ему приходится отключать экземпляры, я собираюсь посмотреть, как настроить Cloudwatch, чтобы сделать это за него автоматически, пока я не смогу лучше понять, что происходит с его приложением под капот.
Я знаю, что это довольно расплывчатые вопросы, и я не предоставил много подробностей о настройке, но я все еще осваиваю его сайт.
Краткий ответ: не сбрасывайте со счетов t1.micro - это способный экземпляр и определенно может запускать сайт PHP, но если вы не можете заставить его работать с одним t1.micro, то получите более крупный экземпляр (в отличие от нескольких t1.micros).
Длинный ответ: экземпляр t1.micro вполне способен генерировать динамический контент и может довольно плавно работать с несколькими небольшими сайтами. Для хорошо оптимизированной настройки (скажем, Wordpress с кешированием) я бы сказал, что t1.micro должен обрабатывать не менее 50 тысяч обращений в месяц, если не больше. Однако одна из ключевых идей заключается в том, что все хорошо оптимизировано - установка Apache по умолчанию довольно быстро отключит t1.micro, поскольку каждый запрос порождает новый процесс - со всеми связанными накладными расходами.
Кроме того, t1.micro по умолчанию не имеет пространства подкачки (может быть полезно настроить том EBS объемом 1 ГБ для использования в качестве пространства подкачки - больше в качестве меры безопасности, чем для его фактического использования. Если вы обнаружите, что он используется часто, то что-то нужно изменить.
Если вы собираетесь запускать несколько экземпляров, я бы не советовал использовать несколько экземпляров t1.micro. Производительность на доллар намного выше на более крупных экземплярах (память, ввод-вывод и ЦП). Еще один момент, связанный с t1.micro, заключается в том, что, хотя вы можете «взорвать» дополнительный процессор, циклы также могут быть «украдены». Обязательно используйте 32-битный экземпляр, если вы идете по маршруту t1.micro - добавленные накладные расходы 64-битных регистров просто приведут к тому, что экземпляру будет проще исчерпать память без какого-либо ощутимого прироста производительности.
Если возможно, я бы рекомендовал использовать php-fpm вместо mod_php - хотя он немного медленнее, он способен выдерживать гораздо больший объем трафика с меньшей нагрузкой на экземпляр. Кроме того, если возможно, разгрузите обслуживание статического контента. Для последнего вы можете использовать CDN, например Cloudfront (или даже S3) - идея состоит в том, что эти запросы не потребляют пропускную способность, дисковый ввод-вывод или вычислительную мощность (или память) экземпляра. В качестве альтернативы вы можете использовать легкий интерфейсный сервер (например, nginx) для обработки статического содержимого, а затем проксировать динамические запросы обратно в apache (если вы не можете полностью переключиться на использование этого интерфейсного сервера) - это добавляет сложности к setup - но особенно если ваши страницы кэшированы (т. е. статические версии, генерируемые при изменении страницы), прирост производительности может быть существенным. Также может быть целесообразно кэшировать динамический контент с помощью внешнего сервера (продолжительность будет зависеть от популярности сайта), чтобы избежать ненужной обработки динамических запросов.
Последнее предложение - которое может оказаться невозможным - подумайте об использовании Linux от Amazon в качестве операционной системы вместо Ubuntu. Я обнаружил, что он чрезвычайно легкий и эффективный на t1.micro - он поставляется с минимумом установленных пакетов и занимает очень мало места.
Запуск динамического веб-сайта на t1.micro, безусловно, возможен - я запустил несколько небольших сайтов (Wordpress / Drupal / Joomla) на одном t1.micro - оба используют nginx / apache / php-fcgi и varnish / nginx / php -fpm - включая почтовый сервер (postfix), imap (dovecot), базу данных (mysql) и ftp-сервер (pure-ftp / vsftp) - с приличной производительностью (сайты Wordpress загружаются за 1-2 секунды), с низкой средней нагрузкой ( обычно менее 0,1, при запросе каждые 15 с) и около 150-200 МБ используемой памяти). Это не было бы моим выбором с точки зрения производительности, но это наименее затратное решение для сайта, которому просто необходимо надежно быть в сети, не ожидая большого трафика.
Я бы сказал, что t1.micro является очень хорошей платформой для работы над вашими навыками оптимизации - он позволяет вам увидеть, сколько вы можете получить от самого минимума и какие оптимизации будут дороже, чем они того стоят. Однако, если ваш сайт слишком велик для одного t1.micro, используйте более крупный экземпляр, а не дополнительные экземпляры t1.micro (если ваша конкретная цель - отработка отказа, но есть вероятность, что на этом этапе вы все равно будете использовать более крупные экземпляры). . Не выполняйте балансировку нагрузки экземпляров t1.micro - такой подход мало что дает - более крупный экземпляр подойдет вам лучше. Однако вы определенно хотите узнать, почему эти экземпляры умирают - я бы держал пари, что это проблема с памятью, а не с процессором. Вы определенно хотите попробовать запустить копию своего сайта и запустить ab (или seigeи т. д.) и посмотрите, что сервер может выдержать - и является ли это дизайном приложения (которое вы, вероятно, не можете изменить) или настройкой сервера.
(Если вы не используете спотовые экземпляры, вы можете довольно легко обновить тип экземпляра - просто остановите (не завершите) и используйте атрибут ec2-modify-instance-attribute для изменения типа перед перезапуском).
Экземпляры t1.micro подходят для общедоступных веб-сайтов, если вы не получаете больше трафика, чем может обработать экземпляр t1.micro. (Предыдущее предложение мало что говорило.)
Похоже, вы получаете больше трафика, чем t1.micro может обработать при текущем написании приложения, поэтому вам следует перейти на более крупный тип экземпляра.
Я не думаю, что балансировка нагрузки t1.micro имеет смысл. На мой взгляд, минимум для балансировки нагрузки - это m1.small, и даже в этом случае вам, вероятно, лучше просто запустить c1.medium, поскольку это дешевле, чем количество m1.smalls, необходимое для получения эквивалентных процессоров.