Обслуживание одновременных запросов JAX-RS с помощью WebLogic 12.2.1

Я написал метод веб-службы JAX-RS для работы в WebLogic 12.2.1, чтобы проверить, сколько одновременных запросов он может обрабатывать. Я намеренно заставляю метод занять 5 минут.Обслуживание одновременных запросов JAX-RS с помощью WebLogic 12.2.1

@Singleton 
@Path("Services") 
@ApplicationPath("resources") 
public class Services extends Application { 
    private static int count = 0; 

    private static synchronized int addCount(int a) { 
     count = count + a; 
     return count; 
    } 

    @GET 
    @Path("Ping") 
    public Response ping(@Context HttpServletRequest request) { 
     int c = addCount(1); 
     logger.log(INFO, "Method entered, total running requests: [{0}]", c); 
     try { 
      Thread.sleep(300000); 
     } catch (InterruptedException exception) { 
     } 
     c = addCount(-1); 
     logger.log(INFO, "Exiting method, total running requests: [{0}]", c); 
     return Response.ok().build(); 
    } 
}

Я также написал автономную клиентскую программу для отправки 500 одновременных запросов на эту услугу. Клиент использует один поток для каждого запроса.

Из того, что я понимаю, WebLogic имеет по умолчанию максимум 400 потоков, что означает, что он может обрабатывать 400 запросов одновременно. Эта цифра подтверждается моим результатом теста ниже. Как вы можете видеть, в течение первых 5 минут, начиная с 10:46:31, было запрошено только 400 запросов.

23/08/2016 10:46:31.393 [132] [INFO] [Services.ping] - Method entered, total running requests: [1] 
23/08/2016 10:46:31.471 [204] [INFO] [Services.ping] - Method entered, total running requests: [2] 
23/08/2016 10:46:31.471 [66] [INFO] [Services.ping] - Method entered, total running requests: [3] 
23/08/2016 10:46:31.471 [210] [INFO] [Services.ping] - Method entered, total running requests: [4] 
23/08/2016 10:46:31.471 [206] [INFO] [Services.ping] - Method entered, total running requests: [5] 
23/08/2016 10:46:31.487 [207] [INFO] [Services.ping] - Method entered, total running requests: [6] 
23/08/2016 10:46:31.487 [211] [INFO] [Services.ping] - Method entered, total running requests: [7] 
23/08/2016 10:46:31.487 [267] [INFO] [Services.ping] - Method entered, total running requests: [8] 
23/08/2016 10:46:31.487 [131] [INFO] [Services.ping] - Method entered, total running requests: [9] 
23/08/2016 10:46:31.502 [65] [INFO] [Services.ping] - Method entered, total running requests: [10] 
23/08/2016 10:46:31.518 [265] [INFO] [Services.ping] - Method entered, total running requests: [11] 
23/08/2016 10:46:31.565 [266] [INFO] [Services.ping] - Method entered, total running requests: [12] 
23/08/2016 10:46:35.690 [215] [INFO] [Services.ping] - Method entered, total running requests: [13] 
23/08/2016 10:46:35.690 [269] [INFO] [Services.ping] - Method entered, total running requests: [14] 
23/08/2016 10:46:35.690 [268] [INFO] [Services.ping] - Method entered, total running requests: [15] 
23/08/2016 10:46:35.690 [214] [INFO] [Services.ping] - Method entered, total running requests: [16] 
23/08/2016 10:46:35.690 [80] [INFO] [Services.ping] - Method entered, total running requests: [17] 
23/08/2016 10:46:35.690 [79] [INFO] [Services.ping] - Method entered, total running requests: [18] 
23/08/2016 10:46:35.690 [152] [INFO] [Services.ping] - Method entered, total running requests: [19] 
23/08/2016 10:46:37.674 [158] [INFO] [Services.ping] - Method entered, total running requests: [20] 
23/08/2016 10:46:37.674 [155] [INFO] [Services.ping] - Method entered, total running requests: [21] 
23/08/2016 10:46:39.674 [163] [INFO] [Services.ping] - Method entered, total running requests: [22] 
23/08/2016 10:46:39.705 [165] [INFO] [Services.ping] - Method entered, total running requests: [23] 
23/08/2016 10:46:39.705 [82] [INFO] [Services.ping] - Method entered, total running requests: [24] 
23/08/2016 10:46:39.705 [166] [INFO] [Services.ping] - Method entered, total running requests: [25] 
23/08/2016 10:46:41.690 [84] [INFO] [Services.ping] - Method entered, total running requests: [26] 
23/08/2016 10:46:41.690 [160] [INFO] [Services.ping] - Method entered, total running requests: [27] 
23/08/2016 10:46:43.690 [226] [INFO] [Services.ping] - Method entered, total running requests: [28] 
23/08/2016 10:46:43.705 [162] [INFO] [Services.ping] - Method entered, total running requests: [29] 
.... 
.... 
23/08/2016 10:50:52.008 [445] [INFO] [Services.ping] - Method entered, total running requests: [398] 
23/08/2016 10:50:52.008 [446] [INFO] [Services.ping] - Method entered, total running requests: [399] 
23/08/2016 10:50:54.008 [447] [INFO] [Services.ping] - Method entered, total running requests: [400] 
23/08/2016 10:51:31.397 [132] [INFO] [Services.ping] - Exiting method, total running requests: [399] 
23/08/2016 10:51:31.475 [207] [INFO] [Services.ping] - Exiting method, total running requests: [398] 
23/08/2016 10:51:31.475 [207] [INFO] [Services.ping] - Method entered, total running requests: [399] 
.... 
....

