Pour les gros sites tu peux me faire confiance si je les ai cité c'est qu'ils ont au moins un portail significatif en Java. Évidement sur une grosse entreprise plusieurs technos sont utilisées selon les besoins et les équipes. Par exemple chez yahoo, flickr est en PHP (même leur système de batch asynchrone est en PHP) mais Q/R à son backend en Java.
Pour linked in, tout est en Java sauf les moteurs de graphes qui sont en C++ sur de grosses machines (le graphe prenait 12Go il y a un ou deux ans). D'ailleurs leurs présentations techniques valent généralement le coup d'œil.
Pour les 30 *hits*/secondes ce n'est vraiment pas gros.
Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en DB.
Note que la conf de tomcat est vraiment de base et pourrie pour les perfs (un max de logs), qu'il n'y a aucune optimisation que l'on pourrait faire pour linux-fr (aucun cache par exemple), que la conf de mysql est celle par défaut et que les clients HTTP attaquent directement le serveur d'appli. Bref je pense pas qu'on puisse faire plus défavorable pour un test.
Je ne dis pas que linux-fr est ridicule. Je dis qu'avec un serveur moderne il n'y a pas de gros exploit à faire tenir le tout sur une machine. De plus java n'est pas si à la ramasse que ca niveau perfs, et sa valeur ajoutée est son écosystème. Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Après linuxfr est "tellement simple" (une seule source de donnée: la DB, pas d'appels à des services externes) qu'au final toutes les solutions me semblent plus ou moins équivalentes.
[^] # Re: Grillé
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 5.
Pour linked in, tout est en Java sauf les moteurs de graphes qui sont en C++ sur de grosses machines (le graphe prenait 12Go il y a un ou deux ans). D'ailleurs leurs présentations techniques valent généralement le coup d'œil.
Pour les 30 *hits*/secondes ce n'est vraiment pas gros.
Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en DB.
La page de test utilisée était similaire à celle là: https://issues.apache.org/activemq/browse/AMQ .Il y a évidement des pages plus coûteuses à générer, mais elle doit être dans la moyenne. Un page plus complexe comme https://issues.apache.org/activemq/secure/IssueNavigator.jsp(...) supporte plus de 20 *pages*/secondes.
Note que la conf de tomcat est vraiment de base et pourrie pour les perfs (un max de logs), qu'il n'y a aucune optimisation que l'on pourrait faire pour linux-fr (aucun cache par exemple), que la conf de mysql est celle par défaut et que les clients HTTP attaquent directement le serveur d'appli. Bref je pense pas qu'on puisse faire plus défavorable pour un test.
Je ne dis pas que linux-fr est ridicule. Je dis qu'avec un serveur moderne il n'y a pas de gros exploit à faire tenir le tout sur une machine. De plus java n'est pas si à la ramasse que ca niveau perfs, et sa valeur ajoutée est son écosystème. Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Après linuxfr est "tellement simple" (une seule source de donnée: la DB, pas d'appels à des services externes) qu'au final toutes les solutions me semblent plus ou moins équivalentes.