Hello!

Je suis en train de bosser pour créer un site web pro 2.0. Je suis développeur Windows/C++ à la base et j'ai des connaissances dans les BDD, XML, webservices, HTML, etc...
Il me manque par contre l'expérience sur l'architecture et les technos orientées web. Mon réflexe de base est l'utilisation d'une base éprouvé (LAMP) avec AJAX, mais je ne connais pas ses limites ni s'il s'agit du bon choix (PHP, ruby on rails,..).

Les contraintes qui risquent de se poser sont :
- gestion de quelques transactions financières (abonnement au site par ex).
- gros traffic (?) : 1 à 5 millions de visiteurs mensuels
- beaucoup de données vont être stockées et vont nécessiter de nombreuses requêtes (calcul de statistiques,...). Mais les mises à jour de la base seront limitées. Il s'agira principalement d'interrogations.

Quid de la sécurité ? (est ce que cela disqualifie certains langages?)
Comment se gère le traffic ? (loadbalancing, sharding...)
MySQL est-il suffisamment robuste pour supporter de nombreuses requêtes ?
Il y a-t-il une "formule" pour connaitre la limite de charge d'un site/architecture ?

Les choix à faire :
- Langage/Framework

• Ruby / Rails
• Python / Django
• PHP / CakePHP, Symphony, Zend, ?

- DBMS

• MySQL
• PostgreSql

- Serveur Web (visiblement le choix du serveur se fait surtout en fonction du duo langage/framework)

• Apache
• Mongrel
• Nginx
• Lighthttpd

J'aimerai donc avoir les retours/avis de personnes travaillant dans le domaine, pour partir sur de bonnes bases.

Merci.

Tu peux demander dans blabla@web j'pense, tu pourras avoir pas mal de réponses sur ce topic.

Je suis dans la bonne catégorie au moins  

Mais où est ce fameux blabla@web ?...

En page 3
http://forum.hardware.fr/hfr/Progr [...] 7202_1.htm

C'était pas sorti sur les 25 1ères réponses de la recherche. Pas très populaire le blabla local...

Vous avez un budget hébergement défini ?

Je prêche un peu pour mon école mais PHP me semble encore OK pour ton projet, et MySQL aussi, d'ailleurs pour te le prouver ce forum utilise mysql.
En ce qui concerne la gestion ecommerce, des outils comme oscommerce existent déjà en PHP. A toi de voir ce que tu préfères.
Pour tes calculs qui nécessitent de nombreuses requêtes, avec un nombre de visiteurs aussi important, tu peux toujours essayer de mettre certaines choses en cache...
EDIT : je ne suis pas expert en la matière mais il me semble qu'avec autant de visites il te faudra un cluster et la difficulté ce sera de gérer çà avec PHP/MySQL

Python / Django et PostgreSQL
 
Le cache est obligatoire
 
 

+1, Django + Satchmo

faut que je l'essaye d'ailleurs

Django ou Satchmo?

Les deux, mais surtout Satchmo.

Tu posteras tes impressions ici alors, j'ai pas eu l'occasion de tester non plus pour le moment

Petit disclaimer je commence a avoir de l'xp mais pas sur des sites à très fort trafic

