Что если использовать один веб-сервер – Apache?

само название mod_php говорит о том, что php в этом случае является составной частью апача, таким же модулем как mod_rewrite к примеру.

и все обращение апача к php происходит внутри одного процесса. во всех остальных случаях (даже nginx + php-fpm) происходит взаимодействие уже между процессами, через сокет, порт, т.е. самую малость, но сложней.

вот именно здесь и рождаются споры.

те самые 5-50% можно с микроскопом обнаружить лишь в определенных условиях. например при очень большом количестве запросов, что и делают бенчмарками... и понятно что к реальности это мало относится. либо на очень медленном железе.

дальше кто-то начитавшись пробует изменить у себя и конечно же не видит ни 5, ни тем более 50% прироста скорости.

все потому что на собственно php скрипты и mysql запросы уходит куда больше работы. и заметить на глаз микроразницу в режимах работы php нереально. скорей куда больше будет заметен переход с php5 на 7. и то не всегда.

так кто же прав? все правы по своему.

да, mod_php лучше и если нет противопоказаний, то почему б его и не использовать?

да, у всех разные ситуации и кто-то ту же проблему разграничения доступа решает через fastcgi, а не apache-itk (например панель только так может)

все равно куда большим тормозом будут продолжать оставаться скрипты, базы, мало памяти, диски, 2ггц процессоры и т.д.

и от смены fastcgi на mod_php не изменится вообще ничего.

но в то же время у кого-то другого может быть все наоборот - очень легкие скрипты и очень много траффика. те возможно и заметят даже на глаз переход на mod_php... все может быть.

мое мнение, что если есть что-то более быстрое, то нужно только его и использовать независимо от того какие сайты, быстрые/тормознутые, с траффиком/без.

от apache-itk отказался несколько лет назад в пользу независимых процессов apache/mod_php под каждого пользователя (а с недавнего времени и с mysql так же сделано).

плюсы очевидны - вся память и кэши принадлежат пользователю и не вытесняются другими, в случае каких-то падений/зависаний у одного, это вообще не влияет на других.

из минусов пожалуй лишь очевидно больший расход памяти, но то такое... докупное :)

и кстати спор fastcgi vs. mod_php можно спроэцировать и дальше.

например mysql локальный через сокет или удаленный по сети.

дисковое хранилище локальное или удаленное.

тоже, одни будут с пеной у рта доказывать что это медленно, а у других могут быть свои весомые причины использовать тот более медленный вариант.

но правда всегда одна - чем короче путь, тем быстрее он проходится. заметно/незаметно - это уже зависит от конкретного применения.

Не расскажете про реализацию такого поведения по MySQL в двух словах? :)

Неужели это просто запуск нескольких MySQL-серверов от разных пользователей? Звучит очень прожорливо.

Если в двух словах, то да - именно запуск нескольких демонов от разных пользователей.

И да, любителям по 1000 юзеров пихать на сервер врядли подойдет т.к. памяти потребуется сильно больше. А для около-vip тарифов почему нет?

Но у меня к примеру на самом загруженном сервере нет и сотни аккаунтов. Несколько месяцев назад решил попробовать в качестве эксперимента.

Особо минусов не замечено и сейчас так сделано на всех серверах, даже на самых дешевых тарифах - все отлично.

Плюсы очевидны - выбор версий. Хош mysql, хош mariadb любой версии - не проблема.

Персональные my.cnf (как и php.ini у персональных апачей) у каждого. Правда конечно никто из клиентов всеми преимуществами пока не пользуется 😐 А ведь можно например если только innodb используются, то больше памяти ей отдать, урезать myisam или наоборот, вкл/выкл/настроить кэширование и т.д. При желании можно под свои сайты подтюнить свою mysql, чего на обычных шаредах конечно невозможно сделать. А главное, соседские более посещаемые сайты не вытесняют менее посещаемые из памяти. Даже если у сайта 3 захода в неделю, то вовсе не обязательно чтоб каждый был "холодным стартом", все должны работать максимально быстро. Ну и какие-то проблемы/падения одной чьей-то mysql вообще не повлияют на других. Сейчас везде ведь как, кому нужны эти преимущества, тем приходится переходить на vps, а там уже выше цена... за меньшее количество ядер процессора, и другие минусы.

