Esta guía explica cómo aumentar el valor max_children en Serveur Cloud para aumentar el número de procesos PHP simultáneos que pueden ser utilizados por su sitio. Esto será muy útil para resolver problemas de carga infinita de las páginas de su sitio.

Prólogo

• Por defecto, en cualquier alojamiento, el límite de max_children está fijado a 20.
  • Aunque es posible aumentar este valor desde el Manager Infomaniak, el límite de max_children se ajusta automáticamente según la configuración de su Serveur Cloud.
  • Para aumentar este límite en alojamiento compartido, migre a Serveur Cloud.
• Para entender cómo calcular con precisión los max_children necesarios, consulte este artículo sobre el tema.

Aumentar el valor max_children

Requisitos previos

• Asegúrate de contar con los recursos necesarios en el servidor Cloud.
• Asegurarse de que todos los recursos del servidor Cloud no estén utilizados; si resulta que están completamente utilizados, el aumento del valor max_children no tendrá ningún efecto (Modificar los recursos del Serveur Cloud).
• Controlar el monitoreo de los recursos de tu servidor, en el caso de que los recursos de tu servidor estén alcanzados, será necesario verificar la optimización de los procesos y de tu sitio antes de considerar aumentar el valor de max_children.
• Consultar los informes de error de PHP desde la carpeta /ik-logs (master process php logs - nombre del archivo: php-fpm.log) para verificar si se ha superado el límite "max_children". Ejemplo de error: [05-Jul-2024 09:08:58] WARNING: [pool www.infomaniak.ch] server reached max_children setting (20), consider raising it

Para acceder a la gestión de los parámetros PHP / Apache del sitio del cual se debe aumentar el valor max_children en Serveur Cloud, consulte esta otra guía.

Podrás, entre otras cosas…

• … elegir un nuevo valor de max_children:
  

Límites según el servidor

Límite de max_children según los recursos del Serveur Cloud:

Esta guía explica cómo modificar las variables de la extensión PHP-CLI que está disponible por defecto en Serveur Cloud Infomaniak.

Modificar las variables PHP_CLI

Para acceder a las extensiones PHP del Serveur Cloud :

1. Haga clic aquí para acceder a la gestión de su Servidor Cloud en el Manager Infomaniak (¿Necesita ayuda?).
2. Haga clic directamente en el nombre asignado al Serveur Cloud correspondiente.
3. Haga clic en Extensiones PHP en el menú lateral izquierdo.
4. Haga clic en el menú de acción ⋮ a la derecha de PHP-CLI en la tabla que se muestra.
5. Haga clic en Configurar:
   
6. Modifique las siguientes variables: allow_url_fopen, allow_url_include, memory_limit, max_execution_time, short_open_tag, allow_local_infile
7. Haga clic en el botón azul Guardar.

Esta guía explica cómo modificar el valor de la directiva php_value include_path.

Modificar el include_path

Al igual que cualquier otro parámetro de PHP, include_path se define en el archivo .user.ini.

Aquí tienes un ejemplo de ruta para usar en el archivo .user.ini:

include_path = .:/home/clients/123456789a12345b12fc345d/web/www.domainetest.abc/public/abc/include

Consulte este otro guía sobre phpinfo para verificar que se ha aplicado su nueva directiva.

Esta guía explica cómo modificar la configuración de un VPS Cloud / VPS Lite.

Modificar el tamaño de almacenamiento en VPS Cloud / VPS Lite

Para acceder al VPS Cloud / VPS Lite:

1. Haga clic aquí para acceder a la gestión de su producto en el Manager Infomaniak (¿Necesita ayuda?).
2. Haga clic en el menú de acción ⋮ a la derecha del objeto correspondiente en la tabla que se muestra.
3. Haga clic en Modificar la oferta:
   
4. Realice los ajustes deseados y complete el procedimiento a continuación:
   
5. Es necesario extender el volumen después de aumentar el volumen de almacenamiento.

