¿A qué se refieren con optimizar?

Hola, a qué se refieren cuando hablan de optimizar una web?
Se refieren a la base de datos, al servidor, archivos, a las palabras clave-seo?

¿Cómo puedo saber si mi website necesita una optimización -(no referente a SEO)?

Tengo un VPS con 50 K visitas mensuales

Optimizacion simplemente es la forma en la que se mejora algo para sacarle el maximo provecho.

Si tu sitio es lento: necesita optimizarce.
Si tu sitio mide mucho: necesita optimizarce.
etc.

Podrias comenzar con los tiempos de carga en Pingdom Tools

Otro tipo de optimizacion seria separar el contenido estatico como las imagenes del contenido dinamico, usando algun servidor externo o CDN.

Por medio de opcodes puedes reducir el uso de memoria RAM en cada peticion y al mismo tiempo reduces el tiempo en la que se genera.

yo también tengo un vos y ultimamente me va súper lento!

al final tendré que contratar a alguien o comprar un vps mayor.

Muchas gracias Shadow, ¿Hay empresas que se encargan de optimizar una web referente a los opcodes?

aitorcillo dijo:

Muchas gracias Shadow, ¿Hay empresas que se encargan de optimizar una web referente a los opcodes?

Hacer clic para expandir...

Yo diria personas, un ejemplo de opcode es PHP APC, actualmente lo uso y el tiempo en que se genera una página con WordPress es de unos 0.046 segundos, siendo que sin el opcode es de unos 0.200 a 0.400segundos, pero solo lo recomiendo con mod_php y no con CGI.

En general Optimizar significa aprovechar de mejor forma los recursos disponibles con el fin de mejorar el rendimiento, obviamente existen muchos tipos de optimizaciones y pueden tener relación con la parte física para optimizar código y archivos, otra sería la optimización lógica como la indexación en las BD y otra como optimizar el posicionamiento o SEO.

Yo me voy a referir básicamente a la optimización física y lógica ya que no soy ni me interesa ser especialista en SEO 🙂

Un concepto básico para hacer una mejora de rendimiento en informática se llama caché y básicamente se puede definir como una memoria de mayor velocidad que permite almacenar información almacenada en otro medio de menor velocidad, mejorando así el rendimiento... el caché existe en casi todos lados, dentro de los procesadores, dentro de los discos duros, dentro de las controladoras RAID, etc y en un servidor la idea es colocar en memoria información recurrente con el fin de no tener que ir cada vez a buscarla a disco.

Como funciona el caché ... el ejemplo lo voy a hacer con una consulta a una BD MySQL para que se entienda más facilmente ... si se hace una consulta "la primera vez" el sistema revisa si ya existen esos datos en caché ( memoria RAM ) ... si no existen los va a buscar al disco y de vuelta deja una copia en en caché ... si va una segunda vez y los encuentra en el caché "no necesita ir al disco" y por lo tanto gana la diferencia de velocidad de la RAM comparada con el disco que puede ser cientos e incluso miles de veces más rápida ... asi de simple es la cosa ... como conclusión lógica si no existe caché el 100% de las veces va a tener que ir al disco.
Otra deducción mas o menos evidente es que para poder usar caché y optimizar MySQL se necesita tener memoria RAM disponible 🙂
A nivel de hardware "mientras más caché" MEJOR ... los procesadores incluyen a veces hasta 3 tipos de caché Level 1, Level 2 y Level 3 ... que son memorias cada vez más rápidas ... pero mientras más rápidas mayor es el costo, por eso las más rápidas siempre van a tener menor capacidad ... asi que ya saben cuando comparen cpus o discos comparen los cachés de cada uno, un procesador más lento pero con más caché podría incluso tener un mejor rendimiento que uno más rápido pero con menos caché 🙂 ... sobre todo en un servidor web.

Para optimizar PHP por ejemplo se usan los caché de código como eAccelerator, xCache, APC, etc que en el fondo almacenan el código PHP ya "compilado" y no necesitan "interpretar" todo de nuevo linea por linea.

