[LUG.ro] Optimizando web/SQL server

Dom Mayo 1 12:15:15 ART 2011

realmente te va a dar resultado el mod_cache... siempre y cuando lo hagas demasiado abarcativo ni demasiado chico, el primero te consume ram y cpu...el 2do ni te das cuenta que esta.

mas alla de prueba/error toma como medida el tamaño medio de archivo, cuantas ocurrencias tiene en la home del sitio; digamos asi, de 100 pedidos, cuantos son siempre iguales y de que tamaño promedio, todo el secreto es parametrizarlo.

tamaño del cache, tamaño de ojbeto, cantidad de objetos, ubicacion, el resto es ir probando...pero realmente funciona y muy bien cuando le encontras la vuelta.

Sent from my iPad

El 30/04/2011, a las 21:37, Luis Diaz <diazluis en gmail.com> escribió:

> Yo tambien googleo bocha, al final con page speed tobe problemas
> horrendos, habia momentos donde el servidor se enloquecia, la carga
> llego a superar 100!!! al punto de casi no responder, por lo que esta
> deshabilitado, tambien fue jodido juzgar las mejorar, que se
> convertian en optimizacion de html entre otras, a costas de un leve
> aumento en la carga! :@
> Ahora mande xcache que lo veo bastante lindo, APC me resulto, pero en
> un punto comenzo a dar cache-slam sin parar y lo saque
> 
> El tema del htaccess, lo notaste realmente mejor?
> 
> de cherokee no se que decirte, ahi lo estoy mirando, algo que tenia
> ganas de probar era el mod_cache de apache y pasar a RAM los archivos
> estaticos q pueda, pero no siempre tengo ganas ni me parece sabio
> probar con el sitio en vivo, y lamentablemente a la vez es el mejor
> test-case que puedo conseguir
> 
> 2011/4/25 blitux <dev.pabloquiroga en gmail.com>:
>> El día 22 de abril de 2011 15:01, Luis Diaz <diazluis en gmail.com> escribió:
>>> Hola, gracias por la respuesta, actualmente estoy mandando el
>>> contenido estatico sin mas vueltas que un "expires: max" el resto pasa
>>> por php-fpm, y apc no funciona porque hace lios por un bug[1]
>>> los otros no los he probado aun, uso gzip, le di una mirada a varnish
>>> pero me causaba problemas, probe cloud-flare para el contenido
>>> estatico, pero no ganaba mucho ya que sus servers estan afuera del
>>> pais, de todas formas el contenido estatico sale de otro domiño (sin
>>> cookies)
>>> optimizaciones a nivel app no hice muchas ya que es una aplicacion que
>>> no hice y tanto no se.
>> 
>> Dale una mirada al .htaccess de http://html5boilerplate.com, que está
>> bastante bien armado. Una mejora a la performance de apache consiste
>> en colocar las directivas del .htaccess en donde definis el
>> virtualhost. De esa forma evitas el overhead de tener que levantar el
>> .htaccess en cada request.
>> 
>>> estoy por probar apache con pagespeed, la carga en el servidor no es
>>> una molestia por ahora! :D
>> 
>> Un servidor que probé con muy buenos resultados para contenido
>> estático es Cherokee [http://www.cherokee-project.com/].
>> Lamentablemente no pude configurarlo bien en un hardy para producción
>> porque habían paquetes viejos (algunos bugs...) y en ese entonces no
>> estaba tan estable. Pero vale la pena probarlo, es (segun dicen)
>> superior a lighttpd y nginx para contenido estático. Lo haces correr
>> en otro puerto, digamos 8080, y usas un proxy para levantar el
>> contenido, o podes hacerlo correr para otro dominio (asi evitas las
>> cookies, por ejemplo)
>> 
>>> mysql no parece tener problemas, pero lo fui tunenando con tunning-primer
>>> 
>>> tenes alguna opinion de eaccelerator o xcache?
>> 
>> No he probado xcache, y eacelerator lo probé hace mucho en mi maquina
>> de desarrollo y hubo mejoras, pero no seguí un proceso de
>> benchmarking. Actualmente tengo un par de sitios con los que puedo
>> probar para ver la diferencia, aunque estan con apc en php 5.3 y no he
>> tenido problemas todavía.
>> 
>>> La verdad ya no se que mas tocar, teniendo en cuenta la carga del
>>> servidor (infima) con 400 usuarios online creo que solo puedo aspirar
>>> a reducir el tiempo que tarda la pagina en generarse y tocar algun
>>> parametro de red
>> 
>> Estaría bueno levantar alguna wiki con este tipo de info para ir
>> estableciendo algunos procedimientos o tecnicas para optimizar servers
>> y aplicaciones web. No llevo notas de todo esto, solo recuerdo qué
>> usaba y despues googleo y veo que encuentro. No conocía, por ejemplo,
>> tuning-primer.
>> 
>>> [1]http://pecl.php.net/bugs/bug.php?id=16814
>>> 
>>> 2011/4/21 blitux <dev.pabloquiroga en gmail.com>:
>>>> El 20 de abril de 2011 21:22, Luis Diaz <diazluis en gmail.com> escribió:
>>>>> 
>>>>> Hola Muchachos, escribo para chusmear que optimizaciones hacen en sus
>>>>> servidores web/SQL para mejorar el rendimiento, actualmente no tengo
>>>>> problemas, pero siempre me gusta exprimir al maximo el hard
>>>>> 
>>>>> Actualmente sali de apache/mod_php y pase a nginx con php-fpm que anda
>>>>> muy muy lindo, mis usuarios dicen que el sitio responde mejor que
>>>>> antes, pero desafortunadamente no es una comparacion valida ya que
>>>>> tambien cambie el hardware
>>>>> 
>>>>> Vi que los de google toquetean parametros de red, pero no se que tan
>>>>> buena sea la idea
>>>>> 
>>>>> Ustedes usan algunos trucos u opciones "no estandar" que ayude con el
>>>>> rendimiento?
>>>> 
>>>> Hola Luis,
>>>> 
>>>> Hay varios frentes para optimizar una aplicación web.
>>>> 
>>>> Del lado del cliente: usar gzip en archivos de texto (css, js, html),
>>>> minificar y combinar css y js para reducir la cantidad de requests
>>>> https, utilizar sprites para reducir la cantidad de imagenes cargadas
>>>> por el browser, cargar archivos javascript en forma asincrónica para
>>>> evitar el bloqueo del renderizado y mejorar la velocidad percibida del
>>>> sitio, habilitar cache y expires para el contenido estático, no setear
>>>> cookies para contenido estatico, etc. Todas estas cosas podes
>>>> lograrlas usando la extensión Page Speed de google para Firefox, y
>>>> cada técnica tiene su laburito.
>>>> 
>>>> Del lado del server/aplicacion: no conozco mucho en cuanto a la
>>>> optimización de redes y en general de apache y mysql, pero las
>>>> técnicas que suelen usarse tienen que ver con la optimización de la
>>>> aplicación en si, mas que de los parametros del servidor. Por ejemplo,
>>>> hay consultas SQL que se pueden reescribir para que sea posible
>>>> cachearlas. Ajustar los parametros del server MySQL como tamaño de
>>>> cache, log slow queries, uso de memoria, etc. pueden mejorar el
>>>> rendimiento de la aplicación.
>>>> 
>>>> PHP puede ser optimizado mediante caches de opcode, como APC,
>>>> eaccelerator y xcache (no todas juntas) y ajustando los parámetros de
>>>> cada una dependiendo de la aplicación. Memcached puede ser utilizado
>>>> para cachear los resultados de operaciones intensivas y mejorar aún
>>>> mas el tiempo de respuesta.
>>>> 
>>>> Si tenes mucho contenido estático (texto, documentos o información que
>>>> no se modifique regularmente) podes utilizar Varnish [1] como caché.
>>>> Vuela.
>>>> 
>>>> Si la aplicación tiene muchos requests concurrentes, por ahi conviene
>>>> utilizar varios servers con balanceo de carga.
>>>> 
>>>> En fin, hay muchas técnicas para mejorar el rendimiento de una
>>>> aplicación, pero la mayoría tiene que ver con cache. Para probar el
>>>> rendimiento podrías usar siege o ab (incluido con apache, creo) que
>>>> básicamente te permite hacer requests concurrentes y tirar un promedio
>>>> de requests/seg. De esa forma podes ver si aumenta el rendimiento y
>>>> cuánto. Estas son las técnicas que he juntado con el tiempo y trato de
>>>> aplicarlas a todas mientras el hosting y la aplicación me lo permiten.
>>>> 
>>>> [1] http://www.varnish-cache.org/
>> 
>> 
>> --
>> Pablo Daniel Quiroga Figueroa | @blitux en twitter
>> Drupal Fan & Freelance Web Developer
>> Movil: (261) 4858 254
>> _______________________________________________
>> Lugro mailing list
>> Lugro en lugro.org.ar
>> http://lugro.org.ar/mailman/listinfo/lugro
>> 
> _______________________________________________
> Lugro mailing list
> Lugro en lugro.org.ar
> http://lugro.org.ar/mailman/listinfo/lugro