Donc déjà j'aurais dit rails
En tout cas pas de CMS genre osCommerce qui est pourri (rien d'autre à dire)

Niveau langage la réponse classique c'est "celui que tu connais" mais bon si tu fais que du C++ c'est mal parti
En tous cas PHP, Python, Ruby oui mais dans tous les cas mieux vaut ama partir d'un framework adapté.

Pour la sécurité on se servira des features du framework

Niveau "scalabilité" il faudra prévoir du cache donc (pages dynamiques stockees localement, memcached...), bien prévoir son architecture niveau servs (sharding ? etc).
Pas de soucis avec MySQL en lui-même

Perso, si c'était à refaire, je me redirigerais sans doute sur du Django (actuellement, boutique en ligne home-made sur base LAMP).

Concernant la sécurité, on retombe toujours sur le même genre de problème quelque soit le langage (et même si php rajoute quelques merdes pour se distinguer, on peut le rendre aussi secure que les autres).

Je passe, le problème ne s'est jamais posé pour moi.

Oui, sans problème. Mais c'est pas le plus complet et pas forcément le plus rapide dans certains cas.

Bon maintenant, je n'ai jamais exploré le monde des sites à forts trafics (pas de pub hors google). Mais ça fait 3 ans que je me contente de maintenir et améliorer en pointillé, et à chaque fois que je reviens dessus, je pleure (à cause de php, à cause de mon manque d'XP à l'époque, ...).
Si je devais recommencer, je ne m'encombrerais ni d'un débutant, ni d'un langage de merde

Bon, faut que je lise consciencieusement vos réponses et que j'apporte des réponses/remarques/questions.

Penche toi du coté de Ruby on Rails, pour le dev web c'est très intéressant et le langage est relativement élégant. ( Après si tu connais déjà Python fonce pour Django ).

 
Oui/Non oui il y a eu un budget alloué à la très grosse louche. Mais, je n'étais pas encore dans l'équipe, donc je veux faire une estimation moi même. Je suis également en train de faire l'estimation pour la taille de la base de données.
 
 
 
Quelles sont les difficultés avec ces langage/soft ? Quels sont les points à prendre en considération pour ce genre de déploiement/architecture ?
 

 
Je recherche des conseils, mais avec un retour d'expérience c'est mieux, je n'ai pas envie de tenter/tester pour vous
 

 
C'est ce que je cherche à déterminer actuellement. Les sites web 2.0 commencent à être suffisamment mures pour espérer trouver un bon framework de développement, non ?
Comme je n'ai pas de connaissance particulière dans un de ces langages, je suis ouvert à tous. j'ai l'habitude du développement et de la découverte de nouvelles APIs/librairies.
je veux partir sur une bonne base donc je ne m'attache pas trop sur la courbe d'apprentissage de ces langages pour le moment.
 
 

 
Ok pour la sécurité. La gestion SSL est par exemple présente/accessible dans tous ? D'autres techniques à prendre en compte ?
 

 
Les pages dynamiques sont stockées côté client ou le résultat de la page dynamique est mis en cache sur le serveur ?
Quelqu'un a-t-il un ordre de grandeur de visites/pages vues supportables par 1 serveur ?
 

 
J'ai vu que l'implémentation de certaines fonctionnalités "classiques" des DBMS était assez récente (foreign key, ..). il faudrait que je cherche un comparatif avec des "benchmarks" entre les différents moteur opensource.
 

 
J'ai peut ietre mal employé le terme ecommerce. Le but n'est pas de vendre des items avec un caddy, mais de gérer quelques transactions financières (abonnement au site principalement).
 

 
Est-ce suffisamment mure ? Il faut que je regarde s'il existe des CMS pour Ruby. Le côté objet de ces langages m'attire et me rassurerait.
 
 
Merci à tous en tout cas pour vos participations.

Pour le cache, les pages dynamiques sont stockées niveau serveur ( de toutes façon je ne vois pas comment stocker niveau client, mis à part tout foutre dans les cookies ). Regarde du coté de memcache pour plus d'infos.
 
Concernant Ruby on Rails, c'est assez mature et des sites de grosses envergures l'utilisent ( Twitter utilise RoR, même s'ils ont eu pas mal de problème au niveau scalability il y a quelques temps ). En tous cas beaucoup de nouveaux projets ( startups ) web se lancent avec RoR.

 
Je dirais rails alors
Il y a certes quelques CMS mais surtout un bon tas de gems/lib/plugins réutilisables et régulièrement mis à jour (ce qui a également ces mauvais côtés bien sur)
 

 
Ce n'est pas le rôle du framework mais du serveur web. Dans le cas de rails (ouais je connais passenger ) ou de django on pourra utiliser nginx, et les serveurs applicatifs derrière. l'avantage de la séparation est également un plus du côté "scalability"
 

 
Les pages sont mises en cache côté serveur (memcache ou fichiers statiques)
Du côté client on jouera sur les headers (etag mais surtout dates de modification/expiration)
 

 
PostgreSQL est mieux réputé et a plus de qualités que MySQL même s'il est moins populaire (perso je l'ai seulement utilisé quand j'etais encore en cours donc pas d'avis sur le sujet, en tous cas avec un framework et un orm pas de soucis d'adaptation sauf besoins spéciaux)
 

 
Rails est définitivement prêt pour des projets de grande envergure et l'a déjà prouvé (yellow pages par exemple).
L'écosystème autour est lui bien en place, et le langage est simplement incroyable quand on vient de PHP avec des habitudes moisies

Pour la BDD après y'a PostgreSQL si MySQL tiens pas la route

A titre indicatif, ils utilisent RoR pour la partie web et Scala pour toutes les opérations en tâche de fond.
Pour ce qui est des benchmarks de BdD, on n'en trouvera pas parce que la plupart des licences de BdD interdisent de les publier (ce qui est un comble). Les quelques benchs que j'ai faits, pour ce qu'ils valent, donnaient comme résultat que MySQL, PostgreSQL et Oracle avaient des perfs comparables. Mais sur N cores, il me semble que Postgres s'en sort mieux que MySQL. Par contre, ce dernier a de meilleurs outils d'administration.
Le goulot d'étranglement possible, c'est plus la BD que les serveurs web.
Un PC quad core aujourd'hui doit normalement pouvoir servir au moins 15-20 pages par seconde et donc répondre aux besoins. Le site sera essentiellement limité par les requêtes en BD, et c'est le plus compliqué à mettre en cluster. Avec Oracle, il y a le RAC, pour Postgres, apparemment PL/Proxy
http://highscalability.com/skype-p [...] lion-users (plein d'infos sur ce site)
Pour MySQL, MySQL Proxy.

Encore une fois merci.

Il faut également que je digère ces réponses.

Juste comme ça : vous pourriez donner des arguments concrets pour RoR plutôt qu'un autre langage par exemple ?
Mis à part Twitter, qu'utilisent certains gros sites web (gmail, facebook, yahoo!,..) ?

En cherchant sur le web ya pas mals de confs/slides sur les archis et outils mis en place par les devs/admins de gros sites.
 
Facebook : php/mysql/apache pour le front, divers pour le reste (memcache, outils c/c++)
 
Twitter : rails en front, scala et autres derrière comme le dit el muchacho
 
Pour gmail wikipedia, me dit java+GWT
 
Pour de gros sites sous rails : http://rails100.pbwiki.com/
(dont hulu et slideshare)
 
Voir aussi
http://en.wikipedia.org/wiki/Postg [...] nent_users (yahoo)
http://en.wikipedia.org/wiki/Memcached (plein de gens)

Merci pour les sources, je vais lire tout ça  

Facebook utilise une pile LAMP ( donc PHP + MySQL à priori ),
Gmail je crois que ça a été développé avec le framework GWT ( donc en JAVA, qui te génère du HTML + Javascript ), pour leur BDD, aucune idée, je sais que Google a ses propres outils pour gérer les gros volumes de données ( cherche BigTable pour plus d'infos ).
Yahoo je crois me souvenir qu'ils utilisent PHP, à vérifier.
 
Arguments concrets pour RoR : framework qui -s'il est bien utilisé- peut te faire gagner beaucoup en productivité et maintenabilité ( comme tous les frameworks mvc ). Disons qu'avec RoR ton code sera plus élégant qu'en PHP  Au passage il ya de très bons frameworks PHP ( Symfony, CakePHP...)
 
edit: un peu burned  

 
pas du tout, ca me montre au moins que ce n'est pas l'avis que d'une personne.

Je ne saurais pas te répondre, je te dis çà parce que je l'ai lu (Extrait du livre best practices PHP 5, que tu devrais lire avant de te lancer là dedans si tu choisis PHP)

Si ton appli va devoir supporter une grosse montée en charge, peut-être pourrais tu penser à utiliser des services "on the cloud" ( du style Amazon web services, ou même google app engine ) qui te permettent de t'affranchir de ta configuration de clusters etc ( en gros ton appli sera scalable automatiquement si tu passes par ce genre de plateformes ). Après il faut voir si ta boite accepte que les données soient sur le cloud...

On a effectivement pensé à ce genre de solution. Surtout vu ma non expertise dans le domaine...

Django ou Merb ou Rails. Si tu ne connais pas php, laisse tomber, aucun intérêt.
N'imagine même pas monter quoi que ce soit avec j2ee.
 
Sinon s'interfacer avec du cloud demande quand même un peu d'expérience.

Tiens tu peux nous en dire plus ? ça m'intéresse. D'après ce que j'ai vu les services mettent à disposition une API assez simple à utiliser généralement, où sont les difficultés à utiliser le cloud ? ( perso je n'ai jamais utilisé ces services encore donc je manque de visibilité là dessus )

 
Tu peux étayer un peu STP ? que ce soit pour les langages ou le cloud computing.
 
Je t'avoue que je n'ai même pas songé à J2EE. Je crois que je préfèrerais encore prendre des licences et faire du .Net à la place.
 
Pour le langage, qu'est ce qui fait la différence selon vous ?

Le fait que tout soit objet en python ou ruby donne un code beaucoup plus lisible selon moi ( notamment comparé au PHP et ses fonctions interminables genre array_assoc_intersect etc )
Après niveau performance, je ne saurais te dire lequel est le mieux. Il y a surement des benchmarks diffusés sur le web...

Bonjour,
 
Effectivement moi je te conseille d'utiliser Ruby on Rails. Pour la base de donnée MySQL devrait pas poser de soucis, mais à ce que j'ai pu lire Postgres serait un peu plus robuste (affirmation à prendre avec des pincettes, je n'ai jamais utilisé Postgres). De toutes façons quelque soit ton choix de SGBD, Rails le supportera de manière plus ou moins équivalente ( opte juste pour un système qui te permet d'utiliser les Transaction, la Replication & co ).
Niveau sécurité "du site" : RoR implémente pas mal de trucs "tout seul" pour que les règles minimales de sécurité soient respectées. Niveau serveur, là ça va dépendre de ton sys admin..
Niveau gestion de la charge, tu peux très facilement créer un système de load balacing avec le duo Apache + Mongrel, c'est ce qu'on utilise là ou je bosse. de plus Rails permet d'implémenter assez facilement une gestion assez bien faite du cache (c'est automatique pour les requêtes SQL et les classes Ruby, ça peut être codé assez vite fait pour les vues).
 
Bref voilà

Merci pour ce complément (je suis à la bourre dans ma veille techno là).
 
Pour le SGBD, j'ai un peu plus l'habitude et plus de connaissances. Mais je surveille également les features pour optimisations (procédures stockées, vues, triggers, etc..).
 
J'ajoute Mongrel à ma liste de choses sur lesquelles je dois me documenter.

Si tu prévois d'orienter ton développement vers Rails, je te conseille d'étudier au passage le fonctionnement (ou du moins les bases) d'un système de versionnement (git ou svn) et de déploiement (qui s'appelle Capistrano pour Rails) car ça une fois que ton appli aura pris de l'ampleur ça te seras excessivement utile