Con el uso de los CMS como WordPress cada día es más crítico que MySQL esté muy bien optimizado ya que a diferencia de un sitio web "html" tradicional que casi no usa MySQL ... WordPress está basado casi en un 100% en MySQL por lo que pasa a ser un elemento crítico.
El problema con la optimización de MySQL es que no es tan simple hacerlo ya que todos los servidores y sistemas son diferentes y necesitan diferentes formas de optimización "de acuerdo a los requerimientos" de cada sistema ... no sirve llegar y copiar una configuración encontrada en Google porque hay que saber los recursos que tenía ese servidor ... además los requerimientos de caché hay que irlos ajustando en el tiempo, algunos sistemas críticos que manejo los reviso al menos unas 2 o 3 veces cada mes.

La pregunta del millón es como saber si necesito una optimización ???
Un sintoma es ir notando que el mismo sistema va cada vez mas lento, es critico cuando ya hay caídas del sistema debido a esto ... normalmente la mejor forma de saberlo es analizando las estadísticas de uso de MySQL ... según mi experiencia más del 95% de los sistemas que usan MySQL no están bien optimizados o simplemente no tienen ningún tipo de optimización y utilizan la configuración que viene por defecto que es pésima.

La complicación que tiene por ejemplo una optimización de MySQL es que son casi 300 parámetros que hay que configurar, aunque los más importantes deben ser unos 30 y eso debe estar correlacionado entre ellos y la cantidad de recursos disponibles, en este caso como lo comenté anteriormente memoria RAM.
Las diferencias en un mismo servidor entre tener un MySQL optimizado o no pueden significar rendimientos incluso de cientos o miles de veces sin modificar el hardware ... y por el contrario si hay un problema grave de falta de caché y se sigue agregando memoria sin hacer una optimización ... no se gana absolutamente NADA, solo se gasta mas dinero.

Otro tipo de optimización que también es cada vez más crítico en las BD tiene relación con la indexación ... una sola consulta mal indexada o NO indexada puede ocasionar que un servidor por muy poderoso que sea ... colapse, la única forma de solucionar eso es analizando los logs de MySQL y agregando los índices correspondientes ... muchas veces me ha tocado solucionar problemas donde una sola consulta demora por ejemplo 12 segundos y luego de optimizar el índice la misma consulta demora un par de milisegundos, el problema se produce porque a veces en esos 12 segundos quedaron "atoradas" decenas de otras consultas en la cola de espera.

Otro tipo de optimización se puede hacer al seleccionar bien el "tipo de tabla" en una BD ... por ejemplo una tabla que requiere muchas actualizaciones simultáneas debería ser InnoDB ya que si es MyISAM las modificaciones se deben hacer de a una y las demas quedan en espera ... a veces "solo" cambiando el tipo de la tabla se soluciona el problema del "cuello de botella" en las modificaciones.

Por lo tanto si alguien está usando un servidor de "dudosa" reputación 🙂 ... sin un sistema de discos eficiente ( RAID ) ... sin controladoras con caché ... sin MySQL optimizado ... sin un buen uso de índices ... aunque agreguen mas cores y potencia de cpu y mas memoria RAM, lo más probable es que el rendimiento no va a tener una mejora apreciable.
Por lo anterior se explica a veces que un "buen" VPS pueda tener un rendimiento de MySQL muy superior a un dedicado con solo un disco SATA.

Otro tipo de optimización se puede hacer físicamente en los archivos de las BD al desfragmentar el archivo ... algo parecido a lo que se hace con la desfragmentación en Windows ... en MySQL existe el comando OPTIMIZE TABLE.

Como pueden ver este tema da para mucho ... además es un tópico que me apasiona y ojalá lo sigamos analizando, discutiendo y aportando en el foro.

Creo que usar cache, optimizar las bases de datos.

Continuando con lo expuesto previamente :

