Синтетические тесты покажут сферических коней в вакууме. Все эти цифры будут сильно отличаться от реальных цифр реальной работы всей системы с реальными пользователями.
Вы сразу пишите, сколько всего бекэндов у вконтакте. Тысяч 15? ))) Это нечестно )) С таким количеством железа можно чудеса highload показывать на любом софте )
Хорошо. Как объяснить факт, что стало лучше, когда его убрали, а все остальное не изменили?
Ваши количества процессов и LA не значат ничего, если неизвестен профиль нагрузки.
А зачем нужны эти расходы в чистом виде? Мне нужно, чтобы система в целом работала )) Реалии таковы, что apache, к сожалению, нетащет более-менее серьезные проекты.
Поэтому я останусь при своем мнении, что лучше его сразу убрать, а не тогда, когда проект из трех строк кода перерастет в этот самый «более-менее».
Так считать нельзя. Представьте, что у меня много кода, много базы данных, везде включен кэш.
ab отработает в keep-alive и разные кэши, в итоге будет стопицот rps и 0мс.
Реальный пользователь зайдет на страничку, авторизуется, отрендерит себе динамически 17 виджетов, каждый из которых лезет в базу, напишет комментарий, чем обновит еще с 500 виджетов из кэша. На него в это время трудятся три фронтенда и куча бекендов. Нужен инструмент с имитацией деятельности пользователя, тот же tsung.
Поверьте, разницу заметить будет несложно )
Измеряли, поэтому не используем. Довольны как слоны. Я уже молчу, что при совсем диких нагрузках apache, когда ему перестает хватать памяти, вместе с сервером впадает в кому и LA добегает до 800.
php5-fpm прожимает до 15000rps. Мы довольствуемся в наших проектах 500rps, для apache это практически недостижимо при равных технических условиях.
Но это лишь наш частный случай, никак не аргумент в споре. Скажем так, это success story из практики и личного опыта. 15000 на badoo, они на highload рассказывали, сам я таких цифр не видел.
То есть возможности = простота конфигурации? Вы сейчас описали функционал, присутствующий также и в связке, допустим, nginx+php5-fpm, причем функционал для фронтенда. Неважно, как это конфигурируется, важно как это потом работает под нагрузкой ))
А мы сейчас вообще говорили про apache/не apache в качестве именно бэкенда, чья задача незатратно прожевать и отдать динамику. Apache при таком решении все же очень затратен по ресурсам и медленнее, чем все остальное, в чем же профит?
Подобные фразы нельзя просто вырывать из контекста. Все очень сильно зависит от профиля, качества и особенностей нагрузки. Для каждого отдельного сервера такие решения необходимо принимать индивидуально.
Где ж вы таких админов только берете. «Трехдневная инспекция, обмолвился про nginx».
А вообще очередной сериал по сотому разу how to become highload-ready. Статей на эту тему уже столько понаписали ))
Сколько вы в итоге времени потратили, чтобы прийти к очень распространенной (можно сказать типовой) в наши дни конфигурации?
Может стоит спросить сектор эксплуатации, как им работается, удобно или нет. Если написать внедренческую документацию, а в ней указать, что необходимо на всех 47 серверах обновить ruby до версии 1.8.7patchlevel 251, то это не значит, что сектору эксплуатации так удобно. Это лично вам скорее удобно.
Проблема у единого центра конфигурации одна — его надо один раз настроить и вбухать кучу времени. Потом все превращается в одну кнопку для всех единиц или десятков машин.
Концепция DevOps (и chef в частности) позволяет вообще отказываться от таких центров внедренческой документации. Прошлый век какой-то. Сам центр конфигурации и будет таким хранилищем. Рецепты прекрасно документируются в процессе написания, все понятно и доступно, логика прослеживается. Процесс работы не превращается в графики составления графиков и документирование документации по написанию документации. Простите, выдыхаю ))
Революция — это не очень хорошее словоПростите, вырвалось.62live.ru/yumor/6706-kak-opredelitue-chto-vash-rebenok-got.html#post115183
Ваши количества процессов и LA не значат ничего, если неизвестен профиль нагрузки.
Поэтому я останусь при своем мнении, что лучше его сразу убрать, а не тогда, когда проект из трех строк кода перерастет в этот самый «более-менее».
load average: 1.59, 2.00, 2.11
Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.2%us, 1.1%sy, 0.1%ni, 85.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 14680064k total, 1575808k used, 13104256k free, 0k buffers
вот здесь сейчас 12000 пользователей онлайн.
ab отработает в keep-alive и разные кэши, в итоге будет стопицот rps и 0мс.
Реальный пользователь зайдет на страничку, авторизуется, отрендерит себе динамически 17 виджетов, каждый из которых лезет в базу, напишет комментарий, чем обновит еще с 500 виджетов из кэша. На него в это время трудятся три фронтенда и куча бекендов. Нужен инструмент с имитацией деятельности пользователя, тот же tsung.
Поверьте, разницу заметить будет несложно )
php5-fpm прожимает до 15000rps. Мы довольствуемся в наших проектах 500rps, для apache это практически недостижимо при равных технических условиях.
Но это лишь наш частный случай, никак не аргумент в споре. Скажем так, это success story из практики и личного опыта. 15000 на badoo, они на highload рассказывали, сам я таких цифр не видел.
А мы сейчас вообще говорили про apache/не apache в качестве именно бэкенда, чья задача незатратно прожевать и отдать динамику. Apache при таком решении все же очень затратен по ресурсам и медленнее, чем все остальное, в чем же профит?
А вообще очередной сериал по сотому разу how to become highload-ready. Статей на эту тему уже столько понаписали ))
Сколько вы в итоге времени потратили, чтобы прийти к очень распространенной (можно сказать типовой) в наши дни конфигурации?
Проблема у единого центра конфигурации одна — его надо один раз настроить и вбухать кучу времени. Потом все превращается в одну кнопку для всех единиц или десятков машин.
Концепция DevOps (и chef в частности) позволяет вообще отказываться от таких центров внедренческой документации. Прошлый век какой-то. Сам центр конфигурации и будет таким хранилищем. Рецепты прекрасно документируются в процессе написания, все понятно и доступно, логика прослеживается. Процесс работы не превращается в графики составления графиков и документирование документации по написанию документации. Простите, выдыхаю ))