Posted by oskar_calvo on August 12, 2011 at 3:15pm
Last updated by oskar_calvo on Wed, 2011-08-31 07:32
Last updated by oskar_calvo on Wed, 2011-08-31 07:32
Con un Drupal pensado mayormente para usuarios, y muy pesado podríamos preparar varias configuraciones de servidores y drupal, a ver que tal tira la cosa, se me han ocurrido ( Varnish y Memcache se podían encender y apagar según necesidades / pruebas ).
| Configuración | Responsable |
|---|---|
| Maquina con apache tal cual te lo instala. | |
| Maquina con apache bien configurado. | |
| Maquina con apache para web y lighthttp para estáticos. | |
| Maquina con nginx | floyd303 and co- perusio |
| Maquina con Cherokee | fastangel |
Comments
Nginx + Varnish?
¿No es un poco redundante? Nginx ya puede hacer lo que hacen apache+varnish.
La aiki es para hacer
La aiki es para hacer sugerencias y mejoras que yo no soy experto en tema de servidores .
Yo diría que la configuración
Yo diría que la configuración Nginx + Varnish es bastante atípica, es más habitual Apache+Varnish o Nginx solamente
He visto hows toma para
He visto hows toma para varnish con nginx . A gusto del consumidor, con tener algunos entornos me conformo .
Creo que es una actividad interesante , a ver sí entre todos logramos llevarlas a cabo.
Para mi el problema principal está en el conjunto de pruebas
Creo sinceramente que el mayor problema estriba en preparar un drupal lo suficientemente representativo y un conjunto de pruebas igualmente ajustado al caso medio (considerando concurrencia de peticiones distintas). Si vamos a considerar escalabilidad de la solución conforme crezcan los datos aún habrá que tener más cuidado en el diseño de las pruebas.
Por otra parte deberíamos saber qué queremos probar, si la combinación de archivos estáticos + Drupal (vamos a por soluciones/pruebas all-in-one) o lo que es puro rendimiento Drupal. Yo me centraría en rendimiento Drupal (PHP) ya que los archivos estáticos pueden delegarse a una capa proxy o a otro servidor (Varnish/Nginx/Squid) o CDN.
En cualquier caso:
- Apache admite al menos 3 formas de ejecutar PHP (Fast-cgi, fcgi, mod_php y fpm), cada una con sus ventajas e inconvenientes (sin entrar en modo de compilación Apache worker vs. prefork).
- Nginx admite al menos 2 formas de ejecutar PHP (cgi y fpm)
- Nginx + Lighttpd es una combinación ciertamente atípica (ambos son servidores de la misma familia y creo haber leído en algún sitio que parte del source de Nginx derivó de Lighttpd)
De momento no puedo comprometer tiempo al asunto, por temas personales la planificación de Agosto se me ha ido al carajo.
Salu2
Creo sinceramente que el
Creo sinceramente que el mayor problema estriba en preparar un drupal lo suficientemente representativo y un conjunto de pruebas igualmente ajustado al caso medio (considerando concurrencia de peticiones distintas).
Yo estaba pensando en utilizar varias distros de drupal- drupalcommons
- openpublish
- openatrium
- blog
Usar devel generate para agregar usuarios y contenido.
Y hacer pruebas de rendimiento sobre todo, ir probando con usuario anónimos y registrados para ver (munit) en que momentos se estresa más cada una de las opciones.
Esa es mi idea inicial.
Oskar
Combinatoria
En mi opinión personal y a riesgo de ser aguafiestas...
Yo elegiría 1 cosa a medir (rendimiento PHP del servidor http, rendimiento de las distribuciones, sistema de base de datos, etc.) y haría constantes el resto de factores... vamos si queremos que las conclusiones sean medianamente válidas/extrapolabes.
Salu2
Tiene mucho sentido ;) Pero
Tiene mucho sentido ;)
Pero mejor Drupal 7 ¿no?
Yo creo que es preferible
Coincido en que a estas alturas probablemente es más util realizar las pruebas sobre la versión 7.
Volviendo al conjunto de datos, estaria bien no solo tener nodos en bruto y las páginas habituales de taxonomía... para ajustarnos a un aso más típico/real de uso y no quedarnos en una prueba teórica. Sugeriría emplear views y/o panels ¿qué opinais?
Salu2
No todo el camo es oregano :)
No todo el camo es oregano :) y para algunas cosas d7 aun no es viable ya que no ofrece todo lo que se necesita o esta en alpha.
Por otro lado desconozco profilesde d7 que nos den unas configuraciones tan completas como las mencionadas arriba.
Así y todo se puede mirar para montar también algún desarrollo a medida "pesado" para d7.
Pero esto hay que decidirlo lo antes posible para no llegar a Sevilla con los deberes sin hacer.
Oskar
En la propuesta inicial si
En la propuesta inicial si están mencionadas ;) (http://groups.drupal.org/node/168179) Así que se podría montar algo con pressflow y/o cocomore también en vez de usar algún profile.
Pero lo comentado antes, hay que "decdirlo" ya, si el 26 de agosto no hay nada decidido y tareas asumidas mejor dejarlo como actividad para otra camp.
Osar
Me reafirmo
Me reafirmo en mi postura incial... si lo que vamos a probar es rendimiento en generación mejor usar un solo perfil/distribución/base de código.
Si lo que queremos probar es distribuciones "out of the box" mejor usar un solo servidor+configuración y probar todas en la misma caja.
Si queremos probarlo todo lo más seguro es que terminemos por no probar nada.
Retorciendo tu argumento, Oskar: ¿Qué resultados le interesan más a la comunidad? ¿Qué prueba es más necesaria?
Salu2
Mi idea inicial o propuesta
Mi idea inicial o propuesta inicial era buscar cuales eran las configuraciones de servidores más óptimas según que tipo de "productos" se vayan a desarrollar.
Tenemos atrium y commons para sitios con usuarios (muchos o pocos) autentificados.
Blog y periodicos para mucho estático y opciones de comentarios de anónimos.
No estaba buscando la configuración perfecta de Drupal o sus productos, sino las mejores aproximaciones de servidores y poder decir en el informe.
Conclusiones:Para productos del tipo de red social con muchos usuarios se ha visto que el mejor rendimiento del servidor es xxxxx
Para productos del tipo periódico con mucho servicio de estáticos y vídeos se ha visto que el mejor rendimiento del servidor es xxxxx
etc....
Oskar
Eso obligaría a diseñar distintas pruebas
Ciertamente tu planteamiento es más ambicioso y más laborioso también.
De todas formas, no sé hasta que punto se podrían generalizar las conclusiones... ya que cada caso de uso particular va a diferir al menos de la distribución pelada en la misma medida que cada distribución difiere de Drupal.
Además si de lo que se trata es de hacerle un perfil a cada distribución (o tipo de proyecto), habría que considerar Memcache (y versión del conector), backend de base de datos, configuración de base de datos...
En cualquier caso, para acotar el trabajo, según tu idea yo lo plantearía por etapas guiadas:
- Caso de rendimiento base: sobre una distribución Linux estandar (vg. Debian o Ubuntu Server LTS) con Apache+mod_php+módulos por defeto sobre el MySQL de la distribución.
- Ejecución de las pruebas de base.
- Premisa X: Incorporar YYY (sustituyase por la tecnogía/ajuste) mejoraría el rendimiento dado ZZZ (que es adecuado por el tipo de uso, que optimiza siempre, ponga su razón aquí)
- Ejecución de las pruebas sobre el sistema base modificado para validar/refutar premisa. En caso de no apreciarse el cambio razonar si existe algún facctor limitante.
- Iterar sobre tantas premisas como se establezcan.
- Combinar todas las premisas verificadas.
La razón por la que lo haría así es limitar el número de combinaciones ddiferentes a probar.
Notesé el uso de condicionales, en mi opinión un estudio así de completo sería inabordable en 45 días... por eso sugería algo más modesto.
Salu2
Hombre, no se si es muy
Hombre, no se si es muy grande, o estan muchas cosas sin definir.
De todas formas como este es el wiki para verlo que otras propuestas u opciones de pruebas tenemos?
Oskar
Se me pasó antes
Antes se me olvidó, pero munin no es aplicable en estos casos... a lo sumo un análisis de la tabla accesslog a posteriori.
Salu2
(ambos son servidores de la
Nem por sombras. AFAIK, o Nginx tem algumas ideias que foram roubadas ao Apache 2, nomeadamente:
Memory pools.
Processing phases.
Tem em comum com o lighty o facto de ambos se basearem num event loop. Uma das coisas que implementou do lighty foi o
X-Sendque no nginx se chamaX-Accel-Redirect. Tem ideias roubadas a ambos mas a base de código é nativa.Estaré equivocado
Es posible que me esté confundiendo en lo de que parte del source derivase. En cuanto a lo de ser de la misma familia me refería en efecto al hecho de que ambos sean asíncronos (http://wiki.nginx.org/Faq : "Nginx and Lighttpd are probably the two best-known asynchronous servers..." vía http://www.wikivs.com/wiki/Lighttpd_vs_nginx)
Tengo curiosidad en que puede motivar el uso de Varnish + Nginx considerando lo bien que se comporta Nginx sirviendo contenido estático (de hecho es su fuerte respecto a Apache)... probablemente se me escapa algún caso de uso.
Da gusto ver a alguien puesto en Nginx, nos aprovecharemos de tus conocimientos! XD
Salu2
Olá
Vou escrever em Português. O meu castelhano é mau, muito mau. E como latinos falarmos numa língua bárbara como o inglês é rude ;)
O Pedro mencionou esta vossa iniciativa no twitter. Em princípio vou ao camp em Sevilha a ver vamos.
Interrogo-me se vale a pena o lightttpd. O que me parece é que basicamente neste momento é um projecto que tem só bugfixes sem desenvolvimento activo. Ao contrário do Nginx que está em ebulição.
A sugestão do Pedro faz sentido. Há quem use o Nginx com o Varnish à frente. Há soluções para replicar muito do que o Varnish faz usando alguns módulos 3rd party do Nginx. Para manter as coisas simples eu por mim eliminaria o lighty e incluiria o Varnish.
Saludos,
António
Se podría montar una máquina
Se podría montar una máquina también sobre cherokee. Si queréis me encargo yo.
@fastangel. Gracias, te lo
@fastangel.
Gracias, te lo asigno, vamos a ir moviendo en el tema de levantar las máquinas para que podais hacer las configuraciones.
Nosotros tenemos intención de
Nosotros tenemos intención de quitar el Apache de nuestro stack lamp para las web Drupal y cambiarlo por Nginx. Lo utilizamos para muchos otros productos que tenemos y estamos muy contentos con su funcionamiento.
Podríamos montar un sitio para pruebas de rendimiento. Lo único que todavía no tenemos planificado cuando lo vamos a hacer.
Un saludo
Roberto
@floyd303 Gracias, la idea es
@floyd303
Gracias, la idea es levantar varias máquinas en una nube, y dar acceso de configuración, a ver si la semana que viene las podemos tener levantadas y os damos acceso para que monteis nginx con las configuracions que considereis oportunas.
Oskar
Olá Oskar
Eu voluntario-me para dar uma mão na configuração do Nginx com o Drupal.
@perusio Gracias, te pongo
@perusio
Gracias, te pongo como co-responable, lo que teneis que hacer es configurar el servidor para que luego se pueda hacer una instalación de varios drupals.
Oskar
Hola Oskar
A minha vida tem sido caótica os últimos quinze dias. Surgiu projecto com um deadline muito curto e que tem que ser muito bem pensado.
Conta comigo a partir da próxima semana para configurarmos isto. Espero que consiga levar uma ideia à prática durante a próxima semana e façamos uma análise exaustiva dentro das possibilidades. Acho inclusive que deviamos publicar os resultados em inglês no High-Performance para lançar o debate.
Eu tenho a intuição (se calhar errada — a ver vamos) de que o Nginx com a sua cache nativa integrada com o Drupal vai esmagar a concorrência, seja em termos de utilização de recursos, seja em termos de desempenho puro e duro. A ver vamos.
Apache y punto
EMHO, apache no es el culpable del rendimiento, puede ocupar un poco más de memoria pero bien configurado no hay porque optar por nginx, lighttpd. Salvo se trate de un servidor exclusivamente para archivos estáticos: jpg, zip, etc. Pero Drupal necesita un servidor web robusto.
Además, si desean ahorrar memoria, configurar apache worker + mod_fcgid + PHP es lo ideal, uno se ahorra hasta la mitad de memoria de lo que mod_php +apache prefork consumen.
--
[develCuy](http://steemit.com/@develcuy) on steemit
Buenas develCuy. Gracias por
Buenas develCuy.
Gracias por la aportación, la idea es probar varios entornos de servidores, y utilizar diferentes configuraciones de Drupal para ver en cada caso cual es la que mejor se adapta a cada producto de Drupal.
Nadie pone en tela de juicio Apache, pero si a Apache le libras de los estáticos y los sirves en lighthttp por otro puerto la cosa va más deprisa, pensemos por ejemplo en un periódico con muchas imágenes/vídeos, etc...
La idea de todo, además de buscar algo para hacer el viernes por la tarde es probar diferentes entornos para diferentes "productos" de Drupal.
Te animas a configurar una máquina con Apache tal y como comentas para las pruebas?
Oskar
Apache mod_php, fcgid...
Podéis ver aquí lo que comentan al respecto:
http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better...
Rendimiento: velocidad vs. recursos
La verdad es qué no tengo experiencia directa en entornos de alto rendimiento con Apache worker debido a que todos los estudios que he visto registran más velocidad de ejecución PHP con mod_php (y esto implica el uso de prefork en la práctica: http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2).
Tal como yo entiendo el rendimiento (o tal como lo suelen necesitar nuestros clientes) es en términos de velocidad de respuesta, por lo que generalmente soy partidario de sacrificar recursos máquina para conseguirla.
Un buen diseño de pruebas nos permitiría medir bien estas cosas (en términos de velocidad, de estabilidad y de consumo)... ¿alguna idea/sugerencia sobre como encararlo?
Salu2
Se puede abrir otra
Se puede abrir otra página/discusión/wiki para definir otras pruebas para el 2012.
Oskar
No lo creo
Há razões fundamentais que justificam a opção Nginx (ou Lighty) como sendo superior. São razões que se prendem com a arquitectura. A realidade é que uma arquitectura baseada num event loop escala como mais nenhuma outra. Isto se não quisermos entrar em questões como o upgrade sem downtime que o Nginx providencia, ou os exploits periódicos que surgem para o Apache como este.
Usar o Nginx é tirar o servidor da equação. Qualquer outra coisa é aumentar a complexidade e introduzir mais incógnitas na equação do desempenho de um site.
Buenas, ¿Cómo anda este
Buenas,
¿Cómo anda este asunto?. ¿Se va a realizar el viernes?. Lo digo por que ya queda poco.
Mañana lunes reparto
Mañana lunes reparto credenciales.
Oskar
Onde está isso
Ainda não recebi informação nenhuma. Ou é segunda-feira (lunes) da próxima semana, dia 26?
Saludos,
António
Primero pedir disculpas,
Primero pedir disculpas, porque ayer que tenía que terminar de configurar el cloud se me lio el tema, lo quiero hacer hoy sin falta.
Sobre todo, porque vosotros necesitáis tiempo, y yo necesitaré luego tiempo para montar los drupals
Oskar