2013-06-21 3 views
2

У меня есть поле ввода для поиска на моем веб-сайте Java Spring, где пользователь может искать содержимое веб-сайта. Я хочу сохранить запросы, введенные пользователями, в мою базу данных MySQL асинхронно для функций автозаполнения. Я знаю, что могу использовать аннотацию @Async весной указания бассейна размером со следующим:Spring @Async save search

<task:annotation-driven executor="executor" /> 
<task:executor id="executor" pool-size="100"/> 

Вопрос:

  • Это хорошее решение для высокого трафика веб-сайт с более чем 10000 поиск в минуту? Принимая во внимание возможность исключения исключения исчерпания пула?
  • Есть ли лучшее решение?
+0

Сохранение поискового запроса и выборки для автозаполнения не представляет для меня тяжелой задачи (если вы правильно указали свою индексацию). Я не думаю, что использование исполнителя необходимо, я бы просто использовал простой DAO, подключенный к контроллеру – gerrytan

+0

Да, я использую SOLR для индексирования. Я вызываю QueryService.save в моем контроллере, после чего я вызываю QueryService.query для запроса SOLR. Я просто подумал, что QueryService.save может немного повлиять на производительность. Значит, я ошибаюсь? – hajime

+0

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

ответ

1

Посмотрите на ThreadPoolTaskExecutor. Когда все потоки в пуле заняты, ваше задание будет просто поставлено в очередь до тех пор, пока поток не будет доступен. Максимальная емкость очереди и количество потоков могут быть скорректированы с помощью свойства queueCapacity/maxPoolSize (queueCapacity по умолчанию INTEGER.MAX_VALUE).

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

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

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

Хороший подход - это просто угадать какое-то значение и настроить хороший контроль пула потоков/очереди/статистики и скорректировать его с течением времени.

+0

Я просто пытаюсь сохранить поисковые запросы, введенные пользователем. Сохранение всех запросов не имеет значения. Поэтому, если я установил размер пула на 100, и если что-то пойдет не так с пулом, возможно, я должен перезапустить пул. Может быть, каким-то образом сохранить весь существующий поток в списке и закрыть его, если что-то пойдет не так. Будет ли это хорошим решением, которое вы думаете? – hajime