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 exécutée sur un cluster de serveurs d'applications Glassfish. Le trafic entrant sera principalement des requêtes RESTful pour des représentations basées sur XML de nos ressources d'application, mais peut-être 5% du trafic pourrait être pour des représentations basées sur JSON ou XHTML/CSS.

Nous étudions maintenant des solutions d'équilibrage de charge pour distribuer le trafic entrant à travers les instances de Glassfish dans le cluster. Nous étudions également comment décharger le cluster en utilisant memcached, une table de hachage distribuée en mémoire dont les clés seraient 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 est de tuer les deux oiseaux avec une pierre et d'utiliser le serveur HTTP/proxy inverse nginx léger et rapide. Nginx gérerait chaque requête entrante en regardant d'abord son URI dans memcached pour voir s'il y a déjà une représentation XML non expirée. Sinon, nginx envoie la requête à l'une des instances de Glassfish. Le module nginx memcached est décrit au this short writeup.

Quelle est votre impression générale avec nginx et memcached utilisés de cette façon, à quel point êtes-vous heureux avec eux? Quelles ressources avez-vous trouvé les plus utiles pour en apprendre davantage à leur sujet? Si vous les avez essayés et qu'ils ne vous convenaient pas, pourquoi pas, et qu'avez-vous utilisé à la place?

Note: voici un related question.

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

Answer 1

En supposant que vous disposez d'une banque de serveurs d'applications en amont des données de livraison 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; 
    } 

Qu'est-ce que l'extrait de nginx.conf ci-dessus est tout fait directement le trafic de http://example.com/dynamic/ * DIRECTEMENT au serveur memcached. Si memcache a le contenu, vos serveurs en amont ne verront AUCUN trafic.

Si le succès du cache échoue avec une erreur 404 ou 502 (pas dans le cache ou que memcache ne peut pas être atteint), nginx transmettra la requête aux serveurs en amont. Comme il y a trois serveurs dans la définition amont, vous obtenez également un proxy d'équilibrage de charge transparent. Maintenant, le seul problème est que vous devez vous assurer que vos serveurs d'applications dorsaux maintiennent les données dans memcache. J'utilise nginx + memcached + web.py pour créer de petits systèmes simples qui gèrent des milliers de requêtes par minute sur un matériel relativement modeste.

Le pseudo-code général pour le serveur d'applications est comme cela 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 choses importantes à retenir dans le code web.py/pseudo ci-dessus est que le contenu provenant de memcached via nginx ne peut pas être changé 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 de votre contenu mis en cache. J'utilise nginx et memcached pour un site Web lié au sport où nous recevons d'énormes impulsions de trafic qui ne durent que quelques heures. Je ne pouvais pas me passer de nginx et de memcached. La charge du serveur lors de notre dernier grand événement sportif du 4 juillet est passée de 70% à 0,6% après la mise en œuvre des changements ci-dessus. Je ne peux pas le recommander assez.