# #google-cloud-pubsub
Вопрос:
Я перехожу от push-подписки к pull-подпискам, и я прочитал документ от Google о параллелизме pubsub. В их примере Исполнитель использует Исполнителя для подписки на тему. Это настроено на 4 потока с значением по умолчанию 1 съемник (поэтому 2 съемника будут использовать 8 потоков). Когда я запускаю синхронизацию, я думаю, что клиент открывает потоковый запрос, который может оставаться открытым некоторое время (возможно). Мой вопрос в том, есть ли 1 исполнитель на подписку или есть исполнитель (и, следовательно, пул потоков) для всех подписок. У меня примерно 200 подписок, так что 4 потока по 200 звучит неправильно. Как же тогда приступить к настройке? Должен ли я просто начать с исполнителя с 10 потоками, обрабатывающими все подписки и loadtest? Если у кого-то есть опыт в этом, было бы неплохо услышать ваши мысли.
Комментарии:
1. Какой язык вы используете?
2. Я использую Java-клиент
3. Возможно, вы неправильно поняли потоковую часть. На подписчике реализуется потоковая обработка. Можете ли вы подробнее рассказать о своей архитектуре? Или вы имеете в виду, что у вас 200 подписчиков в одной подписке? Если это так, по умолчанию у вас есть 4 потока на подписчика, и он должен быть в состоянии обрабатывать обработку сообщений. Вы можете настроить потоки для каждого подписчика, если заметите, что в подписке много нераспакованных сообщений (это можно просмотреть в облачном мониторинге).
4. Итак, 100 тем с 2 подписчиками на тему. Мне интересно, используют ли подписчики ExecutorProvider или у каждого подписчика есть свой собственный исполнитель? Их пример был очень упрощенным с 1 темой и 1 подписчиком. Мне просто интересно узнать о количестве потоков.
5. Так что, возможно, мне не стоит беспокоиться. В этом примере говорится …»Предоставляет службу исполнителя для обработки сообщений. По умолчанию
executorProvider, используемое подписчиком, имеет количество потоков по умолчанию, равное 5. » Таким образом, каждый подписчик должен владеть по умолчанию 5 потоками. Итак, 200 подписчиков… похоже, что потоков много.
Ответ №1:
По умолчанию каждый экземпляр Subscriber имеет свой собственный executorProvider и systemExecutorProvider создает несколько потоков. По умолчанию для первого создается 5 потоков, а для последнего создаются max(6, parallelPullCount) потоки.
Можно переопределить это поведение, установив этих поставщиков с помощью методов Subscriber.Builder.setExecutorProvider and Subscriber.Builder.setSystemExecutorProvider . Вы могли бы предоставить им то же ExecutorProvider самое, например, a FixedExecutorProvider .
Однако, если вы намерены извлекать сообщения из 200 подписок в одном задании, вам может быть лучше использовать push-подписки, если вы можете. Вы бы настроили конечную точку https в своем задании и установили конечную точку push для всех 200 подписок на эту же конечную точку. Все сообщения могут обрабатываться через один и тот же кодовый путь, и у вас не будет накладных Subscriber расходов на экземпляр для каждого из них.