Apache сервер медленно работает при высоком HTTP-вызове API

Похоже, проблема заторов.
Не имеет значения, насколько быстро обрабатывается ваш скрипт / страница, если следующий запрос выполняется в течение времени выполнения предыдущего:

Он собирается использовать ресурсы (процессор, оперативная память, диск, сетевой трафик и соединения).
И делайте все параллельно этому медленнее.

Есть несколько вещей, которые вы могли бы сделать, но вам нужно выяснить, в чем именно заключается проблема вашей настройки, и решить, дает ли мера желаемый результат.

Если основная проблема заключается в том, что ресурсы перегружены параллельными процессами, вы можете уменьшить лимиты подключения, чтобы больше подключений переходило в режим ожидания, который позволяет использовать больше ресурсов для фактической раздачи страницы, а не перегружать все.
Взгляните на это:
http://oxpedia.org/wiki/index.php?title=Tune_apache2_for_more_concurrent_connections

Если сервер принимает подключения быстрее, чем он может их обработать, у вас возникнет проблема, которую вы когда-либо измените. Он должен начать сбрасывать соединения в какой-то момент. Если вы будете прижимать французские багеты к горлу быстрее, тогда он может открыть рот, он задохнется в любом случае.

Если система перегружена сетевыми вещами (ограничение скорости передачи, максимально возможное количество одновременных подключений для ОС и т. Д. И т. Д.), То вам следует рассмотреть возможность использования балансировщика нагрузки. Только после того, как loadbalancer подтвердит, что сервер действительно может обработать запрос страницы, он отправит пользователя дальше.
Обычно это хорошо работает, когда вы выполняете любой вид обработки, который замедляет загрузку страницы (выполнение кода на стороне сервера, большие объемы данных и т. Д.).

Оптимизировать производительность
Есть много способов выполнить PHP-код на веб-сервере, и я предполагаю, что вы используете appache. Я не эксперт, но есть такие режимы, как CGI и FastCGI, например. Что может значительно повысить скорость выполнения. И настройки, связанные с ними, также могут показать вам, что происходит. Это может быть, например, то, что вы используете небольшое количество PHP-угроз для обработки этого количества одновременных соединений.

Посмотрите на что-то вроде этого, например
http://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/

Здесь нет лучшего решения для всех. Чтобы это исправить, вам нужно выяснить, что является узким местом для сервера. И действовать соответственно.

12000 звонков в минуту == 200 звонков в секунду.

Вы можете ограничить свой тестовый набор множеством этих 200 и увеличивать / уменьшать его при изменении настроек. Ваша цель состоит в том, чтобы заполнить это количество запросов за максимально короткий промежуток времени, таким образом гарантируя, что перегрузка никогда не произойдет.

Это сказало: последствия.

Когда вы собираетесь внести изменения, чтобы оптимизировать максимальное количество загрузок страниц, которое вы хотите достичь, вы непреднамеренно вводите другие условия. Например, если бы максимальное использование оперативной памяти Apache было бы проблемой, то увеличение этого предела обеспечит лучшую производительность, но повысит вероятность того, что ОС исчерпает память, когда другие процессы также захотят потребовать больше памяти.

Добавление балансировщика нагрузки добавляет еще один возможный уровень отказа и возможные замедления. Да, вы предотвращаете перегрузку, но стоит ли замедления, вызванного изменением маршрута?

Повышение производительности увеличит нагрузку на систему, что позволит принимать более параллельные соединения. Так что где-то вдоль линии появится другая горлышко бутылки. Большой трафик на разных процессах может всегда заканчиваться сбоем указанного процесса. Apache — очень хорошо построенный веб-сервер, поэтому в теории он должен защищать вас от указанной проблемы, однако неправильная настройка может привести к сбоям.

Так что экспериментируйте с осторожностью и тестируйте, прежде чем использовать его вживую.