Mejorar las Prestaciones de un Equipo como Servidor
Introducción:
La necesidad de mejora del equipo en concreto surje por el hecho de querer convertirlo en un Servidor Web. La necesidad en concreto es mudar una página web de un servicio de hosting a un servidor propio, por motivos económicos. Se muda el servidor web, aunque se mantiene el servidor de base de datos en el servidor antiguo, por la complejidad que tenía la base de datos. En concreto se trata de una tienda online ( generada con Oscommerce, una plataforma OpenSource). Como factores influyentes hay que destacar que el servidor donde se quiere alojar es un ordenador con 4 años de antiguedad, al que se le quiere dar alguna utilidad
Fases de Evaluación del Sistema Informático:
Comenzamos el proceso de mejora, haciendolo de una manera ordenada y siguiendo los pasos establecidos en el tema 1 de la asignatura
1. Fijar objetivos y definicir el sistema base
Nuestro principal objetivo es hacer nuestro servidor mucho más rapido, capaz de soportar gran cantidad de conexiones simultaneas y agilizar el tiempo de servir las páginas web alojadas en él. El sistema base:
| Procesador: AMD Semprom (tn) Procesosr 2800+ Frecuencia: 1602.05 MHz L2 Caché: 256 KB Sistema Operativo: SO Ubuntu 6.10 (recordemos que el equipo tiene 4 años y hace 3 que no se usa Linux en él) |
2. Hacer una lista de los servicios que ofrece el sistema y sus posibles resultados:
El sistema dispone de servicio http, con php 5.2 y apache 2.0, se conecta a una base de datos externa alojada en la misma red local, el servidor en el que se aloja la base de datos está conectado mediante Wifi. Además nuestro servidor dispone de servidor de base de datos que está deshabilitado porque no se está usando
3. Seleccionar las métricas
Las métricas que voy a usar son las siguientes:
- Paginas servidas por segundo
- Tiempo en responder una petición
4. Listar los parámetros que pueden afectar a las prestaciones
Teniendo en cuenta el objetivo de la mejora los parametros que lo condicionan son diversos:
- A nivel hardware (memoria principal, CPU...) mejoras en la rapidez de la ejecución de los procesos, hace que sean más rapidas las peticiones porque tarda menos tiempo en procesar la petición
- A nivel de Software ( un software más actual seguramente sepa aprovechar mejor los recursos )
- Configuración de los parametros del servidor
- Velocidad de conexión (sobre todo de subida)
- Eficiencia del proceso encargado de gestionar la petición (código PHP)
- Tiempo de acceso a la información
5. Factores a estudiar
Teniendo en cuenta que el cambio se hace para evitar gastos, es lógico que nuestra mejora tenga que verse restringida al gasto de dinero, por lo tanto los factores que estudiaremos serán la actualización de software, mejora de la eficiencia del código PHP, configuración de PHP y tiempo de acceso a la información
6. Seleccionar las técnicas de evaluación:
Se ejecutará un benchmark que simula una carga de trabajo indicada. El benchmark que más confianza me da y más facilidad de uso tiene es el incorporado por apache llamado apache benchmark
7. Seleccionar la carga de trabajo
La carga de trabajo que simularemos estará en el rango de una carga de 10 a 20 peticiones y de 1 a 10 peticiones simultaneas, en este rango he seleccionado varias magnitudes para poder hacer varias mediciones por lo tanto las unidades elegidas son:
- 10 peticiones con ninguna concurrente
- 10 peticiones con ninguna concurrente
- 10 peticiones con ninguna concurrente
- 20 peticiones con ninguna concurrente
- 10 peticiones con 5 concurrentes
- 20 peticiones con 5 concurrentes
- 10 peticiones con 10 concurrente
- 20 peticiones con 10 concurrente
8. Diseñar los experimentos
Los experimentos tratan de simular la carga (especificada en el punto anterior) mediante el benchmark de apache desde un servidor totalmente externo y con un ancho de banda bastante amplio, lo suficiente como para que no influya en las mediciones, por lo tanto, especificamente haremos las mediciones desde la IP 150.214.191.99 a la IP 88.3.30.12 que es nuestro servidor. Este sería un benchMark de los que produce Apache BenchMark
| This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 88.3.30.12 (be patient).....done Server Software: Apache/2.2.11 Server Hostname: 88.3.30.12 Server Port: 80 Document Path: /oscommerce/catalog/ Document Length: 29674 bytes Concurrency Level: 10 Time taken for tests: 12.921 seconds Complete requests: 10 Failed requests: 9 (Connect: 0, Receive: 0, Length: 9, Exceptions: 0) Write errors: 0 Total transferred: 301486 bytes HTML transferred: 296576 bytes Requests per second: 0.77 [#/sec] (mean) Time per request: 12920.632 [ms] (mean) Time per request: 1292.063 [ms] (mean, across all concurrent requests) Transfer rate: 22.79 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 66 85 12.7 88 103 Processing: 1859 9794 3446.8 11134 12847 Waiting: 492 1643 605.9 1881 2382 Total: 1925 9879 3455.5 11226 12921 Percentage of the requests served within a certain time (ms) 50% 11226 66% 11436 75% 11785 80% 12118 90% 12921 95% 12921 98% 12921 99% 12921 100% 12921 (longest request) |
9. Analizar e interpretar los datos
Introducción al análisis
El análisis lo haremos como ya hemos especificado en los puntos anteriores. En concreto la orden que vamos usar desde el servidor externo es la siguiente "sudo ab -n10 -c5 http://88.3.30.12/oscommerce/oscommerce-2.2rc2a/catalog/" donde la opción -n es el número de peticiones y el -c el de peticiones simultaneas, por lo tanto el valor de -n oscilará entre 10 y 20 y el de -c entre 1, 5 y 10
Esta imagen corresponde al servidor en Ubuntu 6.10, viendo en un navegador la página web
Sistema Base
Reunimos en una tabla la información obtenida
| Peticiones Concurrentes | Peticiones Totales | Peticiones Fallidas | Peticiones por segundo | Tiempo en atender una petición (ms) | Porcentaje de Peticiones Fallidas |
|---|---|---|---|---|---|
| 1 | 10 | 9 | 0,17 | 5964,258 | 90 |
| 1 | 20 | 18 | 0,15 | 6559,390 | 90 |
| 5 | 10 | 9 | 0,22 | 4631,657 | 90 |
| 5 | 20 | 18 | 0,21 | 4660,543 | 90 |
| 10 | 10 | 7 | 0,22 | 4631,735 | 70 |
| 10 | 20 | 19 | 0,22 | 4584,670 | 95 |
| Media | 15 | 13,333 | 0,19833 | 5172,04 | 88,88 |
Mejora Número 1
La primera mejora era bastante obvia pues el Sistema Operativo era bastante antiguo, actualizarlo implica que esté más evolucionado que trabaje con los recursos del sistema de una manera mucho más eficiente y además nos permite descargar paquetes pues para la versión de Ubuntu6.10 ya no existian paquetes. Asi que actualizamos a Kubuntu 9.04 como podemos ver en la imagen:
| Peticiones Concurrentes | Peticiones Totales | Peticiones Fallidas | Peticiones por segundo | Tiempo en atender una petición | Porcentaje de Peticiones Fallidas |
|---|---|---|---|---|---|
| 1 | 10 | 1 | 0,17 | 5848,434 | 10 |
| 1 | 20 | 18 | 0,16 | 6104,946 | 90 |
| 5 | 10 | 8 | 0,22 | 4630,695 | 80 |
| 5 | 20 | 19 | 0,22 | 4565,102 | 95 |
| 10 | 10 | 7 | 0,22 | 4627,724 | 70 |
| 10 | 20 | 18 | 0,22 | 4584,670 | 90 |
| Media | 15 | 11,83 | 0,2016 | 5060,2618 | 78,888 |
Mejora Número 2
Mudamos la base de datos, del sistema externo a nuestro sistema, por lo que habilitamos el servicio de Base de Datos. La base de datos cabe en nuestro sistema sin problemas y además no se espera un gran crecimiento de esta por lo que su traspaso va a hacer que mejore el sistema. La base de datos será mySQL.
| Peticiones Concurrentes | Peticiones Totales | Peticiones Fallidas | Peticiones por segundo | Tiempo en atender una petición | Porcentaje de Peticiones Fallidas |
|---|---|---|---|---|---|
| 1 | 10 | 9 | 0,89 | 1125,845 | 90 |
| 1 | 20 | 19 | 0,85 | 1180,214 | 95 |
| 5 | 10 | 9 | 1,03 | 970,873 | 90 |
| 5 | 20 | 18 | 1,08 | 925,470 | 90 |
| 10 | 10 | 9 | 0,77 | 1292,063 | 90 |
| 10 | 20 | 19 | 1,08 | 924,538 | 95 |
| Media | 15 | 13,833 | 0,8083 | 1069,833 | 92,22 |
En esta mejora usaremos sistemas de caché en el propio servidor. Este método funciona de la siguiente forma: Cuando se recibe una petición al servidor, se analizan todos los parametros que puedan influir en el resultado ( POST, GET, SESSION y por suspuesto la url en cuestión), se le otorga un código y se almacena en base de datos, de forma que si algún otro consulta la misma página no se tendrá que volver a generar porque ya estaba en la caché
| Peticiones Concurrentes | Peticiones Totales | Peticiones Fallidas | Peticiones por segundo | Tiempo en atender una petición | Porcentaje de Peticiones Fallidas |
|---|---|---|---|---|---|
| 1 | 10 | 0 | 1,04 | 965,808 | 0 |
| 1 | 20 | 0 | 1,04 | 962,493 | 0 |
| 5 | 10 | 0 | 1,15 | 872,265 | 0 |
| 5 | 20 | 0 | 1,19 | 842,917 | 0 |
| 10 | 10 | 0 | 1,16 | 864,598 | 0 |
| 10 | 20 | 0 | 1,03 | 973,382 | 0 |
| Media | 15 | 0 | 1,1016 | 913,577 | 0 |
Ejecución en modo texto: Para evitar el uso de la CPU y que esté libre solo para la tarea que se le encomienda ( la de hacer de servidor) pondremos el sistema en modo texto.
| Peticiones Concurrentes | Peticiones Totales | Peticiones Fallidas | Peticiones por segundo | Tiempo en atender una petición | Porcentaje de Peticiones Fallidas |
|---|---|---|---|---|---|
| 1 | 10 | 0 | 1,03 | 968,043 | 0 |
| 1 | 20 | 0 | 1,04 | 965,567 | 0 |
| 5 | 10 | 0 | 1,16 | 858,432 | 0 |
| 5 | 20 | 0 | 1,18 | 845,525 | 0 |
| 10 | 10 | 0 | 1,12 | 896,534 | 0 |
| 10 | 20 | 0 | 1,19 | 842,006 | 0 |
| Media | 15 | 0 | 1,12 | 896,0178 | 0 |
En esta sección voy a presentar los resultados obtenidos con las mejoras hechas al servidor, y con el que hemos llegado a obtener un aumento de las prestaciones de casi 6 veces más. Recuerdo los pasos seguidos:
- 1. Cambio de SO
- 2. Cambiar localización de Base de Datos
- 3. Implantar un sistema de caché
- 4. Servidor en Modo Texto
| Peticiones por Segundo | ||
|---|---|---|
| Sistema | Media Pet/s | Descripción |
| Base | 0,198 | Este es el sistema base |
| Mejora 1 | 0,202 | Se cambia el SO de Ubuntu 6.10 a Kubuntu 9.04 |
| Mejora 2 | 0,808 | Se cambia de localización la base de datos ( se pone en localhost) |
| Mejora 3 | 1,102 | Se construye un sistema de cachés para ahorrar tiempo de proceso |
| Mejora 4 | 1,120 | Se pone el servidor en modo texto, para evitar la ejecución de procesos innecesarios |
Como podemos ver en el gráfico esta variable es mejor cuanto mayor sea, puntualizado esto vemos que la primera y segunda mejoras no difieren mucho entre si, pero aunque el cambio de sistema operativo, apenas aumente unas centesimas es un cambio obligado para poder pasar a hacer todos los demás. Por otro lado en el gráfico es más que evidente el grán cuello de botella de nuestro sistema es la base de datos, pues son los cambios que afectan a ella (2 y 3) los que más cambios producen, por útimo el cambio 4 apenas produce efecto, aun así produce una mejora (podemos mirarlo en la tabla)
| Tiempo en atender una petición (ms) | ||
|---|---|---|
| Sistema | Media (ms) | Descripción |
| Base | 5172,042 | Este es el sistema base |
| Mejora 1 | 5060,262 | Se cambia el SO de Ubuntu 6.10 a Kubuntu 9.04 |
| Mejora 2 | 1069,834 | Se cambia de localización la base de datos ( se pone en localhost) |
| Mejora 3 | 913,577 | Se construye un sistema de cachés para ahorrar tiempo de proceso |
| Mejora 4 | 896,018 | Se pone el servidor en modo texto, para evitar la ejecución de procesos innecesarios |
Esta variable, como observamos en la gráfica, es contraria a la anterior y es mejor cuanto menor sea. Viendo detenidamente el gráfico, podemos ver mejor la diferencia que supone la primera mejora con respecto al sistema base, además se siguen observando los cambio centrales, con la diferencia de que la mejora 3 no tiene tanto efecto en esta variable como en la anterior, esto se debe a que es capaz de generar una página en mas o menos el mismo tiempo pero es más concurrente por lo que podrá producir más páginas en el mismo tiempo
No hay comentarios:
Publicar un comentario