Le versionnement, je connais, comme je l'explique, je suis quand même développeur, donc ca fait partie des évidences.
 
Pour le déploiement, je ne m'étais pas trop posé la question jusqu'à présent. Merci pour la référence.

 
Si il part sur rails, il peut utiliser une solution plus haut niveau comme heroku, engine yard ou joyent
 

 
+1 sur le fait qu'il y ait vraiment aucun interet à apprendre PHP actuellement
 
Pour les performances du langage peu importe à mon avis, il faudra absolument mettre en place des systèmes de cache qui ne passeront donc pas par l'application elle-même.
 

 
Nginx + thin est définitivement plus adapté qu'apache et mongrel niveau performances (puis bon apache et ses fichiers de conf...).
Sinon, c'est très récent mais passenger (mod_rails) est dispo pour nginx, ca peut être une solution.
Selon les besoins on peut aussi réflehir à mettre en place haproxy ou varnish.
 

 
J'espère bien que l'utilisation d'un scm est un prérequis
 
Pour capistrano son utilisation n'est pas limitée à rails, on peut très bien l'utiliser pour déployer du php (ce que l'on fait) ou du python. D'ailleurs je ne connais pas d'autre solution à part en java (je ne compte pas vlad). A mon avis c'est également un prérequis dans sa situation.