Меню
Что нового?

серверная архитектура для высоконагруженного проекта

я, как всегда, прикалываюсь )))
могу не писать
 
Разделение серверов было актуально во времена однопроцессорных машин.
Сейчас это не то что не догма, это давно не актуально от слова совсем.
Вот деление каналов для распределения сетевой нагрузки ещё может как-то сыграть при повышении частоты запросов.
 
@AnrDaemon, разделение серверов актуально в enterprize для соблюдения стандартов безопасности.
 
Таки то другой вопрос совсем. :) Тут я с вами согласен. Чем меньше знает и может каждое звено архитектуры, тем сложнее построить атаку на.
У меня сейчас контейнер с MySQL вообще не имеет никаких пользователей, кроме системных, и даже SSH нету, ибо не нужен. Туда я и с консоли хоста прицеплюсь при очень большой необходимости.
 
По pci dss с докерами и прочими lxc, скорее всего, пойдешь лесом. Ну только если ассессор добрый попадется.
 
Breeze написал(а):
Кеш тут не при чём, рекомендую посмотреть сколько весит в среднем главная страница новостных порталов, включая картинки и прочие ресурсы, которые не берутся со стороны.
И посчитать трафик, который будет генерить один сервер, если всё раздавать с него. В условии считаем, что сеть у нас идеальная и задержки равны нулю, а канал стандартный 100 мегабит.
Предвидя тему про "картинки кешируются на клиенте", говорю сразу, что сейчас этим можно пренебречь.
Нажмите для раскрытия...
для проекта с 1000 rps хранить статику не в CDN и иметь канал 100 мбит это клоунада
 
чем помешают картиночки с css, которые раздаются из дискового кеша?
 
посмотрел сейчас статистику обмена с главной местного новостного портала. 7метров.
банер раздают со своего сайта размером 3.4м .
что там у нас получается. на 100м карте могут отдать 3 картинки в секунду.
nginx конечно сгладит пик нагрузки. И сокетов может хватить даже на всех.

Но ...
 
grigori написал(а):
чем помешают картиночки с css, которые раздаются из дискового кеша?
Нажмите для раскрытия...
Ничем, речь как раз про то, что мерять производительность системы только количеством rps к бэкенду не совсем правильно.
Сначала товарищ заявляет, что 1000 рпс с одного сервера, где и база, и пых, и нгинкс как нефиг делать (1 сервер на все компоненты для новостного сайта, 8,5 миллионов пользователей в сутки), потом у него это трансформируется в бэкенд + cdn, что уже не является одним сервером, но пропадает куда-то база и кеш.
Зачем вводить ТС в заблуждение? В идеальных условиях 1 железка php+mysql+nginx выдаст и 1000 рпс, и 2000 рпс, но в жизни как правило всё иначе :)
 
Breeze написал(а):
ню-ню
Нажмите для раскрытия...
а какая еще минимальная конфигурация для сервера приложения?

Breeze написал(а):
потом у него это трансформируется в бэкенд + cdn, что уже не является одним сервером
Нажмите для раскрытия...
Тогда еще не забуть DNS, github и почту посчитать отдельными серверами, ведь я их тоже изначально не указывал
 
Последнее редактирование:
Hello написал(а):
а какая еще минимальная конфигурация для сервера приложения?
Нажмите для раскрытия...
В составе nginx + php + mysql железка не является сервером приложений в том виде, в каком принято это понимать.
Термин application server как правило подразумевает трёхзвенную архитектуру, в которой присутствует database server.
Если ты какому-нибудь инженеру из Австралии, скажешь о таком application server , он тебя не сразу поймёт.

В идеале, в понимании кровавого энтерпрайза, должно быть, например, nginx + reactphp, под который ты пишешь своё приложение.
 
@Breeze, Для новостного сайта при предварительных расчетов нужно всех брать униками.
Посмотрите по статистике. Ядро у них не превышает 5%

А при горячей новости вообще стремиться к нулю
 
Войдите или зарегистрируйтесь для ответа.
Сверху