[LUG.ro] Optimizando web/SQL server

Dom Mayo 1 20:29:35 ART 2011

Gracias! invetigue cherokee, pero no encontre nada concluyente, al
menos si pienso darle php junto a lo estatico

2011/5/1 Gustavo Ulises <mortadela en gmail.com>:
> 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
> _______________________________________________
> Lugro mailing list
> Lugro en lugro.org.ar
> http://lugro.org.ar/mailman/listinfo/lugro
>