Otra forma de optimizar el rendimiento de un sitio web es separando los servicios, el ejemplo más básico consiste en separar web y MySQL, la ventaja de esto es que cada servidor se puede optimizar para una función específica, sobre todo el servidor MySQL ya que permite asignar todos los recursos para el motor MySQL, principalmente optimizar el uso de memoria y el acceso al sistema de discos ... en un servidor normal los recursos son compartidos por muchos servicios : web, mail, ftp, MySQL, dns, firewall, etc.
La otra gran ventaja de separar los servicios es que permite balancear la carga y un cluster o grupo de servidores de menor capacidad podrían ofrecer un mejor rendimiento que al tener un solo servidor de mayor capacidad ... hace unos meses monté un cluster con 6 VM's bajo Citrix conectados a un MySQL remoto que soportó 25.000 usuarios simultáneos con solo un 25% de carga global de cpu 🙂

Otra forma de balancear la carga pero cuando hay demasiadas imágenes o archivos es utilizando un CDN que es básicamente un conjunto de servidores distribuídos que "copian" los archivos de un sitio web y distribuyen la carga entre todos ellos, reduciendo así considerablemente el tráfico sobre el servidor que tiene el sitio web ... e incrementando el rendimiento porque el CDN está especializado en entregar información y cuenta para ello con grandes anchos de banda y muchos cache y aceleradores SSD y RAM.
Un CDN actúa como un "cache distribuído" de archivos estáticos.

Un buen indicador para saber si un servidor necesita mas memoria es cuando comienza a usar mucho el swap que básicamente es utilizar disco para almacenar e intercambiar páginas de memoria RAM ... no necesito explicar la diferencia de velocidad que automáticamente significa el uso de swapping, por lo tanto lo "ideal" es que el swap sea CERO ... en Linux se puede ver con el comando free.

Ya comenté que existen los optimizadores de código para PHP ( OPCaches ), pero también es posible "compilar" el código PHP solo una vez y no tener que estarlo "interpretando" cada vez, esto se puede hacer con compiladores como Zend o Ioncube que luego interpretan el código PHP previamente compilado y optimizado ... este sistema se utiliza además para proteger el código PHP ya que no se entrega el código fuente.

Cada día se utilizan más los CMS como WordPress y tal como ya comenté previamente la principal diferencia de los CMS es el uso intensivo que hacen de MySQL, por lo que también se han desarrollado herramientas de caché que se integran dentro del CMS, en el caso de WordPress podríamos hablar por ejemplo de Super Cache o Total Cache ... también se puede integrar un CDN dentro de un CMS con un plugin como Super Cache.

El consumo de cpu y memoria de un servidor también depende del PHP handler o manejador de PHP instalado que básicamente podría ser DSO, CGI, SuPHP o FastCGI, cada uno presenta ventajas y desventajas ( algunos por ejemplo no permiten usar los optimizadores de PHP ), esto de los handlers también da para otro capítulo 🙂

Volviendo a MySQL es muy importante aprovechar al máximo la memoria RAM configurando los distintos cachés de MySQL en forma balanceada y teniendo mucho cuidado de no sobrepasar la capacidad total de RAM ya que eso ocasionaría un problema tal vez mayor ya que podría hacer colapsar el servidor.
La estructura de las tablas también es importante, sobre todo los campos que van a ser usados como índices ... la eficiencia de los índices da para hacer un capítulo aparte pero algunas consideraciones básicas son usar índices del menor tamaño posible, ojalá numéricos y que sean campos con una alta variabilidad, por ejemplo el color del pelo no es un buen índice comparado con la fecha de nacimiento.
Un punto que muchos pasan por alto es el orden de los índices ... si por ejemplo se crea un indice con apellido + nombre y luego la consulta se hace por nombre + apellido, el índice NO SIRVE DE NADA y la busqueda se hace SECUENCIALMENTE demorando cientos o miles de veces más que si se hubiese usado un indice correctamente.

