content top

Mejorar la velocidad de carga web CON y SIN CDN

Si bien el hosting es una pieza clave para tener un buen desempeño y una buena velocidad de carga en un sitio web, existen otros factores y técnicas que nos ayudaran a lograr una buena velocidad de carga y una genial usabilidad para el usuario. Entre los factores que más fastidian” la velocidad de carga es la distancia física existente entre el servidor que aloja el sitio web y el computador del visitante, ya que el servidor puede estar en España y el visitante puede acceder al sitios desde Australia, en este caso existen una distancia de más de 10.000 kilómetros, obviamente las latencias son mucho más altas que si un visitante de Madrid entra a un servidor ubicado en Madrid. El uso de un CDN en un sitios nos ayudara a mantener una buena velocidad de carga a pesar de que los visitantes entren al sitio web a miles de kilómetros del servidor web, así el servidor web asimismo se descarga de la labor de servir los ficheros estáticos del sitio web. Muchos webmasters y administradores de servidores no apoyan la versión de que un CDN puede ayudar mucho a reducir la carga del servidor y a prosperar la velocidad de carga, mas yo en este caso quiero aportar pruebas para que los lectores puedan ver por sí mismos como mejora la velocidad de carga en las diferentes unas partes del planeta utilizando un CDN, pudiendo ver la diferencia entre emplear CDN y no utilizar CDN en un mismo sitio web. Para las pruebas hemos usado un servidor web alojado en España y CloudFlare como CDN, para probar la velocidad hemos utilizado PingDom Tools. Vamos a iniciar a mostrar las pruebas efectuadas, en primer lugar vamos a enseñar el CON CDN y el SIN CDN para un servidor web alojado en España, realizando la prueba desde Amsterdam (Holanda): Como puedes ver, en este caso es en el que menos se nota la distancia, en tanto que el servidor y el visitante se hallan ambos en Europa, donde la conectividad es genial y no tienen que intervenir los cables trasoceánicos. En el próximo caso exponemos exactamente el mismo caso, servidor en la villa de Madrid y visitante en Estocolmo (Suecia), las pruebas de nuevo se efectúan con y sin CDN: En un caso así los desenlaces son hasta mejores que en el caso de Amsterdam, puesto que la distancia más o menos es exactamente la misma y semeja que la conectividad es mejor con Suecia que con Holanda. En el siguiente caso vamos un poco más lejos, el servidor en España y el visitante accede desde la costa este de USA, en concreto desde...

Read More

Desinfectar virus de servidor Linux con Maldet y ClamAV

El malware y los virus no solo se extienden a través de ordenadores Windows, cada dia cientos y cientos de miles de servidores web son inficionados en todo el mundo aprovechando vulnerabilidades en el software o fallos de seguridad en el código de las aplicaciones web instaladas en esos servidores. Ya hemos hablado múltiples veces de la seguridad de WordPress y de lo que puede ocasionar un simple malware en un sitios en un servidor, pudiendo llegar a inmovilizar todo el servidor y a ocasionar graves consecuencias en la reputación de la dirección IP o bien aun el robo de datos. El proceso que describiremos en este manual lo usamos bastante cuando alguno de nuestros clientes del servicio de servidores VPS nos avisa de que tiene malware en su servidor VPS, en el caso de nuestros servidores dedicados no nos pasa, puesto que todos nuestros dedicados son administrados y tenemos medidas proactivas para que el malware no llegue a colarse”. Cuando nos avisan de que un VPS con Linux tiene un malware lo primero que hacemos es entrar por línea de comandos mediante SSH (Putty) y ejecutar el que estimamos entre los mejores antimalware para Linux: Maldet. LMD (Linux Malware Detect) o asimismo llamado Maldet es un antimalware bastante potente que se acostumbra a combinar con ClamAV, un antivirus opensource. Esta combinación es bastante potente y es de la que hablaremos en este pequeño manual. En este caso vamos a proseguir el manual sobre uno de nuestros VPS con CentOS instalado, con lo que el manual es válido para las últimas versiones de CentOS y además de esto para otros sistemas operativos similares como Fedora o RedHat. Lo primero que vamos a hacer es ejecutar la descarga de Maldet desde un sitios, en tanto que no es posible encontrar Maldet en los repositorios: wget http://www.rfxn.com/downloads/maldetect-current.tar.gz Ahora vamos a descomprimir el archivotar.gz que acabamos de descargar desde RFXN con el siguiente comando: tar -xvf maldetect-current.tar.gz Lo siguiente que vamos a hacer es entrar a la carpetita que se termina de crear al descomprimir el archivotar.gz, la carpeta suele llevar el nombre de maldetect-” y la última versión libre que es la descargada, por ejemplo: maldetect-1.4.2”. Entramos dentro de la carpeta con un comando afín a este, pero ajustándonos a la versión que hemos descargado: cd maldetect-catorce Y ahora ejecutamos el instalador de Maldet utilizando el install.sh” que contiene su carpeta, para esto ejecutamos el siguiente comando tras entrar en la carpeta con el comando anterior: ./install.sh Se descargaran durante la instalación las últimas versiones de las firmas de detección de Maldet, esto es bueno puesto que cuanto más actualizadas estén las firmas de nuestro anti-malware,...

