Все что узнал из топика, это то что вы пишите биллинг, поздравляю, скриншот просто бомба.
Что узнал из телеграмм канала - это то, что биллинг пишется Артемом Майером (все таки имеете к нему отношение), у которого репутация "разработчика" скамов.
Сначала выпустите продукт, а потом рекламируйте его. Зачем эта тема? Зачем портить так репутацию будущего продукта? Вы хотите, чтобы к вам в чат зашли посетители с серча и увидели ололоканья, мемасы и матюки?
Есть такие люди, которые не знают что такое адресная строка в браузере, адрес сайта они забивают прямо в Яндекс. Не удивлюсь, если это случай ТС. Пропал сайт в поисковой системе - значит не работает 😈
К хостеру надо обращаться, а не на форумы. Обычно мелкие фирмы нанимают человека ответственного за сайт, потом этот человек пропадает, а владелец бизнеса не знает даже кому проплачивать и на каком хостинге находится сайт, как вариант происходящего здесь.
Персональные my.cnf (как и php.ini у персональных апачей) у каждого. Правда конечно никто из клиентов всеми преимуществами пока не пользуется 😐 А ведь можно например если только innodb используются, то больше памяти ей отдать, урезать myisam или наоборот, вкл/выкл/настроить кэширование и т.д.
Знакомо, вот мы дали клиентам возможность менять настройки php.ini, но из преимущества многие превращают это в недостаток :)
В итоге в конфигах постоянно видим что-то наподобие memory_limit=9999M, подключение модулей, которые вообще не нужны их скриптам. Наоборот специально выносим модули в отдельные библиотеки, чтобы PHP работал быстрее. К примеру, Ioncube Loader или Zend Guard Loader, кто-то из них жестко режет производительность, уж не помню кто, даже если не использовать зашифрованные ими скрипты.
Но рядовой клиент просто подключает все модули и ставит лимиты памяти на полную, не осознавая что действует во вред своим сайтам. Процесс персонального сервера все равно будет убит OOMKiller'ом при выходе за пределы квоты памяти, руководствуясь лимитами политики CGROUPS.
В случае адекватного memory_limit, была бы запись в логах, можно было бы найти прожорливый скрипт и все такое, а вот когда убивает OOMKiller, то ищи виновника как иголку в стоге сена. :)
Если не этот нюанс, то используя обычные cms проблем с mysql без авторизации вроде быть не должно. Наоборот только небольшой плюс к производительности и к примеру можно не париться если вдруг wp-config.php уведут
Я может чего-то не понимаю, но как можно обойти механизм авторизации MySQL? Мы можем создать файл .my.cnf с паролем, но это не обход механизма авторизации, просто вызов CLI mysql автоматически считает файл и попытается авторизоваться. Также можно воспользоваться плагином auth_socket или unix_socket (?), но это опять таки не обходит механизм авторизации, а делает возможность авторизоваться без пароля :)
от apache-itk отказался несколько лет назад в пользу независимых процессов apache/mod_php под каждого пользователя (а с недавнего времени и с mysql так же сделано).
Не расскажете про реализацию такого поведения по MySQL в двух словах? :)
Неужели это просто запуск нескольких MySQL-серверов от разных пользователей? Звучит очень прожорливо.
Хорошо, это так, с этим спорить не буду, возможно ошибся. Но я говорил о его ресурсоемкости и времени отклика. Сделайте замеры. ttfb будет меньше на 30-50% у сайтов на модуле apache и nginx+php-fpm, нежели у тех же сайтов в режиме fastcgi. В то же время использование ресурсов в последнем увеличено.
TTFB в режиме модуля Apache (используется mod_lsapi) - по пингу 68-70мс.
TTFB в режиме FastCGI (используется mod_fcgid) - также по пингу до сервера 68-70мс.
При тестировании в несколько потоков дают примерно одинаковые результаты.
Проблема топика в том, что одни здесь обсуждают работу самого FastCGI, а redeyer обсуждает ее работу в панельки, скорее всего на дефолтных настройках или испоганенных настройках :)
mod_fcgid форкает несколько php-cgi процессов, при нормальных настройках они спокойно живут и обрабатывают запросы, и помирают через определенное время. Но можно настроить через задницу и убить все преимущества mod_fcgid, сделать схему "один запрос => форк процесса php-cgi => выполнение скрипта => смерть" , тогда может и будет +30-50% TTFB за счет форка
Локер подойдет да, правда иногда бывают неточности с одновременными блокировками, но это не про ваш случай, с такой частотой вызовов вероятность мала.
Помню писал скрипт, к которому 20-30 человек обращаются практически одновременно, так как скрипт не в режиме демона, то на каждый запрос по процессу. Первые несколько запросов стабильно выполнялись одновременно. Решил проблему созданием локера-переменной в Memcached, отрабатывает в 100% случаев правильно (веду журналы). Будь это поточный демон, конечно бы использовал мьютексы.
Что касается темы разговора, очень важно чтобы скрипт вел журнал.
Напишите простой класс логгера, который просто будет записывать время и описывать событие, записывать значение переменных, которые у вас теряются, выделите самые важные места в программе и добавьте туда журналирование. Пожалуй, это самое первое с чего нужно начинать любую программу. Иначе можно годы гадать на кофейной гуще и приделывать костыли.
Если важна скорость в однопотоке, то берите сервер с Intel Xeon W-2255.
Актуально, например, для PHP под веб. Чем быстрее PHP-скрипт отработает и умрет, тем лучше. W-2255 за счет высокой частоты и турбобуста будет работать лучше в синглтреде, чем E5.
Так что нужно смотреть, нужны ли вам эти 40 относительно медленных потоков от E5.
Компания ТаймВэб пошла дальше и удалила все нелестные коментарии и заблокировала!!!
Правильно сделали, что удалили и заблокировали.
Прочитайте сколько оскорблений в ваших постах на скриншоте: криворукие, не мужчины.
Вы так с отцом своим поговорите, который воспитал в вас такого "мужчину" эмоционального.
Как я понимаю раз много слов proxy есть в конфиге :), значит он проксируется на Апач.
Да, все будет работать.
Будет при условии проксирования на Apache.
Просто покажите конфигурацию NGINX блок server { } , замените адрес сайта, если не хотите его здесь палить.
