El Problema Nº1 que mata el Hosting PHP de tu Blog y cómo Solucionarlo

Hoy en día, cuando alguien quiere crear una web, es muy raro que no pase por utilizar para ello alguna de las aplicaciones estrella del software libre como, por ejemplo, WordPress para un blog, Joomla como sistema de gestión de contenidos, PrestaShop para una tienda online o phpBB para un foro de discusión.

Estas aplicaciones han sido una auténtica revolución por ser software libre y gratuito, sus prestaciones y calidad, y por haber sido creadas con un lenguaje de programación que también es gratuito y software libre (PHP) y cuyo entorno natural es la combinación del sistema operativo Linux y el servidor web Apache, de nuevo software libre.

Aparte de no librar al usuario de gastarse dinero en el software, esto ha hecho que el coste del hosting de este tipo de aplicaciones también sea bastante bajo y la consecuencia natural ha sido una avalancha en todo el mundo de sitios web basados en aplicaciones PHP creados por usuarios “normales”.

problemas de un hosting php

Imagen de Fotolia - ©Alexandr Mitiuc

Pero no todo son luces, naturalmente también hay sombras y quizás la más grande sea que alojar una aplicación PHP es mucho más exigente para los servidores y también en su administración que una simple web “tradicional” basada únicamente en páginas HTML estáticas.

Un blog en WordPress es un ejemplo perfectamente representativo de este problema y extrapolable a cualquier otra aplicación PHP.

En este post del blog de Víctor Martín puedes hacerte una idea global de cuáles son esos retos en general y en el post de hoy voy a profundizar en los retos que pueden echar abajo el rendimiento de tu hosting PHP hasta un punto que te resulte realmente insoportable (extrema lentitud, caídas continuas, etc.) y cómo superarlos.

De hecho, si ya has montado un blog WordPress con hosting y gozas de cifras de tráfico importantes (1000 visitas o más al día) es muy posible que ya estés empezando a notar estos efectos, pero probablemente no los hayas diagnosticado correctamente.

Así que en este post trataré de que entiendas el fondo de la problemática que explica por qué llegado a un cierto umbral de tráfico, el rendimiento de una aplicación PHP en un hosting puede caer en picado, y te señalaré el camino hacia las soluciones.

En los ejemplos me centraré en WordPress para ser más concreto, pero como decía, la problemática es totalmente extrapolable a cualquier otra aplicación PHP como Joomla, phpBB, Prestashop y similares.

Cuando tu hosting PHP no tiene la culpa

Generalmente cuando aparecen los problemas de rendimiento de los que habla este post, el diagnóstico del usuario es claro: la culpa es de mi hosting que es malo o que ha llegado al límite de su capacidad.

Si bien es cierto que la elección del hosting PHP es crítica para el rendimiento de tu blog, que el mercado del hosting está lleno de piratillas y que, por tanto, hay que saber qué se contrata, también es cierto que se echa muchísimas veces la culpa directamente al hosting cuando éste no tiene nada que ver con los problemas de rendimiento de la aplicación.

La mayoría de los problemas de rendimiento del día a día en un hosting con PHP se pueden reducir en un único problema de fondo que hay que entender bien: que al acceder a las páginas de la web se ejecute código PHP cuando no debería ejecutarse.

Si entiendes bien este problema y sabes diagnosticarlo con certeza (que no es muy difícil como verás más abajo en este post) habrás dado un gran paso porque ya entenderás exactamente lo que está pasando en tu sitio que es la condiciones sine qua non para poder erradicar el problema.

Quizás te resulte demasiado complicado meterte tú mismo con las configuraciones y ajustes necesarios para solucionarlo, pero ya estás preparado para plantearlo al servicio técnico de tu proveedor si cubre aspectos de mantenimiento de la aplicación en cuestión (WordPress, Joomla, etc.), o bien, a un profesional que te ayude con ello.

Recuerda que existen marketplaces como oDesk o Elance con una oferta gigante de profesionales de este tipo y que a través de nuestro formulario de contacto nosotros también te podemos poner en contacto con estos profesionales.

Por qué un hosting sufre tanto con las ejecuciones innecesarias de PHP

WordPress, al igual que el CMS Joomla o el software de foros de discusión phpBB, ha sido creado con el lenguaje de programación PHP y almacena sus contenidos en una base de datos MySQL con la que interactúa para prácticamente cualquier acción en el sitio (cargar una página, guardar un comentario, etc.).

blog WordPress con hosting optimizado

Tiempo de carga de página del blog Ciudadano 2.0 con la caché activada.