Read More

Servidor para mucho trafico – Optimizacion de WordPress

En general cuando exponemos optimizaciones de WordPress, lo que hacemos es exponer las velocidades de carga de antes y después, en el caso de nuestros servidores VPS optimizados, asimismo acostumbramos a exponer la velocidad de carga en el precedente hosting y la diferencia al migrar a nuestros servidores. Mas en un caso así vamos a enseñar algo diferente, vamos a enseñar y también intentar exponer el nivel de eficacia de nuestras configuraciones en servidores VPS y servidores dedicados. Hace dos días mientras estábamos en un día normal, pero bastante ajetreado nos brincaron las alarmas del sistema de monitorización debido al ancho de banda que consumía el servidor dedicado de uno de nuestros clientes del servicio, curiosamente en el dedicado solo hay weblogs WordPress, no se emplea el servidor como CDN, con lo que nos pusimos a mirar que ocurría. Al entrar al panel de control del servidor dedicado  nos encontramos con las próximas gráficas: Uso de ancho de banda en el servidor: Uso de recursos de CPU del servidor (Intel Xeon E5-1650v2 de 8 threads a tres con cuatro Ghz): Empleo de memoria RAM en el servidor (treinta y dos GB de RAM DDR3 a 1866 Mhz). Como puedes ver el consumo de ancho de banda es bestial, si bien cada página servida a los visitantes oscila entre 1,5MB y 2MB, por lo que no hablamos de un consumo por una mala optimización de las imágenes, sino más bien un alto consumo por un enorme volumen de tráfico. Es increíble ver como un servidor está sirviendo más de seiscientos Mbps de ancho de banda sin ni tan siquiera notarse en el desempeño general del hardware, hasta el instante solo habíamos visto picos de uso de ancho de banda PARA UN SOLO CLIENTE de hasta cuatrocientos Mbps, jamás de quinientos Mbps o bien pero de 600 Mbps, si bien pronto aguardamos ver picos de hasta 1 Gbps. Como puedes observar, pese al consumo, la CPU y la memoria RAM ni se alteran, con lo que consideramos que la optimización de este servidor dedicado y de este WordPress es un éxito. En este caso la configuración del servidor está basada en 2 puntos clave que son los cimientos sobre los que se sostiene el volumen de tráfico: Nginx como proxy inverso y como cache: Cacheamos las páginas con cache de veinte minutos, con esto el servidor soporta de forma perfecta los picos de tráfico virales sin subir el consumo de RAM y CPU de forma considerable. OPCache: Nosotros empleamos Zend OPCache ya que en un benchmark de OPCache que hemos hecho hace unos meses nos hemos dado cuenta de que Zend OPCache es la mejor solución...

Read More

Optimizando WordPress – Caso real #8

Ya hacia un buen tiempo que no publicábamos algo relacionado con una optimización de WordPress, en un caso así más que una optimización es una demostración de lo que se consigue migrando tu sitio web a un servidor VPS optimizado de sered Networks. En este caso específicamente el cliente migro un sitios con unas 300 o bien 400 visitas concurrentes continuas al servidor, finalizamos la migración con la implementación de Memcached a través de el uso del complemento Flexicache que nos deja guardar cache en la memoria RAM con la extesion PECL Memcached. El sitio anteriormente estaba sobre un servidor VPS de un proveedor estadounidense, un VPS con 2 GB de RAM y 2 vCores con cPanel como panel de control, el resultado de las pruebas de carga utilizando la herramienta de pingdom.com fueron los siguientes: Como puedes ver en las precedentes imágenes, la velocidad de carga en el servidor anterior no era tampoco demasiado mala, mas el usuario migro a nosotros porque el servidor VPS precedente era incapaz de sostener la carga de usuarios cuando ocurría un pico de tráfico. Después de migrar el sitio e incorporar Flexicache con Memcached conseguimos los próximos resultados de carga: Esta mejora en la velocidad de carga por debajo de 1 segundo se consigue usando Flexicache con Memcached y a la vez utilizando su modo standalone, por si fuera poco el servidor VPS lleva Nginx como proxy inverso con el cache activado en nivel 2, por si fuera poco, Zend OPCache guarda los archivos PHP procesados en la memoria RAM y esto calma bastante la carga. En muy pocos casos podemos decir que hemos hecho que el sitio cargue bajo 1 segundo, supongo que la buena optimización de la plantilla instalada por el cliente tiene bastante relación con la velocidad de carga. Si precisas progresar la velocidad de carga de tu sitios o bien sitios web, puedes contactar con nosotros sin compromiso y te recomendaremos que servidor VPS se ajusta a las necesidades de tu...

