Решил использовать в новом проекте WebFlux, тк Play не понравился, и со спрингом знаком уже давно.
имеем контроллер с задачей сходить в базу и вернуть ответ.
@RestController
@RequestMapping(path = "/test", produces = { APPLICATION_JSON_UTF8_VALUE })
public class UserService {
private JdbcTemplate jdbcTemplate;
@Autowired
void setDataSource(DataSource dataSource) {
jdbcTemplate = new JdbcTemplate(dataSource);
}
@GetMapping(path = "test")
Mono<ResponseEntity<String>> test() {
return Mono.just(ok(jdbcTemplate.queryForObject("select pg_sleep(0.1)", String.class)));
}
@GetMapping(path = "test1")
Mono<ResponseEntity<String>> test1() {
return Mono
.defer(() -> Mono.just(ok(jdbcTemplate.queryForObject("select pg_sleep(0.1)", String.class))))
.publishOn(Schedulers.elastic());
}
@GetMapping(path = "test2")
Mono<ResponseEntity<String>> test2() {
return Mono
.fromCallable(() -> ok(jdbcTemplate.queryForObject("select pg_sleep(0.1)", String.class)))
.publishOn(Schedulers.elastic());
}
}
в различных мануалах предлагают блокирующий вызов оборачивать по методу «test1» или «test2».
проверил с помощью siege на локалхосте и получил странный результат.
siege -c 200 -b http://localhost:8080/test/test
Transaction rate: 38.32 trans/sec
siege -c 200 -b http://localhost:8080/test/test1
Transaction rate: 38.35 trans/sec
siege -c 200 -b http://localhost:8080/test/test2
Transaction rate: 98.02 trans/sec
не понятно почему метод «test1» так тормозит.
