Popular channels

Optimizar server o vps con poca ram para WORDPRESS

En este tutorial aprenderemos a configurar un VPS con poca memoria para poder alojar una o varias instalaciones de WordPress, eliminando por completo las interrupciones por falta de recursos. Las configuraciones predeterminadas de LAMP (Linux, Apache, MySQL, PHP), aunque funcionan, no siempre son las más recomendadas, especialmente si lo que tenemos es un VPS pequeño donde donde alojamos un par de sitios web. Después de haber puesto en práctica este artículo, se ahorrarán dolores de cabeza, como me sucedió a mí en su tiempo.

Trataré de explicar como optimizar los recursos y mejorar el rendimiento de un VPS con poca memoria (mayor o igual a 512MB) para reducir al mínimo los “outages” por falta de recursos o eliminarlos completamente.



¿Qué puedo lograr optimizando la configuración?

Es fundamental la optimización de los recursos. Para aquellos que se inician en el hosting, los VPS (servidores privados virtuales) son una de las herramientas principales por su bajo costo. Como experiencia les comentamos de un servidor que era el más pequeño disponible que tenía con 512 de Ram, 1 núcleo completo de procesador, 10 gb de disco y 1 tb de ancho de banda y aloja 3 blogs de WordPress (Había un cuarto pero no estaba disponible todo el tiempo) . Cada blog tiene aproximadamente 1,000 a 1,500 visitas diarias y el servidor siempre mantiene entre el 25% y 50% de memoria disponible, además el procesador nunca supera el 10% de uso y los 3 blogs funcionan una maravilla. Si te gustaría lograr lo mismo, vamos a comenzar con la optimización de nuestro servidor.

Requisitos previos recomendados:

  • Tener conocimientos básicos acerca del uso de un cliente SSH como PuTTY.
  • Tener conocimientos de comandos básicos UNIX para utilizar con SSH.
  • Haber instalado un sitio WordPress en su servidor LAM
Ahora, vamos a poner manos a la obra.

Crear un archivo SWAP:

No todos los VPS tienen configurado un espacio SWAP por defecto.

Básicamente,“swap” es un espacio de disco que Linux utiliza como si fuese RAM. Es necesario tener habilitado este espacio para evitar “outages” o interrupciones de servicio, especialmente en nuestro servidor MySQL.

Podemos verificar si ya tenemos configurado el espacio swap con el comando “free -m”.

En el caso del servidor donde generé esta imagen, el espacio ya está configurado y es de 512 MB:





Si ya tenemos swap definido, podemos continuar al paso siguiente, si no lo tenemos, lo creamos de la siguiente forma: Primero, vamos a definir el tamaño y el nombre del archivo con el siguiente comando:
dd if=/dev/zero of=/swapfile bs=1024 count=512k
Donde “of=/swapfile” corresponde al nombre del archivo.Veremos un mensaje de confirmación parecido a este:


Una vez creado el archivo, vamos a definirlo como SWAP con el siguiente comando:
mkswap /swapfile

Si todo se realizó correctamente, veremos el siguiente mensaje:


Ahora debemos activar el archivo SWAP que acabamos de crear para que comience a ser utilizado con el siguiente comando:
swapon /swapfile
Este archivo swap que acabamos de crear, solamente estará disponible mientras no reiniciemos el VPS.
Para evitar esto y hacer que siempre esté disponible y activado, abrimos el archivo “fstab” con nuestro editor (el que prefiramos), en mi caso utilizaré vi:
vi /etc/fstab
Una vez abierto el archivo agregamos la siguiente línea:
/swapfile swap swap defaults 0 0
Guardamos nuestro archivo y eso es todo. Ahora solo debemos evitar que este archivo swap pueda ser leído e interpretado por cualquier persona, para ello ajustamos los permisos:
chown root:root /swapfile
chmod 0600 /swapfile


Optimizar Apache: 
Definitivamente cuando hablamos de Apache, hablamos del servidor web más utilizado, aunque hay muchos otros en la red que también ofrecen muy buen desempeño. La clave de Apache está en que debemos dedicarle tiempo a realizar la configuración correctamente para hacer que se comporte como nosotros queremos, pues debido a su estructura de “auto regulación”, mientras más recursos le asignemos, más recursos consumirá y bueno, para que WordPress funcione correctamente no necesita mayores recursos de parte de Apache. Comencemos a configurar nuestro servidor apache, abriendo el archivo de configuración en nuestro editor vi, pues es aquí donde nosotros podemos controlar lo que hace Apache. El archivo de configuración es
/etc/httpd/conf/httpd.conf 


