Подтвердить что ты не робот

Как оптимизировать Tomcat для подачи

У нас есть мобильное приложение, которое представляет фид для пользователей. API REST канала реализуется на tomcat, который параллельно делает обращения к различным источникам данных, таким как Couchbase, MYSQL, для представления контента. Простой код приведен ниже:

Future<List<CardDTO>> pnrFuture = null;
Future<List<CardDTO>> newsFuture = null;

ExecutionContext ec = ExecutionContexts.fromExecutorService(executor);

final List<CardDTO> combinedDTOs = new ArrayList<CardDTO>();

// Array list of futures 
List<Future<List<CardDTO>>> futures = new ArrayList<Future<List<CardDTO>>>();

futures.add(future(new PNRFuture(pnrService, userId), ec)); 
futures.add(future(new NewsFuture(newsService, userId), ec)); 
futures.add(future(new SettingsFuture(userPreferenceManager, userId), ec)); 

Future<Iterable<List<CardDTO>>> futuresSequence = sequence(futures, ec); 

// combine the cards 
Future<List<CardDTO>> futureSum =  futuresSequence.map( 
        new Mapper<Iterable<List<CardDTO>>, List<CardDTO>>() {
            @Override 
            public List<CardDTO> apply(Iterable<List<CardDTO>> allDTOs) { 
                for (List<CardDTO> cardDTOs : allDTOs) {
                    if (cardDTOs != null) {
                        combinedDTOs.addAll(cardDTOs);
                    } 
                } 

                Collections.sort(combinedDTOs);
                return combinedDTOs;
            } 
        } 
); 

Await.result(futureSum, Duration.Inf());  
return combinedDTOs; 

Сейчас у нас есть около 4-5 параллельных задач для каждого запроса. Но ожидается, что он достигнет почти 20-25 параллельных задач, поскольку мы вводим новые виды товаров в фид.

Мой вопрос: как я могу улучшить этот дизайн? Какая настройка требуется в Tomcat, чтобы обеспечить оптимальное 20-25 параллельных вызовов при большой нагрузке.

Я понимаю, что это широкая тема, но любые предложения были бы очень полезными.

4b9b3361

Ответ 1

Я понимаю, что вы вызываете это из мобильного приложения, и количество каналов может увеличиться.

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

Как было предложено nickebbit, такие вещи, как DefferedResult, очень легко реализовать. возможно ли, что данные из этих фидов не будут обновляться быстро? Если это так - вам следует исследовать использование EHCache и аннотации @Cacheable.

Вы можете найти решение, в котором пользователь всегда вытаскивает кешированную версию вашего контента с вашего сервера tomcat. Но ваш tomcat-сервер постоянно обновляет этот кеш в фоновом режиме.

Это дополнительная работа - но в конце дня, если пользователь не работает быстро - пользователи не захотят использовать это приложение

Ответ 2

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

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

Никакая конфигурация tomcat не поможет с тем, что вы представили в своем вопросе.

Ответ 3

Похоже, что вы используете Akka, но на самом деле не обнимаете модель Actor, так что это, скорее всего, увеличит parallelism и, следовательно, масштабируемость вашего приложения.

Если бы это был я, я бы отложил запросы от моего REST API до одного или пула координирующих участников, которые будут обрабатывать запрос асинхронно. Используя Spring RestController, это можно сделать с помощью Callable или DeferredResult, но, очевидно, будет эквивалент в любой используемой структуре.

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

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