On 11 avr. 2009, at 11:48, "Renaud (Nel) Morvan" <[email protected] > wrote:
> >>> je n'arrive pas à voir l'intéret par rapport à un mod_rack si ce >>> n'est la >>> fingerprint. Y a un grand secret que j'ignore ? >> >> c'est surement parce que tu aimes tant ta solution que certains en >> aiment aussi d'autres ;) >> > > Non justement moi je n'ai pas d'amour pour les solutions que je > choisis, je choisis le meilleur rapport finance/performance Je reste persuade qu'il faut aussi regarder du cote des solutions qui nous sont agreables. Sinon pourquoi avoir choisi rails et pas un autre framework plus rapide ? > >> En restant toujours sur la même solution tout en dénigrant les aut >> res, >> je doute qu'on ai beaucoup de diversité au final. > > Qui parle de dénigrer, on parle de solution adaptée à la réalité. > >> plusieurs raisons : >> - apache à une latence plus importante que nginx ou lighttpd > perceptible par un httperf, pas par un humain Firefox me donne des temps de reponse tres differents sur une machine evidemment située sur un reseau local. Donc perceptible par un humain. > >> - apache est moins performant que nginx, surtout sur la portion gzip > perceptible par un httperf, pas par un humain Meme point ici. > >> - laisser tourner constamment mes applis me permet de voir les >> fuites >> de mémoire sur mes applications et donc de voir les problèmes > mouais... > >> - passenger mets du temps à démarrer la première instance de ra >> ils >> lors de la première requête, on peut laisser toujours tourner une >> appli rails avec passenger, mais on commence à vite perdre l'interet >> de passenger > super donc ce setup est adapté à des sites qui font 30 req par jours Point interessant : passenger est toujours moins performant que les autres solutions evoquées ici. Donc passenger est adapté a ? > >> - la consommation mémoire constante est plus facile à administrer >> que >> des fluctuations en fonction du nombre d'instances lancées > si tu veux, mais passenger peut fonctionner comme ca également > > Bon et bien pas de grand secret, juste des critères de goût humain. > C'était bien mon point. > Au final, tu choisis la solution que tu veux. Si tu souhaites oublier certains faits ou points constatés pour favoriser tel ou telle solution, tu ne t'en privera pas. Le choix reste donc humain. Je constate que des utilisateurs m'ont dis avoir constaté un changement de vitesse apres la migration de passenger vers nginx/thin. Ca n'est pas un point verifiable avec un logiciel ou un point de vue objectif, ca reste purement humain. Et evidemment, ca n'est pas un site avec 30 req/j. Mais pourtant ce projet va finir hebergé sur du passenger, pour coller avec les processus d'hebergement existant de la boite. Je reste sur mes preferences tout en conseillant d'utiliser des technos auquels on croit et que l'on maitrise. --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