Read More

FancyBox puede provocar el hackeo de tu WordPress

Hace unas horas aparecía en Internet una noticia sobre un esencial fallo de seguridad en un plugin de WordPress muy utilizando: FancyBox para WordPress. Nosotros hemos protegido de forma rápida a nuestros clientes de hosting compartido contra el malware que puede ser insertado en WordPress a través del fallo de seguridad de FancyBox. Recomendamos a todos nuestros clientes del servicio de servidores VPS, servidores VPS optimados y servidores dedicados que actualicen su complemento FancyBox en caso de tenerlo instalado o bien que lo desinstalen temporalmente hasta el momento en que aparezca una solución completa para el problema, en tanto que es mejor prevenir que tener inconvenientes. A través de este fallo de seguridad el atacante puede efectuar una inyección XSS en el sitio web WordPress logrando acceso al sitios y si el servidor no está adecuadamente configurado y protegido el atacante podría conseguir acceso completo al servidor. En el blog de Sucuri, en la nota oficial de la vulnerabilidad, se comenta un ejemplo de como el atacante puede conseguir la inyección XSS mediante una solicitud POST a un factor del plugin FancyBox for WordPress: Esta vulnerabilidad se puede prevenir por medio de una modificación de las reglas del firewall del servidor, que es lo que hemos hecho para nuestros clientes de alojamiento compartido, en el caso de nuestros servidores VPS optimizados solo existe una solución: actualizar o borrar el plugin de la instalación de WordPress. Esta vulnerabilidad se añade a la lista que poquito a poco va incrementando de vulnerabilidades que aparecen en plugins populares durante el último año, la ultima fue una vulnerabilidad fundamental en el plugin Revolution Slider para WordPress (plugin que empleamos nosotros en este sitio web) y la vulnerabilidad relacionada con el malware CrypPHP que causo daños esenciales en instalaciones de WordPress. Si precisas ayuda para sostener tu WordPress seguro puedes contactar con sered.net y te informaran sin ningún compromiso de de qué forma puedes tener tu WordPress seguro, si ya eres usuario nuestro no te...

Read More

Amazon CloudFront con W3 Total Cache en WordPress

Para el que no conozca exactamente lo que es un CDN tenemos un artículo publicado anteriormente donde explicamos precisamente lo que es un CDN o bien Content Delivery System. Estos sistemas sirven esencialmente para proporcionar el contenido estático por medio de diferentes POPs, puntos de presencia o servidores distribuidos alrededor del planeta. Nosotros generalmente empleamos Amazon CloudFront, pero en este caso hablaremos de de qué forma incorporar Amazon CloudFront en un sitios WordPress usando para ello el plugin W3 Total Cache. La razón de emplear el plugin W3 Total Cache es que realiza la gestión automática de los buckets S3 que van a marchar como origen y gestiona también el adecuado funcionamiento de los CNAME que redireccionan a la dirección de CloudFront. Evidentemente ya antes de iniciar con la configuración de Amazon CloudFront debemos instalar W3 Total Cache, y ya que está instalado deberíamos implementar el cache, ya que de este modo lo aprovechamos. Si buscas un servidor VPS preparado para utilizar el cache de W3 Total Cache en Memcached puedes consultar los precios de nuestros servidores VPS optimizados con VestaCP. Antes de nada, quizá te interese ver todo paso a paso a través del siguiente videotutorial: CONFIGURAR W3 TOTAL CACHE Primero vamos a dirigirnos a la sección General Settings” de W3 Total Cache, a la sección CDN”: Debemos elegir Amazon CloudFront” en el bloque Origin Push” en el desplegable y pulsamos el botón azul Save all settings”, de momento no marcamos la casilla CDN” como Enable puesto que por el momento no vamos a activar CloudFront hasta tenerlo plenamente configurado. Vamos a dirigirnos a la sección de CDN de W3 Total Cache, para esto vamos a utilizar el menú de Performance” que se colocan en el panel de WordPress cuando instalamos W3 Total Cache: Ahora nos dirigimos a la sección Configuration”, donde debemos configurar los datos de autentificación de la cuenta de Amazon AWS. Lo siguiente que tenemos que hacer es configurar Amazon AWS para conseguir los datos que debemos insertar en W3 Total Cache. CONFIGURAR AMAZON CLOUDFRONT Lo primero que vamos a hacer es crearnos una cuenta en Amazon AWS, si es una nueva cuenta vamos a tener la posibilidad de aprovechar el Free Tier de Amazon, que incluye cincuenta GB de tráfico en Amazon CloudFront y dos mil de peticiones por mes. Después de crear la cuenta vamos a crear los credenciales de autentificación a fin de que nuestro WordPress pueda acceder al API de Amazon CloudFront. En el panel donde se muestran todos y cada uno de los servicios de Amazon AWS nos dirigimos a IAM ya antes de nada: Vamos a dirigirnos a la sección Users” y pulsamos sobre...

Read More
content top