Si un diseño así sería prácticamente imposible crear unos productos tan sofisticados y completos como lo son estas aplicaciones. Pero todo tiene un precio y en este caso es que una web dinámica (no existen páginas HTML creadas a priori) supone mucho más carga para un servidor web que una web estática (que sólo se compone de ficheros estáticos HTML creados de antemano todos) puesto que en una aplicación PHP como las citadas, antes de que el servidor web entregue la página web al navegador del usuario ha de construirla en cada acceso desde un navegador web.

Construir una página web dinámica “sobre la marcha” le supone al servidor web acceder a la base de datos MySQL para recuperar los contenidos y ejecutar el código PHP para componer con esta información el HTML de la página que devuelve finalmente al navegador.

Todo esto requiere muchos más recursos de CPU y  memoria que si esta página HTML fuese estática, es decir, un simple fichero que existiese de antemano y que simplemente se descarga al navegador web del usuario. Además, si la aplicación usa plugins o extensiones similares, cuantos más use, más aumenta la cantidad de código PHP ejecutado y los accesos a la base de datos y con ello más la carga del servidor. De ahí que haya que tener cuidado con los plugins usados.

Para el hosting de tu web te recomiendo Webempresa, Raiola o Hostgator

Con poco tráfico esto no es un gran problema, pero incluso para un hosting PHP potente que ya no sea un alojamiento web compartido básico, en un blog WordPress, por ejemplo, típicamente a partir de las 1000 visitas diarias esto empieza a ser un problema.

Pero, en realidad, el problema no lo es tanto el número de visitas al día, sino que el criterio realmente clave aquí es el patrón de tráfico: las visitas concurrentes (simultaneas).

Cada visita supone la ejecución de un proceso PHP que consume tiempo procesador y una determinada cantidad de memoria. Si se acumulan demasiadas visitas simultáneas, el servidor llegará a su límite de procesos y/o a su límite de memoria y la web dejará de funcionar. Por eso, el límite de memoria y de procesos son dos parámetros tan importantes en la contratación de un hosting PHP. Cuanto más holgados estos parámetros, más visitas concurrentes aguantará el servidor.

blog WordPress con hosting sin optimizar

Tiempo de carga de página del blog Ciudadano 2.0 con caché la desactivada.

En ese sentido, un sitio web con 2.000 visitas al día, pero una distribución muy uniforme con muy poca concurrencia en las visitas, puede tener muchos menos problemas que sitio con 500, pero con picos de tráfico concurrentes muy pronunciados. Un poco más abajo veremos que es casi seguro que el origen de todos los males de tu sitio sea un patrón de este tipo, incluso aunque creas que no sufres picos de este tipo.

Multiplica el Nº de gente que lee tu blog

Con este eBook gratuito de plantillas de copywriting crearás titulos que dispararán los clics en tus contenidos:

  • 77 Plantillas de títulos probadas que multiplicarán los clics.
  • Sacaras infinitas ideas crear tus propios títulos.
  • Con las palabras "mágicas" redactarás textos irresistibles.
¡Buenas! ¿Me dices tu nombre?

¡Un placer conocerte!

Apuntáte aquí y recibirás gratis una copia del eBook.

Por qué una caché no soluciona el problema al 100%

Por suerte, hay una muy buena solución al problema anterior: usar una caché de páginas.

La idea básica es muy sencilla: una caché aprovecha el HTML creado en la ejecución de una página dinámica PHP y lo convierte en una página estática HTML, es decir, crea literalmente un fichero con ese código HTML como si fuese una página estática tradicional y lo guarda como tal en el servidor web.

Si otro usuario accede a la misma página y la aplicación detecta que no ha habido cambios en ella, en vez de acceder de nuevo a la BD MySQL  y procesar el PHP, sirve directamente el fichero anteriormente guardado. Resultado: mucha más velocidad y mucho menos carga para el servidor, por tanto, mucha más capacidad de tráfico.

WordPress y Joomla, por ejemplo, disponen de plugins que implementan este tipo de cachés.

Hasta aquí la solución es perfecta, incluso con un hosting básico y económico, pero de calidad como Webempresa o Hostgator, que son los que recomendamos en este blog, la capacidad del sitio sube a muchas miles de páginas al día sin problemas.

Pero como verás ahora, hay un problemilla que nos agua la fiesta y mucho…

… las (malditas) URLs parametrizadas.

Una URL parametrizada tiene este aspecto:

https://www.ciudadano2cero.com/hosting-hostgator/?utm_source=rss& utm_reader=feedly

