Servidor para mucho trafico – Optimizacion de WordPress

Posted by on mar 16, 2015 in cpanel, 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:

trafico viral servidor

  • Uso de recursos de CPU del servidor (Intel Xeon E5-1650v2 de 8 threads a tres con cuatro Ghz):

cpu trafico viral pico

  • Empleo de memoria RAM en el servidor (treinta y dos GB de RAM DDR3 a 1866 Mhz).

memoria ram servidor

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 de OPCache para PHP.

Verdaderamente Nginx es quien nos ayuda a aguantar los picos de tráfico, en tanto que sino el consumo de PHP al administrar las paginas sería demasiado impacto para el servidor. Por otro lado, que los archivos estáticos se sirvan con Nginx ayuda mucho al desenlace final, Apache consume muchísimos más recursos si tiene que efectuar exactamente el mismo trabajo, se multiplicaría prácticamente por treinta el consumo de recursos en los picos de tráfico.

Como aclaración, asimismo deseamos remarcar que los blogs NO emplean ningún género de CDN como CloudFlare, CloudFront o MaxCDN.

Adicionalmente asimismo exponemos las gráficas mostradas por nuestro sistema de monitorización y alarmas Observium:

  • Uso de ancho de banda según Observium:

trafico viral

  • Empleo de CPU según el sistema de monitorización Observium:

traficoviral2

Como puedes ver,  estamos especializados en aguantar tráfico viral y logramos resultados bastante buenos logrando la mejor eficacia en las configuraciones de nuestros servidores y en los  Hosting WordPress.

Optimizando WordPress – Caso real #8

Posted by on mar 15, 2015 in cpanel, wordpress

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.

optimizacion wordpress

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:

wordpress optimizacion

wordpress optimizacion

wordpress optimizacion

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:

wordpress optimizacion

wordpress optimizacion

wordpress optimizacion

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 proyecto.

FancyBox puede provocar el hackeo de tu WordPress

Posted by on mar 12, 2015 in cpanel, 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.

seguridad wordpress 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:

fancybox vulnerable

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 cobraremos.

Hacienda rastreará más de 200 mil dominios en internet para batallar contra el fraude fiscal

Posted by on mar 11, 2015 in Hosting y dominios

La Agencia Tributaria acentuará la lucha contra las nuevas formas de fraude que se generan en la red, a través de la captación y explotación de la información pública libre en internet que deje descubrir actividades escondes o bien recursos objeto de un comercio ilegal. De esta forma consta en el Plan de Control Tributario dos mil quince de la corporación, publicado este miércoles en el Folleto Oficial del Estado (BOE).

En el plan Hacienda asimismo apunta que asimismo va a hacer actuaciones de control sobre aquellos fabricantes o bien prestadores de servicios que comercialicen sus recursos o bien servicios mediante internet para asegurar la conveniente tributación en España de las rentas generadas por esa actividad.

Dicha captación de información se efectuará mediante una serie de herramientas informáticas que dejarán ordenar y sistematizar la información. De este modo, está previsto cruzar la información de sobra de doscientos dominios para su siguiente integración a las bases de datos de la Administración Tributaria.

Del mismo modo, y al objeto de valorar la relevancia económica de las páginas de comercio online,  se procederá a la captación de los “rastros de éxito” que ofrecen las compañías expertas en análisis y valoración de páginas y en redes sociales.

Asimismo se utilizará la tecnología de las redes sociales para examinar operaciones comerciales entre agentes económicos para identificar patrones de comportamiento que se corresponden con actividades defraudadoras.

Amazon CloudFront con W3 Total Cache en WordPress

Posted by on mar 10, 2015 in cpanel, 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”:

cloudfront wordpress

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:

cloudfront wordpress

Ahora nos dirigimos a la sección Configuration”, donde debemos configurar los datos de autentificación de la cuenta de Amazon AWS.

cloudfront wordpress

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:

cloudfront wordpress

Vamos a dirigirnos a la sección Users” y pulsamos sobre el botón Create New Users”:

cloudfront wordpress

Durante la creación del usuario nos aparecerán los nuevos credenciales de acceso para el nuevo usuario:

cloudfront wordpress

Las credenciales tachadas en la imagen anterior son las que tienes que poner en W3 Total Cache:

cloudfront wordpress

Cuando las tengamos rellenadas pulsamos sobre el botón azul Save all settings” para que se guarden las credenciales de acceso.

Ahora vamos a cubrir una parte que dejaremos ahí para después, mas cubierta:

cloudfront wordpress

Nos tenemos que dirigir al panel donde controlamos el DNS del dominio para agregar múltiples subdominios en registros CNAME, en este caso vamos a incorporar los próximos 7 subdominios de CDN:

  • cdn1.midominio.es
  • cdn2.midominio.es
  • cdn3.midominio.es
  • cdn4.midominio.es
  • cdn5.midominio.es
  • cdn6.midominio.es
  • cdn7.midominio.es

