Este artículo será útil para aquellas personas que ya tienen su propio sitio o que planean abrirlo. Un artículo particularmente interesante serán los webmasters ambiciosos que sienten que la mejor hora de su proyecto está a la vuelta de la esquina y quieren prepararse para la afluencia de visitantes de la página.
Incluso aquellos que todavía sueñan con miles de usuarios en su sitio, probablemente se preguntaron: "¿Cuántos usuarios mantendrá mi sitio si inician sesión al mismo tiempo?" Inmediatamente recuerdo la conocida expresión "Habraeffect", el fenómeno de la falla del sitio, que resultó no estar listo para numerosas conversiones después de la aparición del enlace en Internet.
Supongamos que el sitio ya existe (o lo estará pronto): ¿dónde se puede ubicar? ¿Debería ser un servidor clásico de alojamiento o vps? Si es vps, ¿cuál y cómo es mejor configurarlo? ¿O tal vez no hay ninguna diferencia y es más fácil elegir lo que es más barato? En este artículo, consideraremos varias opciones y en la práctica nos aseguraremos de cuál es el mejor para nuestro sitio.
Experimentaremos: establezca diferentes modos de operación del servidor y mida el rendimiento. Simularemos la carga en el sitio utilizando el servicio Loaddy.com. Allí puede establecer el número de usuarios, el tipo de carga creciente y el gráfico mostrará cómo el servidor responde a ellos. Se cree que un usuario genera aproximadamente una solicitud al sitio en 10 segundos. Como sitio de prueba, tome una tienda de demostración en línea en cms moguta. Se llenará con los "productos" de prueba que se muestran en la página principal de acuerdo con varios criterios (es decir, cuando se está formando la página, se está trabajando con la base de datos, etc.). De una forma u otra, esto le permitirá comparar los modos entre ellos.
Como sitio de prueba, crearemos un servidor VPS en Ubuntu. Su configuración será [1 núcleo, 1 Gb de RAM]. Suponemos que son precisamente estos servidores de nivel de entrada los que se crean en la mayoría de los casos para nuevos proyectos. La versión de prueba de la tienda en línea estará disponible en la dirección IP
http://130.193.44.219/El alojamiento clásico también es útil, para lo cual también llenaremos la misma tienda en línea para realizar pruebas. ¡Puede seguir nuestro propio camino y realizar las mismas pruebas en su proyecto!
Dado que en la mayoría de los casos, junto con vps, se ofrece un panel de control, realizaremos los principales cambios en la configuración. En el servidor vps, tenemos 3 modos de funcionamiento:
- Apache
- Apache en modo CGI;
- Nginx + php-fpm (sin Apache).
Pero primero, probemos el alojamiento:
Alojamiento clásico de bajo costo
El resultado está disponible
aquí .
Los errores aparecen cuando el número de visitantes supera las 50 personas. El hosting deja de dar contenido, sin embargo, si va al panel de control de hosting, podemos ver algo como lo siguiente:
Su sitio ha estado sujeto a restricciones durante las últimas 24 horas. Los recursos del procesador fueron limitados para su sitio. Ha alcanzado los límites de los procesos de entrada (la cantidad de scripts PHP y CGI que se ejecutan simultáneamente, tareas programadas y sesiones de consola) 126 veces.
Bueno, por supuesto, el hosting es hosting, más económico. Por supuesto, puede encontrar una tarifa que le brinde más opciones, pero debe tener en cuenta todo esto, de alguna manera averiguar los datos exactos de las restricciones y cada proveedor de alojamiento.
VPS: Apache
El siguiente en línea es nuestra Fuerza Aérea de prueba con modo Apache, que por cierto se ofrece de forma predeterminada al instalar el panel de control del ISP.
El resultado está disponible
aquí .
Los problemas comienzan cuando el número de usuarios excede los 90. Si vamos a nuestro servidor a través de ssh y miramos ese momento en la lista de procesos usando el comando superior, ordenados usando Shift + M (por la cantidad de memoria consumida), veremos algo como esto:
Vemos que el proceso apache2 se ha convertido en muchas filiales y se han comido toda la RAM de nuestro servidor vps.
Aquí necesitas hacer un pequeño comentario. El hecho es que para el servidor Apache, en teoría, hay un modo que permite, en lugar de este gran número de procesos secundarios para cada conexión, crear varios llamados multiproceso, cada uno de los cuales serviría para varias conexiones. Este modo se llama
trabajador , a diferencia del
prefork predeterminado. Pero no es fácil instalarlo, es imposible hacerlo en paneles como ISP, y si se desconcierta y trata de hacerlo a través de ssh, resulta que apagar prefork y encender a trabajador no es suficiente, aún necesita una versión segura de php. Y si se utilizan módulos como Zend o IonCube, también deben ser seguros para subprocesos. De todos modos, el sitio oficial de PHP
no recomienda configurar este modo.
VPS: CGI
Veamos qué sucede cuando se usa el modo CGI. Para hacer esto, debe permitir el uso de PHP en modo CGI en el panel de control del ISP, esto se hace en la sección "Cuentas - Usuarios - Configuración para el usuario".
El resultado está disponible
aquí .
Una imagen sombría resultó. El servidor se niega a entregar contenido ya con más de 55 visitantes, la memoria RAM es cargada por los procesos "php". El siguiente es un intento de restaurar la funcionalidad, pero aún así termina en casi un 100% de falla.
VPS: Nginx + PHP-FPM
Ha llegado el momento de un modo en el que el servidor Apache no se utiliza en absoluto, Nginx funciona en su lugar y php es procesado por el módulo php-fpm. Si usa el panel de control del ISP, debe habilitar este modo para el usuario. Esto también se realiza en la sección "Cuentas - Usuarios - Configuración de usuario". Además, este modo debe estar disponible en la sección "Configuración - Características - Servidor web (www)".
El resultado está disponible
aquí .
Lo que necesitas! 100% de disponibilidad, mientras que la velocidad de descarga y el tiempo de respuesta del servidor están en niveles aceptables, aunque aumentan con el aumento de la carga. Sin embargo, el servidor está haciendo frente!
Veamos la tabla de procesos en el momento de la carga máxima en el servidor:
Vemos que todavía tenemos un suministro de RAM disponible. Y los procesos secundarios php-fpm7.0 no crecen en grandes cantidades, sino que están limitados a 5 instancias, cada una de las cuales sirve a varios hilos.
Bueno, parece que se define un "modo ganador". Veamos cuántos visitantes simultáneos puede servir nuestro servidor en este modo. Pero antes de eso hacemos un pequeño "ajuste". En primer lugar, dado que apache no se usa para la operación de dicho servidor, puede deshabilitarse por completo. Haremos esto en el panel de control del ISP en la sección "Sistema - Servicios". En segundo lugar, cambiamos un poco el principio de iniciar procesos php-fpm. Por defecto, es dinámico. Esto significa que los procesos secundarios se quedarán en la memoria incluso cuando no sean necesarios. Al mismo tiempo, la memoria no se libera y, con el tiempo, estos procesos pueden crecer más de lo que quisiéramos. Por lo tanto, se propone establecer el modo "bajo demanda" - bajo demanda. Y establezca el número de procesos secundarios y el tiempo de espera para ellos.
Para hacer esto, deberá ir al servidor a través de ssh y registrar esta configuración en el archivo de configuración de php. Esto se hace convenientemente en el archivo para el usuario para el que se creó el dominio en ISP.
Por lo general, se encuentra en /etc/php/7.0/fpm/pool.d
Entonces
sudo nano /etc/php/7.0/fpm/pool.d/www-root.conf
Vemos por defecto las siguientes configuraciones:
[www-root] pm = dynamic pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_children = 5 pm.max_spare_servers = 5
Para habilitar el modo ondemand, debe reemplazar esto con:
pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s
Y reinicie php-fpm con el comando
sudo service php7.0-fpm restart
Después de eso, los procesos php-fpm7.0 se crearán a pedido (si hay una carga), su número máximo será = 5, y después de 10 segundos de inactividad, el proceso se anulará, liberando RAM.
Por si acaso, volveremos a ejecutar nuestra prueba para asegurarnos de que toda esta actividad amateur no haya afectado el rendimiento del sitio web para peor:
El resultado está disponible
aquí .
Ahora ejecutemos Loaddy con muchos visitantes para comprender cuántas conexiones puede manejar nuestro servidor:
El resultado está disponible
aquí .
La buena noticia es que todas las solicitudes se procesaron, aunque con un gran retraso, con una gran cantidad de ellas por segundo. El tiempo de respuesta del servidor es cercano a 10 segundos con más de 190 visitas, pero recordemos el gráfico del modo apache, donde obtuvimos 4 segundos de respuesta del servidor con más de 80 usuarios, mientras que en el modo php-fpm, se observan retrasos similares con 130 solicitudes que asignamos especialmente cursor en la tabla de arriba.
Pero este es el mismo VPS.
Tabla de los principales procesos al final de la prueba (con 200 usuarios):
Tenga en cuenta que después de la prueba, la memoria utilizada por pfp-fpm se libera:
Entonces nuestro servidor está listo para nuevas cargas.
Debe recordarse que el sitio funciona en modo nginx + php-fpm, lo que significa que apache2 no se usa en el trabajo y, como resultado, no se usa .htaccess. Esto puede no parecer conveniente, pero es la opción más rápida posible, y los motores de búsqueda clasifican mejor los sitios que funcionan rápido.
Conclusión
En conclusión, un pequeño punto más: si configuró todo en el servidor que deseaba y decidió desconectar el panel de control del ISP, o si se le acabó la licencia, tenga en cuenta que el proceso "central" de él seguirá colgando en su servidor. Después de meses, puede crecer, por lo que es mejor "matarlo" y eliminarlo del inicio y el crona.
Si desea probar de forma independiente el sitio utilizando Loaddy u otros métodos, está disponible en
http://130.193.44.219/