Еще хотел было реализовать одну уникальную фичу - доступ к mysql без авторизации. Это в теории дало бы еще каплю ускорения если убрать проверку логин/пароля при каждом запросе.

С персональными mysql это сделать не проблема, но возникает повышенное требование к сознательности пользователей. К примеру закинет он себе adminer.php в корень или phpmyadmin/ и без авторизации это прямо дырища в безопасности. Но может позже еще и реализую опцию типа вкл/выкл авторизации и жирное красное предупреждение о возможных последствиях если будут в открытом доступе на сайте какие-то инструменты управления базами. Если не этот нюанс, то используя обычные cms проблем с mysql без авторизации вроде быть не должно. Наоборот только небольшой плюс к производительности и к примеру можно не париться если  вдруг wp-config.php уведут (нормально же сделать архив сайта и просто скинуть его в корень или другое общедоступное место, да? 😀). Паролем этим просто ну никак не удастся воспользоваться, или вообще там можно будет вписать любой набор букв.

Знакомо, вот мы дали клиентам возможность менять настройки php.ini, но из преимущества многие превращают это в недостаток :)

В итоге в конфигах постоянно видим что-то наподобие memory_limit=9999M, подключение модулей, которые вообще не нужны их скриптам. Наоборот специально выносим модули в отдельные библиотеки, чтобы PHP работал быстрее. К примеру, Ioncube Loader или Zend Guard Loader, кто-то из них жестко режет производительность, уж не помню кто, даже если не использовать зашифрованные ими скрипты.

Но рядовой клиент просто подключает все модули и ставит лимиты памяти на полную, не осознавая что действует во вред своим сайтам. Процесс персонального сервера все равно будет убит OOMKiller'ом при выходе за пределы квоты памяти, руководствуясь лимитами политики CGROUPS.

В случае адекватного memory_limit, была бы запись в логах, можно было бы найти прожорливый скрипт и все такое, а вот когда убивает OOMKiller, то ищи виновника как иголку в стоге сена. :)

Я может чего-то не понимаю, но как можно обойти механизм авторизации MySQL? Мы можем создать файл .my.cnf с паролем, но это не обход механизма авторизации, просто вызов CLI mysql автоматически считает файл и попытается авторизоваться. Также можно воспользоваться плагином auth_socket или unix_socket (?), но это опять таки не обходит механизм авторизации, а делает возможность авторизоваться без пароля :)

Ну про злоупотребления - это скорей редкость, чем постоянно так происходит. И да, ограничить память можно уровнем выше, пусть хоть сколько угодно ставят memory_limit.

В любом случае, всем же не навязываю, у вас своя политика, у меня своя - чем меньше ограничений, тем лучше для конечного клиента. А с теми редкими случаями нагления лучше решать вопрос индивидуально, чем из-за них резать все подряд всем.

Да, auth_socket и по-сути да, авторизация конечно никуда не пропадает, а просто чуть упрощается. И да... возможно насчет какого-то ускорения это я загнул 😀

Просто была мысль попробовать, но застопорилось на проблеме скриптов типа phpmyadmin в открытом доступе.

Основная идея скорей была в упрощении. Т.е. добавляя новую базу, нужно бы было от пользователя только имя базы и все. Момент с логин/паролями вообще упразднить. И чтоб в скриптах своих логин/пароли на базу они могли использовать любые. К примеру перенес с другого хоста и сразу заработало, без правки конфигов.

Суть в том, что если что-то (например php скрипт) уже запущен от имени какого-то пользователя, то смысла еще авторизоваться по паролю к mysql нет никакого. Если это скрипт злоумышленника, то также не составит труда этим скриптом открыть любой файл конфига и там взять этот пароль.

Авторизация нужна если доступ к сокету mysql есть у всех (в случае одной общей mysql например) или, что еще хуже, mysql открыта портом в интернет.

А когда у нас все заперто в рамках одного пользователя (mysql, apache/php, все файлы), то эта доп. авторизация mysql вообще не несет ценности. Самое главное это не запускать опасный код из под себя. А если уж запустил, то все... никакая авторизация не спасет.