Evidentemente debemos cambiar midominio.es” por nuestro dominio, generalmente solo se crean cinco subdominios, mas en un caso así se trata de un sitios que realiza muchas solicitudes al servidor, con lo que vamos a intentar paralelizar al límite las descargas de elementos al navegador del visitante.

Al rellenar esto ahora antes de nada lo que logramos es que al crear la distribución automáticamente se agreguen los CNAME a la lista de CNAMEs tolerados para repartir contenido.

Lo próximo que haremos es darle permisos a esta nueva cuenta, específicamente vamos a darles permisos de control total en Amazon S3 y control total en Amazon CloudFront.
Para ello nos dirigimos a la sección Users” y pulsamos sobre el botón azul Attach Usuario Policy”:

cloudfront wordpress

Nos aparecerá algo como esto donde debemos buscar los próximos 2 elementos y pulsar el botón Select”:

  • Amazon S3 Full Access
  • CloudFront Full Access

cloudfront wordpress

En ambas asignaciones de permisos debemos hacerlo separadamente, o sea, primero Amazon S3 Full Access” y más tarde CloudFront Full Access”, una primero y después la otra, separadamente, y aplicando las políticas de seguridad.
Sin este paso no podremos proseguir, esto es, nos fallara la creación del bucket en S3 y la creación de la distribución en CloudFront, ya que se precisan permisos específicos a fin de que W3 Total Cache pueda efectuar las acciones por API.

Ahora vamos a pulsar el botón Create distribution” en W3 Total Cache y debemos aguardar a que se termine de crear, el beneficio de W3 Total Cache es que creara de forma automática todo lo preciso a través de API para que no tengamos que preocuparnos de nada, solo de esperar.

cloudfront wordpress

Este proceso en el que se crea el bucket en Amazon S3 y la distribución en Amazon CloudFront de forma automática, puede tardar entre 10 minutos y 25 minutos dependiendo de las localizaciones elegidas para utilizar como CDN.
Al paso que se crea la distribución nos va a poner el estatus en progreso:

cloudfront wordpress

Cuando concluya se cambiara el In Progress” por Active”.

Lo próximo que haremos es rellenar algunos datos más en W3 Total Cache, específicamente el nombre del subdominio en CloudFront y los CNAME de nuestro dominio que se usaran como mirror y lugar desde donde se descargaran los estáticos.

cloudfront wordpress

En un caso así el panel de control es VestaCP, el panel de control que usamos en nuestros servidores VPS optimizados (de hecho se trata de uno de nuestros servidores VPS optimizados), pero los DNS se administran desde los DNS de CloudFlare, por lo que debemos agregar los registros CNAME en CloudFlare:

cloudfront wordpress

En el momento en que se propaguen los cambios DNS en el dominio vamos a poder acceder al mirror de CloudFront a través de esos subdominios.

Para revisar que todo está correcto y que podemos empezar a utilizar Amazon CloudFront en nuestro WordPress, puedes pulsar el botón Test S3 upload & CloudFront distribution” esto nos va a dar un mensaje de fallo en colorado si falla algo o nos dará un Test Passed” en verde si todo marcha correctamente.
Es importante comprobar si marcha ya antes de activar el CDN, puesto que si no dejaremos de ver el sitio web apropiadamente.

Frente a un mensaje como este deberíamos aguardar a que finalizara la propagación DNS:

cloudfront wordpress

También puede representar que es preciso incorporar los subdominios CNAME a la lista de CNAMEs de Amazon CloudFront para la distribución en cuestión:

cloudfront wordpress

Para editar la lista de CNAMEs debemos editar la distribución endesde la configuración para la distribución.

Cuando la prueba nos responda con el mensaje Test Passed” en verde, vamos a poder activar el CDN en la configuración general de W3 Total Cache.

IMPORTAR ELEMENTOS A AMAZON S3

Antes que CloudFront como CDN sea el responsable de subir los archivos a la red de distribución de contenidos, debemos importar los ficheros estáticos a Amazon S3 utilizando W3 Total Cache, esta acción posteriormente la realizase de forma automática con unos cambios que haremos.

cloudfront wordpress

En la precedente foto podemos ver los elementos que podemos elegir para importar y proporcionar a través del CDN. La pantalla de importar elementos es algo como esto:

cloudfront wordpress

El proceso de importado puede tardar aproximadamente dependiendo del número de elementos estáticos que tenga el sitio.

Para olvidarnos de volver a hacer la importación y que se realice de forma automática cuando el CDN esté marchando debemos mudar algunas opciones en la página CDN” de W3 Total Cache, concretamente debemos mudar las próximas funciones:

  • Force over-writing of existing files: Con esto sobreescribiremos los archivos en Amazon S3 con los archivos actualizados de nuestra web, es recomendable tenerla marcada, aunque al tenerla marcada y activada estemos consumiendo algo más de recursos en Amazon S3.
  • Disable CDN on SSL pages: Con esto evitaremos muchos problemas, es recomendable tenerlo desactivado a no ser que realicemos la configuración concreta para SSL.
  • Export changed files automatically: Con esto se importasen automáticamente a Amazon S3 los ficheros cambiados en los artículos y páginas de WordPress, por defecto se comprobara cada 3600 segundos

