Los propietarios de sitios que tienen un problema de alta carga a menudo se comunican con nosotros en "Revisión". La situación en la que el propietario recibe una "carta de felicidad" del proveedor de alojamiento, que es un presagio de bloqueo del sitio, no es de ninguna manera rara, absolutamente cualquier propietario o editor del sitio puede enfrentarla, por lo que decidimos considerar en detalle las causas. y soluciones a este problema.
Por lo general, los editores aprenden sobre el exceso de carga de sus servidores, quienes regulan y controlan estrictamente el proceso de consumo de tiempo de la CPU y, a nivel del plan de tarifas, establecen la carga permisible que una cuenta puede crear (generalmente se mide en% de un cierto valor permitido o en minutos CP / CPU).
El hoster intenta distribuir uniformemente los recursos del procesador entre todos los clientes del servidor. Si la cuenta de hosting de alguien consume el 90% de los recursos del procesador, el resto obtendrá solo el 10%. Por lo tanto, en tales casos, el propietario de una cuenta que exceda los límites recibirá una advertencia. Y en caso de violaciones sistemáticas, la cuenta se bloquea para no interferir con el trabajo de otros sitios ubicados en el mismo servidor. Y esto, de ninguna manera, no es un intento de "diluir" al cliente a una tarifa más cara, como piensan algunos webmasters, ya que no es culpa del hoster que el sitio haya requerido más recursos durante algún tiempo.
Intentemos averiguar con qué se puede conectar el aumento de la carga en el alojamiento y cómo se puede resolver este problema.
Es importante tener en cuenta que la alta carga puede deberse tanto a externoy interno en relación con el sitio y los factores de alojamiento.
Factores externos
Los factores externos que crean una carga alta son todo lo que no depende de la configuración del alojamiento, el trabajo de los scripts y el proceso de administración del sitio. Este es el resultado de solicitudes externas al sitio por parte de varios servicios, bots u otros sitios. Son muchos los factores.
- Escanee el sitio en busca de vulnerabilidades, busque "archivos confidenciales", busque el panel de administración.
Cualquier sitio cuyas páginas estén indexadas en un motor de búsqueda puede convertirse en un "objetivo" para hackers y bots, todos los días alguien lo escaneará, buscará "agujeros", intentará piratearlo. Es imposible detener este proceso, pero puedes contrarrestarlo.
Las solicitudes de sitios, especialmente si se realizan de forma intensiva y utilizan el método POST, consumen muchos recursos del procesador. Por lo tanto, el proceso de escanear un sitio con un escáner externo se expresa en un aumento de la carga. Si, como resultado del escaneo, un atacante descubre una vulnerabilidad o una variante de pirateo del sitio, lo más probable es que cargue un código malicioso en el sitio o cometa algunas acciones destructivas. Si no se detectan problemas de seguridad como resultado del análisis, el sitio continuará funcionando normalmente y la carga volverá a la normalidad. Hasta el próximo escaneo ... - Adivinar la contraseña desde el panel de administración del sitio (ataque de fuerza bruta).
Uno de los ataques populares, cuyo propósito es obtener acceso administrativo mediante ataques de fuerza bruta en combinaciones populares de nombres de usuario / contraseñas de administrador, es un ataque de fuerza bruta. El bot hacker usa un diccionario especial con combinaciones populares TOP1000 (admin / admin, admin / 123456, ...) e intenta ingresar al panel de administración del sitio con ellas. El proceso de fuerza bruta en sí mismo aumenta la carga, ya que se realizan solicitudes constantes a la página del panel administrativo y las solicitudes se realizan mediante el método POST de uso intensivo de recursos. - Registro masivo de usuarios o envío masivo de spam a través de formularios de comentarios inseguros.
A menudo, los sitios utilizan formularios de comentarios o formularios de registro de usuarios con mecanismos de protección anti-bot débiles. Es bueno si el formulario tiene al menos algún tipo de "captcha" de la serie "demuestra que no eres un bot". Si el sitio está incluido en la base de datos de spammers, pero no hay "captcha" u otro mecanismo de protección contra "http flood", entonces comienza el registro masivo de usuarios con perfiles de spam, envío de correo a través de un formulario, etc. Todo esto crea una carga en el hosting y, además, puede provocar el envío de spam, por lo que la empresa de hosting apaga el servicio de correo o bloquea el sitio por completo.
Cabe señalar que en este momento todos los mecanismos de defensa simples son fácilmente pasados \u200b\u200bpor alto por los bots modernos, por lo que debe instalar inmediatamente algo serio, por ejemplo Google Recaptcha2.
- Indexación de sitios por robots de búsqueda.
A veces, con un índice de búsqueda suficientemente grande (cuando una gran cantidad de páginas cae en la base de búsqueda de Yandex y Google), el proceso de reindexación puede llevar mucho tiempo y crear una gran carga en el servidor. Si su sitio tiene solo una docena de páginas, también puede encontrar un problema similar, por ejemplo, si el sitio fue pirateado y alojó una puerta con 50,000 páginas que llegaron a los resultados de búsqueda. O el índice de búsqueda podría ser enviado por correo no deseado por un competidor que se aprovechó de los errores en los scripts de su sitio. Hay muchas opciones aquí.
- Captura y depuración de contenido.
Los propietarios de contenido único deben preocuparse por el problema de descargar contenido del sitio (depurar y capturar). Esto se puede hacer mediante bots especiales que pasan por alto las páginas del sitio y copian los textos y las imágenes publicadas en el sitio para crear clones. Si el proceso de rastreo de su sitio es regular y el sitio tiene muchas páginas, esto puede crear una carga impresionante en el alojamiento.
- Importación de datos (alimentación, descarga de artículos básicos).
A menudo, los recursos de comercio electrónico utilizan un mecanismo de intercambio de datos con servicios externos. Por ejemplo, se puede descargar una lista de artículos básicos de las tiendas en línea, se pueden cargar datos de 1C en ellas, los sitios de noticias pueden exportar regularmente feeds de noticias, etc. Si el contenido no es estático, cada una de estas solicitudes creará una gran carga. en el servidor.
- Usar imágenes o enlaces a su sitio.
Uno de los momentos no obvios que crean una carga puede ser la colocación de un enlace al sitio o el uso de una imagen del sitio en un recurso más visitado. Una de las fuentes del problema es el llamado "efecto habra", cuando el sitio no puede hacer frente al flujo de visitantes de un recurso más popular. La segunda opción es cuando alguien (o usted mismo) publicó una imagen de su sitio en el blog que visita (por ejemplo, en los comentarios), y cada visitante la carga y crea una carga en su alojamiento. Especialmente, esto puede crear serios problemas si la imagen es generada por scripts (por ejemplo, escalada usando scripts timthumb / phpthumb). - Ataques a otros sitios (por ejemplo, una vulnerabilidad en xmlrpc.php).
A menudo, los piratas informáticos utilizan los sitios que contienen vulnerabilidades para realizar ataques a otros recursos. A veces, un atacante ni siquiera necesita piratear el sitio para esto. Por ejemplo, los propietarios de versiones que no sean las más recientes de Wordpress pueden encontrar este problema (ataque a través del archivo xmlrpc.php). En este caso, su sitio actuará como un enlace intermedio y el trabajo de los scripts del sitio creará una gran carga en el servidor.
- Ataque DDOS
Si hay un ataque DDOS en el sitio, entonces sin conectar medios técnicos especiales que trafican con el proxy (servicio de alojamiento o servicio de protección DDOS), no será posible hacer frente a él. Es difícil no notar el DDOS. Debido al hecho de que se creará una gran carga en el servidor, el proveedor de alojamiento puede hacer diferentes cosas: ofrecer un servicio de protección DDOS, mover el sitio a otro servidor o bloquear completamente (deshabilitar) el sitio. Por lo tanto, para protegerse contra DDOS, es recomendable tener una solución preparada con anticipación, para que cuando surja un problema, se pueda resolver rápidamente. - Crecimiento del tráfico
Si el tráfico es orgánico, esta es la razón más positiva del aumento de carga. Así que es hora de escalar el sitio y pensar en optimizar los scripts para un mayor tráfico.
Con el fin de encuentra el motivo de la cargagenerado por factores externos, es necesario analizar los registros del servidor web. Para hacer esto, puede usar aplicaciones especiales o una combinación de comandos en la consola SSH.
En los resultados del análisis, debe mirar las 20 solicitudes TOP por el método POST, las 20 solicitudes TOP por el método GET / HEAD, las 20 direcciones IP TOP por el número de visitas, las 20 páginas de referencia TOP por el número de visitas. Todo esto permitirá identificar la fuente y el tipo de tráfico, así como los puntos de entrada al sitio o scripts que más se llaman. Lo más probable es que sean la causa de la alta carga.
Para reducir la carga en caso de ataques externos o solicitudes intensivas, en la mayoría de los casos, es suficiente habilitar la protección contra la inundación de http (por ejemplo, las clásicas "cookies en el cliente + redireccionamiento con verificación") o conectar el sitio a los servicios de proxy de tráfico que bloquearán solicitudes peligrosas o especialmente activas, pero buenas y legítimas: omitir. Además, el contenido estático (imágenes, scripts y estilos) se ofrecerá no desde su sitio, sino desde servidores CDN, lo que también reducirá significativamente la carga.
Puede intentar conectar un complemento de almacenamiento en caché en un CMS o un servicio de almacenamiento en caché en un alojamiento, pero en el caso de factores externos que afecten la carga, es posible que esto no ayude.
Factores internos
Los factores internos incluyen todo lo que afecta el rendimiento del sitio a nivel de scripts y configuraciones. Es decir, algo que puede controlar el webmaster (propietario del sitio).
- Scripts no optimizados y base de datos en expansión.
Debido a la arquitectura de una aplicación web diseñada de forma analfabeta o la implementación ineficiente de scripts por parte de desarrolladores sin experiencia, es posible que simplemente abrir la página de inicio o mostrar los resultados de búsqueda en el sitio pueda cargar seriamente el servidor. Y el crecimiento en el volumen de la base de datos (por ejemplo, un aumento en la cantidad de artículos básicos) con cada actualización del sitio lo ralentizará cada vez más, aumentando la carga en el alojamiento. Las páginas individuales de un sitio con una gran cantidad de bloques de información pueden enviar decenas de consultas a la base de datos, realizar repetidamente las mismas operaciones con archivos y, a veces, incluso bloquear el funcionamiento de otros elementos del sitio. A menudo nos encontramos con un problema similar con las tiendas en línea que se ejecutan en la versión anterior de Joomla con el complemento Virtuemart. En algunos casos, se realizan más de 100 consultas a la base de datos al abrir una página de catálogo. - Infección del sitio con virus
Hackear e infectar un sitio web con scripts maliciosos es una causa bastante común de aumento de carga. Aumenta debido a la actividad viral derivada de la introducción de fragmentos maliciosos en scripts legítimos del sitio, el lanzamiento y funcionamiento de procesos residentes, así como la conexión de scripts a recursos externos al momento de abrir cualquier página del sitio. - Conexiones legítimas externas a recursos de terceros
Pocas personas tienen en cuenta la carga creada por las conexiones a fuentes externas de información (widgets, informadores del clima y del tipo de cambio, fuentes de noticias, etc.). A menudo, los datos que se descargan de otros sitios no se almacenan en caché localmente y cada vez que se abre la página, se conecta y descarga contenido de otro servidor. Si por alguna razón la fuente externa deja de responder rápidamente, afectará la carga y la velocidad de carga del sitio principal. - Errores en la secuencia de comandos
Al ejecutar scripts, pueden ocurrir errores que no se muestran a los visitantes, pero que se escriben en el registro del servidor web o en el registro de php. Si se visita el sitio o hay muchos errores, esto también puede aumentar la carga en el alojamiento. Muy a menudo, los errores comienzan a generarse en el momento de cambiar el sitio a una versión más reciente de PHP, con la que los scripts no son compatibles. O cuando no se actualizan todos los componentes del sitio y surgen conflictos entre el nuevo núcleo del CMS y las versiones anteriores de los complementos.
Para analizar el problema de alta carga causado por factores internos, debe verificar el sitio en busca de código malicioso (por ejemplo, verificar el sitio de forma gratuita) y, si no se encuentra ningún código malicioso, luego perfilar los scripts usando xhprof o xdebug módulos.
Para resolver el problema de alta carga causado por la actividad de código malicioso, es necesario desinfectar el sitio e instalar protección contra piratería repetida. Será mejor si la curación y protección del sitio se realiza en lugar de hacerlo por desarrolladores web.
Si la causa de los problemas está en la arquitectura del sitio o los errores, entonces la optimización del sitio por parte de un desarrollador web experimentado ayudará. Una de las soluciones alternativas para el segundo caso es la instalación de un complemento de almacenamiento en caché, que en algunos casos puede reducir el consumo de recursos del procesador (carga de alojamiento) y acelerar el sitio.
Duración
En conclusión, me gustaría considerar una propiedad más de la carga del procesador: su duración. Puede ser una ráfaga a corto plazo en el gráfico durante el día o un crecimiento constante durante mucho tiempo.
Si ve un pico único en el gráfico de consumo de CPU, no se preocupe. Es prácticamente invisible, no afecta la disponibilidad del sitio y no interfiere con los vecinos de hosting. Es peor si el gráfico avanza lentamente durante mucho tiempo o muestra la carga máxima del procesador (o excede el límite) durante varios días. ¿Qué hacer en este caso? Es necesario auditar los sitios de la cuenta como se describe anteriormente, verificando los factores externos e internos que causan problemas.
Nuestros servicios de ciberseguridad
Promoción "2 por el precio de 1"
La promoción es válida hasta fin de mes.
Cuando conecta el servicio "Sitio bajo supervisión" para un sitio, el segundo en la misma cuenta se conecta de forma gratuita. Sitios posteriores en la cuenta: 1500 rublos por mes para cada sitio.
Una situación que puede sucederle a todos los propietarios de un sitio en desarrollo con una carga creciente:recibir una advertencia sobre la superación del límite de recursos.
Si su proveedor de alojamiento le informa sobre la carga en el procesador, pero está seguro de que debe tener suficientes recursos, intente comprender cuál podría ser el motivo de esta carga. Sabiendo el motivo, puede solucionar rápidamente el problema.
Carga de CPU al ejecutar scripts PHP o Perl
En tales casos, el proveedor de alojamiento no siempre puede decir claramente qué secuencia de comandos está causando el problema, y \u200b\u200bdeberá determinarlo usted mismo. Si está utilizando un CMS modular, por ejemplo, Joomla, Wordpress o Drupal, entonces el motivo puede ser el trabajo incorrecto de un módulo separado.
Casi siempre, el enlace problemático en el sistema de su sitio se puede determinar comparando el momento del problema con los registros de solicitudes a su sitio en ese momento. Por lo general, puede obtener acceso a los registros del servidor web en el panel de control de alojamiento, incluso sin comunicarse con el proveedor.
Cargue en la CPU y / o el sistema de disco desde el servidor web Apache
El servidor web Apache puede crear una carga excesiva cuando el sitio está representando una gran cantidad de gráficos y otras estáticas. La arquitectura de Apache está diseñada de tal manera que solo una solicitud es procesada por un hilo o proceso. En consecuencia, si su sitio tiene mucha información gráfica, entonces se gastará una cantidad excesivamente grande de recursos de procesador y RAM en su devolución. La carga en el disco del servidor también será significativa.
En este caso, puede utilizar el servidor web Nginx como interfaz para Apache. Nginx, debido a su arquitectura asincrónica, le permite manejar miles de conexiones dentro de un solo proceso y proporciona contenido estático mucho más fácil y rápido. El único problema es que en muchos servicios de alojamiento solo se usa Apache como servidor web, y el paquete Nginx + Apache se usa con bastante poca frecuencia.... Sin embargo, al cambiar a un VPS, puede configurar este paquete sin problemas. Por lo general, su proveedor de alojamiento puede realizar la transferencia de sitios a VPS desde el alojamiento y la configuración del software necesario, incluso sin cargo adicional.
Solicitudes de sitio excesivas
Una gran cantidad de solicitudes del mismo tipo a un sitio desde una IP o varias direcciones IP es el llamado HTTP flood, uno de los tipos de ataques DDoS. Puede resultar útil bloquear las direcciones IP problemáticas en el archivo .htaccess mediante la directiva "denegar desde".
Si el hosting usa solo Apache, y el hoster no puede reflejar las solicitudes problemáticas por medio del mismo Nginx, y el ataque es intenso, el hoster puede bloquear su cuenta en el servidor y pedirle que transfiera los sitios a un VPS o un servidor dedicado.
Si se produce un ataque por primera vez, es lógico ponerse en contacto con el proveedor de alojamiento para que le ayude a repelerlo, o al menos para exigir que se desbloquee la cuenta y la posibilidad de seguir trabajando con el alojamiento inmediatamente después de que finalice el ataque . Si tal problema surge sistemáticamente, entonces cambie a un VPS o servidor y su configuración competente para un funcionamiento tolerante a fallas del sitio (por ejemplo, instalando scripts para autobloquear direcciones IP de máquinas bot basadas en el análisis de registros, instalando Nginx como un front-end a Apache y filtrar las solicitudes de problemas a su nivel) realmente tiene sentido.
Aumento significativo de la asistencia al proyecto
Con el desarrollo del sitio, el crecimiento de su tráfico es un fenómeno natural y, tarde o temprano, el sitio puede quedar realmente abarrotado con el plan de tarifas actual. Esto es normal para proyectos en desarrollo. En la mayoría de los casos, en el alojamiento compartido ordinario para sitios dinámicos, el umbral de tráfico es de 2000 a 4000 visitantes únicos por día.
Si el tráfico a su sitio se acerca a estas cifras, entonces la transición hacia o será la decisión correcta, que tendrá un efecto positivo en su futuro desarrollo.
La carga en la CPU y el sistema de disco desde el lado de MySQL
Se considera que el tiempo normal para ejecutar una consulta en una base de datos MySQL es de varias decenas de milisegundos. Las consultas que tardan más (especialmente más de 0,5 segundos) a menudo suponen una carga excesiva tanto en el sistema de disco del servidor como en su procesador. Si el hoster le advierte sobre un problema similar, pídale los registros de consultas lentas y optimice la estructura de la base de datos, así como borre la base de datos de información irrelevante.
El uso intensivo del servicio de alojamiento para envíos masivos instantáneos a cientos o miles de destinatarios puede causar una carga significativa en el servidor. Por esta razón, la mayoría de los proveedores establecen ciertas restricciones sobre el envío de correo, generalmente de 25 a 50 cartas por hora, o alrededor de 500 a 1000 cartas por día. Esta limitación tiene como objetivo combatir el correo basura y reducir la carga en el subsistema de correo del servidor. Para el trabajo normal con correo en el sitio, estas restricciones suelen ser suficientes, y para envíos masivos es mejor utilizar alojamiento de correo, servicios de correo instantáneo o adaptar un VPS para este propósito.
Debe comprender que un proveedor de alojamiento puede enfrentar docenas y cientos de problemas similares al suyo todos los días, lo que significa que puede ayudarlo a resolverlos. El hoster es su aliado, no su enemigo, en la lucha contra estos problemas.
Es más rentable para un proveedor de hosting ayudar a resolver un problema y retener a un cliente que negarse a brindar servicios, mientras que no solo pierde ganancias, sino que también daña su reputación.
Si el proveedor ofrece una transición a una tarifa más alta o un servicio de clase superior, especifique qué le dará exactamente esto. Vale la pena escuchar los argumentos si son realmente importantes.
Al elegir un alojamiento, probablemente entienda cuál será la carga. Hoy en día, solo hay dos opciones que son resistentes a cargas pesadas, además de cumplir con los requisitos de rendimiento: una solución en la nube o en clúster. Tanto uno como el otro son bastante dignos, por lo que es más probable que el precio juegue un papel aquí.
Elegir el mejor hosting
¿Cuál es la diferencia entre un clúster y una nube?
Las soluciones agrupadas se crean sobre la base de dos o más servidores dedicados, generalmente físicos. Además, los equipos de servidor se utilizan constantemente, y cuando aumenta la carga, alquilan un número adicional de servidores o compran más.
Las soluciones de clúster generalmente se pagan mensualmente.
Las soluciones en la nube también se construyen sobre la base de varios servidores virtuales. La cantidad de servidores involucrados en un momento determinado depende de la carga. En un nivel alto, un gran número y en un nivel bajo, los servidores que no están involucrados simplemente se apagan.
El alojamiento en la nube a menudo se paga por horas. Se cobra necesariamente una hora de funcionamiento de cada servidor individual en la nube. El monto del pago depende completamente de la carga. Si es alto, entonces el monto a pagar es mayor, y si no hay carga, entonces el pago es mínimo.
Al comparar los costos en efectivo por hora de ejecutar servidores similares en la nube y en un clúster, verá que los clústeres son algo más baratos. Al mismo tiempo, después de un buen análisis del porcentaje general de uso efectivo de los recursos pagados, se vuelve bastante obvio: en las "nubes" es más alto.
Con un alojamiento de este tipo, paga exclusivamente por el consumo real, mientras que en un clúster, la facturación también se aplica al hardware inactivo.
Nublado mejor hosting en términos de escala, la velocidad supera al grupo. Además, se presta a la automatización. La construcción de un clúster requiere más tiempo, hay muchas menos operaciones automáticas.
Detengámonos en algunas características más de cada una de las soluciones de alojamiento descritas.
Clusters
Se debe elegir el alojamiento en clúster si la carga es alta todo el tiempo o aumenta constantemente.
En tales circunstancias, todos los recursos del clúster están constantemente involucrados, por lo que el equipo no está inactivo. Por lo tanto, hay tiempo para escalar (aumentar el número de servidores). Esto sucede gradualmente, a medida que aumenta la carga.
Más a menudo que otros, el clúster es elegido por servicios web, tiendas en línea, aplicaciones comerciales, redes sociales.
"Nubes"
El alojamiento en la nube en Europa está justificado para sitios de eventos, exposiciones, promociones especiales y otros, que tienen poco tráfico la mayor parte del tiempo, pero en determinados momentos pueden aumentar drásticamente.
En otras palabras, estamos hablando de sitios donde los saltos de carga están estrechamente relacionados con la actividad de marketing o se eleva como una avalancha, y no hay tiempo para implementar un clúster. En este caso, el precio más alto por hora de trabajo compensa el hecho de que el equipo no está inactivo.
Así, una de las ventajas del alojamiento en la nube es que la "nube" reduce el tiempo de implementación, así como de comercializar proyectos y aplicaciones.
Producción
Por supuesto, habrá opositores y partidarios de ambas soluciones. Sin embargo, dado que existen, sirven a una gran cantidad de proyectos, entonces son una forma razonable de acceder a la Web. Cuál elegir depende de ti.
Como se mencionó anteriormente, el alojamiento en la nube en Ucrania es adecuado para cargas periódicamente altas y un aumento impredecible en el número de visitantes al mismo tiempo.
Las soluciones de clúster se utilizan con cargas elevadas constantes o con un crecimiento sistemático previsto del tráfico.
Centrándonos en factores tan simples, la elección será mucho más rápida y sencilla.
