Ищу учебники и информацию о распределении нагрузки между потоками - PullRequest
7 голосов
/ 28 февраля 2012

Я знаю, что термин «Балансировка нагрузки» может быть очень широким, но предмет, который я пытаюсь объяснить, более конкретен, и я не знаю правильной терминологии.То, что я создаю, представляет собой набор приложений сервера / клиента.Сервер должен иметь возможность обрабатывать огромные объемы передачи данных, а также клиентских подключений, поэтому я начал изучать многопоточность.

В сущности, я вижу три способа реализации любого вида потоков длясервер ...

  • Один поток обрабатывает все запросы (игнорирует назначение потока, если в нем зарегистрировано 500 клиентов)
  • Один поток на пользователя (что рискованно создавать 1 потокдля каждого из 500 клиентов)
  • Пул потоков, которые делят работу поровну для любого количества клиентов (что я ищу)

Третий - это то, что я хотел бынравится знать.Он состоит из такой настройки:

  • Максимум 250 потоков, работающих одновременно
  • 500 клиентов не будут создавать 500 потоков, но будут использовать 250
  • Очередьзапросы ожидают передачи в поток
  • Поток не привязан к клиенту, и наоборот
  • Сервер решает, в какой поток отправить запрос, основываясь на активности (loadбаланс)

В настоящее время я пока не ищу какой-либо код, но информацию о том, как работает такая установка, и желательно учебник для достижения этой цели в Delphi (XE2).Даже подходящего слова или имени для этой темы было бы достаточно, чтобы я мог самостоятельно выполнить поиск.

РЕДАКТИРОВАТЬ

Я счел необходимым объяснить немного одля чего это будет использоваться.Я буду транслировать как команды, так и изображения, будет установка с двумя сокетами, где есть один «Главный сокет команды» и другой «Дополнительный сокет потокового изображения».Поэтому на самом деле одно соединение - это 2 сокетных соединения.

Каждое соединение с главным сокетом сервера создает (или повторно использует) объект, представляющий все данные, необходимые для этого соединения, включая потоки, изображения, настройки и т. Д.каждое соединение с основным сокетом, потоковый сокет также подключен.Это не всегда потоковые изображения, но командный сокет всегда готов.

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

Ответы [ 3 ]

4 голосов
/ 28 февраля 2012

IOCP сервер. Это единственное высокопроизводительное решение. По сути, он асинхронный в пользовательском режиме ('перекрывающийся ввод-вывод в M $ -speak), пул потоков выдает вызовы WSARecv, WSASend, AcceptEx, а затем все ждут в очереди IOCP записей о завершении. Когда происходит что-то полезное, пул потоков ядра выполняет фактический ввод-вывод, а затем ставит в очередь записи завершения.

Вам нужен как минимум класс буфера и класс сокета (и, возможно, другие для высокопроизводительных классов - objectPool и pooledObject, чтобы вы могли создавать пулы сокетов и буферов).

3 голосов
/ 28 февраля 2012

500 потоков может не быть проблемой на компьютере серверного класса. Блокирующий поток TCP не делает много, пока ожидает ответа от сервера.

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

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

Чтобы обеспечить масштабируемость, напишите идею для нескольких серверов, и вы можете продолжать масштабирование, добавляя оборудование.

Может быть какая-то причина для ограничения количества фактических рабочих потоков, например ограничение конкуренции за блокировку в базе данных или что-то подобное, однако в целом вы распределяете работу путем добавления потоков и позволяете аппаратному обеспечению (ЦП, перенаправителю) , коммутатор, NAS и т. д.) планируйте загрузку.

2 голосов
/ 28 февраля 2012

Ваша реализация полностью связана с используемыми вами коммуникационными компонентами. Если вы используете Indy или что-то на основе Indy, это один поток на соединение - точка! Нет способа изменить это. Indy будет масштабироваться до 100-х соединений, но не до 1000-х. Ваша лучшая надежда на использование пулов потоков с вашими коммуникационными компонентами - IOCP, но здесь ваш выбор ограничен отсутствием сторонних компонентов. Я провел все исследования раньше, и вы можете увидеть мой вопрос по адресу stackoverflow.com / questions / 7150093 / scalable-delphi-tcp-server-реализация .

У меня есть полностью работающая распределенная среда разработки (многопоточность и связь), которая использовалась в производстве уже более 3 лет в более чем полудюжине отдельных систем и в основном охватывает все, что вы просили до сих пор. Код также можно найти в Интернете.

...