Как сервер (например, сеть) управляет несколькими запросами/соединениями?

Question

Я прочитал, что у apache есть решение для создания нового потока для нового запроса, но у меня все еще есть некоторые вопросы.

Как возможно, что один сервер может управлять тысячами (даже соединение milion - зависит от приложения) одновременно?

От этого зависит CPU? ОЗУ? Пропускная способность?

Когда мы говорим «в одно и то же время» (или когда apache создает новый поток), мы имеем в виду, что эти соединения выполняются параллельно/одновременным? или они параллельны?

Или это зависит от самого сервера? например если сервер многоядерный, сервер может выполнять оба, даже параллельно (каждый поток в своем ядре), даже cuncurrent (несколько потоков в одном ядре одновременно).

Если я хочу обрабатывать тысячи соединений одновременно для одного веб-приложения, что мне нужно сделать? Купить больше пропускной способности? Invenst в CPU?

Я новичок в этом и некоторые хорошие объяснения были бы замечательными.

Я спрашиваю здесь, потому что я был так в посоветовали другой общины: https://serverfault.com/questions/807458/how-does-a-server-e-g-web-manage-multiple-request-connections?noredirect=1#comment1025357_807458

Answer 1

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

Следующая вещь, которую вы должны учитывать, заключается в том, что помимо использования потоков ЦП также необходимо выполнить IO: читать данные из базы данных, ждать на мьютексе, отправлять данные клиенту. Когда поток ожидает ввода-вывода, ему не нужен процессор, поэтому может выполняться другой поток. Поэтому полезно использовать больше потоков, чем доступные ядра ЦП. В этом случае потоки будут выполняться одновременно на нескольких ядрах.

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

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

Это зависит от процессора? ОЗУ? Пропускная способность?

Это зависит от вашей задачи. Вы должны профилировать свой фактический сервер и найти, где это узкое место. В highload нет универсальных решений.