LiteSpeed admite paneles de proveedores de alojamiento populares como WHM / cPanel, DirectAdmin, Plesk y más.
Sin embargo, Hostinger utiliza un panel de alojamiento personalizado, hPanel, que tiene una gestión dinámica de vhost basada en Redis y Openresty + scripts LUA personalizados. Así es como funciona: los datos de vhost se guardan en Redis. Openresty recupera dichos datos cuando se recibe una solicitud web. Luego se pasa al servidor web Apache.
Originalmente, LiteSpeed se configura mediante archivos de configuración. Sin embargo, queríamos implementar una administración completamente dinámica, que no necesita recargar los servicios para actualizar la configuración, como hicimos con la configuración de Openresty. Nos contactamos con el soporte de LiteSpeed, explicamos nuestra configuración actual y el hecho de que queremos que sea administrada de forma dinámica.
Resulta que tuvimos suerte porque ya estaban desarrollando LiteSpeed versión 5.4. Estaban felices de ayudar e implementarlo en la rama de desarrollo. Fue una gran noticia para nosotros, ya que no tuvimos que volver a implementar nuestro proceso actual de administración de vhost.
Así que no solo reemplazamos Apache, sino que también nos deshicimos de Openresty, reduciendo la pila de software utilizada para procesar solicitudes, lo que también aumenta la ganancia de rendimiento.
Ritmo de desarrollo
Cuando inicialmente planeamos migrar a LiteSpeed, pensamos que esto debería tomar alrededor de un mes. Después de discutir cómo debería implementarse, los ingenieros de LiteSpeed desarrollaron una versión funcional con administración dinámica de vhost en aproximadamente una semana, lo que es realmente rápido para dicho software. Lo instalamos en nuestro entorno de desarrollo y preparamos herramientas de migración para reemplazar Apache.
Se agregó compatibilidad con Redis a LSWS 5.4RC3. Para nuestra desgracia, no nos dimos cuenta de cuántos cambios se planearon y ya se hicieron en LSWS 5.4RC3. Aún no conocíamos la fecha de lanzamiento de la versión estable. RC4 también estaba en camino con cambios adicionales que debían probarse. Aquí, en Hostinger, a menudo experimentamos tráfico deficiente que llega a los sitios web de nuestros clientes, por lo que fue un buen entorno para detectar todos los errores inesperados. Después de la primera implementación en nuestro servidor de producción, comenzamos a recibir informes de fallas. En este punto, comenzó la temporada de caza de insectos. Durante casi dos meses desde la primera implementación, comenzamos a informar de errores a los ingenieros de LiteSpeed a diario. Lo bueno es que cuando LSWS falla por cualquier motivo, solo un visitante que golpea ese error se ve afectado ya que LSWS genera un archivo central y se reinicia con gracia en casi ningún momento. Los ingenieros de LiteSpeed se centraron en corregir esos errores y obtuvimos una nueva versión en solo unas horas después de informarlos todos los días. Cuando dejamos de recibir informes de fallas del primer servidor, aumentamos el grupo de servidores que se ejecutaba con LiteSpeed, luego comenzaron a aparecer nuevos errores. Después de aproximadamente tres meses de tales pruebas, la verificación, el informe y la corrección de errores llegó una semana sin informes de fallas y pudimos decir que finalmente llegó la versión estable.
