Programmation de socket, Java, Tomcat 6, Mise à l'échelle

Question

Je suis assez nouveau à la programmation web et je suis en train de développer un backend web pour une application mobile. Actuellement, les utilisateurs se connectent à l'aide d'interactions servlet et une fois qu'ils ont un accès complet à l'application, j'ai besoin d'ouvrir une connexion socket pour pouvoir fournir des push serveur. Maintenant, le problème que je rencontre est la façon dont les gens gèrent des milliers de connexions socket simultanées. J'ai rencontré des gens qui parlent de ThreadPools qui semble assez facile à implémenter et de NIO. Y a-t-il un cadre avec lequel je peux travailler pour m'assurer que mes serveurs traitent au moins 20-30k connexions simultanées. Je pourrais aussi oublier les connexions TCP et aller pour les interrogations longues, mais d'après ce que j'ai compris, TCP est la meilleure option en matière de ressources.

@Steve - Je regarde l'ancien: Un socket de serveur avec des milliers de connexions.

Answer 1

Je voudrais regarder dans le clustering l'extrémité Web immédiatement et l'utiliser comme votre mécanisme d'échelle primaire. Les connexions 30k sont assez nombreuses et vous n'avez pas beaucoup de place pour la croissance avant d'atteindre une limite de serveur quelconque. Si les E/S elles-mêmes ne sont pas onéreuses, j'utiliserais beaucoup de threads et de serveurs avec beaucoup de puissance et de mémoire. Faites-le fonctionner de telle sorte que vous puissiez l'expédier, et ayez un plan de repli pour passer à NIO multiplexé si la performance ou la mise à l'échelle devient un problème, mais soyez averti que c'est une refonte radicale et environ dix fois plus complexe que java.net. Après plusieurs années de réflexion, je m'interroge de plus en plus sur le fait que le NIO puisse vraiment économiser sur les threads: il ajoute plusieurs nouveaux problèmes, tels qu'un besoin d'analyse poussée; les problèmes de synchronisation avec le sélecteur s'il y a des threads de travail qui ont besoin de changer l'état d'enregistrement des canaux; beaucoup de façons d'obtenir le code erroné; et le fait que la surcharge de planification se déplace hors de l'OS dans votre application, où vous avez seulement des structures de données de set-itérateur linéaire pour y faire face à moins que vous vous engagez dans un autre niveau de complexité. Il est bon de rappeler que select() a été inventé pour Unix pour permettre d'économiser sur les processus, qui sont coûteux. Les threads sont vraiment pas chers, et fournissent un modèle de programmation très simple avec un contexte intégré pour gérer une seule connexion. NIO gère à peine cela du tout sauf par l'utilisation disciplinée des pièces jointes clés de sélection, beaucoup moins naturellement.