Resumen

Wordpress manejador de contenido (cms) popular por su facil manejo y como si fuera poco, lo conforma una gran comunidad que desarrollan plugins y temas que lo hace más atractivo. Pero, esto no es suficiente, el rendimiento de wordpress no depende solamente de plugins o de temas; sino de ajustes (torque) necesarios en servicios que potencian su funcionamiento base de datos-servidor http. Para ello los objetivos planteados son: Evaluación de tiempo de carga y concurrencia, con el uso de herramientas que pueden ser ulitizadas para observar el comportamiento de wordpress en la web, incluye también el estado del servidor (Hardware) y concientiza su capacidad y límites de uso. Para la capa de base de datos, se relizan ajustes para mejorar su rendimiento que implica la elección del motor de almacenamiento orientado a la necesidad del portal y ajustes, además de la activación del servicio de desahogo para la capa de base de datos que es la reutilización de recursos a través memcached. Todo en funcion de generar una sinergía en los servicios que lo mantienen funcionando.

Benchmarking tiempo de carga

Escenarios para la evaluación de tiempo de carga del servidor http (apache), operaciones de computo y velocidad de disco del Servidor.

Herramientas de evaluación

Veamos cuales son y su funcionalidad el enfoque que tiene el uso de cada una de ellas es para evaluar tiempo de carga y el estado sistemico del servidor

ab

Es una herramienta de apache para evaluación de rendimiento de HTTP es opensource multi-plataforma. Una de las cualidades de AB te muestra cuantos solicitudes por segundos es capas de servir tu servior web.

sudo apt install apache2-utils

ahora executemos el comando hacia nuestro objetivo, para probar los tiempos de respuesta

ab -n100 -c20 http://prueba.com/

Se debe esperar algunos segundos mientras realiza las peticiones solicitadas en el comando inicial.

Atención: Estas pruebas no deben aplicarse en ambientes de producción, puede afectar el rendimiento del portal hasta acarrea un problema legal, por los efectos que pueda generados al incrementar los parametros de ab.

This is ApacheBench, Version 2.3 <$Revision: 1757674 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking google.com (be patient).....done


Server Software:        xsx
Server Hostname:        prueba.com
Server Port:            80

Document Path:          /
Document Length:        219 bytes

Concurrency Level:      20
Time taken for tests:   2.644 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      52800 bytes
HTML transferred:       21900 bytes
Requests per second:    37.81 [sec] (mean)
Time per request:       528.893 [ms] (mean)
Time per request:       26.445 [ms] (mean, across all concurrent requests)
Transfer rate:          19.50 [Kbytes/sec] received

primero, el comando tiene los siguientes parametros de ejecución:

• -n100 número de peticiones (request) al objetivo.
• -c20 multiples peticiones en un tiempo determinado.
• http://prueba.com url objetivo

Esta es la primera parte, del resultado:

• 25.91 segundos por cada 100 peticiones
• el tiempo alcanzó 528.893 [ms] por petición
• incluyendo todas las peticiones fue un total de casi 38.602[ms] equivalente a 39 segundos
• por último la velocidad de transferencia fue de 303.77 [Kbytes/sec].

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       76  211 289.7    121    1146
Processing:   101  197 154.8    140     912
Waiting:      101  183 138.6    138     893
Total:        185  408 315.3    266    1444

Percentage of the requests served within a certain time (ms)
  50%    266
  66%    291
  75%    421
  80%    533
  90%   1036
  95%   1255
  98%   1285
  99%   1444
 100%   1444 (longest request)

El cuadro permite ver los tiempos de conexion, indica cuanto es el mínimo para conectarse la media y el máximo por procesamiento y la espera. Si se observa con atención la conexion minima es de 76[ms] y la medida máxima es de 1146[ms]

Ab tiene otras opciones: peticiones con método post, usando un tipo de protocolo, conexion keepalive entre otras, que son utiles para intencificar la prueba de rendimiento.

wrk2

wrk es una herramienta de benchmarking http capaz de generar una importante carga de trabajo ejecutado en modo simple. También brinda la posibilidad de hacer uso de hilos (threads) para intensificar las peticiones hacia el objetivo.

La instalación en distros linux a través de github haciendo los pasos siguientes:

Atención Debes tener instalado git para descargar el paquete.

