Pour des batchs long, le coût CPU est négligeable, tu as raison même si le coût que tu indiques est pour une JVM « vide ». Charge quelques lib et le temps s'allonge... Depuis quelques temps la JVM ne charge plus tout le rt.jar, ce qui donne un temps à vide plutôt sympa. Malheureusement les développeurs ne sont pas économes en chargement de lib :-).
De plus, dans notre cas d'usage, nous devons gérer à la fois des batchs longs et des batch courts voir très courts (1 à 2 sec) mais nombreux (>100 000 par heure en pic).
Dans un pur cas de batch long, nous aurions sans doute opté pour une JVM externe. La gestion d'un pool de thread avec un classloader spécifique n'a pas été la partie la plus facile du dév :-)
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Pour des batchs long, le coût CPU est négligeable, tu as raison même si le coût que tu indiques est pour une JVM « vide ». Charge quelques lib et le temps s'allonge... Depuis quelques temps la JVM ne charge plus tout le rt.jar, ce qui donne un temps à vide plutôt sympa. Malheureusement les développeurs ne sont pas économes en chargement de lib :-).
De plus, dans notre cas d'usage, nous devons gérer à la fois des batchs longs et des batch courts voir très courts (1 à 2 sec) mais nombreux (>100 000 par heure en pic).
Dans un pur cas de batch long, nous aurions sans doute opté pour une JVM externe. La gestion d'un pool de thread avec un classloader spécifique n'a pas été la partie la plus facile du dév :-)