Прежде всего, ваш метод тестирования не может продемонстрировать пул соединений, так как для каждого вызова рождается клиент curl, а затем он умирает.Как мертвые люди не много говорят, мертвый процесс не может поддерживать соединение живым.
У вас есть клиенты, которые беспокоят ваш прокси-сервер.
Client ====== (A) =====> ProxyServer
Давайте назовем это соединение A. Вашепрокси-сервер ничего не делает, это просто понты.Красивый и трудолюбивый сервер настолько скромен, что прячется за ним.
Client ====== (A) =====> ProxyServer ====== (B) =====> WebServer
Здесь, если я не ошибаюсь, защищенное соединение - А, а не В, верно?
Повторение моего первогона вашем тесте вы создаете отдельного клиента для каждого запроса.Каждому клиенту нужно отдельное соединение.Связь - это то, что происходит между двумя сторонами.Одна сторона уходит, и соединение потеряно.
Хорошо, давайте сейчас забудем curl и вместе посмотрим, что мы действительно хотим сделать.
Мы хотим иметь SSL на A, и мы хотим, чтобы сторона AТрафик должен быть максимально быстрым.Для этой цели мы уже разделили сторону B, поэтому она не сделает A еще медленнее, верно?
Пул соединений?Нет такой вещи как пул соединений в A. Каждый клиент приходит и уходит, производя много шума.Единственное, что может помочь вам уменьшить этот шум, это «Keep-Alive», что означает, что соединение с клиентом a будет поддерживаться в течение некоторого короткого промежутка времени, чтобы тот же самый клиент мог запрашивать другие файлы, которые будуттребуется по этому запросу.Когда мы закончим, мы закончим.
Для соединений на B соединения будут объединены;но это не принесет вам никакой производительности, поскольку при настройке с одним сервером у вас не было этой части производства шума.
Как мы можем помочь этой системе работать быстрее?
Если эти два сервераМы находимся на той же машине, мы должны избавиться от сервера понты и продолжить наш трудолюбивый веб-сервер.Это добавляет много ненужной работы в систему.
Если это отдельные машины, то вы хорошо относитесь к веб-серверу, принимая по крайней мере нагрузку encyrption (для ssl) от этого бедного парня.Однако, вы можете быть еще лучше.
Если вы хотите продолжить работу с Apache, переключитесь на mpm_worker с mpm_prefork.В случае более 300 одновременных запросов это будет работать намного лучше.Я действительно понятия не имею о емкости вашего оборудования;но если обработка 300 запросов затруднена, я полагаю, что это небольшое изменение очень поможет вашей системе.
Если вы хотите иметь еще более легкую систему, рассмотрите nginx как альтернативу Apache. очень просто настроить для работы с PHP, и он будет иметь лучшую производительность.
Помимо внешней стороны, также рассмотрите возможность проверки сервера базы данных.Пул соединений будет иметь реальное значение здесь.Убедитесь, что ваша установка PHP настроена на повторное использование подключений к базе данных.
Кроме того, если вы размещаете статические файлы в той же системе, переместите их либо на другой веб-сервер, либо сделайте еще лучше, переместив статический файл.файлы в облачную систему с CDN, например AWS S3 + CloudFront или CloudFiles Rackspace .Даже без CloudFront S3 порадует вас.Решение Rackspace поставляется с Akamai!
Удаление статических файлов сделает ваш веб-сервер "о, что случилось, что это за тишина? Ооо, рай!"так как вы упомянули, что это веб-сайт, и на веб-страницах есть много статических файлов для каждой динамически генерируемой html-страницы.
Я надеюсь, что вы можете спасти беднягу от убийственной работы.