Spring Boot y cientos de peticiones por segundo

Ya estaría satisfecho con >100/200, pero desconozco cómo abordar este tipo de problemas, especialmente cuando se tiene que seguir un orden estricto en cuanto al procesamiento de la petición (al 1ª en llegar - 1 X libre etc) y se dan escenarios de concurrencia elevada. No tiene por qué ser cada segundo, pero sí ser capaz de atender estas situaciones.

He probado varias soluciones y la que más garantías me da (pero con un rendimiento pobre) es buscar y servir los elementos disponibles en un método con la anotación Transactional e isolation=Serializable (utilizando un Lock Pessimistic Write en la consulta), pero a la mínima se degrada mucho el rendimiento (>8 peticiones) y se produce un cuello de botella.

En fin, habrá que seguir probando.

Vas a tener que tener procesos distribuidos, una maquina dudo te aguante eso

Y meterte en concurrencia distribuida es un dolor de cabeza, al menos las pase putas en la uni con esto.
En la vida real imagino que habrán soluciones más transparentes que usar tu mismo los algoritmos de concurrencia, como lamport

Os doy la razón es que es una mierda (no cuestiono la tecnología, al menos no con estas penosas pruebas). Acabo de probar ahora y lanzando 10 peticiones desde el JMeter comprando 1 elemento tarda sobre ₁₀ segundos en despachar todo. Es lamentable.

Controller:

@RequestMapping("/putavida")
public DeferredResult<List<Elemento>> cola(@RequestParam int comprados, @RequestParam String id_cliente, @RequestParam String tiempo_compra) 
{
 // ...
		DeferredResult<List<Elemento>> result= new DeferredResult<List<Elemento>>();
		elementoService.testBusquedaDev(comprados)

	return result;
}
}

Búsqueda y devolución:

@Async
@Transactional(isolation=Isolation.SERIALIZABLE)
public void testBusquedaDev()
{
		Instant start = Instant.now();
		List<Elemento> elementos = em.createQuery("SELECT e FROM Elemento e WHERE disponible=true AND precio=:precio ORDER BY c.id_elemento).setParameter("precio", precio).setLockMode(LockModeType.PESSIMISTIC_WRITE).setMaxResults(comprados).getResultList();

	elementos.forEach(action -> action.setDisponible(false));
// Devolvemos resultado 
		req.setResult(elementos);
		Instant finish = Instant.now();
		long timeElapsed = Duration.between(start, finish).toMillis();

}

El hardware de pruebas donde corre la aplicación no es gran cosa, pero no puedo creer que sea tan lamentable.

• Aplicación corriendo en W10 + 8GB RAM + i3 7100 CPU 3,9Ghz
• DB MariaDB en una VM Debian9 con 4GB y 2sock/2core. Tabla 500k registros (distinta máquina a la mía)

PESSIMISTIC_WRITE en un Select ? why ?

No entiendo muy bien que quieres conseguir, 100-200 request/s en qué llamada ?

En comprar entrada ?
En ver disponibles ?

Depende mucho del negocio/dominio vaya...

Si lo que quieres es "ver disponibles", puedes tenerlo cacheado si es una sala, de forma que actualizas la cache por cada compra (redis o similar), si solo es 1 server, incluso en memoria.

Tu mayor problema aquí, es que quieres procesar los requests en orden de llegada por tiesmtamp y no hay nada que te solucione esto, porque es muy complicado garantizar esto, y que vaya en real time.

Si tienes 1 solo server, sincronizas en memoria, si quieres tener 2 o más servers, tendrías que meter todo en un sitio, e ir ordenandolo, por ejemplo:

A las 10:37 procesas todo lo que falte por procesar hasta las 10:36 (hace un minuto), si algo llega con más de un minuto de retraso respecto a su timestamp, que se jodan. (Pero ahi ya no es un 100% guarantee).

Y tienes X servers que reciben las peticiones y las guarda, y un worker que las procesa (solo puedes tener 1 si quieres orden estricto) (cada minuto ordena lo que halla llegado con un ts < hace un minuto, lo ordena y lo procesa)

Si no permites paralelizar 2 llamadas, no tiene sentido tener más de 1 máquina procesando los comandos, pero puedes tener más de 1 recibiendo peticiones y guardandolas.

Pros:

• Aguantas los picos de peticiones sin problemas
• Order guaranteed
  Cons:
• Throughput limitado a 1 maquina, la cola puede crecer mucho (como las del super)
• La compra es asíncrona