Es decir, una URL parametrizada tiene un “apéndice” con parámetros que empieza con “?” y una lista de parámetros. En el ejemplo, “utm_source” y “utm_reader” son los nombres de los parámetros y “rss” y “feedly” los correspondientes valores.

El ejemplo es un ejemplo real simplificado (he eliminado varios parámetros) de las URLs que en este caso usa el lector RSS Feedly en sus entradas. Es decir, cuando un usuario hace clic para irse a la web original de un post de su feed, la URLs que se usa es de este tipo.

Hay muchas fuentes que usan URLs de este tipo. Otro ejemplo típico son las URLs acortadas de Twitter y las de otros acortadores.

Si te interesa el tema blogging, tampoco te pierdas nuestra recopilación de los mejores recursos para blogs & bloggers

En principio, una URL de este tipo es algo muy útil porque a través de los parámetros permite pasar información útil al servidor. En este caso, por ejemplo, son parámetros para Google Analytics que desde nuestro servidor se pueden pasar a su vez a Analytics para saber cuánta gente accede vía un lector RSS al blog. Esto permite discriminar las fuentes de tráfico en nuestra analítica web.

Pero hay un gran problema: para WordPress la URL parametrizada de arriba es una página diferente a la URL “normal” que sería ésta:

https://www.ciudadano2cero.com/hosting-hostgator/

Y con razón es así porque normalmente los parámetros afectan al contenido de la página, es decir, que diferentes parámetros suponen diferentes contenidos en la página aunque las diferencias sean sólo matices.

Lo puñetero de todo esto es que siendo así, cada URL parametrizada diferente supone una nueva página PHP que se procesa completamente desde cero sin poder aprovechar la caché. Incluso para un proveedor como Webempresa, que es el proveedor con los servidores más holgados que hemos probado hasta la fecha, esto supone una carga importante para sus servidores.

En el caso de Feedly, por ejemplo, no es muy grave porque la URL parametrizada es la misma para todos los lectores, se procesa una vez, se cachea y los subsiguientes accesos ya se sirven desde la caché. El problema es que hay otras fuentes que pueden generar un pico de tráfico intenso al generar tráfico a través de muchas URLs parametrizadas distintas a la vez. En nuestro caso, por ejemplo, nos ocurrió con el tráfico procedente de Twitterfeed.

Si tienes un blog WordPress, tampoco te pierdas nuestra recopilación de los mejores plugins de WordPress

Si tu sitio web empieza a tener tráfico, empezará a haber muchos sitios con diferentes parámetros que provocan que tu caché no se aprovecha al 100% porque muchas de las páginas se procesan una y otra vez “tontamente” metiendo mucho más carga al servidor.

Por la naturaleza intrínseca del problema éste se agrava conforme tu sitio gane popularidad. Así que, como ves, ¡también aquí la fama tiene su precio!

Cómo detectar que tienes problemas

Como es mejor prevenir que curar, te contaré ahora cómo puedes detectar que estás siendo afectado por un problema de exceso de acceso vía URLs parametrizadas. Este punto ya se vuelve un poco técnico, pero si te atreves, verás que se mantiene asequible.

Monitoriza tu servidor web

Una señal de alarma muy clara es que empieces a tener caídas de corta duración de tu servidor (unos pocos minutos como mucho), provocadas por los picos de concurrencia. Estas caídas al principio normalmente van a pasar desapercibidas por su corta duración hasta que sean más severas, por eso te recomiendo  que uses una herramienta de monitorización con avisos automáticos como Pingdom para detectarlas. Así detectarás incluso caídas de un minuto. Este post te habla más en detalle de ella.

Observa los procesos PHP

La característica más clara para detectar que tienes un exceso de páginas que no se están sirviendo desde la caché es el monitor de procesos de tu hosting (si tu hosting lo tiene…). El problema es que tienes que pillar el problema “in flagranti”, justo en el momento que se produce.

captura procesos PHP cpanel

Los hostings con cPanel como Hostgator o Webempresa suelen incluir un widget como éste donde puedes ver fácilmente cuantos procesos PHP concurrentes se están ejecutando en un momento determinado.

Si detectas una caída o señales de lentitud en tu blog, entra en las herramientas de tu hosting y observa cuantos procesos de “index.php” aparecen. Incluso con muchas decenas de visitas, en una situación normal con un % normal de accesos con URLs parametrizadas no se deberían observar más de 4 o 5 procesos de “index.php” en paralelo, como mucho.

En el caso de que veas un número mayor es que probablemente algo va mal, te está llegando un tráfico concentrado de URLs parametrizadas anormal. Para que te hagas una idea, un hosting compartido de buena calidad suele tener un límite en torno a 20-25 de estos procesos, si se supera esta cifra, se caerá.