Al marcar estas opciones el CDN debería funcionar de manera perfecta y en el caso de WordPress sin SSL no debería dar ningún tipo de problema.

CONCLUSIONES SOBRE W3 TOTAL CACHE Y CLOUDFRONT

Debes tener en consideración varias cosas, la primera es que W3 Total Cache en combinación con Amazon CloudFront tiene 2 formas diferentes de trabajar, la primera es cogiendo los archivos estáticos de forma directa desde el servidor del hosting y la segunda cogiéndolos desde Amazon S3. Personalmente me gusta más la segunda forma, puesto que tiene un funcionamiento mucho más fluido cuando el tráfico es alto y al unísono nos ayuda a independizar un poco el CDN del alojamiento o bien servidor donde se aloja el sitio.

Si precisas ayuda para implementar Amazon CloudFront o cualquier otro CDN en tu sitio web puedes contactar con nosotros sin compromiso y te informaremos de nuestras tarifas y nuestra disponibilidad.

Optimando WordPress – Caso real #9

Posted by on mar 8, 2015 in cpanel, wordpress

Estos días estamos volviendo a publicar resultados de optimizaciones y resultados de lo que significa migrar a nuestros servidores VPS optimizados.
Hace escasamente dos días hemos migrado a uno de nuestros servidores VPS optimizados a un blogger hispano que creemos que tiene bastante futuro, en su blog expone ensayos posicionamiento en buscadores de una manera muy peculiar, contando sus experiencias sobre posicionamiento web y monetización web.

Si bien este blogger tenía múltiples webs alojadas en su precedente hosting, pero solo vamos a exponer los desenlaces de dos, una de ellas es absolutamente publica, en verdad es campamentoweb.com y la otra web expuesta es un micronicho que vamos a mantener en el anonimato para prevenir posibles hurtos de ideas”.

optimizacion wordpress

Cuando E. de CampamentoWeb.com llego a nosotros estaba alojado en un alojamiento compartido de un conocido proveedor de alojamiento web de venezuela,

En el caso de CampamentoWeb.com los desenlaces de carga según PingDom Tools ya antes de la migración son estos:

optimizar wordpress

optimizar wordpress

optimizar wordpress

Lo que hicimos más tarde es migrar CampamentoWeb.com a uno de nuestros servidores VPS optimizados, en concreto a un servidor VPS 1 optimado con el cache de Nginx activado y con el plugin Flexicache para WordPress usando el servicio Memcached del VPS para guardar el cache.

Tras migrar CampamentoWeb.com y tener todo listo y marchando conseguimos los próximos resultados de carga:

optimizar wordpress

optimizar wordpress

optimizar wordpress

Como ves, simplemente migrando y usando un complemento de cache que aprovecha las funcionalidades y peculiaridades de nuestros VPS logramos buenos resultados, verdaderamente notables.

En CampamentoWeb.com se notan los resultados en aproximadamente 1 segundo de carga, mas en otros sitios web asimismo migrados hemos notado mejoras más notables, en verdad en el siguiente sitios la diferencia de carga entre el hosting precedente y nuestro VPS optimizado es más que notable.

Estos son los desenlaces de velocidad de carga de WordPress conforme Pingdom Tools en el viejo hosting:

optimizar wordpress

optimizar wordpress

optimizar wordpress

Y estos son los desenlaces conseguidos tras migrar el sitio web a uno de nuestros servidores VPS optimados y después de aplicar exactamente las mismas configuraciones que en el caso de CampamentoWeb.com:

optimizar wordpress

optimizar wordpress

optimizar wordpress

Como puedes ver en las imágenes anteriores, los desenlaces óptimos en la velocidad de carga son más que notables, esto se logra siguiendo varias reglas:

Si después de ver esto estas interesado en probar uno de nuestros servidores VPS optimados no dudes en contactar con nosotros y te proporcionaremos un cupón a fin de que pruebes a lo largo de 1 semana uno de nuestros servidores VPS optimizados, estamos seguros de que te quedaras con él.

El consumo de memoria RAM en WordPress

Posted by on mar 6, 2015 in cpanel, wordpress

Para comprender el consumo de recursos de WordPress es preciso entender el funcionamiento y la manera en que se ejecutan los ficheros PHP, puesto que PHP es un lenguaje de programación web que se ejecuta del lado del servidor.

El núcleo de WordPress es PHP y consume recursos por el mero hecho de visualizar una página creada con WordPress, pero debemos tener en cuenta que cada complemento que instalemos en nuestro WordPress va a acrecentar el consumo de recursos, y no solo eso, sino que los themes asimismo aumentan el consumo de recursos que se produce al visualizar una página creada con WordPress.

wordpress php memory

