Make sure the REST API handles concurrent requests about fasten HOT 4 CLOSED

Consider using h2load or JMeter for load testing when most of the stuff is done.

from fasten.

@MihhailSokolov

With Spring's embedded Tomcat, it'll be possible with a simple server.tomcat.max-threads=20 in the server configuration file.

Done in 6d5a9a6

from fasten.

Our REST API only has GET endpoints, so we don't have to worry about data consistency.

As far as concurrency is concerned, I haven't found clear evidence that RESTeasy handles concurrent requests in separate threads. Moreover, the documentation suggests using asynchronous HTTP request processing in these cases:

The primary use case for Asynchronous HTTP is in the case where the client is polling the server for a delayed response. The usual example is an AJAX chat client where you want to push/pull from both the client and the server. These scenarios have the client blocking a long time on the server’s socket waiting for a new message.

I don't think this is our case though.

(in fact using asynchronous processing may actually hurt your performance in most common scenarios)

We can still come up with a stress test and compare our current implementation with a multithreaded one.
Practically, this could be achieved by running endpoints' logic into separate threads, so this:

Might turn into this (tested & working):

@GET
@Path("/{pkg}/{pkg_ver}/files")
@Produces(MediaType.APPLICATION_JSON)
public void getPackageFiles(@Suspended final AsyncResponse response,
                            @PathParam("pkg") String package_name,
                            @PathParam("pkg_ver") String package_version,
                            @DefaultValue("0")
                            @QueryParam("offset") short offset,
                            @DefaultValue(RestApplication.DEFAULT_PAGE_SIZE)
                            @QueryParam("limit") short limit) {
    new Thread(() -> {
        Response result = service.getPackageFiles(package_name, package_version, offset, limit);
        response.resume(result);
    }).start();
}

Our endpoints wouldn't be returning Response objects anymore, but clients would have to pass AsyncResponses as arguments.

from fasten.

@MihhailSokolov

With Spring's embedded Tomcat, it'll be possible with a simple server.tomcat.max-threads=20 in the server configuration file.

from fasten.