Analiza los logs de Apache

Por suerte, los servicios de hosting PHP te suelen permitir descargarte el log del servidor web que en cerca del 100% de los casos va a ser Apache. Ésta la mejor herramienta de diagnóstico de todas porque tiene la información más completa, puedes buscar fácilmente los patrones conflictivos y puedes ir atrás en el tiempo.

Es un fichero de texto que muestra el orden cronológico de los accesos que ha tenido tu sitio, contiene, entre otras cosas, la hora exacta de cada acceso, la URL de acceso utilizada y el país desde el cual se produjo el acceso.

Te sorprenderás cuando lo veas, entre otras cosas, porque verás la cantidad de tráfico no humano (bots) que tiene que soportar tu hosting si tu sitio web ya ha alcanzado cierta visibilidad.

La cuestión es que el log te permite buscar URLs parametrizadas y con patrones concretos. Por ejemplo, si buscas la cadena de texto “/?” puedes localizer todos los accesos con URLs parametrizadas y si hay momentos en los que se concentran muchos accesos y de dónde proceden. Si buscas “=twitterfeed” estaría filtran por URLs que han usado este parámetro.

Para ello te recomiendo muy encarecidamente la herramienta Apache Logs Viewer, dispones de una versión gratuita, pero te recomiendo encarecidamente que te gastes los 10€ que cuesta la versión de pago porque añade funcionalidad que hace todo este proceso mucho más cómodo.

Tu peor enemigo en un alojamiento web con PHP: los “bots”

En el análisis del log de Apache puedes descubrir muchas cosas muy interesantes.

Una de las más interesantes (y más “pesadilla”) es la cantidad de robots o “bots” que acceden a tu sitio una vez que ha conseguido una cierta visibilidad. Hay bots “buenos” como el bot de Google que indexa tu sitio para posicionarlo en el buscador y bots “malos” como los bots de spam que escanean tu web, por ejemplo, para averiguar huecos de seguridad o hacer spam de comentarios.

captura de ataque de spam a WordPress

Trazas del log de Apache de un ataque de spam, fíjate especialmente en el parámetro “replytocom”, la frecuencia de los accesos y la procedencia de los mismos. Fueren cientos de accesos en segundos ejecutando PHP que acabaron provocando una caída del servidor.

La manera fácil de detectar los bots es el agente de usuario que identifique tu log. Si ves algo como “Googlebot/2.1”, por ejemplo, estás viendo el robot de Google. Sin embargo, los botos malos no suelen revelar su verdadera identidad así que tienes que rastrear otros indicadores.

Dos de los más fáciles de detectar son el país de origen y la frecuencia de acceso. Por ejemplo: no es muy normal que tengas 10 accesos en un segundo de alguien de Georgia. Algo así canta.

Luego hay indicadores específicos, pero aquí ya hay que tener conocimientos avanzados. En el caso específico los ataques spam a un blog WordPress, que son un auténtico grano en el culo, es típico el uso de URLs con el parámetro “replytocom” que es el que se usa al enviar un comentario en WordPress.  Si, además, ves muchos accesos seguidos en cuestión de pocos segundos es evidente que se trata de un ataque de spam porque resulta obvio que no se trata de un patrón de uso humano. Este tipo de ataques, por ejemplo, son la causa de muchas caídas de corta duración en blogs WordPress.

En cualquier caso los ataques de spam, de fuerza bruta y similares son un terreno en el que hay mucha tela que cortar y que requieren, como mínimo, un post específico que haré próximamente. Hoy sólo pretendo darte un poco de perspectiva.

Cómo solucionar el problema

La mejor técnica para solucionar este problema que he visto hasta el momento y del cual, por cierto, apenas se publica nada (incluso en la blogosfera ingles) siendo un problema de los “gordos”, es aprovechar una maravilla de Apache que son las reglas de reescritura en el fichero .htaccess

La idea fundamental consiste en filtrar determinados parámetros de las URLs acceso antes de que el servidor procese nada y eliminarlos de la URL. De este modo la URL se convierte nuevamente en una URL “normal” para la cual entra en acción la caché.

Si añades, por ejemplo, el siguiente código a tu fichero .htaccess aquellas URLs que contengan algún parámetro “twitterfeed” se convertirán en la correspondiente URL sin parámetros:

La noticia mala es que toquetear el fichero .htaccess ya son palabras mayores. La puedes liar parda en tu sitio web si no sabes lo que haces, así que hagas lo que hagas, lo primero es sacar una copia de seguridad del fichero .htaccess. Si tienes esa copia, por mucho que la hayas liado, con restaurarla ya dejas todo en orden otra vez.