Esto es el consumo de memoria RAM en MB y las consultas que realizan a la base de datos MySQL algunos de los complementos más utilizados para WordPress, para las pruebas se ha comprobado el consumo de memoria RAM y las consultas al MySQL recargando el index predeterminado de una instalación de WordPress con el tema Twenty Twelve:

  • BuddyPress con todos y cada uno de los módulos activos: 11,64MB y 8 consultas.
  • bbPres con la configuración predeterminada: cuatro,82MB y 26 consultas.
  • Jetpack (base) autentificado en WordPress.com y por defecto: 9,10MB y 27 consultas.
  • Wordfence con la configuración por defecto: 2,72MB y 28 consultas.
  • iThemes Security con la configuración por defecto: 1,20MB y doce consultas.
  • WooCommerce con la configuración predeterminada: 5,51MB y dieciocho consultas.
  • WordPress posicionamiento SEO by Yoast (datos falseados por el plugin): 3,02MB y 1 consulta.
  • All in One Seo Paquete con la configuración predeterminada: 2,37MB y ocho consultas.
  • Akismet activado: 0,40MB y dos consultas.
  • Contact Form 7 sin formularios creados: 1,7MB y 0 consultas.
  • Clef sin configurar nada: 1,4MB y 1 consulta.
  • WPTouch Mobile Plugin con la configuración predeterminada: 2,49MB y 4 consultas.
  • TablePress sin ninguna tabla creada: 0,77MB y 1 consulta.
  • Anti-spam 3.5: 0,2MB y 0 consultas.
  • Pretty Link Lite sin link creado: 1,29MB y 1 consulta.
  • Google Analytics by Yoast: 0,21MB y 0 consultas.
  • Google XML Sitemaps: 0,25MB y 0 consultas.
  • EWWW Image Optimizer con la configuración por defecto: 1,94MB y 1 consultas.
  • WP Smushit con la configuración por defecto: 0,55MB y cuatro consultas.
  • Shortcodes Ultimate sin insertar ningún shortcode: 2,3MB y 2 consultas
  • TinyMCE Advanced: 0,28MB y 0 consultas.
  • Yet Another Related Posts Complemento sin activar: 0,9MB y 1 consulta.

Algunos plugins de los nombrados podrían ejecutar subprocesos o procesos en background que consumieran más memoria de la mostrada al entrar al sitio web un visitante. Uno de los plugins que más memoria RAM y recursos de CPU consumen en background es el complemento Broken Link Checker, cuantos más enlaces salientes tenga nuestro blog, mayor va a ser el consumo de Broken Link Checker.
Por otra parte, asimismo deseaba dejar claro que cuantas más consultas más aumenta el consumo de RAM forzado por el servidor MySQL, por lo que ese consumo de memoria RAM se suma al consumo que efectúa el intérprete PHP del servidor web.

Cosas a tener en cuenta tras ver el listado anterior:

  • Debemos tener mucho cuidado con Jetpack, si al tener ningún modulo activado consume prácticamente 10 MB de RAM y hace veintisiete consultas, conforme se vayan activando módulos el consumo de RAM y las consultas al MySQL se disparasen.
  • Los complementos que producen el sitemap tienen picos de consumo de recursos bastante altos cuando se ejecuta la tarea de crear el sitemap, cuantas más paginas tenga el sitio web más alto será el consumo de RAM.
  • El complemento WordPress posicionamiento SEO by Yoast es conocido en el WPO por ocultar” su consumo de recursos a través de técnicas poco éticas”, en concreto es capaz de engañar al complemento P3 Profiler para WordPress que deja ver el consumo de memoria RAM.

Este artículo no pretende ser una referencia, simplemente intenta dar a comprender que la instalación de un simple plugin puede aumentar o reducir de forma esencial la infraestructura necesaria para sostener on line un blog con cientos y cientos de miles y miles de visitas concurrentes.
Lo idóneo para un complemento seria no consumir más de 5MB de memoria RAM por petición y no incorporar ninguna query o bien no más de dos querys, en tanto que el resultado si juntamos más de 20 plugins con un theme de los nuevos” es un WordPress que consume unos 100 MB por petición, lo que equivaldría más o menos a tres mil usuarios concurrentes en un servidor dedicado con treinta y dos GB de memoria RAM siempre y cuando la configuración sea la correcta (debemos tener en cuenta el beneficio posterior de los complementos de cache, mas vamos a pensar que hablamos de paginas interactivas que no se pueden cachear).

Si estás buscando a alguien para optimizar tu WordPress, en Raiola Networks somos especialistas en esta clase de labor, tenemos extensa experiencia en instalación con muchos usuarios concurrentes, si precisas ayuda, contacta con nosotros sin ningún compromiso.

Tweaking avanzado del wp-config.php de WordPress

Posted by on mar 5, 2015 in cpanel, wordpress

En el artículo anterior charlamos sobre el consumo de RAM de ciertos complementos más usados en WordPress, también hicimos alusión a las consultas que efectúa WordPress a la base de datos MySQL y que ciertos plugins pueden hacer demasiadas consultas.
Este articulo va a ser un poco distinto, pero entrando en temas técnicos de WordPress que son útiles para los que trabajamos con este CMS, pero que muy pocos conocen puesto que son sus entresijos.

