Parece que ya hemos vuelto a la vida digital de nuevo. Llevo tres días con el hosting haciendo cosas raras. Parece que ayer por la tarde empezó a estabilizarse y esta mañana ya no me llegan avisos de errores por ningún sitio y me deja ya publicar cosas en el blog.
El tema tiene mucha retranca. Resulta que me dicen de la empresa de hosting que he consumido muchos recursos (creo, porque no me lo dicen claro, que se trata deconsumo de procesador) y que por eso me han desconectado. En teoría (porque ya no tengo nada claro) tengo unVPS. Yo imaginaba que en un VPS si tengo un 4% del consumo de CPU, pues no puedo pasarme de ahí. Si hago algo mal y mi web necesita más ciclos de procesador, pues irá más lenta. Pero parece que no es así en mi caso.
Ya me he perdido por las ramas. Me dicen del hosting que como tengo muchas visitas, y que el nuevo tema consume mucha máquina, pues me bloquean primero y no preguntan después. Pero lo divertido, es que la semana pasada a raiz del exito de una entrada que recibió cuatro veces más visitas de lo normal, el blog pegó un bajón de rendimiento muy serio. Vi además que me estaba comiendo el ancho de banda mensual muy deprisa. Así que me pasé todo el fin de semana tratando de aprender a optimizar un blog de WordPress para conseguir mejores velocidades (tengo la entrada escrita, contando lo que hice y los resultados que obtuve). Para resumirlo, antes de hacer nada la carga de la página principal del blog me daba una media de 36 segundos y pesaba 579 k. Al final del proceso el tiempo medio bajo a 12 segundos y la página pesaba solo 90k. Y usando el Yslow de Yahoo, pasé de tener una puntuación de 46 puntos a 84 puntos. Los principales puntos que toque fueron:
– Elimine tres ficheros de javascript para hacer efectos en algunos plugins del blog.
– Unifique casi todos los .css en uno solo. Luego optimicé dicho fichero. Pase de cargar 7 .css con un peso de 60k a dos con un peso dd 11k.
– Active en el servidor la compresión gzip del contenido que se envia (yo creo que esto fue lo que provocó el aumento de consumo de procesador, pero no sé como comprobarlo)
– Indique al boot de google que entrase menos a la web y que dejase más tiempo entre visita y visita. Había detectado que las visitas del boot de google se estaban triplicando en estos dos últimos meses.
– Elimine varios plugins que no pasaron un filtro cosas que hacen/consumo de tiempo de carga
– Quite todas las llamadas a la base de datos de WordPress en el header y en el footer que podían sustituirse por código estático: nombre del blog, tipo de codificación, rss…
Y resulta que depués de estar el sábado y el domingo un montón de horas leyendo, aprendiendo y probando, dos días después muere el hosting, porque el tema no está optimizado… me dan ganas de hacerle algo malo a alguien.
Así que de momento he eliminado la compresión en el hosting y vamos a ver si esto mejora. Y creo que tengo el hosting en la televisióne española en blanco y negro, esa que cuando yo era niño de vez en cuando mostraba el cartel de: Perdonen la interrupción, pero por causas técnicas ajenas a nuestra voluntad, no podemos seguir con la emisión. Y nunca sabíamos cuales eran esas causas técnicas de tan ajenas que eran y de tan poca voluntad que había en explicarlo.
Anterior y Posterior
20 Comentarios
Comentarios Cerrados
Esto de los hostings es muy cachondo… te ofrecen planes con condiciones draconianas de consumo.
Pero lo peor es que ante un tema así, en lugar de hablar contigo o hacer que la web vaya más lenta, te desconecten sin más explicaciones.
Desde luego, eso del servicio al cliente no lo tienen muy trabajado.
Supongo que has hecho bien, por lo que cuentas prima la eficiencia, pero me da pena por la mantenibilidad 🙁
Creo que es mala idea deshabilitar la compresión por gzip. Te recomiendo que busques las cosas que publicó Ricardo Gallir sobre la optimización del menéame. Por ejemplo un post donde habla de eso: http://mnm.uib.es/gallir/posts/2006/12/11/905/
La cuestión es que cuanto antes acabe el apache de servir una página menos tiempo estará consumiendo CPU y memoria, y lo paradójico es que comprimir la página con gzip compensa.
Una duda, para decirle a google que no rastrease la web con tanta frecuencia ¿usaste las Google Webmaster Tools?
Y por último si realmente quieres reducir el gasto de CPU pasa de Apache, y usa nginx o por lo menos quítale módulos inútiles como el de Frontpage.
Suerte
hola supertendero!
Nosotros tenemos una web bastante concurrida y hemos tenido los mismos problemas. Tenemos un VPS visitas moderadas y nos cierran el VPS porque dicen que consumimos demasiada cpu.
Llevamos 4 meses con el problema y hemos probado a usar caché, quitar plugins, blablabla a usar de todo pero nada, todo se va al garete al de unos días, el principal problema para nosotros son los bots y spiders, el de google ultimamente tmb nos está machacando y no vale con decirle al bot que nos visite menos amenudo, esas ordenes como supongo que sabes se caducan al de pocos meses y te verás en la misma situación cada mes.
Si tienes VPS presupongo que tienes linux y presupongo que cuenta ssh. Nosotros con un cron, cada 5 min guardamos el uptime para guardar el cpuload y luego mostrarlo en gráficas y así monitorear un poco.
Igualmente por cron lo que hacemos es qeu una vez por minuto comprobar que si la cpuload es mayor de 1.0 renombrar los index.php a otro y poner un index.php de backup que tenemos con solo código HTML donde dice que el servidor volverá a la vida en pocos segundos. esto hace que la cpuload se calme cuando hay picos y el hosting no se mosquea, pero tampoco resuelve el problema.
Pero sin ninguna duda, y esto igual no te lo crees, lo que de verdad nos ha bajado el cpuload de 1.0 a 0.1 de media, ha sido poner en todos los index.php, un require_once a un pequeñísimo script hecho de la casa que logea las IPs en una tabla de la base de datos, borra las visitas que tengas más de 45 segundos, deja pasar a los que hayan visitado la web menos de 7 veces en 45 segundos, y muestra un mensaje de error y de invitación a descansar un minuto a los que han visitado la web más de 7 veces en menos de 45 segundos. Esto contiene a todos los bots y spiders que son los más peligrosos no porque sean los que más te visitan pero sí porque lo hacen en oleadas y en el mismo segundo varias páginas y eso tira al servidor con pocas visitas.
Si quieres te paso el script (responder por aquí), es hipersencillo elevado a la máxima exponencia para que no sobrecarge todavía más y llevamos 2 semanas con el cpu usage ridículamente bajo, nos han felicitado y todo en el hosting (estamos en inmotion).
Que hosting usas? Si usas VPS te recomiendo AXARNET que va bastante bien, es el que uso yo y no es muy caro http://www.axarnet.es/vps/index también tienes por buen precio piensasolutions http://www.piensasolutions.com/servidores-virtuales/index.htm
Un saludo
Tendero, te recomiendo redcoruna.org. Son muy profesionales y tienen un servicio atención al cliente estupendo.
cuwhois https://changlonet.com
Has pasado de tener un 4 en diciembre a un 3 ahora mismo.
En cuanto al hosting Jaguar Technologies LLC, la primera noticia.
Yo buscaría otro que ofreciese mejor servicio. Por supuesto, fuera de España y con atención en español.
Supongo que tienes activado el plugin WP-cache o similar.
***************
@juantxo
¿Me podrías pasar el script para echar un vistazo?
efecto meneame…
Hola, la red de jaguar no tiene muy buena fama, de todos modos creo que el tendero tiene contratado el hosting a otras gente, la cual a su vez alquila los servidores/vps a jaguar y luego los revende, te recomiendo alquilar un servidor baratito o un vps fiable, en alemania o francia, nada de españa o usa a ser posible.
En cuanto a lo que te tiren el vps por consumo de cpu suena muy raro…lo normal seria en caso de que necesitara muchos recursos limitar el consumo de cpu a ese vps (que normalmente casi siempre esta limitado desde un principio), echale un ojo a los vps de ovh (no se si estan en francia o españa) pero tienes buenos precios con trafico ilimitado, si no en alemania tienes muchas opciones tambien.
Mi experiencia con Hostings (desde el 2001):
A) Nunca contrates en España, dan asco. En mi caso tengo 1AND1 (que tiene filial en españa) pero servidores dedicados en Alemania.
B) Nunca contrates un VPS: NO SIRVE PARA NADA. Tienes todas las desventajas de un hosting compartido y todas las desventajas de un hosting dedicado.
No se si os compensa pasaros a un servidor dedicado, en 1AND1 están por 39 euritos y puedes montar CENTENARES de dominios…
Un vps siempre compensa, no compartes los datos ni el servidor con otros, en hosting compartido si hay cualquier fallo de seguridad en cualquier dominio puede verse afectado todo el servidor, la seguridad del vps depende de ti, puedes instalar y configurar todo como quieras, es simplemente un servidor dedicado con menor potencia (la que te limiten), instalar el software y versiones que quieras, usar el panel de control que quieras, hostear los dominios, correo electronico que quieras etc, si se contrata un vps lo suyo es de al menos 512mb (aunque optimizando puedes tener suficiente con 200mb aunque la pag tenga miles de visitas).
El pero que lo tienes que configurar tu o tener a alguien que lo haga, pero compensa, ademas si hay algun fallo tendras claro porque es y no te pueden colar cualquier bulo los del hosting.
Devastador efecto menéame en el blog, como les suele pasar a muchos.
Aunque ayuda bastante que las condiciones de los proveedores dejen tanto que desear.
Me alegro que estés de vuelta, al menso todo esto ha servido para aprender algo.
El efecto meneame no ha sido solo. La semana anterior tuve más visitas con otro artículo en Meneame. Y cuando tenía el hosting compartido tuvimos varios enlaces en blogs y páginas que atraen mucha atención y no cayó el blog. Esta vez ha coincidido, pero no es solo el meneame.
a ver, que puse este post antes pero ha desaparecido (a las 19.30…)!!!! (o lo pondría yo mal supongo que iba con prisas…)
El enlace con los scripts va aquí: http://www.bultza.com/archivos/access_security.zip
PAra instalarlo, primero el script de la base de datos SQL, es una tabla con 3 campos supersimple que siempre va a estar cuasivacía.
Luego el archivo php lo rellenais con vuestros datos de la base de datos.
Luego en vuestros archivos index.php teneis que poner como segunda lína (la primera será la que abre la etiqueta php)
require_once(dirname(__FILE__) . ‘/access_security.php’)
Con eso debería ser suficiente 😉