Optimizar MPM Prefork: Esta creo que es la parte más importante a tomar en cuenta, pues es donde le indicamos a Apache cuántos procesos debe iniciar es donde más memoria RAM ahorramos. Esta sería una configuración recomendada para una instalación como las que mencionaba anteriormente que es utilizada en el VPS con tres blogs. Para encontrar esta configuración, debemos abrir el archivo “httpd.conf” en el editor vi y buscar la parte del archivo titulada “#MPM Prefork”.



StartServers        1
MinSpareServers     1
MaxSpareServers     3
MaxClients          10
MaxRequestsPerChild 3000



Con esta configuración le indicamos a apache que queremos que inicie solamente un servidor o proceso yque cuando llegue a 3000 solicitudes simultáneas, arranque un nuevo servidor, hasta llegar a un máximode 3. Esto no sucede muy a menudo, pero si se diera el caso de que tuviéramos realmente demasiadas visitas, por ejemplo, atender las solicitudes de 300 personas conectadas simultáneamente la mayor parte del tiempo, podemos ir aumentando el número de MaxClients y MaxSpareServers y definitivamente
necesitaríamos un VPS con más recursos para atender semejante tráfico.


Optimizar MPM Worker: Esta es otra parte importante de nuestra optimización y está bastante ligada a la anterior. La forma de funcionar de este módulo también es muy similar al Prefork. Este módulo permite atender las solicitudes que lleguen al servidor de forma simultánea, pero si no está bien configurada, puede consumir recursos innecesariamente, pues mantiene abiertos los procesos esperando por solicitudes. La configuración que recomiendo, para ir de la mano con la anterior es esta:

StartServers        1
MinSpareThreads     5
MaxSpareThreads     15
ThreadLimit         25
ThreadsPerChild     5
MaxClients          25
MaxRequestsPerChild 200

KeepAlive: Creo que muchos webmasters nos vemos en el dilema de si debemos activar o no la opción“KeepAlive” pues algunos opinan dan testimonio de que al desactivar esta característica, el uso de memoria RAM y el rendimiento de su VPS mejoró considerablemente. Por otra parte, algunos opinan que cuando la desactivaron sobrecargaron mucho la carga de CPU de su VPS y su sitio web estaba fuera de línea en las horas pico de tráfico. Para poder tomar una buena decisión, examinemos un poco a fondo qué es lo que hace KeepAlive en Apache.
El protocolo HTTP es libre de sesión, es decir, se abre una conexión para transferir un archivo cualquiera y cuando la transferencia termina, la conexión se cierra. Esto mantiene las cosas simples, pero cuando tomamos en cuenta que cada solicitud abrirá una nueva conexión, vemos que las cosas son simples, pero no eficientes.
De esta situación es que nace KeepAlive, que lo que hace básicamente es que cada vez que se transfiere un archivo cualquiera, mantiene abierta la conexión esperando si hay otra solicitud de transferencia del mismo cliente. Si es así, utiliza la misma conexión ahorrando recursos al servidor, pues no es necesario abrir otra conexión para transferir más archivos. Se escucha genial, pero la verdad es que mantener abiertas las conexiones significa un consumo de memoria RAM.
Ventajas de KeepAlive:
  • Aumenta la velocidad del sitio web: Pues reduce la latencia en la entrega de archivos por HTTP al no tener que crear nuevas conexiones para cada solicitud, lo que mejora la experiencia del usuario.
  • Reduce el uso del CPU: Considerando que un sitio web normal tiene muchos archivos como hojas de estilo, archivos javascript, imágenes, etc. el servidor tendría que abrir y cerrar conexiones para cada uno de estos archivos haciendo trabajar un poco más al CPU, cosa que se evita activando KeepAlive.

Desventajas de KeepAlive:
  • Aumenta el uso de memoria RAM: Apache tiene que mantener abiertas las conexiones y en espera, haciendo que ocupen memoria RAM. Aparte de esto, Apache debe crear más procesos para las nuevas conexiones (como les expliqué en Prefork y Worker) y consumirá más memoria aún, la cual podría servir para atender a otros usuarios.
