Как только вы выйдете за пределы 100 000 обращений в месяц, что люди в этом сообществе сочтут самым большим препятствием?
Моя ситуация: тонны статических носителей (аудио / видео / изображения) обслуживаются вне S3 / CDN, но хранятся локально в качестве резервных копий (хотя не обслуживаются). Все, что можно кэшировать, кэшируется, примерно с 8 гигабайтами памяти с возможностью увеличения до 32.
В настоящее время мы без проблем обрабатываем около 100 000 обращений и хотели бы знать, с какими проблемами сталкивались другие: балансировка нагрузки? проблемы с памятью? дисковый ввод / вывод?
Спасибо за любые советы. Я просмотрел связанные вопросы, и они хорошо на них ответили, но просто хотел получить больше отзывов.
В наши дни оборудование настолько дешево, что все меньше людей даже доходят до того, что им требуется более одной машины. За 10 000 долларов вы купите:
Такой тип машины может обслуживать более 10 000 одновременных пользователей даже на слегка оптимизированном сайте для всех приложений, кроме наиболее ресурсоемких.
В основном есть два подхода к масштабируемости:
Посмотрите на StackOverflow: он в основном работает на веб-сервере плюс сервер базы данных и делает более 6 миллионов обращений в месяц.
При этом масштабируемость - это поиск и устранение узких мест.
Однако в конечном итоге 100 000 обращений в месяц - это не так уж и много. Я подозреваю, что в наши дни на типичном веб-сайте вам нужно будет выходить за рамки 10 миллионов в месяц, прежде чем у вас возникнут реальные проблемы, если вы не делаете ничего плохого (например, если вы не индексируете поиск по базе данных, то, конечно, вы будут проблемы с этим, но они не имеют отношения к хитам в месяц).
Я бы сказал, что избыточность - гораздо большая головная боль, чем масштабируемость. Проблемы, связанные с наличием избыточных ссылок, процессами мониторинга сбоев системы, наличием и обслуживанием сайта аварийного восстановления (аварийного восстановления), решением возникающих проблем (например, кластеризацией с разделенным мозгом) и т. Д., Являются гораздо более сложными и утомительными.
Использовать Лак или Кальмар. Оба являются веб-ускорителями и отлично подходят для статических мультимедийных файлов.
При горизонтальном масштабировании у вас даже может быть 1 машина для веб-кеша и 1 машина для динамического контента.
В качестве альтернативы вы можете попробовать настроить apache с помощью модов: mod_expires, mod_headers, mod_cache, mod_file_cache, mod_mem_cache.
Другие отметили, что 100 000 просмотров не проблема, хотя я подозреваю, что они упустили вашу точку зрения, что вы уже обслуживает столько хитов без проблем ...
Учитывая, что ваш контент включает видео, я бы предположил, что вашей первой проблемой будет пропускная способность сети, за которой последуют запросы ввода-вывода, когда у вас будет достаточно одновременных запросов для больших объектов. Если у вас больше ОЗУ, чем данных, то ввод-вывод будет меньшей проблемой, как только все будет помещено в кеш (хотя для заполнения кеша после любого выключения сервера потребуется время).
Одна вещь, которую вы должны указать при попытке установить такие требования к размеру, - это то, какое распределение имеют ваши обращения. Распределяются ли они равномерно в течение месяца или более скачкообразно? Например, сайт, на котором размещена информация о национальной лотерее, может видеть 80% или более своего еженедельного трафика в двухчасовом окне после времени розыгрыша - 80% 100K запросов за два часа составляют 2,7 в секунду (при условии, что 4 недели в месяц) все еще не массово, но доставляется в зависимости от размера / сложности или ответов. Возможны и другие, менее предсказуемые всплески, например, что произойдет, если видео на вашем сайте попадет на первую страницу Digg или аналогичного.
Как только вы выйдете за пределы 100 000 обращений в месяц
НИЧЕГО !!! Если у вас проблемы с обслуживанием 100 тысяч обращений в месяц, значит, у вас проблемы. Как правило, у вас не должно возникнуть проблем с большинством самых глупых систем, обслуживающих 100К в день.
Это про LAMP ... и CMS системы
Моя ситуация: тонны статических носителей (аудио / видео / изображения) обслуживаются с S3 / CDN
Для этих целей есть очень хорошие веб-серверы: lighttpd - он обслуживает потоковую передачу мультимедиа YouTuble, nginx тоже хорош.
Это легкие веб-серверы, которые очень хорошо масштабируются при высоких нагрузках.
Помогло бы даже переключение модуля Apache с mod-prefork на mod-worker (даже lighttpd по-прежнему намного лучше).
Нижняя граница: эти нагрузки далеки от высоких.
Немного зависит от того, какая база данных обрабатывает ваши действия - обслуживаете ли вы статический контент или почти статический контент; вы сможете масштабироваться далеко за пределы 100K / мес с очень скромным оборудованием.
Сложные сайты, управляемые базами данных, такие как форумы, могут быть более серьезной проблемой, вам нужно будет изучить репликацию базы данных, обратные прокси-серверы на основном веб-сайте, чтобы действовать как дополнительные кеши, и дополнительные веб-серверы с балансировкой нагрузки. Большинство «тяжелых» программ, использующих БД, также поддерживает такие вещи, как memcached, которые можно использовать для уменьшения нагрузки на базу данных при выполнении общих запросов.
Хотя, честно говоря, я думаю, что вы, вероятно, переоцениваете спрос прямо сейчас - 100 тысяч - это вполне приемлемо для обработки на одной машине. После того, как вы превысите 10M, вам нужно будет рассмотреть более сложные решения, такие как те, которые я описал выше.
Мой личный совет - всегда отдавать предпочтение параллельным машинам над отдельными сложными - это не только в конечном итоге дешевле, но и дает вам гораздо больше возможностей для роста, когда придет время. Расширяя и без того дорогое оборудование, вы попадаете в область серверов за 25 000 долларов, где «цена за деньги» исчезает.
Вероятно, самые большие препятствия
приведение вашего приложения в форму для слабосвязанной архитектуры, которая отбрасывает ACID и другие строгие ограничения, чтобы обеспечить асинхронную работу и краткосрочные несоответствия. Видеть Теорема Брюера CAP для широкого обзора этой темы.
Разберитесь с правильным управлением множеством узлов. Сюда входят основные задачи системного администрирования, такие как управление пакетами, а также тестирование и развертывание запросов на изменение. Когда у вас есть 50 веб-серверов, вы не можете просто «перезапустить все серверы apache»; некоторые мысли должны быть внесены в эти задачи
что подводит меня к моему последнему пункту - понять эффекты, которые можно увидеть в больших системах. Громовое стадо это одна из вещей, которые вы собираетесь увидеть. Эта статья на Аудиогалактике также описывают несколько проблем больших систем.
Масштабируемые Интернет-архитектуры и Искусство планирования мощностей две книги по этой теме, которые я очень рекомендую.
Я занимаюсь масштабированием, у меня одно правило: всегда оставляйте себе возможность выкупить себя из-за проблем с производительностью.
Все, что нельзя исправить, потратив деньги, не имеет фиксированного `` времени на решение '', поэтому всегда пытайтесь кодировать / конфитировать свой выход из проблемы, но всегда оставляйте себе возможность выбросить ядра / циклы / память / хранилище / пропускную способность / что бы там ни было - их всегда можно заказать в FedEx :)
Как только вы выйдете за пределы 100 000 обращений в месяц, что люди в этом сообществе сочтут самым большим препятствием?
Из-за обдумывания проблемы, из-за разработки платформы и из-за усложнения системы.
100к / месяц это ничего. Вся ваша цель на этом этапе должна заключаться в том, чтобы уделять как можно меньше времени сосредоточению на ней внимания.