我在apache2服务器上预先运行PHP（MOD_PHP）。 该设置在Linux Ubuntu 10.04上。 我使用的数据库是一个火鸟数据库2.5.2。 apache2服务器运行在由8个Web服务器组成的Web群集中。
在某个时间点，由于对应用程序的请求（我们有偷看时间）的高峰，我们遇到了严重的性能问题。 显示的瓶颈是需要解决很短时间内发出的请求数量的数据库连接数量。 火鸟并没有很好地处理这个问题，只是要求超时。
这种types的数据库没有连接池，这就是为什么我一直使用PHP中的pconnect来缓解数据库中的压力。 这会在apache2进程中保持数据库连接。 这是一个主要的性能提升。 不利的一面是，我们不得不让apache2进程在被轮换之前需要很多请求，并且即使没有负载，我们仍然运行很多apache2进程。 Web服务器每个运行70个Apache进程。 这是为了保持连接的开放和准备。 基本上我们试图让apache2成为我们的连接池。 这工作。 当用户请求应用程序时，数据库句柄已准备就绪，Firebird不必担心创build新数据库连接的成本。
这是我的问题。 我们现在需要有很多数据库 – 小数据库。 但是他们都将在apache2服务器集群中运行。 这意味着，在apache2进程的生命周期中，它很可能与多个数据库（可能是80-100）保持连接。
我关心apache2如何处理这种情况。 apache2中有多less个连接可以处理？ 它会变慢吗？只会在记忆中增长，处理一切完美？
现在对数据库分片没有任何关系。 我们（作为开发团队）完全不喜欢分解数据库的想法。 但是，重写应用程序并没有绿灯，并创build一个新的数据库结构，以获得更多的代码性能。 硬件，现在是答案。 还有一些法律问题迫使我们分成几个数据库来封装数据。 但是这是我有点担心apache2能够处理。
有人知道吗？
首先，你应该仔细考虑这个devise。 数据库devise的最佳实践是尽可能避免在多个数据库中分割数据。 当然，也有例外情况（例如，如果您需要让客户/应用程序修改其架构），但通常在连接到多个数据库的方向上的可伸缩性是不好的。 另外，跨数据库查询在许多（大多数？）数据库系统中很难编写，昂贵且得不到很好的支持，迫使您做了很多工作，而这些工作可以由应用程序中的数据库完成。 当数据库和应用程序之间有N..N关系时，可维护性是一场噩梦。
其次，你的解释有点不清楚，但我想知道你如何使用你的游泳池..？ 通常prefork你周围几个服务器，以提高延迟。 只要服务器有效，持久连接也应该如此。 pconnect并不真正集合，听起来也不像你。 你能举一个更清晰的例子吗？
第三，有几个资源可以用完。 文件描述符可能很早就出现问题，并且每个工作者的许多连接都会占用Apache和数据库中的内存。 另外build立连接将是昂贵的，即使连接池。 如果您不能减less正在使用的数据库的数量，您将很可能不得不花费使用连接而不是pconnect的成本来减less过时数据库连接浪费的资源量。
如果有人来找我devise一个需要连接到Apache工作者的数百个数据库的devise，我会直接把它们发回到绘图板。 这样的devise有太多的东西可以和会出错。 合并数据库，如果不可能的话，放入一个中间层。
编辑：好的，现在事情更清楚了一点。
这部分是一个能力计划问题，而这些问题通常不可能提供很好的答案。 但是，要澄清几点。
如前所述，在尝试与许多数据库build立连接时，您可能遇到很多严格的限制。 文件描述符和内存（尤其是共享内存）很可能是您碰到的早期极限。
你在做什么不是真正的连接池，因为永久连接永远不会被返回到池中。 这只是持久连接，这可以节省一些开销。
我的方法，如果我真的必须以这种方式分割数据库（我认为这是一个非常糟糕的deviseselect）将是为每个数据库专用Apache进程。 这样我就减less了在一个过程中累积太多持久连接的风险。 据我所知，没有办法做到这一点，而不需要多次安装Apache2并根据FQDN拆分请求。 替代解决scheme我会考虑将吃掉使用连接和使用caching的成本，以尽量减less数据库命中，并检查是否无法分离Web应用程序从数据库混乱。
apache2中有多less个连接可以处理？
是的，它的configuration参数（MaxClients，MaxServers，KeepAlive，MaxRequestsPerChild等）和CPU /内存（KeepAlive可以交换其中一个）。
它会在内存中增长吗？
是的，线程越多，内存使用越多，连接越多。 看看每个Apache线程使用多less内存（20 – 30MB是典型的），所以你可以有一个想法，你可以有最大的可用内存。 如果禁用未使用的模块，则每个线程将消耗更less的内存。
可选地，如果内存是一个问题，你可以看看使用Nginx而不是Apache，因为nginx消耗一个（小）固定的内存量。
在任何情况下，通常瓶颈将不在Web服务器中，而是在数据库和磁盘I / O中，通过caching和数据库设置/代码/模式优化进行寻址。
最终，这看起来像是一个容量规划问题，最后，确定系统是否可以处理大量连接的唯一方法是在testing环境和基准testing中复制设置（或其代表部分）它。