Но то, что я не понимаю, как приходят первые 400 запросов не обслуживались в то же время с помощью метода обслуживания? Как видно из результатов теста, первый запрос обслуживался в 10: 46: 31,393, но 400-й запрос обслуживался в 10:50: 54.008, что более чем на 4 минуты позже.

Если мы посмотрим на access.log, мы увидим, что все 500 запросов были получены WebLogic между 10:46:31 и 10:46:35. Поэтому кажется, что даже несмотря на то, что WebLogic получил запросы с очень коротким периодом времени, он не выделяет поток и быстро вызывает быстрый метод службы.

10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:31 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
.... 
.... 
10.204.133.176 - - [23/Aug/2016:10:46:35 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:35 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:35 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0 
10.204.133.176 - - [23/Aug/2016:10:46:35 +0800] "GET /Test/Services/Ping HTTP/1.1" 200 0

EDITED

Добавлен менеджер работы определить минимум 400 потоков.

weblogic.xml

<wls:work-manager> 
    <wls:name>HighPriorityWorkManager</wls:name> 
    <wls:fair-share-request-class> 
     <wls:name>HighPriority</wls:name> 
     <wls:fair-share>100</wls:fair-share> 
    </wls:fair-share-request-class> 
    <wls:min-threads-constraint> 
     <wls:name>MinThreadsCount</wls:name> 
     <wls:count>400</wls:count> 
    </wls:min-threads-constraint> 
</wls:work-manager>

web.xml

 <init-param> 
     <param-name>wl-dispatch-policy</param-name> 
     <param-value>HighPriorityWorkManager</param-value> 
    </init-param>

источник

2016-08-23 user3573403

Вот как WebLogic весы threadpools (они "самонастройки"), она не запускается 400 Темы сразу , Это более медленное увеличение потоков для максимальной пропускной способности.

https://docs.oracle.com/cd/E24329_01/web.1211/e24432/self_tuned.htm#CNFGD113

источник

2016-08-23 06:18:13 Slettal

Когда я снова запустить мой тест, без перезагрузки сервера, результат все тот же. Можно ли одновременно обрабатывать первые 400 запросов? – user3573403

Вы можете увеличить размер мини-резьбы до 400, установив параметр run для сервера -Dweblogic.threadpool.MinPoolSize = 100, тогда потоки будут немедленно доступны (см. Здесь: https://blogs.oracle.com/muraliveligeti/ entry/why_we_should_not_try). Не уверен, что это все еще работает в 12c, но вам, возможно, придется определить нового рабочего менеджера – Slettal

Я добавил менеджера, чтобы определить минимум 400 потоков, как показано в моем правиле выше. Теперь, когда я закачиваю запросы, первые 400 запросов обслуживались почти в одно и то же время. 400-й запрос обслуживался через 3,3 секунды после первого запроса. Это большая разница с 4 минутами плюс это было замечено ранее. – user3573403

Обслуживание одновременных запросов JAX-RS с помощью WebLogic 12.2.1

ответ

Смежные вопросы