Один экземпляр apache против нескольких экземпляров apache
Я работаю в SaaS-приложении, построенном на Django (Python) и работающем с Apache/mod_wsgi.
Сайт регистрации создает файлы конфигурации виртуального хоста apache, файлы wsgi и настройки. И, наконец, перезапускает сервер apache.
Это означает, что каждый раз, когда новый пользователь регистрирует учетную запись, перезапускается apache, и это влияет на производительность приложения для текущих клиентов.
Возможным вариантом является создание отдельного экземпляра apache для новых клиентов, однако это увеличит объем ОЗУ, необходимый для всех клиентов.
Какие у вас есть рекомендации по этому поводу?
3 ответа
Побочным эффектом нескольких экземпляров является то, что все они не могут работать на одном и том же порту.
Возможно, ваш сценарий может выполнить "apachectl configtest", чтобы сначала убедиться, что конфигурация действительна (что помогает предотвратить ее запуск из-за ошибки в конфигурации).
А затем запустить Apachectl изящно.
Изящный apachectl: Изящно перезапускает демон Apache, отправляя ему SIGUSR1. Если демон не запущен, он запускается. Это отличается от обычного перезапуска тем, что открытые в данный момент соединения не прерываются. Побочным эффектом является то, что старые файлы журнала не будут закрыты сразу. Это означает, что при использовании в сценарии ротации журналов может потребоваться существенная задержка, чтобы обеспечить закрытие старых файлов журналов перед их обработкой. Эта команда автоматически проверяет файлы конфигурации с помощью configtest перед началом перезапуска, чтобы убедиться, что Apache не умирает.
apachectl configtest: запустить синтаксический тест файла конфигурации. Он анализирует файлы конфигурации и сообщает о синтаксисе Ok или подробной информации о конкретной синтаксической ошибке.
Вы обнаружите, что с Apache/mod_wsgi, он привязан к версии Django. Поэтому, если у вас есть код Python 2 с mod_wsgi2, у вас должен быть отдельный экземпляр httpd с mod_wsgi3, если у вас также есть код Python 3.
Я не знаю, насколько хорошим должно быть совпадение, но я думаю, что мне сказали, что я ожидаю иметь еще один экземпляр Apache, как только мы закончим переход с 2 на 3, а затем на 3.next. Добавьте к этому и другим конфликтам модулей в том же блоке для некоторого другого промежуточного программного обеспечения, и этот блок в настоящее время имеет три экземпляра httpd.
Надеюсь, ваш сайт будет избыточным, и вы сможете перезапустить одну сторону за раз. Вы должны мультиплексировать между сайтами с обратным прокси, возможно httpd с чем-то вроде mod_cluster.
А как насчет пространства процессов внутри mod_wsgi? Защищены ли два клиента друг от друга безопасным образом, если ими управляет один и тот же экземпляр httpd?
Если бы у меня был выбор, я бы, возможно, развернул бы развертывание FastCGI.... Я думаю, что Django может сделать это (с помощью gunicorn?), Но прошло уже некоторое время с тех пор, как мы смотрели, и я не был тем, кто делал поиск,
Надеюсь, это поможет.
Это, вероятно, излишне, но у меня есть хитрый план.:-)
Установите правило iptables, например:
iptables -t nat -i PREROUTING -m tcp -p tcp --dport 80 -j DNAT --to-destination :81
Установите Apache на порт 81. Входящие соединения для порта 80 будут перенаправлены на порт 81.
Теперь, когда вы получите новую конфигурацию, сохраните ее в отдельном месте и прослушайте порт 82. Теперь вы можете попробовать запустить второй экземпляр Apache. Если он не запускается, вы знаете, что у вас есть проблема с конфигурацией, и вы можете продолжить работу со старой конфигурацией, пока она не будет решена.
Если он все-таки запустится, замените приведенное выше правило iptables указателем на порт 82. Существующие соединения будут продолжать идти к старому порту до тех пор, пока они не будут завершены. Дайте им некоторое время перед тем, как закрыть старый экземпляр. Таким образом, вы запускаете совершенно новый экземпляр и закрываете старый, но не прерываете пользователей. Затем вы можете сделать то же самое со следующей конфигурацией, возвращаясь к порту 81.
apachectl graceful, вероятно, то, что вы хотите, но если это не сработает для вас, это может быть другой вариант.