sudo apt-get update
git clone https://github.com/giltene/wrk2.git
cd wrk2
make
// move the executable to somewhere in your PATH
sudo cp wrk /usr/local/bin

hecha la instalación el siguiente paso es ejecutar el comando para realizar las pruebas de carga de trabajo.

./wrk -t1 -c2 -d60s -R2 http://prueba.com

los parámetros usados para realizar la operación son los siguientes:

• -t1 uso de 1 hilo (thread) para la carga de trabajo.
• -c2 habilitar dos conexiones.
• -d60s tiempo de la prueba 60 segundos
• -R2 cantidad de peticiones.

Running 1m test @ prueba.com
1 threads and 2 connections
Thread calibration: mean lat.: 240.948ms, rate sampling interval: 1034ms
Thread Stats   Avg      Stdev     Max   +/- Stdev
Latency   244.84ms  228.38ms   1.31s    85.63%
    Req/Sec     9.38      1.30    13.00     87.50%
Latency Distribution (HdrHistogram - Recorded Latency)
    50.000%  131.58ms
    75.000%  248.06ms
    90.000%  590.85ms
    99.000%    1.08s
    99.900%    1.24s
    99.990%    1.31s
    99.999%    1.31s
    100.000%    1.31s

En los resultados finales se puede observar con detalle que son similares a ab.

threads and 2 connections
Thread calibration: mean lat.: 240.948ms, rate sampling interval: 1034ms
Thread Stats   Avg      Stdev     Max   +/- Stdev
Latency   244.84ms  228.38ms   1.31s    85.63%
Req/Sec     9.38      1.30    13.00     87.50%

promedio tiene una latencia de 244.84ms y máximo 1.31s también se observa las peticiones por segundo promedio 9.38 13s fue el tiempo máximo por petición. Hay que tener claro, que mientras más opciones sean usadas el tiempo de carga tardará más segundos o milisegundos, lo crucial es conocer la carga de trabajo que soporta servidor web.

Sysbench

Evalua el rendimiento, como característica es multihilo (multithreaded) y multi-plataforma. El objetivo, conocer en esencia el rendimiento del sistema, en términos de los factores que influyen en el funcionamiento del servidor de base de datos. Un ejemplo, se puede medir la E/S de los archivos, alojamiento de mejora y velocidad de transferencia.

El primer paso es hacer la instalación, en debian 9 el paquete se encuentra ya en los repositorios

sudo apt install sysbench

en caso de no contar con los repositorios , existe un respositorio para su instalación en github informa cada paso para su instalación

Primero vamos a medir la capacidad de respuesta del cpu del servidor, con la identificación de números primos.

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
total time:                          32.6782s
total number of events:              10000
total time taken by event execution: 32.6762
per-request statistics:
min:                                  3.22ms
avg:                                  3.27ms
max:                                  8.34ms
approx.  95 percentile:               3.34ms

Threads fairness:
events (avg/stddev):           10000.0000/0.00
                               execution time (avg/stddev):   32.6762/0.00

la prueba, puede variar según lo actualizado del hardware. Lo primero total de tiempo transcurrido 32.6782sg, con una estadística de cálculo de operaciones

• min, tiempo de operación mínimo.
• avg, en promedio de todas las operaciones de números primos.
• max, la operación que llevo más tiempo en realizar.
• 95% de la operación se llevó acabo correctamente.

Ahora a evaluar el comportamiento del las E/S del disco duro del servidor

// crea el archivo
mkdir prueba
// posicionate en el archivo
cd prueba

//Primer comando  para preparar el ambiente
sysbench --test=fileio --file-total-size=20G prepare 

// segundo comando para ejecutar el test de E/S 
sysbench --test=fileio --file-total-size=20G --file-test-mode=rndrw \

se puede elevar el tamaño total de los archivos para la prueba, esto depende si se tiene el espacio suficiente.

Este es el resultado:

Operations performed:  19080 Read, 12720 Write, 40597 Other = 72397 Total
Read 298.12Mb  Written 198.75Mb  Total transferred 496.88Mb  (1.6562Mb/sec)
106.00 Requests/sec executed

Test execution summary:
total time:                          300.0020s
total number of events:              31800
total time taken by event execution: 146.6071
per-request statistics:
min:                                  0.01ms
avg:                                  4.61ms
max:                                212.82ms
approx.  95 percentile:              11.47ms

Threads fairness:
events (avg/stddev):           31800.0000/0.00
execution time (avg/stddev):   146.6071/0.00

