Параллельные соединения с базой данных в отношении веб-запросов (http) и масштабируемости

Question

Одно соединение с базой данных равно одному веб-запросу (если, конечно, ваш клиент читает базу данных при каждом запросе). Используя пул соединений, эти соединения создаются заранее, но они по-прежнему используются по одному на запрос.

Теперь перейдем к некоторым цифрам - если вы поищите в Google «одновременные соединения Tomcat» или «Параллельные соединения Apache», вы увидите, что они без проблем поддерживают 16000 - 20000 одновременные соединения.

С другой стороны, лучшие практики администратора MySQL говорят, что максимальное число одновременных подключений к базе данных составляет 4096 .

При быстром поиске я не смог найти никакой информации о PostgreSQL.

Q1 : существует ли программный предел для одновременных подключений в PostgreSQL, и он действительно является MySQL 4096

Q2. Я что-то пропустил, или MySQL (или любой дБ, устанавливающий ограничение максимального числа одновременных соединений) будет выглядеть как узкое место, если оборудование и ОС допускают большое количество одновременных соединений?

Обновление: Q3 насколько именно большее число соединений отрицательно влияет на производительность?

Answer 1

Q1: вы устанавливаете параметр конфигурации max_connections. Его значение может быть намного выше 4096, но вам определенно рекомендуется держать его намного ниже, чем это по причинам производительности.

Q2: вам обычно не нужно столько подключений, и все будет намного быстрее, если вы ограничите число одновременных запросов в вашей базе данных. Вы можете использовать что-то вроде pgbouncer в режиме транзакций, чтобы чередовать много транзакций по меньшему количеству соединений.

Answer 2

Q2: на вашем веб-сайте может быть гораздо больше пользователей, чем подключений к вашей базе данных, поскольку каждый пользователь не держит соединение открытым. Пользователи требуют подключения только часто и только на короткое время. Ваш пул подключений к веб-приложениям, как правило, будет намного меньше, чем предел 4096.

Подумайте о ресторанной аналогии. Ресторан может иметь 100 клиентов (пользователей), но только 5 официантов (соединений). Это работает, потому что клиенты время от времени требуют официанта только на короткое время.

Время, когда все идет не так, когда все 100 клиентов поднимают руку и говорят «проверьте, пожалуйста», или когда все 16 000 пользователей нажимают кнопку «Отправить заказ» одновременно.

Answer 3

Пример исследования в Википедии

• 30 000 HTTP-запросов / с в пиковое время
• 3 Гбит / с трафика данных
• 3 дата-центра: Тампа, Амстердам, Сеул
• 350 серверов, от 1x P4 до 2x Xeon Quad-Core, 0,5-16 ГБ памяти
• ... под управлением ~ 6 человек

Это немного не по теме ваших вопросов.Но я думаю, что вы могли бы найти это полезным.Вы не всегда пинаете БД за каждый запрос.Правильная стратегия кэширования - почти всегда лучшее улучшение производительности, которое вы можете применить к своему веб-приложению.много статического контента может оставаться в кеше, пока он явно не изменится. Вот как это делает Википедия .

Answer 4

По ссылке, предоставленной вами на "Лучшие практики администратора MySQL"

"Примечание: соединения занимают память, и ваша ОС может не справиться с большим количеством соединений. Двоичные файлы MySQL для Linux / x86 позволяют иметь до 4096 одновременных соединений, но у самоскомпилированных двоичных файлов часто меньше ограничения. «

Так что 4096 кажется текущим максимумом. Помните, что для каждого сервера установлено ограничение, и вы можете иметь несколько подчиненных серверов, которые можно использовать для обслуживания запросов.

http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-scaleout.html