¿Debo activar o no KeepAlive? La decisión de activar o no KeepAlive depende más del tipo de sitios que alojemos, pero unas muy buena recomendaciones serían las siguientes:
  • RAM Vs. CPU: Debemos identificar cuál de estos dos es el recurso más limitado. Si tenemos una memoria RAM muy pobre, definitivamente no debemos activar KeepAlive, pues dejará sin recursos a nuestro VPS y nuestros sitios podrán pasar fuera de línea por algún tiempo. Si nuestro procesador es el limitado, por ejemplo, hay proveedores que ofrecen VPS muy baratos, pero con 1/4 de núcleo de CPU por cada uno. En estos casos, activar KeepAlive ayudará a aliviar al procesador.
  • Comportamiento del tráfico: Esta es quizá la mejor forma para determinar si utilizar o no KeepAlive. Si el tráfico de su sitio web se extiende de manera uniforme a lo largo de un día, entonces usted debe activar  KeepAlive. Pero en cambio, si la mayoría de tráfico de su sitio web tiene horas pico, donde la mayoría de usuarios llegan de forma simultánea durante un corto período de tiempo, KeepAlive disparará el uso de su memoria RAM, haciendo que su sitio pueda quedar inoperable durante estos períodos de tiempo de alto tráfico. En estos casos, es recomendable desactivarlo.

KeepAlive Time Out: Si tomamos la decisión de activar KeepAlive, debemos optimizar el tiempo de espera que Apache asignará a las conexiones, pues un tiempo muy largo, hará que Apache se exceda en el consumo de memoria RAM, haciendo que el servidor utilice demasiado el espacio SWAP, lo que hará nuestros sitios más lentos, pues el disco duro es siempre más lento que la memoria RAM y un tiempo muy corto, provocará demasiados errores en la conexión frustrando a nuestros usuarios. Un tiempo aceptable sería entre 10 y 15 segundos. En la mayoría de sitios web donde he utilizado KeepAlive, utilizo 15 Segundos. El tiempo lo definimos en esta línea:
KeepAliveTimeout 15
La máxima que debemos tomar en cuenta utilizando KeepAlive KeepAlive Time Out es monitorear el comportamiento de nuestro VPS y de nuestros sitios al realizar los cambios, para poder elegir la configuración óptima.
Continuamos con el siguiente paso de optimización:
Cargar solamente los módulos necesarios: Apache por defecto, carga la mayoría de módulos que se adaptan a casi cualquier tipo de sitio web para mejorar su compatibilidad. Como solamente vamos a alojar sitios con WordPress, no necesitaremos todos estos módulos y podemos desactivarlos.
Estos son los módulos que una instalación típica de WordPress con Woocommerce instalado necesita para funcionar correctamente:


LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
Para desactivar los demás módulos en Centos, solamente comentamos las líneas de los módulos que no necesitemos con “#”.
Si utilizamos Debian o Ubuntu, debemos utilizar los comandos “a2enmod” para habilitar módulos y “a2dismod”para desactivar módulos.
Debemos ser cuidadosos al desactivar módulos comentando líneas, pues hay algunas líneas de configuración que afectan solamente a esos módulos y si están activas, provocarán un error en el arranque de Apache y si lo reiniciamos así, nuestros sitios quedarán fuera de línea hasta que corrijamos los errores en el archivo de configuración. Podemos desactivar estos módulos y guardar el archivo de configuración, luego con “configtest” podemos probar si el archivo no tiene errores. El comando se ejecutaría así:
service httpd configtest
Nos mostrará el error y el número de línea donde se originó el error. Podemos tomar nota de ese o esos números de línea y abrimos el archivo de configuración en vi. Luego podemos escribir “:set number” en minúsculas y sin comillas para que vi muestre los números de línea y sea más facil corregir los errores. Una vez corregidos todos los errores, podremos probar nuevamente con el comando “configtest” y si nos devuelve el mensaje “Syntax OK” podemos proceder a reiniciar Apache con plena confianza.
Instalar mod-pagespeed de Google: Este es un excelente módulo desarrollado por Google para Apache. También está disponible para NginX, pero la instalación debe hacerser desde el “source”.
En palabras sencillas, lo que hace este módulo es implementar automáticamente las mejores prácticas de desarrollo web para mejorar la latencia y la velocidad de la entrega de contenidos. Edita automáticamente el código de nuestros sitios web para mejorar la velocidad del mismo y sin afectar su apariencia ni su funcionamiento. Y lo mejor de todo es que es desarrollado y actualizado por Google en conjunto con las mejores compañías de hosting y CDN actuales. ¿A quién no le gustaría tener a google trabajando para su sitio web?
Para instalar este módulo en Centos, debemos primero agregar el repositorio de Google al repositorio base de Yum. Primero vamos a crear el archivo de repositorio con vi usando el siguiente comando:
vi /etc/yum.repos.d/google-mode-pagespeed.repo
Este comando nos abrirá un archivo vacío llamado “google-mode-pagespeed.repo”, pues cuando abrimos un archivo que no existe con vi, lo crea automáticamente. Agregamos estas líneas en el archivo vació:
[google-mod-pagespeed] name=google-mod-pagespeed
baseurl=http://dl.google.com/linux/mod-pagespeed/rpm/stable/$basearch
enabled=1
gpgcheck=0
Guardamos el archivo escribiendo “:wq” y ahora podemos proceder a instalar el módulo con el comando yum:
yum install mod-pagespeed
Una vez terminada la instalación, no necesita configuración, pues la configuración predeterminada es suficiente para la mayoría de las instalaciones. Si desean modificar algo, pueden hacerlo. Pueden aprender más acerca de mod-pagespeed en este enlace: https://developers.google.com/speed/pagespeed/module
Optimizar el servidor MySQL: Para optimizar el rendimiento de MySQL hay muchas cosas que podemos modificar en el archivo “My.cnf”, de las cuales puedo mencionarles esta que es la más importante: InnoDB, que es un mecanismo de almacenamiento de base de datos que exige integridad referencial en el caso de usar sistemas a base de transacciones con claves foráneas. Pero para el caso de WordPress, que la mayoría de uso de la base de datos sera para SELECT y UPDATE, no es necsario utilizar el motor InnoDB, además de que consume mucha memoria RAM. Para esto podemos agregar esta línea al archivo /etc/my.cnf
skip-innodb
De esta forma evitaremos desactivaremos Innodb en nuestro servidor MySQL.
Para hacernos la vida un poco más fácil, el servidor MySQL incluye dentro de la documentación instalada en nuestro servidor varios archivos de configuración de ejemplo con las configuraciones recomendadas para servidores pequeños, medianos, grandes, gigantes y enormes. Basado en el archivo de configuración “small” y otras recomendaciones que he leído en algunos foros y la documentación de MySQL, he llegado a este archivo de configuración, que es el que me ha servido para la mayoría de instalaciones. Les dejo el contenido completo para que lo utilicen y pueden investigar algo para modificar y mejorar el rendimiento:


[mysqld] port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
skip-name-resolve
# For low memory, InnoDB should not be used so keep skip-innodb uncommented unless required
skip-innodb
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 – 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump] quick
max_allowed_packet = 16M
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk] key_buffer = 8M
sort_buffer_size = 8M
[myisamchk] key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy] interactive-timeout


Optimizar php: Aunque realmente php no representa un consumo de recursos relevante, modificando estos valores del archivo /etc/php.ini puede ser de alguna ayuda:
memory_limit = 128M
realpath_cache_ttl=300
realpath_cache_size=1M
Utilizar software de Caché estático: Definitivamente, algo que ayuda mucho a reducir la carga y el tiempo de respuesta de nuestro servidor, es utilizar algún software de caché estático, es decir, que este software crea una versión estática de nuestro sitio dinámico ahorrando recursos del servidor en cada visita.
Del lado del servidor, podemos utilizar Varnish Caché y Alternative PHP Caché (APC). Pero la configuración es un poco complicada, de la cual haré un par de posts más adelante.
Del lado de WordPress, podemos instalar algún plugin como W3 Total Caché o WP Super Caché, que son los más recomendados, pero debemos  monitorear siempre el comportamiento de nuestro servidor aún después de haber realizado las instalaciones de este software, pues puede que nos consuman bastantes recursos y nuestro servidor deje sin servicio a algunos clientes. Debemos analizar si en realidad nos conviene o no utilizar caché.
Hasta aquí este tutorial, que espero que les sea de mucha ayuda.
Recuerden que pueden utilizar los comentarios para preguntar, sugerir o simplemente saludar; y también, no se olviden de compartir el artículo para que pueda servirle a alguien más.
Visita mi blog si te interesa más info similar:
http://luiszambrana.com.ar/optimizar-server-o-vps-con-poca-memoria-para-wordpress/

¡Hasta la próxima!
Compartir el post "Optimizar server o VPS con poca memoria para wordpress"
0
0
0
0No comments yet