wordpress php memory

En este artículo explicaremos las variables que pueden ser definidas en el fichero wp-config.php de WordPress, para modificar su funcionamiento o bien para ahorrar” solicitudes a la base de datos definiendo ciertos parámetros que jamás cambian.
Vamos a intentar que este articulo sea lo más completo posible y con la mayor cantidad de información sobre todo lo que puedes incluir en tu wp-config.php, si bien algunos los vamos a excluir de la lista ya que utilizarlos seria poco inteligente en nuestros días o al contrario son cosas demasiado avanzadas como para efectuarlas de forma optima con un simple factor en el wp-config.php.

DB_NAME

El parámetro DB_NAME nos deja configurar y definir el nombre de la base de datos MySQL a la que se conectase WordPress para marchar, se define con el siguiente código:

define( ‘DB_NAME’, ‘database_name_here’ );

DB_USER

El parámetro DB_USER nos deja configurar y acotar el nombre del usuario que usara WordPress para conectarse a la base de datos MySQL, se define con el siguiente código:

 define( ‘DB_USER’, ‘MyUserName’ );

DB_PASSWORD

El factor DB_PASSWORD nos deja configurar y delimitar la contraseña que utilizara el usuario definido en DB_USER para acceder a la base de datos MySQL, se define con el siguiente código:

 define( ‘DB_PASSWORD’, ‘MyPassWord’ );

DB_HOST

Con este factor definimos cual va a ser el host de la base de datos, si el servidor MySQL que vamos a utilizar se halla en exactamente el mismo servidor debemos emplear localhost” o 127.0.0.1”, en este factor también podemos emplear un MySQL Socket, se define con el siguiente código:

define( ‘DB_HOST’, ‘MyDatabaseHost’ );

DB_CHARSET

Con el parámetro DB_CHARSET podemos configurar la codificación de caracteres de la base de datos MySQL a la que nos marchamos a conectar, podemos definirlo con el próximo código:

 define( ‘DB_CHARSET’, ‘utf8′ );

dólares americanos table_prefix

Con el parámetro $ table_prefix podemos configurar el prefijo de la base de datos para las tablas de la base de datos MySQL que utilizamos en nuestro WordPress, podemos acotar el prefijo con el siguiente código:

  dólares americanos table_prefix = ‘y77_';

WP_SITEURL

