J'ai un VPS chez wiredtree où j'aimerais exécuter une application scala/lift avec jeety sur un serveur LAMP. Je veux utiliser des acteurs de comet donc je vais utiliser le "long http hack" et je ne sais pas si c'est important.
Alors quelles options ai-je? Comment puis-je réaliser cela? J'ai lu qu'il y a des moyens de le faire avec mod_rewrite et avec mod_proxy mais je n'ai aucune idée!
Toutes les solutions de comète reposent sur le maintien de la connexion entre le serveur web ouverte aussi longtemps que possible, soit en ayant le client effectuer une requête POST puis en retardant l'envoi des données, soit en ayant le serveur renvoyer une réponse GET, en retardant encore une fois les données.
Ces deux méthodes posent des problèmes similaires pour l'origine, à savoir la consommation d'un socket et de mémoire par connexion, et éventuellement un thread, sauf si vous utilisez quelque chose comme les continuités Jetty.
En plaçant un proxy inverse comme Apache devant Jetty, comme Apache chaque connexion ouverte entre Jetty et le client va également consommer un worker. Selon le modèle de worker d'apache que vous choisissez (par exemple mod_prefork ou mod_worker_mpm), il y aura des limitations sur le nombre maximum de connexions que votre serveur apache peut supporter. Cela se situe autour de quelques centaines pour mod_prefork et est généralement limité par la quantité de mémoire physique que chaque processus worker consomme, à quelques milliers avec mod_worker_mpm. Si vous mélangez mod_worker_mpm avec php, vous devriez étudier les options avec lesquelles votre version de php a été compilée car il existe des incompatibilités connues avec php et mod_worker_mpm.
Vous devrez également être vigilant quant aux délais d'attente à la fois dans Apache et Jetty. Les connexions de style Comet simulent soit une requête POST lente, donc vous devrez ajuster Apache pour être tolérant envers cela, ainsi que la taille du corps de la requête. Les requêtes de style GET sont également soumises à un délai d'attente si rien n'est transmis du serveur d'origine. Vous devrez appliquer ces délais de temporisation des deux côtés de la connexion proxy inverse, du client à Apache, et d'Apache à Jetty.
Si je déployais une solution de ce type, je placerais soit le service de comète basé sur Jetty sur un domaine différent, en utilisant un répartiteur de charge pour acheminer plusieurs back-ends Jetty pour une capacité et une fiabilité accrues, soit j'utiliserais un autre proxy inverse, comme HAProxy, pour agir à la place d'Apache, et diriger les requêtes vers les différents backends (Apache, Jetty), en fonction de l'URL.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
