Estoy de acuerdo con GBN y Marian.
Para responder a su pregunta con respecto a las 2 CPU que manejan 25 solicitudes: Tengo un sistema de 2 CPU que admite alrededor de 750 conexiones de usuario y un promedio de solicitudes de lotes de 4K por segundo. Varios elementos son importantes para mí: diseño, administración y ajuste. Si comienza con un diseño deficiente de su aplicación y base de datos, fallará en la carga (piense en la escala).
CPU alta puede indicar presión de memoria. Menciona que solo hay 7 GB de memoria disponibles para SQL Server. Si tiene índices de bajo rendimiento (demasiados índices, índices incorrectos o ningún índice), esto hará que el sistema coloque más páginas de la base de datos en la memoria para varias solicitudes, si hay índices apropiados. Advierto que volverse loco creando índices, ya que los incorrectos también lo perjudicarán, ya que cada uno tiene el potencial de requerir una actualización en el curso de una operación de actualización de fila (Crear-Actualizar-Eliminar).
Además, el uso de los DMV de índice perdido requiere el uso de lo que sabe de su aplicación y base de datos y no solo la implementación de cada índice recomendado. Verificaría las entradas del blog de Kimberly Tripp con respecto a los índices aquí . Después de la sección Índice, mirar las otras categorías puede ser útil para su situación.
Si su actualización de Java / Hibernate de 5 tablas en una sola transacción está haciendo las actualizaciones a través de múltiples viajes de ida y vuelta a la base de datos, entonces se está quedando abierto a la contienda (solicitudes CRUD bloqueadas). El problema empeora si la aplicación no puede regresar a la base de datos de manera oportuna. Mientras está en la aplicación, la transacción activa asociada podría bloquear el procesamiento de otras solicitudes y causar tiempos de espera de solicitudes.
Agregue los dos problemas anteriores juntos y comenzará a tener un desagradable caso de dolores de cabeza por rendimiento.
Reducir la cantidad de viajes de ida y vuelta de la base de datos dentro del contexto de una sola transacción sería algo muy bueno. Quizás un procedimiento almacenado ayudaría.
El resto requerirá trabajo para poder escalar su aplicación. También puede considerar la memoria, pero eso debería ocurrir después de que se realice una revisión de diseño y rendimiento y se implementen los cambios necesarios, ya que agregar memoria de inmediato enmascarará sus problemas.
Siga absolutamente las sugerencias que Marian ha esbozado.
¡Diría que te has encontrado un desafío maravilloso y te deseo un gran éxito!