Con el factor WP_SITEURL podemos acotar de forma estática la URL del sitios WordPress, incluso podemos configurar como URL un dominio con una subcarpeta, podemos delimitar la URL del sitios con el próximo código:

 define( ‘WP_SITEURL’, ‘http://example.com/wordpress’ );

WP_HOME

Con el parámetro WP_HOME podemos acotar la URL de la página primordial del weblog, algo similar al WP_SITEURL mas para el weblog (loop de WordPress), puedes definir esta variable con el próximo código:

 define( ‘WP_HOME’, ‘http://example.com/wordpress’ );

WP_CONTENT_DIR

Con el factor WP_CONTENT_DIR podemos definir otra ubicación personalizada para el directorio WP-CONTENT de WordPress, podemos acotar este parámetro a través de una ruta interna o mediante una URL, el código usado es el siguiente:

 define( ‘WP_CONTENT_DIR’, dirname(__FILE__) ‘/blog/wp-content’ );

WP_PLUGIN_DIR

Podemos modificar la ubicación de la carpetita de complementos con el factor WP_PLUGIN_DIR, como en el caso de WP_CONTENT_DIR podemos utilizar una ruta interna o una URL, el código utilizado para ello es el siguiente:

 define( ‘WP_PLUGIN_DIR’, dirname(__FILE__) ‘/blog/wp-content/plugins’ );

UPLOADS

Podemos modificar la ubicación de la carpeta usada para guardar los archivos subidos mediante el parámetro UPLOADS, el código usado para esto es el siguiente:

define( ‘UPLOADS’, ‘blog/wp-content/uploads’ );

AUTOSAVE_INTERVAL

Como muchos van a saber, WordPress realiza un autoguardado automático de los artículos y páginas que se están editando mediante revisiones, con este factor podemos configurar cada cuanto tiempo se guardan revisiones automáticas, el código utilizado para ello es el siguiente:

 define( ‘AUTOSAVE_INTERVAL’, ciento sesenta );

EMPTY_TRASH_DAYS

Este factor nos permite configurar cada cuanto tiempo se vacía la papelera de WordPress, aun podemos desactivar la papelera de reciclaje. Podemos modificar el comportamiento de la papelera usando el próximo codigo:

 define( ‘EMPTY_TRASH_DAYS’, 0 );

WP_POST_REVISIONS

Con la variable WP_POST_REVISIONS podemos activar o desactivar la creación de revisiones por parte del autoguardado de WordPress, con este factor también podemos delimitar cuantas revisiones se guardan, el código usado para ello es el siguiente:

 define( ‘WP_POST_REVISIONS’, false );

COOKIE_DOMAIN

Utilizando el factor COOKIE_DOMAIN podemos delimitar cuál será el dominio o bien subdominio primordial del blog que va a tener las cookies y las instalase en el navegador del usuario, podría dedicar solo un blog post a redactar sobre esta alternativa y sus ventajas, mas creo que no es el momento, el factor para delimitar este factor es el siguiente:

 define( ‘COOKIE_DOMAIN’, ‘www.askapache.com’ );

WP_ALLOW_MULTISITE

Esta alternativa sirve para activar WordPress Multisite, tras activar esta opción y entrar a WordPress debemos seguir un asistente de configuración de la red de blogs. Para activar esto podemos usar el próximo parámetro:

 define( ‘WP_ALLOW_MULTISITE’, true );

WP_DEBUG

El DEBUG es una de las mejores herramientas para determinar y advertir inconvenientes en una instalación de WordPress, solo tiene dos modos de funcionamiento, puede estar encendido o apagado. Para activar esto podemos usar el siguiente parámetro:

 define( ‘WP_DEBUG’, true );

SCRIPT_DEBUG

Esta opción la he usado bastante poco en tanto que apenas le veo utilidad, mas saca algunos errores de Javascript y CSS así como los errores de PHP cuando el WP_DEBUG está activado, puedes activar el SCRIPT_DEBUG utilizando el siguiente código:

 define( ‘SCRIPT_DEBUG’, true );

WP_DEBUG_LOG

Si tenemos el WP_DEBUG activado y posteriormente activamos WP_DEBUG_LOG podemos guardar un registro con todos los fallos que ha dado la instalación de WordPress, los ficheros de log se guardaran en wp-content para activar el log podemos usar el siguiente parámetro:

 define( ‘WP_DEBUG_LOG’, false );

WP_MEMORY_LIMIT

De forma predeterminada WordPress impone un límite de memoria usable, podemos forzar la cantidad de memoria RAM empleada utilizando el siguiente parámetro:

 define( ‘WP_MEMORY_LIMIT’, ’64M’ );

WP_MAX_MEMORY_LIMIT

Este parámetro se parece al WP_MEMORY_LIMIT, mas solo afecta a la memoria usada al ejecutar el panel de administración de WordPress, podemos forzar esta opción con el próximo parámetro:

 define( ‘WP_MAX_MEMORY_LIMIT’, ‘256M’ );

WP_CACHE

Este parámetro hoy en día no se usa para lo que está concebido, pero es preciso tenerlo activado en el wp-config.php para que funcionen ciertos plugins de cache para WordPress, puesto que lo que hace es activar el fichero advanced-cache.php, podemos activar WP_CACHE con el próximo código:

 define( ‘WP_CACHE’, true );

CUSTOM_USER_TABLE

Podemos alterar la tabla donde se guardan los usuarios en la base de datos de WordPress, aunque en la práctica esto no tiene mucha utilidad, es una alternativa más que se puede delimitar con el próximo código:

define( ‘CUSTOM_USER_TABLE’, dólares americanos table_prefix.’my_users’ );

CUSTOM_USER_META_TABLE

La tabla META de usuarios guarda datos adicionales sobre los usuarios registrados en una instalación de WordPress, esta alternativa nos permite cambiar el nombre de la tabla donde se guardan estos datos, podemos definir esta opción con el próximo código:

 define( ‘CUSTOM_USER_META_TABLE’, dólares americanos table_prefix.’my_usermeta’ );

WPLANG

Este parámetro nos permite configurar el idioma por defecto de la instalación de WordPress, obviamente antes de configurar este factor debemos asegurarnos de que nuestra instalación de WordPress tiene los ficheros de idioma en la carpeta pertinente. Podemos definir el idioma con el próximo código:

 define( ‘WPLANG’, ‘de_DE’ );

WP_LANG_DIR

Con este factor podemos configurar la carpeta donde WordPress buscara los archivos de idioma, sinceramente creo que es un factor un tanto absurdo, pero podemos delimitar el idioma con el próximo código:

 define( ‘WP_LANG_DIR’, dirname(__FILE__) ‘wordpress/languages’ );

FS_CHMOD_DIR

Este factor es entre los más ignotos y a la vez entre los más útiles, ya que nos permite configurar los permisos para las carpetas de la instalación de WordPress,excelente utilidad para que nuestro WordPress tenga los permisos adecuados. Podemos delimitar los permisos de las carpetitas con el próximo código:

 define( ‘FS_CHMOD_DIR’, ( 0755 & ~ umask() ) );

FS_CHMOD_FILE

Este parámetro es semejante al FS_CHMOD_DIR, mas en un caso así lo que hace es definir los permisos de todos los ficheros de la instalación de WordPress, podemos delimitar los permisos de los ficheros con el siguiente código:

 define( ‘FS_CHMOD_FILE’, ( 0644 & ~ umask() ) );

WP_ALLOW_REPAIR

Este parámetro es un enorme desconocido, pocos saben que WordPress trae entre sus utilidades una herramienta para reparar la base de datos de WordPress, podemos activarla usando el siguiente parámetro:

 define( ‘WP_ALLOW_REPAIR’, true );

WP_HTTP_BLOCK_EXTERNAL

Lo que hace este factor es no permitir que WordPress realice peticiones externas a otros servidores HTTP, es un parámetro útil si estamos efectuando un desarrollo sobre WordPress en local. Podemos aplicar el bloqueo con el siguiente código:

 define( ‘WP_HTTP_BLOCK_EXTERNAL’, true );

WP_ACCESSIBLE_HOSTS

Este factor va directamente ligado al precedente, ya que nos deja crear una lista blanca con algunos dominios y hostnames a los que WordPress sí que podrá efectuar peticiones HTTP externas. Podemos aplicar el bloqueo con el próximo código:

 define( ‘WP_ACCESSIBLE_HOSTS’, ‘api.wordpress.org,.github.com’ );

DISABLE_WP_CRON

Podemos activar o bien desactivar el WP-CRON, este factor nos ayudase a desactivar el WP-CRON de WordPress y empezar a emplear el CRON de Linux, podemos hacerlo con el próximo parámetro:

 define( ‘DISABLE_WP_CRON’, true );

DISALLOW_FILE_EDIT

Con este factor puedes desactivar el editor integrado de themes y plugins desde el panel de WordPress, puedes desactivar el editor usando el próximo código:

 define( ‘DISALLOW_FILE_EDIT’, true );

DISALLOW_FILE_MODS

Este parámetro nos deja bloquear la instalación y actualización de themes y complementos en una instalación de WordPress, podemos activar esta opción utilizando el siguiente codigo:

 define( ‘DISALLOW_FILE_MODS’, true );

FORCE_SSL_LOGIN

El parámetro FORCE_SSL_LOGIN te dejará obligar a que todos y cada uno de los usuarios que quieran entrar al panel de administración de WordPress lo hagan a través de conexión cifrada HTTPS, podemos activar esta opción con el próximo codigo:

 define( ‘FORCE_SSL_LOGIN’, true );

FORCE_SSL_ADMIN

Este parámetro se parece al parámetro FORCE_SSL_LOGIN pero tiene una diferencia, en este caso se aplica solo a los administradores de la instalación de WordPress, podemos activar esta alternativa con el próximo código:

 define( ‘FORCE_SSL_ADMIN’, true );

AUTOMATIC_UPDATER_DISABLED

Esta opción nos deja desactivar el actualizador automático de complementos, themes y de WordPress, una alternativa útil si tenemos cambios específicos en el código de la instalación de WordPress y no deseamos perderlos, podemos activar esta opción con el próximo código:

 define( ‘AUTOMATIC_UPDATER_DISABLED’, true );

WP_AUTO_UPDATE_CORE

Esta opción nos permite activar o desactivar las actualizaciones automáticas del núcleo de WordPress, es decir, de los archivos del propio WordPress, podemos activar esta opción con el próximo código:

 define( ‘WP_AUTO_UPDATE_CORE’, false );

FTP_HOST

Esta alternativa nos deja guardar en la configuración de WordPress el servidor FTP donde se encuentra la instalación de WordPress, podemos delimitar esto con el próximo código:

 define( ‘FTP_HOST’, ‘ftp.example.org’ );

FTP_USER

Nos deja guardar el usuario FTP del servidor donde se guarda la instalación de WordPress, podemos acotar esto con el siguiente código:

 define( ‘FTP_USER’, ‘username’ );

FTP_PASS

Podemos acotar también la contraseña del usuario FTP del servidor donde se guarda la instalación de WordPress, podemos delimitar y guardar esto con el próximo código:

define( ‘FTP_PASS’, ‘password’ );

MÁS PARAMETROS DEL WP-CONFIG.PHP

Podría contabilizar más de 300 factores o bien variantes de factores que podríamos utilizar en el wp-config.php de WordPress para modificar funcionalidades en WordPress o bien desactivar funcionalidades de WordPress, es más, esta es la única forma que conozco de cambiar la manera de funcionar del núcleo de WordPress.
Desgraciadamente si incluyese todos y cada uno de los factores y sus variaciones esta lista sería imposible de leer y no se podría buscar nada en ella.

Si precisas ayuda para resolver algún problema en tu WordPress o bien estás buscando a alguien para desarrollar tu web sobre WordPress te recomendamos xtudiografico.com

Administración de DNS y dominios en servidores VPS

Posted by on mar 4, 2015 in cpanel

Cuando charlamos de alojamiento compartido normalmente el funcionamiento de los servidores DNS y de los dominios se resumen a poner el dominio y el alojamiento ya funciona, ya que la plataforma cPanel y su cluster de DNS facilitan mucho las cosas.
En el caso de los servidores VPS la cosa no es exactamente así, un servidor VPS puede tener su servidor DNS o no, mas por otra parte, los dominios registrados no se ligan” de manera automática al servidor VPS, ya que no guardan relación alguna.

Hasta hace relativamente poco tiempo hemos estado asignando a nuestros clientes DNS propias que apuntaban a los servidores DNS de sus propios servidores VPS, mas hemos decidido implementar una mejora, un gestor de DNS y dominios para TODOS nuestros servidores VPS, usando para esto PowerDNS y SolusVM.

Para iniciar a administrar dominios con el servidor DNS que ponemos a predisposición de nuestros clientes del servicio de VPS en primer lugar debemos dirigirnos al nuestro panel general de servidores VPS: https://vpspanel.raiolanetworks.es:5656/login.php

dnsvps1

Como ves en la imagen de arriba, después de autenticarte con tu cuenta (que te ha tenido que llegar en un correo electrónico al contratar el VPS), verás un listado de todos y cada uno de los VPS que tienes contratados con nosotros.
A los VPS no vamos a hacerles caso, vamos a dirigirnos a la barra superior, concretamente al botón DNS” y lo pulsamos, con esto vamos a acceder al gestor DNS, que en un principio estará totalmente vació:

dnsvps2

Rellenamos el campo Add New Domain” con nuestro dominio y pulsamos el botón azul Add”.
Hecho esto el dominio se agregará al listado:

dnsvps3

Pulsamos el botón azul Manage” rodeado con un cuadro colorado en la imagen anterior para configurar los 3 registros básicos de la zona DNS, lo suficiente para que nuestro dominio pueda llevar al visitante a nuestro VPS y que los correos puedan llegar al servidor VPS.

Debemos incorporar 3 tipos diferentes de registros:

  • A Records
  • CNAME Records
  • MX Records

Vamos a iniciar por el registro A o bien A Record, en este caso vamos a imaginarnos que la IP de nuestro servidor VPS es 8.8.8.8 y que el dominio es pruebaraiola.es

dnsvps4

Debemos cubrir los datos como puedes ver en la imagen anterior, dejando vacio el campo Domain” ya que cojera el dominio que hemos creado.

Ahora vamos a crear el registro CNAME que apuntara www.pruebaraiola.es a pruebaraiola.es, para eso rellenamos los campos de la próxima forma:

dnsvps5

Como puedes ver, ponemos solo www”, ya que el resto del subdominio tras las www” los pone el gestor: www.pruebaraiola.es”.

Finalmente, haremos que los e-mails de ese dominio puedan llegar a nuestro servidor VPS, para esto configuramos los campos del MX Record de la próxima forma:

dnsvps6

De nuevo el sistema intuye que al dejar el campo en blanco estamos hablando del mismo dominio.

Tras hacer todo este proceso de configuración nos dirigimos a nuestro registrador del dominio y configuramos como servidores DNS los siguientes DNS:

  • dns1.webcloud.es
  • dns2.webcloud.es

Una vez hecho eso tu dominio comenzara a marchar cuando se propaguen las DNS, esto puede tardar hasta doce o 24 horas para poder iniciar a utilizar el dominio.

Si aún no has probado ninguno de nuestros servidores VPS, contacta con nosotros y pídenos información sin compromiso alguno, estamos seguros de que no te van a defraudar.

Poner un Mega Menu en WordPress con un complemento

Posted by on mar 2, 2015 in cpanel

Normalmente cuando los themes para WordPress más utilizados comienzan a agregar nuevas funcionalidades, no tardan en aparecer complementos para poder emplear esas funcionalidades en otras instalaciones de WordPress independientemente del tema.

Un ejemplo de esto son los Mega Menus, o bien lo que es exactamente lo mismo, poder introducir contenido abundante en los desplegables de un menú primordial de un sitios, con esto logramos una apariencia mucho más completa y más dinámica.

Existen muchas formas de incorporar un Mega Menu en WordPress, aunque personalmente la que me ha llamado la atención es utilizando el plugin Max Mega Menu, un plugin completamente gratis.

max mega menu

Como puedes ver, es posible insertar cualquier tipo de contenido en el Mega Menu creado por Max Mega Menu, solo debemos ser capaces de insertar un widget en el sitio correcto, incluso podemos seleccionar las columnas que queramos y en la distribución que nosotros deseemos.

max mega menu

Aun Max Mega Menu nos da la oportunidad de crear pancartas” informativas desplegables sin link para que cuelguen” del menú principal, sin duda una opción bien interesante y que nos deja ofrecer más contenido al visitante.

max mega menu

Por otro lado, si lo que queremos hacer es edificar menus primordiales completos con muchas opciones e iconos que sean simples de entender, Max Mega Menu tampoco se queda a otras, ofreciéndonos un catálogo bastante amplio de iconos:

max mega menu

Indudablemente un Mega Menu puede asistirte a darle un nuevo aspecto a tu sitios WordPress, si bien tampoco hace milagros, por otro lado, si no deseas complicarte con la instalación y configuración de un complemento, siempre puedes cambiar tu tema por un tema que traiga Mega Menu instalado.

Puedes descargar Max Mega Menu de forma absolutamente gratuita desde el repositorio de complementos de WordPress en la próxima dirección URL: https://wordpress.org/plugins/megamenu/