Los datos emitidos por la prueba, arroja con exáctitud la ejecución que representa un 95% con un tiempo de duración de 300sec que equivale a 5min, con un total transferido 496.88Mb equivalente a 1.6562Mb/sec.

Ya al finalizar las pruebas de benchmarking por carga de trabajo y hardware, no hubo falla, errores o lentitud significativos, ahora lo siguiente
ajustar nuestra base de datos(mysql) y servidor http (apache) para una entonación de los servicios.

Motor de almacenamiento y análisis de sentencias.

Obtenida la información de tiempo de carga y capacidad de respuesta de el servidor. Ahora el siguiente paso, es determinar el consumo de tiempo de los queries que el motor de base de datos más utiliza. El modelo de base de datos de wordpress esta bien customizada, lo que quizá no se puede decir de cada plugins que existen en la comunidad. Para hacer ajustes elementales de la base de datos se considera lo siguiente:

• Activación de logs
• Análisis y evaluación de sentencias sql de alto consumo.
• Torque motor de almacenamiento (MyISAM).

Lectura de Logs

Para observar de cerca los queries que tienen alto consumo de recursos. Se debe activar en el archivo de configuración de Mysql. La configuración que se realizará se ejecuta en un Mysql versión 5.7.

la ruta para agregar las lineas que permitirán la observación de los logs

/etc/mysql/my.cnf

ahora para activar los logs la primera slow_query_log =1 permite establecer el tiempo referencial que un query sql puede tardar en ejecución, la segunda es la ruta donde el motor de base de datos los dejará a nuestra disposición.

slow_query_log = 1 
slow_query_log_file = /var/lib/mysql/mysql-slow.log

cuando se agreguen las lineas, es necesario reiniciar (restar) el servicio de mysql o recargar (reload) su configuración

/etc/init.d/mysql restar | reload

importante:, si se ejecutan queries que no consuman el tiempo límite configurado, no se visualizará las pruebas que se estén realizando .

Estás son las salidas de la configuración de los logs de alto consumo. Con este resultado, se ha cumplido con la activación de los logs.

Análisis y evaluación queries de alto consumo (herramientas)

La idea principal es encontrar el o los sql que consumen más tiempo de lo establecido. Ahora bien, para este post se usarán sólo dos, que a mi críterio son muy utiles.

• mysqldumpslow
• pt-query-digest

Esto permitirá hacer un análisis constante [depende del analista] de los query que en tiempo de ejecución esta realizando el motor de base de datos.

mysqldumpslow: Es un script hecho en perl que resume los queries de alto consumo, y muestra la veces que aparecen in el log estás son las diferentes opciones que ofrece para presentar diferentes formas la salidas del comando.

Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

  --verbose    verbose
  --debug      debug
  --help       write this text to standard output

  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al, at, ar, c, l, r, t), "at" is default
                al: average lock time
                ar: average rows sent
                at: average query time
                 c: count
                 l: lock time
                 r: rows sent
                 t: query time
  -r           reverse the sort order (largest last instead of first)
  -t NUM       just show the top n queries
  -a           dont abstract all numbers to N and strings to "S"
  -n NUM       abstract numbers with at least n digits within names
  -g PATTERN   grep: only consider stmts that include this string
  -h HOSTNAME  hostname of db server for -slow.log filename (can be wildcard),
               default is "*", i.e. match all
  -i NAME      name of server instance (if using mysql.server startup script)
  -l           dont subtract lock time from total time

antes de utilizar el comando, se tiene una base de datos con una buena cantidad de registros . Esto para observar los sql con mayor consumo en tiempo.

Estos quieries tienen particularidades, por ejemplo, el segundo es bien sabido que el uso de * from en consultas que tengan gran cantidad de registros tiende a ser alto consumo de tiempo, a parte lo que ímplica en seguridad de base de datos (sql-injection).

ahora ejecutamos este comando para obtener la información de los queries que tienen alto consumo

  sudo mysqldumpslow -v -s t  -t 5

Count: 1  Time=24.14s (24s)  Lock=0.00s (0s)  Rows=25.0 (25), root[root]@localhost
  SELECT * FROM datos
  ORDER BY datos.primerapellido ASC LIMIT N, N

Count: 1  Time=23.63s (23s)  Lock=0.00s (0s)  Rows=504266.0 (504266), root[root]@localhost
  SELECT * FROM datos WHERE fecha like "S"