Por último podría mencionar las mejoras de rendimiento debidas a una mejora en el software del servidor web, utilizando por ejemplo caching proxy como Varnish o Squid que reducen el ancho de banda y mejoran los tiempos de respuesta haciendo caché y reusando las páginas usadas mas frecuentemente ... o reemplazando Apache por otro servidor web mas "liviano" que consuma menos cpu y ram como Nginx o Lighttpd.

Como ya lo dije antes ... este tema de la optimización es muy interesante 🙂 🙂 🙂

Vamos a agregar otro tipo de optimización :

Una que surgió despues del post anterior y que tiene que ver con el "peso" y los "tipos" de archivos utilizados para las imágenes ... me tocó revisar un sitio hecho en WordPress que presentaba caídas permanentemente y una de las razones era por su alto tráfico y sin un caché 🙂 ... al analizar las imágenes de la portada casi la totalidad estaban en formato .PNG lo cual es altamente ineficiente dado que en promedio la misma imágen se puede reducir a solo un 10% del peso original al convertirla a formato .JPG

Respecto al formato en general la idea es utilizar imágenes del mismo tamaño que se van a visualizar en pantalla, muchas veces se almacenan imágenes que tienen una resolución mayor a la resolución que aparecen en pantalla ... por ejemplo en pantalla la imágen se presenta con 400 pixeles de ancho, pero el archivo original tiene 2048 pixeles de ancho y pesa 10 veces más.

Otra ventaja que tiene el formato .JPG es que permite comprimir la imágen reduciendo un poco la calidad pero que muchas veces es imperceptible al ojo, lo importante es que también se puede reducir el peso.

Si hacemos un ejemplo práctico ... supongamos que hay 5 imágenes .PNG que pesan en promedio 450K c/u en la portada, al convertirlas a .JPG con un poco de compresión podríamos llegar fácilmente a unos 45K por cada una ... o sea redujimos el "peso" de la página de 2,25 Mb a solo 225 Kb ... si hay 10.000 visitas diarias implicaría reducir el tráfico desde 22,5 Gb a solo 2,25 Gb o sea un ahorro de 20 Gigabytes que no es nada de despreciable ... esto obviamente en forma "bruta" sin considerar todos los caches que puedan estar instalados.

La mayoría de las cámaras digitales hoy en día pueden tomar sin problemas fotos de 3.000 o más pixeles de ancho, pero ninguna pantalla va a permitir visualizarlas a full resolución por lo que cada vez es mas importante procesar previamente todas las imágenes ... la alta resolución solo tiene sentido para la impresión en alta calidad o en gran formato.

También me ha tocado ver scanners que quedan configurados "por defecto" para almacenar las imágenes en formato .PNG o incluso algunos formatos mucho mas antiguos como .TIF ... recomendación entonces utilizar .JPG, del tamaño que se va a visualizar y con algún nivel de compresión, esto es muy común también cuando se envían documentos digitalizados por e-mail ... varias veces me ha tocado "matar" correos que llevan atachado un documento de una página que pesa 30 o 40 Megas porque lo escanearon a 2400 dpi 🙂

Una herramienta bastante simple de usar, liviana, gratuita y en español que podríamos recomendar para solucionar todos estos problemas de formatos, compresión e imágenes en general podría ser :

http://www.dotpdn.com/files/Paint.NET.3.5.10.Install.zip

Algunos utilizan programas mucho mas "pesados" y complejos como PhotoShop ... pero eso es como salir a cazar patos con un tanque 🙂

También existen algunas herramientas que permiten analizar y visualizar el "peso" de una página web y detectar cuando hay imágenes muy pesadas y que requieren algún tipo de procesamiento, por ejemplo :

Pingdom Tools

Ya vendrán nuevas optimizaciones ... hasta la próxima 🙂

Aveces es mejor usar una imagen PNG indexada que JPG, depende de como sea la imagen no se pierde calidad y el peso baja desde 400 hasta solo 15KB, casi siempre los PNG indexados pesan 40% menos que un JPG en baja calidad