Como no es moco de pavo trabajar con reglas de re-escritura explicaremos los detalles de esto en un futuro post dedicado a ello. En cualquier caso, ya sabes lo que importa que es por dónde van los tiros de la solución. No obstante, si quieres ir atacando el problema desde ya, te dejo esta referencia que contiene el mejor tutorial para principiantes sobre reglas de re-escritura que he encontrado hasta la fecha, aparte de la documentación oficial de Apache sobre el tema.

De hecho, lo ideal sería contar con el apoyo del servicio técnico de tu proveedor de hosting o la ayuda de una persona técnica con conocimientos sólidos de Apache y reglas de re-escritura para crear las que tú necesitas para tu sitio.

Ya por último, una advertencia: date cuenta de que los parámetros que filtres, los pierdes.

Esto quiere decir que te fijes bien si estás filtrando información relevante que quizás prefieras conservar asumiendo la carga adicional correspondiente al servidor. Por ejemplo: determinada información de tracking (seguimiento) para Google Analytics que te interesa. En este ejemplo, si eliminases los parámetros de Google Analytics, esta información se dejará de aparecer en tu cuadro de analítica web.

Como curiosidad puedes echar también un vistazo a este hilo de la comunidad de  Google Plus de Desarrollo de WordPress en Español dónde lance en su momento un pequeño reto pidiendo ayuda sobre este problema cuando estaba intentando solventarlo para este blog. Tiene muchos detalles técnicos sobre este que quizás te resulten de interés.

Conclusiones

Desgraciadamente el precio que pagas por el éxito de tu sitio cuando usas un hosting con PHP es el que conforme ganes en visibilidad garantizar el buen funcionamiento del hosting se vuelve cada vez más complicado.

Entre todos estos problemas destaca especialmente el problema del acceso con URLs parametrizadas por anular la caché de las páginas, un problemón que debido a la gran cantidad de tráfico de este tipo que generan los bots puede acabar con el rendimiento de tu sitio si no tomas medidas a tiempo.

Solucionar el problema correctamente, por desgracia, ya requiere conocimientos técnicos avanzados, pero, al menos, entender bien el problema, que es lo que pretende este post, te permitirá plantearlo con el servicio técnico de tu hosting o un profesional que te ayuda. Aquí es dónde valorarás tener un soporte técnico más premium como el de Webempresa que abarque también WordPress porque te ayudará mucho más con este tipo de problemas que son propios de las aplicaciones y no del hosting en sí.

Un problema difícil como ésta será, además, una buena prueba para evaluar la calidad de tu soporte técnico y averiguar si se lo toman en serio, si se echan balones fuera o si simplemente no están a la altura.

De hecho, ésta es la razón que hay detrás del concepto de hosting gestionado como el que ofrece, por ejemplo, WPEngine y en el que el equipo de soporte se encarga también de los problemas relacionados con las aplicaciones alojadas, no solamente de la parte “pura” de hosting. Por eso es mucho más caro que un hosting compartido o un hosting VPS “normal”.

Una buena opción lo son también los hostings con un servicio adicional de soporte técnico especializado en aplicaciones concretas como como JoomlaWordPress o PrestaShop.

No son un hosting gestionado (ellos te guían, pero las acciones la realizas tú, no ellos), pero una opción intermedia muy muy interesante porque con un proveedor bueno en la práctica puedes llegar a un nivel de servicio muy parecido por una fracción del coste.

Ahora mismo el mejor servicio con diferencia del mercado de estas características (en nuestra opinión) lo ofrece Webempresa que es, por cierto, nuestro actual proveedor para este blog. Con unos precios solamente un pelín más elevados que un hosting compartido puro como el que ofrece, por ejemplo, Hostgator (que es un buen hosting), ofrecen un nivel de servicio claramente superior.

De hecho, la holgura de sus máquinas y la calidad de sus configuraciones es tal que el problema de las URLs parametrizadas simplemente “desapareció” sólo después de la migración la cual te cuento aquí en detalle:

De Hostgator a Webempresa. Cómo y por qué migramos de hosting

Acerca del autor: Berto López

Soy autor y cofundador de este blog, actividad que realizo como hobby ya que las nuevas tecnologías siempre me han atraído mucho.

Ahora trabajo por cuenta ajena, pero he sido empresario durante casi una década trabajando en la implantación de proyectos tecnológicos en sectores con carencias en conocimiento de las nuevas tecnologías, como Retail y Pymes.

De hecho, esta experiencia ha sido la inspiración para el blog: ayudar a profesionales y pequeños empresarios a conocer y aprovechar el potencial de las nuevas tecnologías y la web 2.0.


