我在用Django（Python）构build的SaaS应用程序中工作，并使用Apache / mod_wsgi运行。
注册站点创build一个Apache虚拟主机configuration，wsgi和设置文件。 最后重新启动Apache服务器。
这意味着，每当新用户注册一个帐户apache重新启动，这会影响当前客户端的应用程序的性能。
一个可能的select是为新客户端创build一个单独的apache实例，这将增加所有客户端所需的RAM太多。
你有什么build议呢？
几个实例的副作用是它们都不能在同一个端口上运行。
也许你的脚本可以做一个“apachectl configtest”，以确保configuration是有效的（有助于防止由于configuration错误而不能启动）。
然后运行apachectl优雅。
apachectl graceful ：通过发送一个SIGUSR1，很好的重启Apache守护进程。 如果守护进程没有运行，则启动它。 这与正常重启的不同之处在于当前打开的连接不会中止。 副作用是旧的日志文件不会立即closures。 这意味着如果在日志轮转脚本中使用，则可能需要大量的延迟才能确保在处理旧日志文件之前closures旧日志文件。 这个命令在启动重启之前通过configtest自动检查configuration文件，以确保Apache不会死机。
apachectl configtest ：运行configuration文件语法testing。 它分析configuration文件，并报告语法Ok或有关特定语法错误的详细信息。
这可能是矫枉过正，但我有一个狡猾的计划。 🙂
设置一个iptables规则，例如：
iptables -t nat -i PREROUTING -m tcp -p tcp --dport 80 -j DNAT --to-destination :81 让Apache在端口81上运行。端口80的传入连接将被redirect到端口81。
现在，当你得到一个新的configuration时，把它保存到一个单独的位置，让它监听端口82.现在你可以尝试启动第二个Apache实例。 如果启动失败，则说明存在configuration问题，可以继续使用旧configuration运行，直到解决问题。
如果它启动，则将上面的iptables规则replace为指向端口82的iptables规则。现有连接将继续到旧端口，直到它们完成。 给他们一些宽限期，然后closures旧的实例。 通过这种方式，您可以启动一个全新的实例并closures旧的实例，但不会中断用户。 然后你可以用下一个configuration回到81端口。
apachectl优雅可能是你想要的，但如果它不适合你，这可能是另一种select。
你会发现，使用Apache / mod_wsgi，它是版本locking到Django的版本。 所以，如果你有mod_wsgi2的Python 2代码，如果你还有Python 3的代码，那么你必须有一个单独的httpd实例和mod_wsgi3。
我不知道这场比赛有多好，但是我想我已经被告知希望在我们完成从2到3，然后3。 添加到其他模块与其他中间件相同的模块冲突，该框当前有三个httpd实例。
希望你的网站是多余的，你可以一次重新启动一边。 您应该使用反向代理在站点之间进行多路复用，或许使用类似mod_cluster的httpd。
那mod_wsgi里面的进程空间呢？ 如果两个客户端由相同的httpd实例pipe理，它们是否以安全的方式相互隔离？
如果我有select的话，我会试着用FastCGI部署….我认为Django可以做到这一点（用gunicorn？），但是从我们看了一段时间以后，我不是那个正在做的。
希望有所帮助。