Используя pconnect на нескольких базах данных в PHP на Apache2
Вы попробовали cloudfront или maxcdn
они будут всегда кэшировать Ваши данные в течение предварительно установленного промежутка времени, но можно вручную произвести чистку кэша или установить релевантный, истекает к содержанию для хранения кэшируемым в течение более низких промежутков времени
не кэшируя данные в граничных местоположениях нет абсолютно никакого преимущества в использовании cdn, потому что это на самом деле удваивает соединение наверху для пользователя, если cdn должен получить файл от Вашего сервера каждый раз также.
Прежде всего, вам действительно стоит внимательно рассмотреть этот дизайн. Лучшие практики проектирования баз данных - максимально избегать разделения данных на несколько баз данных. Конечно, есть исключения (например, если вам нужно разрешить клиентам / приложениям изменять их схему), но в целом масштабируемость в направлении подключения к нескольким базам данных плохая. Кроме того, кросс-запросы к базе данных сложно писать, они дороги и плохо поддерживаются во многих (большинстве?) Систем баз данных, что вынуждает вас выполнять большую работу, которую вместо этого может выполнять база данных в приложении. Ремонтопригодность - это кошмар, когда между базами данных и приложениями существует неразрывная связь.
Во-вторых, ваше объяснение немного неясно, но мне интересно, как вы используете свой бассейн? Обычно с prefork у вас есть несколько серверов, для уменьшения задержки. Пока сервер жив, постоянное соединение должно быть. pconnect на самом деле не пул, и не похоже на вас. Не могли бы вы привести более ясный пример?
В-третьих, вы можете исчерпать несколько ресурсов. Дескрипторы файлов могут вызвать проблему довольно рано, и наличие большого количества соединений от каждого рабочего будет потреблять память как в Apache, так и в базе данных. Кроме того, установка соединений будет дорогостоящей, даже с пулом соединений. Если вы не можете уменьшить количество используемых баз данных, вам, скорее всего, придется съесть расходы на использование connect вместо pconnect, чтобы уменьшить количество ресурсов, потраченных впустую из-за устаревших соединений с базами данных.
Если кто-нибудь пришел ко мне с дизайном требуя подключения к сотням баз данных от работника Apache, я бы отправил их прямо на чертежную доску. Слишком много вещей может пойти не так, как надо, с таким дизайном. Объедините базы данных или, если это невозможно, поместите средний уровень.
редактировать: Хорошо, теперь все прояснилось.
Это частично вопрос планирования мощности, и на него обычно невозможно дать хорошие ответы. Но проясним несколько моментов.
Как упоминалось ранее, у вас есть много жестких ограничений, с которыми вы можете столкнуться при попытке установить соединения со многими базами данных. Файловые дескрипторы и память (особенно разделяемая память), вероятно, станут вашими ранними ограничениями.
То, что вы делаете, на самом деле не является пулом соединений, поскольку постоянные соединения никогда не будут возвращены в пул. Это просто постоянные соединения, которые позволяют сэкономить на накладных расходах.
Мой подход, если я действительно абсолютно должен таким образом сегментировать базы данных (что я считаю ОЧЕНЬ плохим выбором дизайна), заключался бы в выделении процессов Apache для каждой базы данных. Таким образом я уменьшаю риск накопления слишком большого количества постоянных соединений в одном процессе. Насколько мне известно, это невозможно сделать без нескольких установок Apache2 и разделения запросов на основе FQDN. Альтернативные решения, которые я бы рассмотрел, - это съесть стоимость использования подключения и использовать кеширование, чтобы попытаться минимизировать количество обращений к БД, и проверить, не могу ли я отделить веб-приложение от беспорядка базы данных.
Is there a limit in apache2 in how many connections it can handle?
Yes, it's limited by its configuration parameters (MaxClients, MaxServers, KeepAlive, MaxRequestsPerChild etc) and by CPU/memory (with KeepAlive you can trade some of one for the other).
will it just grow in memory...?
Yes, the more connections the more threads and more memory used. Look at how much memory each Apache thread is using (20 - 30MB is typical) so you can have an idea of the maximum you can ave given the available RAM. If you disable unused modules you'll consume less memory per thread.
Optionally if memory is an issue you can look at using Nginx instead of Apache, since nginx consumes a (small) fixed amount of memory.
In any case typically the bottleneck won't be in the web server but in the database and disk I/O which are addressed with caching and database settings/code/schema optimization.
Ultimately this looks like a capacity planning question, and at the end the only way of knowing for sure if your system can handle a number of connections is to try and replicate the setup (or a representative part of it) in a test environment and benchmark it.