TNonblockingServer, TThreadedServer и TThreadPoolServer, какой из них лучше подходит для моего случая?

Question

Наш аналитический сервер написан на c ++. Он в основном запрашивает базовый механизм хранения и возвращает довольно большие структурированные данные через экономию. Типичные запросы могут занять от 0,05 до 0,6 секунд, в зависимости от размера запроса.

Я заметил, что есть несколько вариантов того, какой сервер Thrift мы можем использовать в коде c ++, в частности TNonblockingServer, TThreadedServer и TThreadPoolServer. Похоже, что TNonblockingServer - это то, что нужно, поскольку он может поддерживать гораздо больше параллельных запросов и все еще использовать пул потоков за сценой для сокращения задач. Это также позволяет избежать затрат на строительство / разрушение нитей.

Обновление Facebook на комиссионных: http://www.facebook.com/note.php?note_id=16787213919

Здесь, в Facebook, мы работаем над полностью асинхронным клиентом и сервером для C ++. это сервер использует управляемый событиями ввод-вывод, как текущий TNonblockingServer, но его интерфейс код приложения основан на асинхронных обратных вызовах. Это позволит нам написать серверы, которые могут обслуживать тысячи одновременных запросов (каждый из которых требует совершать звонки на другие серверы Thrift или Memcache) с помощью нескольких потоков.

Похожие сообщения по стеку: Большое количество одновременных соединений в хозяйстве

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

Просто интересно, есть ли другие факторы, которые я здесь упускаю? Как мне решить, какой из них лучше всего соответствует моим потребностям?

Answer 1

Один парень на Github сделал хорошее сравнение

TThreadedServer

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

TNonblockingServer

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

TThreadPoolServer (здесь не тестируется)

TThreadPoolServer похож на TThreadedServer; каждое клиентское соединение получает свой собственный выделенный серверный поток. Он отличается от TThreadedServer двумя способами:

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

Answer 2

Запросы, которые выполняются за 50-600 миллисекунд, довольно длинные.Время, затрачиваемое на создание или уничтожение потока, намного меньше этого, поэтому не стоит учитывать этот фактор в своем решении.Я бы выбрал тот, который проще всего поддерживать и который менее подвержен ошибкам.Вы хотите минимизировать вероятность незначительных ошибок параллелизма.

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

Если нагрузка вашей транзакции увеличивается (т. Е. Больше клиентских транзакций) или запросы становятся быстрее обрабатыватьсяприближается к 1 миллисекунде на транзакцию), тогда издержки транзакции становятся более важным фактором.Метрика, на которую следует обратить внимание, - это пропускная способность: сколько транзакций выполняется за единицу времени.Абсолютная продолжительность одной транзакции менее важна, чем скорость, с которой они завершаются, по крайней мере, если она остается значительно ниже одной секунды.