Quelle expérience avez-vous de l'utilisation de nginx et de memcached pour optimiser un site Web?

Question

Nous avons une application Web Java EE s'exécutant sur un cluster de serveurs d'applications Glassfish . Le trafic entrant sera principalement constitué de requêtes RESTful de représentations basées sur XML de nos ressources d’application, mais peut-être que 5% du trafic pourrait concerner des représentations basées sur JSON ou XHTML / CSS.

Nous étudions actuellement des solutions d'équilibrage de charge pour répartir le trafic entrant sur les instances Glassfish du cluster. Nous cherchons également à décharger le cluster à l'aide de memcached, une mappe de hachage distribuée en mémoire dont les clés sont les noms des ressources REST (par exemple, "/ user / bob", "/ group / jazzlovers") et dont les valeurs sont les représentations XML correspondantes.

Une approche qui semble prometteuse consiste à faire d'une pierre deux coups et à utiliser le système rapide et léger nginx serveur HTTP / proxy inverse. Nginx traiterait chaque demande entrante en consultant d'abord son URI dans memcached pour voir s'il existe déjà une représentation XML non expirée. Sinon, nginx envoie la demande à l'une des instances de Glassfish. Le module nginx memcached est décrit dans cette brève description .

Quelle est votre impression générale avec nginx et memcached, comment êtes-vous heureux avec eux? Quelles ressources avez-vous trouvées les plus utiles pour en savoir plus sur elles? Si vous les avez essayées et qu'elles ne vous convenaient pas, pourquoi pas et qu'avez-vous utilisé à la place?

Remarque: voici une question connexe .

Mise à jour: plus tard, j'ai posé la question sur ServerFault.com. Les réponses suggèrent principalement des alternatives à nginx (utiles, mais indirectement).

Answer 1

En supposant que vous disposiez d’une banque de serveurs d’applications transmettant en amont les données aux utilisateurs.

upstream webservices {
    server 10.0.0.1:80;
    server 10.0.0.2:80;
    server 10.0.0.3:80;
}
server {
    ... default nginx stuff ...
    location /dynamic_content {
          memcached_pass localhost:11211;
          default_type   text/html;
          error_page     404 502 = @dynamic_content_cache_miss;
          set $memcached_key $uri;
    }
    location @dynamic_content_cache_miss {
          proxy_pass http://webservices;
    }

Le fragment de code nginx.conf ci-dessus dirige tout le trafic depuis http://example.com/dynamic/ * DIRECTEMENT sur le serveur memcached. Si memcache a le contenu, vos serveurs en amont ne verront AUCUN trafic.

Si le cache réussit avec une erreur 404 ou 502 (ni dans le cache ni dans memcache), alors nginx transmettra la demande aux serveurs en amont. Comme il existe trois serveurs dans la définition en amont, vous obtenez également un proxy transparent d’équilibrage de charge.

Maintenant, le seul inconvénient est que vous devez vous assurer que vos serveurs d'applications back-end conservent les données dans memcache. J'utilise nginx + memcached + web.py pour créer de petits systèmes simples capables de gérer des milliers de demandes à la minute sur du matériel relativement modeste.

Le pseudo-code général du serveur d'applications ressemble à ceci pour web.py

class some_page:
     def GET(self):
         output = 'Do normal page generation stuff'
         web_url = web.url().encode('ASCII')
         cache.set(web_url, str(output), seconds_to_cache_content)
         return output

Les éléments importants à garder à l'esprit dans le code Web.py / pseudo ci-dessus sont que le contenu provenant de memcached via nginx ne peut pas être modifié du tout. nginx utilise des chaînes simples et non unicode. Si vous stockez la sortie unicode dans memcached, vous obtiendrez au moins des caractères étranges au début et à la fin du contenu mis en cache.

J'utilise nginx et memcached pour un site Web spécialisé dans le sport où nous avons d’énormes flux de trafic qui ne durent que quelques heures. Je ne pourrais pas me passer de Nginx et memcached. La charge de serveurs au cours de notre dernier grand événement sportif du 4 juillet a chuté de 70% à 0,6% après la mise en œuvre des modifications ci-dessus. Je ne peux pas le recommander assez.