Esta guía explica cómo autorizar ciertos puertos entrantes y/o salientes en el cortafuegos (o firewall) de un servidor VPS Cloud / VPS Lite.

Acceder a la herramienta de gestión

Para gestionar el firewall VPS Cloud / VPS Lite:

1. Haga clic aquí para acceder a la gestión de su producto en el Manager Infomaniak (¿Necesita ayuda?).
2. Haga clic directamente en el nombre asignado al producto correspondiente.
3. Haga clic en Firewall en el menú lateral izquierdo:
   

Regla para permitir el ping en VPS Cloud / VPS Lite

Para agregar una regla en el firewall:

1. Haga clic en el botón azul para Agregar una regla.
2. Haga clic en Selección manual.
3. Seleccione ICMP:
   
4. Valide en la parte inferior de la página.

Abrir el puerto saliente 25 de manera global

El puerto saliente 25 (puerto SMTP Mail) está bloqueado por defecto.

Se recomienda utilizar una solución de envío de correo autenticado.

Para abrir este puerto, contacte con el soporte de Infomaniak justificando su solicitud.

Infomaniak no ofrece cifrado de disco virtual en VPS Cloud / VPS Lite pero proporciona un dispositivo de bloque que puede formatear y cifrar si lo desea.

Esta guía trata sobre el intercambio en Servidor Cloud.

Intercambio y memoria RAM

Puede haber swap aunque el uso de RAM sea bajo. De hecho, el sistema puede usar el swap en cualquier momento si lo considera útil.

El swap no es un espacio de memoria dedicado a ser utilizado solo si no hay RAM libre, aunque ese sea su uso principal más común.

Si desea obtener más información, existe un parámetro "swappiness" que permite definir cómo el sistema utilizará el swap. El valor predeterminado es 60 y no se puede modificar.

Esta guía explica cómo conectarse a Elasticsearch después de instalarlo en Magento desde un Servidor Cloud Infomaniak.

Requisitos previos

• Tener un Servidor Cloud Infomaniak.
• Instalar Magento.
• Contactar con el soporte de Infomaniak para la instalación de Elasticsearch.

Información de conexión

Una vez conectado a su espacio Magento, será necesario indicar la siguiente información para iniciar Elasticsearch:

• Nombre de host: localhost o 127.0.0.1
• Puerto :9200
• Prefijo :magento2

Esta guía presenta varios ejemplos de uso de Varnish en Servidor Cloud Infomaniak.

Configuración de Varnish

Después de la instalación, la configuración de Varnish incluye reglas importantes para la caché y el purgado. Tenga cuidado de no autorizar accidentalmente direcciones IP no deseadas.

Aquí está un ejemplo de un archivo de configuración básico con algunos casos comunes y diferentes acciones/reglas en un solo ejemplo:

vcl 4.0;
# Configuration du backend par défaut
backend default {
    .host = "127.0.0.80";  # Adresse IP du backend
    .port = "80";           # Port du backend
}
# Définition d'une liste de contrôle d'accès (ACL) pour les IPs autorisées à purger le cache
acl purge {
    "localhost";            # IP locale
    "1.2.3.4";              # IP de votre domicile
    "42.42.42.0"/24;        # Plage d'IP publique de votre entreprise
    ! "42.42.42.7";         # Exclusion d'une IP spécifique (ex : un collègue gênant)
}
# Traitement des requêtes à leur réception par Varnish
sub vcl_recv {
    # Autoriser les requêtes de purge
    if (req.method == "PURGE") {
        # Vérification si l'IP du client est autorisée à purger
        if (!client.ip ~ purge) {  # 'purge' fait référence à l'ACL définie plus haut
            # Retourne une page d'erreur si l'IP n'est pas autorisée
            return (synth(405, "Cette IP n'est pas autorisée à envoyer des requêtes PURGE."));
        }
        # Si l'IP est autorisée, purger le cache pour cette requête
        return (purge);
    }
    # Autoriser la purge de toutes les images via une requête PURGEALL
    if (req.method == "PURGEALL" && req.url == "/images") {
        if (!client.ip ~ purge) {
            return (synth(405, "Cette IP n'est pas autorisée à envoyer des requêtes PURGE."));
        }
        # Invalider tous les objets en cache correspondant à des images
        ban("req.url ~ \.(jpg|png|gif|svg)$");
        return (synth(200, "Images purgées."));
    }
    # Ne pas mettre en cache les pages avec une autorisation (header Authorization)
    if (req.http.Authorization) {
        # Passer la requête directement au backend sans la mettre en cache
        return (pass);
    }
}
# Traitement de la réponse du backend avant de la renvoyer au client
sub vcl_backend_response {
    # Mise en cache des images pour une durée de 1 jour
    if (beresp.http.content-type ~ "image") {
        set beresp.ttl = 1d;
    }
    # Si le backend indique que la réponse ne doit pas être mise en cache, respecter cette consigne
    if (beresp.http.uncacheable) {
        set beresp.uncacheable = true;
    }
}

