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 <[email protected]> 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 <[email protected]>: >> El día 22 de abril de 2011 15:01, Luis Diaz <[email protected]> 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 <[email protected]>: >>>> El 20 de abril de 2011 21:22, Luis Diaz <[email protected]> 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 >> [email protected] >> http://lugro.org.ar/mailman/listinfo/lugro >> > _______________________________________________ > Lugro mailing list > [email protected] > http://lugro.org.ar/mailman/listinfo/lugro _______________________________________________ Lugro mailing list [email protected] http://lugro.org.ar/mailman/listinfo/lugro
