Cantidad razonable de subprocesos para el grupo de subprocesos que ejecuta solicitudes de servicio web

Question

Al crear un objeto Ejecutor FixedThreadPool en Java, debe pasar un argumento que describa el número de subprocesos que el Ejecutor puede ejecutar simultáneamente. Estoy creando una clase de servicio que es responsabilidad de procesar una gran colección de números de teléfono. Para cada número de teléfono necesito ejecutar el servicio web (ese es mi cuello de botella) y luego guardar la respuesta en un hashmap.

Para que este cuello de botella sea menos nocivo para el rendimiento de mi servicio, he decidido crear una clase Worker que recupere elementos no procesados ​​y los procese. La clase trabajadora implementa la interfaz Runnable y yo ejecuto Workers using Executor.

El número de Trabajadores que se pueden ejecutar en el mismo tiempo depende del tamaño de Executor FixedThreadPool. ¿Cuál es el tamaño seguro para un ThreadPool? ¿Qué puede pasar cuando creo FixedTheradPool con un gran número como argumento?

Answer 1

Si cada subproceso de trabajo necesita realizar una llamada de servicio web, la cantidad de subprocesos de su grupo de servidores debe verse fuertemente influenciada por la cantidad de solicitudes simultáneas que puede realizar su servicio web. Cualquier hilo más que eso no hará más que abrumar al servicio web.

Answer 2

He leído en alguna parte que el número óptimo de hilos es el número de núcleos * 25. Parece que .NET usa esto como predeterminado para ThreadPool. Sin embargo, si tiene un gran número de llamadas al servicio web, es mejor utilizar un solo hilo y consultar una lista de llamadas al servicio web para obtener una respuesta. Cuando la respuesta ha llegado solo procesa la entrada y elimínala de la lista.

Answer 3

Si tiene acceso de desarrollador para el servicio web, considere crear una función por lotes para verificar varios números de teléfono en una llamada.

En el .NET más nuevo existe un ThreadPool que puede crecer y reducirse en función de su propio perfil de rendimiento. Desafortunadamente, la versión de Java es Fixed o crece hasta un límite basado en el trabajo entrante.

Tuvimos una vez preocupaciones similares. Nuestra solución fue permitir al cliente ajustar el tamaño de la agrupación y ajustar el rendimiento a su antojo.

Puede haber algunas propiedades de red y datos consideradas para el tamaño del grupo de operaciones de E/S: ancho de banda de red, tamaños de mensaje, tiempo de proceso y estilo del servicio web, número de núcleos locales.

Answer 4

Si cada cómputo es equivalente a una llamada a un servicio web, entonces debe considerar cuánta carga está poniendo en ese servicio/cuántas conexiones concurrentes tolerará ese servicio o lo permitirían los propietarios de los servicios. La mayoría de los servicios de acceso público esperarían solo una de esas conexiones de un solo usuario a la vez. Si es posible, comuníquese con los propietarios de los servicios para conocer sus políticas de uso. El número de tales conexiones determinará la cantidad de hilos que puede usar.

Answer 5

No olvide que cada hilo que cree también exigirá memoria para su tamaño de pila. Por lo tanto, la creación de un grupo de subprocesos afectará la huella de memoria de su proceso (tenga en cuenta que algunos grupos no crean los subprocesos hasta que realmente se necesiten, por lo que al inicio no verá ningún aumento de memoria).

Este tamaño de pila se puede configurar a través de -Xss (similar a -Xmx etc.). Creo que el valor predeterminado es de 512 Kb por hilo. Por el momento no puedo encontrar ninguna autoridad para confirmar eso.

Answer 6

Me pregunto si sería mejor utilizar NIO en lugar de hilos, ya que su factor limitante será servidor de servicios web + cuello de botella de red, no CPU del cliente.

De lo contrario, como máximo, no debe exceder el número de conexiones simultáneas que su servicio web puede admitir.

Answer 7

Si está realizando cálculos pesados, digamos que para manipulaciones de matriz paralela, la regla general es tener el número de subprocesos para la cantidad de procesadores.

Answer 8

Supongamos que el servicio web es infinitamente escalable y que a nadie le va a importar que esté enviando correo basura con las solicitudes. Supongamos también que las respuestas del servicio web están en el rango de 1 segundo, mientras que el tiempo de procesamiento local es de 5 milisegundos.

El rendimiento se maximiza cuando tiene la misma cantidad de hilos ocupados que los núcleos de procesamiento.

Según estas suposiciones, no podrá maximizar el rendimiento en un procesador multi-core para cualquier tamaño de grupo de subprocesos. Para lograr transacciones máximas por segundo, debe dividir el hilo por modelo de conexión. Busque la E/S no bloqueante (NIO) mencionada anteriormente o una implementación Java del patrón Token de finalización asíncrona (IO Completion en Windows).

Tenga en cuenta que la memoria de pila que está reservada para cada subproceso creado en realidad solo está reservada espacio de dirección, memoria no asignada o confirmada real. A medida que la pila intenta crecer, se lanzan excepciones que hacen que la memoria de la pila se comprometa a pedido. La consecuencia es que solo es realmente relevante para los administradores de memoria de 32 bits. Para la memoria de 64 bits, tiene un gran espacio de direcciones a pesar de que solo respalda una pequeña parte de ese espacio con memoria física. Al menos, así es como entiendo que Windows funciona, no estoy seguro del mundo de Unix.

Answer 9

Algo que podría ser considerado está mirando

Runtime.getRuntime().availableProcessors() 

que da una cierta dirección de cuántos hilos que tendría sentido para el sistema.