Count: 1  Time=13.89s (13s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
  SELECT count(idc) FROM datos WHERE fecha like "S" and primernombre  like "S"

Count: 1  Time=13.65s (13s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
  SELECT count(idc) FROM datos WHERE fecha like "S"

Count: 1  Time=1.41s (1s)  Lock=0.00s (0s)  Rows=1000000.0 (1000000), root[root]@localhost
  SELECT * FROM datos limit N

Como se observa el comando genera como resultado, despliega las sentencias sql que se ejecutarón y generarón más tiempo de carga según lo establecido en el archivo de configuración.

• (-v ) desplegar la información
• (-s t) Ordenar por consumo de tiempo
• (-t 5) listar las últimas 5 sentencias.

La segunda sentencia tiene un tiempo de ejecución de 23.63 seg, para un total de 504.266 columnas y la cantidad de veces que se realizó la sentencia aparece solo 1 vez. Obtenida la información, ya tenemos información para la revisión y mejora de la sentencia que tiene alto consumo de tiempo y recursos.

Con las opciones presentadas arriba si se desea se organizan, se listan por prioridad y hasta opciones de busqueda más avanzadas incluyendo identificar esos factores que afectan el rendimiento de nuestra base de datos.

pt-query-digest: Análiza los logs de alto consumo, los generales, y por último los archivos de logs binarios. Es una navaja suiza tiene una gran cantidad de opciones , solo se usará lo básico para explorar los resultados muy someros de los datos arrojados por los logs.

En los repositorios de debian a partir de la 7 wheeze hasta la 9.

sudo apt-get install percona-toolkit 

para otras versiones de linux puedes encontrar información pt-query-digest

sudo pt-query-digest /var/lib/mysql/mysql-slow.log

 360ms user time, 20ms system time, 34.80M rss, 96.48M vsz
 Current date: Tue Apr  9 08:26:50 2019
 Hostname: 4l3x
 Files: /var/lib/mysql/mysql-slow.log
 Overall: 108 total, 28 unique, 0.00 QPS, 0.00x concurrency 
 Time range: 2019-04-03T21:44:10 to 2019-04-06T22:45:12
 Attribute          total     min     max     avg     95%  stddev  median
 ============     ======= ======= ======= ======= ======= ======= =======
 Exec time            77s   193us     24s   712ms    23ms      4s   503us
 Lock time           37ms    82us     8ms   346us   799us   711us   185us
 Rows sent          1.44M       0 976.56k  13.61k   40.45 102.76k    0.99
 Rows examine      94.01M       0  23.26M 891.32k  212.52   4.23M   31.70
 Query size        22.00k      35   1.31k  208.62  420.77  253.56  130.47

se reutiliza la información que se registra en el archivo mysql-slow.log pero se presenta de otra forma, desagregada y específica aún más que mysqldumbslow. Presentando lo siguiente:

• tiempo de duración de consulta 24seg
• tiempo de ejecución total 77 seg
• columnas verificadas total 94MB
• tamaño del query 22.00k

Selección de Motor de almacenamiento

Luego de haber evaluado estado actual del hardware y tiempo de consumo de la aplicación; tener esta información clara, es que permite continuar con este paso, que son los ajustes y definir el motor de almacenamiento.

Existen muchos motores de almacenamiento en Mysql; sin embargo, como se está orientando a su uso en wordpress, se mencionará muy superficial alguno de ellos.

Motores de almacenamiento

MyISAM Es el motor por defecto de Mysql y es el más viejo. Provee un buen compromiso en rendimiento y caracteristicas utiles; cómo full-text indexing, compresción, and spatial (GIS) funcion. No soporta, transacciones entres sus carácteristicas más resaltantes está:

• busqueda-concurrencia
• reparación automática y manual
• indexación.

InnoDB Esta diseñado para procesamiento de transacciones –especialmente procesar muchas en tiempo reducido. Actualmente sigue siendo uno de los motores de almacenamiento más populares para transacciones.

• recuperación automática de daños.
• colección de datos conocido como tablespaces.
• MVCC (control de concurrencia).
• index.

Estos son los motores tradicionales sin embargo hay otros que quiza se hayan usado son los siguientes: Memoria (memory), Archivo (Archive), CSV, Hoyo-negro (Black-Hole), NB-CLUSTER, Maria entre otros. Cada uno de ellos, para un caso en particular o necesidades asociadas a la aplicación.

Para wordpress su enfoque no son las transacciones – a menos que sea modificado para ello. Una buena busqueda con un mínimo de consumo y un buen tiempo de respuesta.

Configuración

Antes de iniciar la configuración del motor MyISAM, se debe tomar en cuenta lo siguiente:

• Ser cuidadoso al realizar cambios de veriables. “Más no siempre es mejor”; sino se tiene idea de lo que se está haciendo se puede causar inconvenientes en el servidor.
• realizar un plan de benchmarking.
• Evita la modificación de variables de manera vertiginosa. Cambia dos variables y con pruebas de benchmarking serciorate si dieron resultados.
• Guarda una copia de la configuración actual my.cnf

Memory

Importante, para el buen rendimiento de Mysql es la cantidad de memoria asignada . Antes que nada, determinar la arquitectura de nuestro Sistema Operativo si su funcionamiento es de 32 o 64 bits, luego estimar cuanto consume normalmente en funcionamiento con todas sus aplicaciones en ejecución , ese resultado es el total de memoria usada ejemplo: si el total es de 3GB usado todas las aplicaciones incluyendo el sistema operativa, al configurar Mysql ya se conoce la cantidad que se debe dejar.

The Key cache / key Buffers

Esta variable permite designar una cantidad de espacio para el uso de Key Buffers. Lo mas importante de esta variable, deberia tener asignado en promedio como un 25% o 50% del total de la cantidad de memoria para cache.

Ejemplo.
archivo my.cnf de mysql 
Key_buffer_size = 256M

Cuando se configuró el archivo my.cnf para emitir las consultas de alto consumo, se colocó cual es la ruta que además hay que tener encuenta que para Windows y otras distribuciones de linux y BSD tienen otra ruta para agregar nuevos parametros.

Para el motor MyISAM es super importante porque el uso de cache va orientado hacia las indexaciones y no a los datos (tarea que se la deja al sistema operativo).

The thread cache

Variable que especifica el numero de hilos que Mysql puede mantener en cache.

 mysql -h localhost -u root -pxxx -B -e "SHOW STATUS LIKE 'Threads_connected';" | cat > /home/4l3/Documentos/hilos_conectados

el resultado

+-------------------+------+
| Variable_name     |Value |
+ ------------------+------+
| Threads_connected | 1    |
+ ------------------+------+

Importante: si el servidor no recibe suficiente peticiones que responder, no es necesario configurarlo .

Ejemplo.
#archivo my.cnf de mysql 
Key_buffer_size   = 256M
Thread_cache_size = 10

Key cache Block size

Esto permite mejora de rendimiento de las operaciones de E/S para los archivos index. También porqué es el modo en que MyISAM interactua con la cache del sistema operativo y el filesystem.

Lo primero, conocer “page size” de nuestro equipo, luego se le configura 1/4 parte del total.

sudo getconf PAGE_SIZE

4096

myisam_recover_option

Opción permite verificar a mysql las tablas del motor MyISAM sí contienen errores y repara automáticamente . existen 4 opciones : DEFAULT, BACKUP, FORCE y QUICK.

• DEFAULT : intenta reparar las tablas que esten marcadas con errores o sin ellos.
• Backup : Realiza un respaldo dentro de un archivo con extensión .BAK. El cual puede ser revisado si es necesario.
• FORCE : Continuamente realiza recuperación en caso de que más de una columna pueda perderse.
• QUICK : Evita la recuperación a menos que existan bloques de datos eliminados, que a futuro pueden ser usados para nuevos registros.

Ejemplo.
//archivo my.cnf de mysql 
Key_buffer_size   = 256M
Thread_cache_size = 10

//reparación
myisam-recover-options = FORCE,BACKUP

concurrent_insert

Permite controlar lectura/escritura simultaneamente, MyISAM no maneja MVCC, esta es una manera de solventarlo. Las opciones disponibles para esta variable son las siguientes:

• 0: No permite inserciones concurrentes.
• 1: Son permitidas las inserciones concurrentes.
• 2: Forza las concurrentes inserciones al final de las tablas – espacios vacíos.

Ejemplo.
//archivo my.cnf de mysql 
//cache
Key_buffer_size   = 256M
Thread_cache_size = 10

//reparación
myisam-recover-options = FORCE,BACKUP

//concurrencia
concurrent_insert      = 2

La modificación de estás variables depende de la capacidad de respuesta de nuestro servidor (hardware) de lo contrario no habrá mejora de nuestro servicio de base de datos en consecuencia un vago rendimiento a wordpress.

Servidor http (apache)

La elección de un servidor web para wordpress es importante pero, potenciar su funcionamiento lo es aún más. Existen cualquier cantidad de opciones de servidores web para el funcionamiento del cms pero no es de ello lo que aquí se especificará, sino más bien en realizar ajustes necesarios que permita un buen rendimiento de wordpress.

Apache es un servidor http pieza importante de software siendo uno de los más usados en el mundo opensource, desarrollado en lenguaje C en 1996 y con una buena aceptación en el mercado de páginas web –colocar enlace wikipedia apache http con más información.

se va a realizar los siguientes ajustes:

• Determinando consumo de memoria.
• Selección y parametrización basica módulo-multiproceso (Prefork).
• Comprime archivos
• Keep-alive reutiliza conexiones

Determinando el consumo de memoria

Por general las distribuciones Linux tienen repositorios que permite facilmente la instalación de un paquete de software, pero en su momento no se piensa que eso ya viene con variables de configuación por defecto, que no necesariamente son efectivas para el servicio que se este implementando apache es uno de ellos.

Anteriormente se expuso lo importante que es la memoria para el servicio de base de datos, además que apache es otro servicio que necesita su reserva pero no debería consumir más de lo necesario.

Lo primero que se debe saber que cantidad esta usando apache para responder las peticiones http.

ps axo rss,comm,pid | awk '{proc_list[$2] += $1; } END { for (proc in proc_list)\
{ printf("%d\t%s\n", proc_list[proc], proc);  } }'\
 | sort -n | tail -n 10 | sort -rn | awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}'

Como resultado el comando emite esta información

3454MB	chromium
277MB	soffice.bin
221MB	evince
219MB	mysqld
120MB	apache2
87MB	hugo
74MB	Xorg
73MB	mate-panel
70MB	megasync
66MB	caja

142 mb es el consumo que tiene el apache en mi computador, con unos parametros que fueron modificados, ahora bien el siguiente paso con un comando muy parecido se puede observar los procesos que ejecuta apache para tener ese consumo de memoria.

 ps aux | grep 'apache2' | awk '{print $6/1024 " MB ";}

estos son los procesos y el consumo

44.6836 MB
14.6523 MB
15.0234 MB
15.0234 MB
15.0234 MB
15.0234 MB
15.0234 MB
0.957031 MB

La suma total debe darte igual que el primer comando.

Desde luego, al tener recursos (hardware) para soportar una carga mayor puedes modificar las opciones de apache , siempre y cuando partiendo del benchmarking, esto da una idea de la capacidad de soportar o limite que tiene el servidor web.

Este consumo se debe al modulo multi-proceso que esté configurado en tu servidor. En la sección siguiente describiremos prefork, es el elegido para este post, sin embargo se mencionará otros que posee apache para otras necesidades.

Selección y parametrización del módulo multi-procesos (Prefork)

El consumo de recursos en parte se debe a la configuración del servidor http, de respuestas.

Se usará prefork, por que es el estandar y una configuración menos rigurosa que pueden tener los demás módulos, además es pertinente para un sitio básico en wordpress.

veamos una pequeña descripción de cada uno de ellos importante para considerarlo en su implementación.

• Prefork: multi-proceso, no implementa procesos (threads) para su uso. Es una versión de bajo consumo, que es muy raro tener que hacer ajustes de parámetros. Lo más importante es que MaxrequestWorkers los parametros sean elevados para manejar muchas peticiones, pero a su vez que sus procesos minimos por el consumo de memoria del servidor.

• Worker: a diferencia de Prefork es un servidor web multi-proceso/multi-hilo, cada subproceso de este modulo, puede tener multiples hilos, puede menjar más peticiones que prefork con poco uso de recursos. El módulo generalmente es recomendado para servidores que ámerite la gestión de alto tráfico.

• Event: Cada proceso es manejado por eventos, puede contener multiples hilos, sin embargo es diferente ha worker porque es capas de hacer mas de una tarea, también es de bajo consumo. El módulo esta soportado en versiones de apache 2.4 en la 2.2 es experimental.

Conocidos algunos módulos y a que puede ir orientado cada uno, veamos los parametros del prefork para adecuarlo a los recursos. Para prefork la configuración

se debe tener activo el módulo para hacer los ajustes

4l3x:> sudo vi /etc/apache2/mods-available/mpm_prefork.conf

Lo importante como se dice conceptualmente es adaptarlo al recurso que tenemos y no dejar variables por defecto

<IfModule mpm_prefork_module>
	StartServers		 4 
    MinSpareServers		 1 
	MaxSpareServers		 2  
	MaxRequestWorkers	 100 
	MaxClients			40
	MaxConnectionsPerChild 4
    ServerLimit 100
</IfModule>

• MaxrequestWorkers: establece un limite simultaneo de peticiones que estarán servidas. Esta fuertemente vinculada con ServerLimit.
• ServerLimit: esta directiva establece un máximo de valores configurados para MaxrequestWorkers para el tiempo de vida de los procesos de apache. Por lo general es usada si solo sí se necesita incrementar MaxRequestWorker más de 256 (por defecto).
• MinSpareServers/MaxSpareServers: establece un número deseados de sub-procesos inactivos –que no manejan peticiones.
• StartServers: estabece el número de sub-procesos creados al iniciar.
• MaxConnectionsPerChild: establece el limite de conexiones que un sub-proceso individual podrá manejar.

Luego de realizar, estos ajustes mi equipo al inicio tenia un consumo de 500mb solo con apache, luego paso a solo consumir 240mb máximo, interesante, porque en servidores con gran capacidad de memoria y de computo una coniguración por defecto podría tener aún mayor cantidad de consumo y sin limites de peticiones.

Reduce ancho de banda (mod_deflare)

Muchos portales web actualmente tienen cualquier cantidad de archivos enlazados para gestionar interfaces (css), y programación del lado del cliente (javscript). Pero cuando cualquier persona visita el portal, se ve afectado el tiempo de carga por la cantidad de enlaces estáticos que debe buscar el servidor http. Para esto apache tiene un modulo para comprimir y que el portal reduzca notablemente los tiempos de carga, es llamado mod_deflare.

primero se debe activar el mod_deflare en apache.

sudo a2enmod deflate

reincias el servicio de apache para que reconozca los cambios

/etc/init.d/apache2 restart

esta claro, que para otras versiones de linux y windows se activa de diferente manera

Primero es buscar el archivo .htacess y agregar lo siguiente este archivo por lo general es localizado en la carpeta principal del proyecto está oculto. abrir con un editor de texto y agregar las siguientes lineas:

<IfModule mod_deflate.c>

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

En la imagen se puede observar cuando está activa la compresión de archivos en wordpress

Las imagenes pueden ser reducidas sin perder la calidad esto también contribuye a un buen rendimiento de wordpress, existen plugin o con aplicaciones.

Reutiliza conexiones (KeepAlive)

Por defecto el comportamiento del servidor web http por cada documento es sencillamente solicitar una nueva conexion. Esto causa mucho consumo de tiempo para abrir y cerrar las conexion.

• KeepAlive permite hacer multiple peticiones sobre una simple conexion, lo que evita gastar tiempo en establecer conexion a socket. En pocas palabras, hace más productivo la interación de los usuarios al portal.

KeepAlive tiene dos caracteristicas determinantes para su configuración

• MaxKeepAliveRequest: indica cuantas peticiones deberian ser permitidas en una simple conexion, por defecto esta directiva tiene 100, pero hay que tener cuidado en dejarla en cero (0) queda sin limite de peticiones.

• KeepAliveTimeUp: indica cuanto tiempo una conexion se mantendrá activa cuando no se reciban más peticiones.

Estos valores pueden ser altos o bajos dependiendo de la cantidad de contenido que se esté presentando en el portal, se expone que si es muy alto, apache mantendrá estos procesos de conexión activos, lo cual podría transformase de beneficio a un vulnerabilidad de seguridad. Es decir, hay que tener un aproximado de estadia que pueda nuestros usuarios estar presente en el portal web.

la ruta de configuración de esta directiva

/etc/apache2/apache2.conf

KeepAlive On

MaxKeepAliveRequests 15

KeepAliveTimeout 5

por defecto el apache pre-compilado de los repositorios de debian ya viene configurado, pero considerando lo expuesto anteriormente hacer los ajustes según la cantidad de contenido que tiene nuestro web-site mejora su tiempo de respuesta.

Al final, la configuración de estos parámetros deben llevarse acabo verificando el tráfico un día normal para nuestro portal incluyendo el benchmarking ambos cruciales para los ajustes de cada servicio.

Memcached aligerando capa de base de datos

Libre y opensource, alto-rendimiento, sistema distribuido de cache de objetos en memoria, que aporta velocidad a aplicaciones web dinámicas, aligerando la carga de base de datos. Su funcionamiento se basa en registrar dentro de la memoria resultados de consultas de llamadas a base de datos, esto ofrece la posibilidad de reutilizar la información almacenada.

¿Que se desea activando este servicio? aligerar la carga y facilitar la carga de objetos (consultas-html) alojada en memoria a fin de incrementar la velocidad de wordpress.

Lo siguiente es instalarlo, para versiones de linux debian se puede buscar en los repositorios.

sudo apt-get install php-memcached memcached

se verifica la instalación con la activación del módulo en php. Para ello se debe tener activo el servidor http apache y php

creo un archivo con extensión .php dentro de está ruta /var/www/html/ y agrego este script

<?php
  echo phpinfo();
?>

lo usual es consultarlo en localhost o 127.0.0.1 y se verifica si está activo el servicio.

si se tiene esta instalación, se procede a verificar el servicio está activo en linux

Ahora se necesita integrar el servicio de memcached con wordpress, se debe instalar este plugin Memcached-is-your-friend

se clona el plugin dentro de la carpeta raíz de tu wordpress, la ruta que uso es /var/www/html/wordpress/wp-content/plugins/

git clone https://github.com/wpbullet/memcached-is-your-friend.git

Luego de clonar la carpeta del plugin para funcionamiento con wordpress, se agrega unas lineas en el documento wp-config.php

hay que saber cual es el tiempo de carga inicial, sin memcached

Ya activo el servicio de memcached

Como se observa aproximadamente unos 300[ms] de diferencia que puede darle mejor tiempo de respuesta a los usuarios. Estas adecuaciones también dependen de un buen proveedor de servicio para tener mejor velocidad de wordpress.

Conclusión

Los proveedores de serviicio de hosting ya tienen configurado y customizado la capa de base de datos y servidor http, lo que se dificulta que se personalicen, no obstante existen opciones que estan predeterminadas en cpanel para ser usadas incrementando el rendimiento de nuestro portal. Sin emabargo, si nuestra plataforma es independiente o se basa en vps o cloud server, se pueden realizar estos ajustes claro está, dependiendo de la capacidad (hardware) que tenga el servidor. Sin embargo, el iniciar con el benchmarking lo que arroje de información la evalaución sea un proveedor de servicio (restringido-personalizado) no evitará informarle sobre mejoras que deberá considerar para nuestro servicio aún así se deba pagar un poco más el beneficio sera retribuido por tiempo de respuesta. Para la capa de base de datos, hago enfasis en el uso de un solo motor de almacenamiento para wordpress esto puede hacer complejo el torque de mysql, es necesario conocer los parámetros que usa mysql para mejores resultado.

En el servicio de memcached, a pesar de no usar tanto procesamiento su fuerte está en la memoria, en mi trabajo pude apreciar que es necesaria su activación en un servidor distinto al de base de datos y http, por seguridad además que no saturas su funcionamiento. Creo que es necesario la adecuación de un servidor con una protección de tipo firewall para evitar cualquier ataque que deje inestable su funcionamiento. En otra oportunidad pude apreciar la velocidad que daba la activación de un módulo de php llamado opccache, puedo decir que disminuyó aún más el tiempo de respuesta del portal, rayaba aproximadamente en 500[ms], pero no pude profundizar en el consumo de recursos por ello, no lo mencioné, pero para otra oportunidad hablaré sobre su funcionamiento.

Wordpress no solo vive de plugin, como se ha presentado existe una diversidad de servicios que permiten potenciarlo al máximo y ofrecer una mejor experiencia para nuestros usuarios.

Referencias

• Baron Schwartz, Peter Zaitev, Vadim Trakchenkco, Jeremy D. Zawodny, Arjen Lentz & Derek j. Balling (2008) Higth Performance 2da edición Mysql Editorial O’Reilly

• Ken Coar and Rich Bowen, (2008) Apache Cookbook 2da Edición O’Reilly