Разработка многопоточного клиента REST API

Question

Я работаю над программой, которая получает поисковые запросы по теме, выполняет API-вызовы для API New York Times для получения статей, связанных с этой темой, а затем для API Twitter для получения твитов с упоминанием статей и, наконец, обрабатываетрезультаты и возвращает его обратно.

Я должен сделать это многопоточным.Я думал об использовании ExecutorService с пулом потоков фиксированного размера.Таким образом, каждый входящий поисковый запрос будет обрабатываться отдельной веткой.Я также использую интерфейс Callable для отправки задач.Класс, который реализует Callable, выполняет обработку API (создание и получение запросов / ответов API).Наконец, результат затем выбирается Future и отображается в качестве вывода.Это происходит для каждого входящего запроса.

Имеет ли это смысл?Или есть лучший способ сделать это?

РЕДАКТИРОВАТЬ: я запускаю это на моем локальном компьютере, принимая данные из интерфейса командной строки.

Answer 1

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

Единственное, о чем нужно заботиться:

• не использовать synchronized
• очистка любых ThreadLocal переменных, которые вы используете

Answer 2

Я бы сконцентрировался на том, чтобы получить правильный рабочий процесс, а затем профилировать, чтобы увидеть узкие места, а затем попытаться выяснить, где параллелизм ( многопоточность! = Параллелизм или асинхронное выполнение ) может вам помочь.Насыщение вашего ЦП, сети или дискового ввода-вывода несколькими потоками выполнения не приведет к ускорению и обычно ухудшает производительность, особенно на многопоточных процессорах Intel.

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

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

Также, если вы используете это на линейке ноутбуков Core i7вы получите только 4 реальных потока (4 гиперпотока обычно ухудшают работу приложений с привязкой к процессору), а чрезмерная попытка заставить вещи происходить не по порядку, а затем их возврат обратно может не принести вам никакой реальной выгоды имного сложностей.На гораздо большем количестве основных серверов это может быть не так, а на ноутбуке многопоточность не принесет вам большой пользы.

"Выполнить параллелизм легко, правильно выполнить параллелизм это очень тяжело! " - перефразируя мой айкидо сэнсэй