Limpieza desde la interfaz CLI

Desde allí, las reglas enumeradas en la configuración anterior funcionan en todas las solicitudes, por lo que si el sitio configurado es "domain.xyz", simplemente puede usar la herramienta CLI "curl" y hacer lo siguiente:

# Envoyer une requête PURGE pour purger la page d'accueil de "domain.xyz"
$ curl -X PURGE https://domain.xyz/
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Erreur 200 : Purge effectuée</h1>
    <p>La page a été purgée avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 2</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

Y allí, la página de inicio se ha purgado. O para purgar otra URL, simplemente apunte la solicitud a esta última:

# Envoyer une requête PURGE pour purger un fichier spécifique à "domain.xyz"
$ curl -X PURGE https://domain.xyz/some_path/some_file.html
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Erreur 200 : Purge effectuée</h1>
    <p>Le fichier a été purgé avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 4</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

O, como se indica en la configuración VCL, purgar todas las imágenes:

# Envoyer une requête PURGEALL pour purger toutes les images dans "domain.xyz"
$ curl -X PURGEALL https://domain.xyz/images
# Réponse renvoyée par le serveur Varnish
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged images</title>
</head>
<body>
    <h1>Erreur 200 : Images purgées</h1>
    <p>Toutes les images ont été purgées avec succès.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 32770</p>
    <hr>
    <p>Serveur de cache Varnish</p>
</body>
</html>

Purga desde un CMS

Es un poco más difícil ilustrar este caso porque hay muchas maneras de gestionar la caché desde un backend. En el ejemplo de configuración anterior, se agrega un control en el encabezado "Uncacheable", que desactiva la caché. Con esta opción, cualquier CMS podría simplemente establecer este encabezado en la respuesta para desactivar la caché de esta solicitud, por ejemplo.

Desde cualquier código PHP y con la configuración anterior, puedes simplemente enviar una solicitud HTTP y usar este fragmento para realizar una PURGA de la caché:

<?php
if ($curl = curl_init("http://127.0.0.1/some_url")) {
    curl_setopt_array($curl, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => "PURGE",
        CURLOPT_HTTPHEADER => [
            "Host: {$_SERVER['HTTP_HOST']}"
        ]
    ]);
    curl_exec($curl);
    if (curl_getinfo($curl, CURLINFO_HTTP_CODE) == 200) {
        echo "Cache purged!";
    }
    curl_close($curl);
}
?>

Saber más

Enlaces útiles sobre el lenguaje de configuración de Varnish (VCL) para controlar el procesamiento de solicitudes, el enrutamiento, la caché y varios otros aspectos:

• Tutorial VCL
• Guía del usuario de VCL
• Referencia VCL

No es posible ordenar y obtener más direcciones IP en un VPS Cloud / VPS Lite.

Las alternativas posibles serían usar…

• … un alojamiento de tipo Public Cloud (es posible añadir tantas direcciones IP como se desee),
• … la herramienta Newsletter según sus necesidades.