Как ограничить количество открытых сокетов в Spring-webflux WebClient? - PullRequest
Новая
       75

Как ограничить количество открытых сокетов в Spring-webflux WebClient?

0 голосов
/ 02 сентября 2018

У меня есть RESTful-сервис, и у меня была идея подготовить простой тест производительности с Reactor и Spring WebClient. Бенчмарк просто создает N пользователей, а затем за каждый созданный пользовательский пост M голосует.

К сожалению, следующий код превышает максимально допустимое число открытых файлов на моем компьютере с Linux, равное 1024 (ulimit -n 1024). 

    RestService restService = ...
    int N_ITERATIONS = 100;
    int M_VOTES = 100;

    Flux.range(0, N_ITERATIONS)
            .parallel()
            .runOn(Schedulers.parallel())
            .flatMap(iteration -> restService.postUserRegistration(User.builder().build()))
            .flatMap(user -> Flux.range(0, M_VOTES)
                    .flatMap(vote -> restService.postUserVote(Vote.builder().build()))
                    .collectList()
                    .map(votes -> Tuple.of(user, votes))
            ).doOnNext(userVotes -> log.info("User: {} voted: {}", userVotes._1(), userVotes._2()))
            .sequential()
            .toIterable();

RestService реализован со стандартным WebClient от Spring Webflux.

Есть ли способ ограничить количество созданных сокетов на основе системного лимита?

StackTrace: 

Caused by: io.netty.channel.unix.Errors$NativeIoException: newSocketStream(..) failed: Too many open files
    at io.netty.channel.unix.Errors.newIOException(Errors.java:122) ~[netty-transport-native-unix-common-4.1.27.Final.jar:4.1.27.Final]
    ... 98 common frames omitted

1 Ответ

0 голосов
/ 02 сентября 2018

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

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

Во-вторых, вы оставляете конфигурацию параллелизма вплоть до планировщика. Вы должны знать, что есть вариант оператора flatMap, который позволяет вам контролировать, сколько Publisher может быть подписано и объединено параллельно: 

Flux<V> flatMap(
            Function<? super T,? extends Publisher<? extends V>> mapper,
            int concurrency)

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

...