Primero debe determinar qué hará el grupo si entra una solicitud y no hay conexión gratuita para atenderlo. ¿Lanza una excepción? ¿Regresar nulo? ¿Bloquear hasta que se devuelva otra conexión al grupo?
Una vez que sepa lo que sucederá cuando se exceda la capacidad, piense cómo podría tratar esto en el código de llamada, y en qué situaciones es aceptable que esto suceda. En algún momento, a medida que aumente el número de conexiones, tendrá que comenzar a rechazar el envío de algunas solicitudes, pero solo usted puede decidir cuál es ese punto. El punto real depende de muchos factores, incluyendo cosas tales como
- su inactividad actual y las tasas de solicitudes de ocupado
- la volatilidad de estas tasas (quieres más "espacio para respirar" si las tasas de saltar alrededor de un lote
- cualesquiera proyecciones futuras de aumento de capacidad en comparación con las mejoras de hardware y tiempo del desarrollador presupuestado para revisar este código (si planea actualizarlo en un par de meses, necesita menos sobrecarga que si estuviera destinado a seguir funcionando un par de años)
- cualquier garantía que su empresa tenga sobre la capacidad de procesamiento
- la capacidad de los clientes para comprender las solicitudes "intentar de nuevo más tarde", p. si sabes que es un script automatizado en el otro extremo que duerme durante un minuto en un 503 e intenta de nuevo, es mejor que un humano recibiendo un mensaje de "capacidad temporalmente excedida" y ambos son mucho mejores que un script por lotes que obtiene un 200 respuesta y simplemente se cierra con un error.
- la urgencia de las solicitudes: algunas solicitudes (mirar fotos de gatitos) pueden demorarse razonablemente, pero otras (órdenes de compra de acciones) pueden ser muy sensibles al tiempo.
Y así sucesivamente.
suerte de lo anterior que debe ser capaz de llegar a la cantidad de solicitudes que necesita para ser capaz de procesar simultáneamente (y si hay diferentes tipos de la solicitud, puede que tenga que tomar esto en preocupación también) . Luego, solo se trata de observar cómo las solicitudes entrantes adquieren y usan conexiones, razonamientos y perfiles hasta que descubra la cantidad de conexiones en el conjunto que se requiere para mantener su tasa de conexiones objetivo.
No olvide tener en cuenta cosas como subprocesos no solicitados (por ejemplo, grupos de trabajadores) obtener sus propias conexiones del mismo grupo (el grupo debe ser más grande), así como las solicitudes que solo tienen una conexión para una parte de su ejecución (pool puede ser más pequeño).
5 laks = 500,000, ¿sí? –
sí. gracias ... lo cambio a medio millón. – Shashi
Hola Shashi. Es posible que desee echar un vistazo a http://stackoverflow.com/questions/1208077/optimal-number-of-connections-in-connectionpool. –