Comentarios

  1. Hola Berto:

    Muy buen post! Tienes razón cuando dices que hay poca información bien clara al respecto. Me topé con este post porque el proveedor que suelo usar indica en algunos de sus planes que soportan aproximadamente “40 conexiones simultáneas a los scripts dinámicos de apache, así como a los trabajos SSH y cron que se ejecutan simultáneamente.”

    Te quería consultar un par de detalles. Cuando introduces ese código en el .htaccess, dónde va, al inicio o al final?… o por ejemplo cuando es WordPress el código del .htaccess comienza en # BEGIN WordPress y termina en # END WordPress.

    La otra consulta es: para el eliminar en WordPress las URLs parametrizadas no es suficiente con configurar “Enlaces Permanentes” con la opción “nombre de la entrada”?, por ejemplo.

    Guardo tu blog en mis favoritos. Saludos

    • Berto López dice:

      Hola Armando,

      Debe ir al principio, antes de la parte de WordPress.

      Con la opción de “enlaces permanentes” no soucionar el problema, no tiene que ver. No se trata de cómo son tus URLs, se trata de cómo otros accedan a ellas.

      Es decir, tu URL puede ser así:

      http://[tudominio]/mi-pagina

      Pero la liamos si un enlace apunta a ella de este modo:

      http://[tudominio]/mi-pagina?par1=valor1&par2=valor2&%5B…]

      Y eso no está bajo tu control.

      Lo que hace el código del .htaccess es eliminar esa parte de parámetros para que la caché del blog no interpreta estas URLs como diferentes a la original cuando no lo son.

      ¿Me explico?

      ¡Un saludo!
      Berto

  2. Berto, yo tengo como proveedor a goddady y me ocurrido todo lo que mensionas sobre la deficiente seguridad de wp. Ahora, tengo problemas con mis cuentas de correo alojadas en cpanel. Cada vez que envio correos a empresas con altos niveles de seguridadme rebotan por spam o virus detectado. Hable con la gente de goddady y la solucion que me dan es pasar los correos de cpanel a oficce 365 con un costo cercano a las Usd400.

    Tu que me puedes recomendar para solucionar este problema?

    Saludos

  3. Hola Berto gracias por la explicación, tengo una duda yo tengo hosting con GoDaddy y de un tiempo para acá me ha venido apareciendo un aviso acerca de que estoy al límite de la utilización de archivos (es de 250.000 y estoy por los 214.000 pero no entiendo porqué hay tantos “archivos” si en realidad lo que tengo son como 200 entradas nada más (mi sitio es como un blog) tendrá algo que ver con bots o ese tipo de cosas porque no veo donde pueden haber tantos archivos además de que he visto lo que comentas acerca de breves caídas de la página… si me puedes dar una luz te quedo inmensamente agradecida. Saludos desde Colombia.

    • Berto López dice:

      Hola Carolina,

      Desde la distancia es imposible dar con la causa. Eso es algo que se lo tienes que plantear al soporte técnico y que te lo aclaren.

      ¡Un saludo!
      Berto

  4. Perdona Berto, estoy leyendo esta entrada y te quería hacer una pregunta si es posible.

    Si desde una pag. dinámica se crea una pag. estática en la Caché siendo la URL “normal”, ¿porque para una URL parametrizada no se crean N páginas estáticas en la Caché desde la página dinámica de forma que se pudiera emplear la misma operativa de acceso en primer lugar a la Caché también en este caso ?? Ya que entiendo que cada parámetro de la URL parametrizada tiene un conjunto finito de valores conocidos ¿no?

    Muchas gracias y perdona mi ignorancia.

    • Berto López dice:

      Hola Pablo,

      En primer lugar, se puede hacer, es decir, el plugin que usamos nosotros, por ejemplo, WP Super Caché, te permite hacerlo.

      Pero lo cierto es que en muchos casos, si se dispararía el número de entradas de caché y no está claro que merezca la pena cuando normalmente la enorme mayoría de las visitas (+90%) van a ser a URLs sin parámetros.

      ¡Un saludo!
      Berto

      • Si, pero si es el 10% restante el que origina “el caos” y no siendo en la actualidad ningún problema el tema de memoria como sucedía en tiempos pasados, no entiendo porque no se tiene en consideración.

        Perdona de nuevo y gracias por responder

        • Berto López dice:

          Hola de nuevo,

          Para que el hosting compartido puede venderse a los precios irisorios a los que se vende hoy en día y que lo ha hecho asequible para todo el mundo, los recursos, tanto memoria como CPU, sí son un problema y tienen que ajustarlos bien. Dar memoría y CPU a tutiplén dispararía los precios.

          ¡Un saludo!
          Berto

  5. Muy buen post.

    Siempre he utilizado Joomla y todas nuestras web estan bajo este CMS. Tengo una web con 4000 visitas promedio y otra promedia cerca de 1000 diario. Me ha costado trabajo mantenerla “corriendo” estables ya que hay momentos en las que hay alguna informacion que eleva las visitas y me friza el servidor.

    Decidí alquilar un servidor dedicado para el hosting de nuestras web y hemos tenido muchos inconvenientes en los dias que hay muchas visitas pero, ya hemos encrontrado normalizarlas y tenemos ya un buen tiempo que el servidor no se ha frizado.

    Comparto con ustedes lo que he tenido que hacer:

    1. Obviamente hemos tenido que habilitar el CACHE de Joomla, en una de las web esta con unos 10 minutos y otra con 5 minutos.

    2. Instalamos SQUID en el servirdor como proxy.

    3. Habilitamos compresion gzip.

    Mientras nuestras web recibian menos trafico, con estos bastó pero aun el servidor se frizaba.

    Hay muchas otras configuraciones que hay adjustar dependiendo cada servidor. Hicimos unos ajustes en la configuracion de Apache y MySQL que ha mejorado bastante el rendimiento del servidor como wait_timeout, max_connection y los valores KeepAliveTimeout, y Timeout, estos solo por mencionar.

    Fue muy dificil conseguir la estabilidad que actualmente tenemos y aun no ha sido una solucion “perfecta” o un “one size fits all”.

  6. Estupendo artículo. Tengo muchos días más de 3000 visitantes en la web y últimamente he notado algún problema que no sabía de dónde venía, no soy ninguna experta… hala, otro frente abierto y más temitas que estudiarme ;). Muchas gracias.

    • Berto López dice:

      Hola Miríam,

      Normal… Es un umbral típico en el que empiezan los problemas con la mayoría de los hostings. Como te has leído el post, mi consejo ya sabes cual es 🙂

      ¡Un saludo!
      Berto

  7. Hola, tal vez no tenga qué ver con el tema o tal vez un poco.
    Si teniendo una batalla con mi hosting compartido (GoDaddy) y planeo rentar un VPS y montar los dos blogs que administro (Espero que me funcione bien con ambos) Generalmente, amobos blogs llegan a picos que sobre pasan 30 usuarios online pero lo normal es que ronden los 15 a 25 usuarios simultáneos según Google Analytics. Creo que tengo bien optimizado mi sitio porque cuando no hay problemas con el hosting compartido carga muy rápido en en promedio de 1 a 1.5 segundos.
    En escuchado que NGINX es mejor que Apache pero no se si lo recomiendes o si es un mito que tiene mejor rendimiento. No soy experto pero creo poder con un vps no administrado y me muevo mejor con Apache y no sé qué tanto cambie o el htacces son iguales o si me quito de broncas, lo administro yo y con apache pero cuidando al máximo la seguridad, optimizar, etc.

    ¿Qué opinas?

    • Berto López dice:

      Hola Tomás,

      No soy administrador de servidores web y ese sentido no me atrevo a recomendarte uno frente a otro. Lo que te puedo decir es que Nginx efectivamente tiene muy buena prensa por su ligereza y escalabilidad y lo usan cada vez más proveedores de hosting.

      Un saludo,
      Berto

  8. Impresionante análisis Berto. Hace tiempo que te sigo y me encantan tus contenidos. Muy útiles y aclaratorios.

    También comentarte que los enlaces que incluyes, como el del hilo en Google+ sobre el problema de cron-jobs de WordPress, me han resultado muy útiles.

    Un saludo!

  9. Hola,

    Excelente artículo, me ha dejado claros algunos puntos sobre caché en WordPress que tenia trasnochados de tanto Joomla 🙂

    Una duda que me asalta es si al final es conveniente cachear RSS o Feeds para mejorar la carga o si este punto acaba siendo indiferente para los consumos del servidor cuando se visita el sitio WP correspondiente.

    Saludos y gracias!!

    • Berto López dice:

      Buenas,

      En principio es el mismo problema porque cualquier contenido de WordPress, sin caché, se construye sobre la marcha. Me figuro que en Joomla es similar.

      Lo que no tengo tan claro es que carga real supone. Quiero decir, ¿los lectores de Feedly, tirán directamente de una caché propia de Feedly o leen todos el feed RSS del blog?. La verdad es que estas cosas ya no las sé, un día habría que investigarlo.

      Por otra parte, también hay que tener en cuenta que al usar un servicio como Feedburner o Feedblitz, la carga se deriva a este servicio.

      ¡Un saludo!
      Berto

  10. Otro post increíble. Gracias por ayudar a los blogueros. Me pregunto si tengo pensado abrir blogs con Blogger, ¿a partir de que tráfico diario tendré problemas?

  11. Hola:

    Solo un par de comentarios:

    1. Hay muchos blogs con la misma temática de este blog, pero este tiene algo que lo diferencia del resto. Este blog soluciona problemas. Es práctico, útil y va al grano. Sin piruetas, sin excentricidades, sin adornos que no aportan nada. Yo he conseguido hacer y entender cosas que hasta ahora no había podido. Así debería ser cualquier blog.

    2. El problema nº1 de WordPress es…los usuarios de WordPress. Hemos endiosado un CMS que no es tan bueno como pensamos. Los fantásticos temas y plantillas que día a día van saliendo son los arboles que no dejan ver el bosque. WordPress es lento, muy lento. El hecho de que haya tropecientos plugins que hacen mil chorradas tampoco lo hace bueno de por si. La velocidad del back-end con 10 plugins instalados es una pesadilla. El front-end con tráfico cero ya es lento. Joomla está más optimizado y es más rápido pero no es tan “user friendly” como WordPress. Yo uso WordPress pero en cuanto salga una solución ligeramente mejor me cambio sin pensarlo.

    • Hola David,

      Estoy bastante de acuerdo en que no se es todo lo crítico que se debería con WordPress. Efectivamente es lento, pero con una buena caché esto se soluciona.

      En mi experiencia es mucho peor que por la falta de seguridad inherente que describe este post, cuando empiezas a tener tráfico serio como es mi caso los problemas se disparan totalmente. El tema de los ataques de spam ?replytocom es una pesadilla y no tendría que ser así, el patrón es sencillísimo de detectar y WordPress debería estar diseñado para defenderse.

      Por la misma regla de tres, cualquier blog WordPress si lo hinchas a peticiones con parámetros variando solamente el valor del parámetro, lo tumbas en segundos. Eso no es aceptable a estas alturas.

      Por lo demás, sigue siendo una excelente herramienta, pero el tema seguridad y resistencia frente a ataques incluso simplones ya ha pasado de castaño oscuro.

      Espero que no les pase como a Google dada su posición en el mercado y empiecen a pasar de todo perjudicando a sus usuarios sin remordimientos.

      ¡Un saludo!
      Berto

  12. Sin duda, un interesantísimo post, súper didáctico y de gran utilidad. Me lo guardo para enfrentarme a ello próximamente. Enhorabuena por vuestra profesionalidad.

  13. La verdad que administrar un vps para gestionar tu propio blog puede llegar a ser un verdadero quebradero de cabeza, pero si te aventuras a ello lo mejor es instalar en el servidor eaccelerator, es un sistema de cache para el propio php y el modulo Page Speed de google para el servidor apache, tras estas instalaciones y un apache2.conf bien configurado el servidor va como la seda y aguanta hasta efectos meneame…

    • Berto López dice:

      Buenas,

      Totalmente de acuerdo, esa es una buena vía. Lo malo es que en los hostings compartidos normalmente no tienes este tipo de opciones con lo cual tienes quye buscarte la vida. Y en los VPS muchas veces tienes que contratar ya un nivel de servicio bastante alto para que puedas tener la posibilidades de implementar este tipo de cosas.

      ¡Un saludo!
      Berto

      • Si, si, para contrar un VPS y administrarlo tu mismo tienes que tener ciertos conocimientos, pero para que se sepa, mi experiencia con esas dos implementaciones ha sido muy buena y a veces se desconoce, así que lo recomiendo encarecidamente si llevas un VPS, está claro que un compartido son lentejas…

Deja un comentario

Para ello, por favor, sigue estas pautas, por respeto a nuestra comunidad (y a nosotros):

  • Usa tu nombre personal, ni nombres inventados, ni el de tu web, ni el de tu empresa.
  • Cuida la redacción: separa párrafos y no escribas en mayúsculas (equivale a gritar).
  • No dejes enlaces a tu web en el comentario, dispones del campo "sitio web" para ello.
  • Eliminaremos comentarios con insultos, ofensivos o con lenguaje soez.

*

 

Rellena el formulario y accede a nuestro training rápido de pro-blogging

Aprenderás paso a paso y desde cero cómo usar las mejores técnicas, trucos y secretos de los top bloggers para dar el salto al siguiente nivel

Y todo 100% gratis :)