J’ai abandonné OpenLiteSpeed ​​et je suis revenu au bon vieux Nginx

Agrandir / Ish est en feu, yo.

Depuis 2017, pendant mon temps libre (ha !), j’aide mon collègue Eric Berger à héberger son site de prévisions météorologiques pour la région de Houston, Space City Weather. Il s’agit d’un défi d’hébergement intéressant : au cours d’une journée typique, SCW effectue entre 20 000 et 30 000 pages vues pour 10 000 à 15 000 visiteurs uniques, ce qui est une charge relativement facile à gérer avec un minimum de travail. Mais lorsque des phénomènes météorologiques extrêmes se produisent, notamment en été, lorsque des ouragans menacent le golfe du Mexique, le trafic du site peut atteindre plus d’un million de pages vues en 12 heures. Ce niveau de trafic nécessite un peu plus de préparation à gérer.

Hé, c'est <a href="https://spacecityweather.com">Météo de Space City</a> ! » src= »https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screenshot-2024-01-24-at-9.02.05%E2%80%AFAM.jpg » width= »300″ height= »235″ /><figcaption class=
Agrandir / Hé, c’est la météo de Space City !

Lee Hutchinson

Pendant très longtemps, j’ai exécuté SCW sur une pile backend composée de HAProxy pour la terminaison SSL, de Varnish Cache pour la mise en cache sur boîte et de Nginx pour l’application de serveur Web proprement dite, le tout piloté par Cloudflare pour absorber la majorité de la charge. (J’ai longuement écrit sur cette configuration sur Ars il y a quelques années pour les personnes qui souhaitent des détails plus approfondis.) Cette pile a été entièrement testée au combat et prête à dévorer tout le trafic que nous lui avons lancé, mais elle était également d’une complexité ennuyeuse. , avec plusieurs couches de cache à gérer, et cette complexité rendait les problèmes de dépannage plus difficiles que je ne l’aurais souhaité.

Ainsi, lors d’une interruption hivernale il y a deux ans, j’ai profité de l’occasion pour abandonner une certaine complexité et réduire la pile d’hébergement à une seule application de serveur Web monolithique : OpenLiteSpeed.

Fini l’ancien, place au nouveau

Je ne connaissais pas grand-chose sur OpenLiteSpeed ​​(« OLS » pour ses amis), à part le fait qu’il est souvent mentionné dans les discussions sur l’hébergement WordPress – et comme SCW utilise WordPress, j’ai commencé à m’y intéresser. OLS a semblé recevoir de nombreux éloges pour sa mise en cache intégrée, en particulier lorsque WordPress était impliqué ; il était censé être assez rapide par rapport à Nginx ; et, franchement, après cinq ans passés à administrer la même pile, j’avais envie de changer les choses. C’était OpenLiteSpeed !

La console d'administration OLS, affichant les hôtes virtuels.  Cela provient de mon serveur Web personnel plutôt que du serveur Space City Weather, mais cela semble identique.  Si vous souhaitez des détails plus approfondis sur la configuration OLS que j'utilisais, <a href="https://blog.bigdinosaur.org/configuring-wordpress-openlitespeed/">consultez mon blog</a>.  Oui, j’ai toujours un blog.  Je suis vieux. » src= »https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screen-Shot-2022-06-09-at-6.37.47-AM-1.jpg » width= »640″ height= »398″ /><figcaption class=
Agrandir / La console d’administration OLS, affichant les hôtes virtuels. Cela provient de mon serveur Web personnel plutôt que du serveur Space City Weather, mais cela semble identique. Si vous souhaitez des détails plus approfondis sur la configuration OLS que j’utilisais, consultez mon blog. Oui, j’ai toujours un blog. Je suis vieux.

Lee Hutchinson

Le premier ajustement important à gérer était que OLS est principalement configuré via une véritable interface graphique, avec tous les problèmes potentiels ennuyeux que cela entraîne (un autre port à sécuriser, un autre mot de passe à gérer, un autre point d’entrée public dans le backend, plus de PHP). ressources dédiées uniquement à l’interface d’administration). Mais l’interface graphique était rapide et exposait principalement les paramètres qui devaient être exposés. Traduire la configuration WordPress Nginx existante en langage OLS a été un bon exercice d’acclimatation, et j’ai finalement opté pour les tunnels Cloudflare comme méthode acceptable pour garder la console d’administration cachée et théoriquement sécurisée.

Juste un avant-goût des options qui vous attendent dans le plugin WordPress LiteSpeed ​​Cache.
Agrandir / Juste un avant-goût des options qui vous attendent dans le plugin WordPress LiteSpeed ​​Cache.

Lee Hutchinson

L’autre ajustement majeur a été le plugin OLS LiteSpeed ​​Cache pour WordPress, qui est le principal outil utilisé pour configurer la manière dont WordPress lui-même interagit avec OLS et son cache intégré. Il s’agit d’un plugin massif avec des pages et des pages d’options configurables, dont beaucoup concernent l’utilisation du service Quic.Cloud CDN (qui est exploité par LiteSpeed ​​Technology, la société qui a créé OpenLiteSpeed ​​et son frère payant, LiteSpeed).

Tirer le meilleur parti de WordPress sur OLS impliquait de passer du temps dans le plugin, pour déterminer laquelle des options serait utile et laquelle serait préjudiciable. (Peut-être sans surprise, il existe de nombreuses façons de s’attirer des ennuis stupides en étant trop agressif avec la mise en cache.) Heureusement, Space City Weather fournit un excellent terrain d’essai pour les serveurs Web, étant un site bien actif avec un cache très important. -charge de travail conviviale, j’ai donc élaboré une configuration de départ dont j’étais raisonnablement satisfait et, tout en prononçant les anciennes paroles sacrées du rituel, j’ai actionné le commutateur de basculement. HAProxy, Varnish et Nginx sont restés silencieux et OLS a pris le relais.

Source-147