Besoin de votre avis : architecture web et gestion de charge

bongour,

je cherche des idées pour l’architecture d’un site qui j’espère devrait supporter du 100000+ V/jour

c’est un site qui ne peut pas être mis en cache car le principe serait de présenter des infos contextuelles en permanence
ma question est :

  1. dois je m’orienter vers du load balancing de base de données (clasique)

  2. ou plutot créer des “webservice” (dans le sens flux xml variabilisable)
    Ces petits WebService iraient taper dans un moteur de recherche (lucene ?) et dans des base de données.
    ces différents blocs pourraient eux être mis en cache séparément et il y a donc une profondeur de serveur supplémentaire entre mes frontaux Web et les bases de données pour absorber la charge.

j’aime bien la seconde approche mais je voudrais pas me planter

merKi
Edité le 10/06/2007 à 19:56

up : sympa l’entraide :confused: :slight_smile:

Oui enfin tu sais peut être que tout simplement personne n’a été confronté au problème, et que personne n’a envie de dire des âneries… en général, on parle de ce qu’on connaît :wink:

moi je brode sur tout et n importe koi !

et toi t as pas d avis sur la repartition de charge dans une archi web ?

Je serais pour la première solution plus facile et moins coûteuse.

L’autre, je ne sais pas. WebService, c’est du XML? C’est pas lourd ça aussi? Genre passer son temps à parser des requêtes XML and co…

moins couteuse, plus simple …

l’interet d’un site modulaire c’est aussi la maintenance… et l’evolutivité, chaque module etant fonctionnellement indépendant il sont réutilisables…

ou alors du pure WebService SOAP un peu plus lourds à mettre en place mais permet de dissocier la logique applicative et l’ergonomie des regles et objets métiers…

je tire à pile ou face

Bonjour,

Oui, c’est ça, quand on est au dev, on ne connait pas trop le dimensionnement des serveurs c’est plus du travail d’admin.
Mais je peut parler de ce qu’ils font là ou j’ai travaillé sur des sites de 10 000 à 100 000 connections selon l’appli (plutôt moins que 100 000)
bref leur archi:
2 serveurs type Sun en frontal avec apache, suivi de 2 serveurs WAS derrière, le tout connecté sur 1 seule BD.
le “simple” load balancing de BD était trop compliqué ici :smiley: alors ils ont préféré ne pas en faire.

Brancher une couche WSDL/SOAP intermédiaire pourrait effectivement permettre de faire un load balancing classique sur des serveurs d’appli Web, mais ça t’oblige à changer tes applis pour utiliser la couche SOAP, et à implémenter les couches SOAP d’accès aux BD. + alimenter les 2 BD en parallèle, donc mettre en place une sunchronisation des données, avec toutes les incohérences que ça implique, sauf si c’est des accès en lecture uniquement.
Edité le 11/06/2007 à 14:11

j’ai pas d’appli à réécrire !

c’est du tout beau tout neuf !

et le load balancing de bd en read/write c’est toujours la galère !

donc WebServices !

Moi je mettrais des clusters MySQL (ça s’installe en deux secondes et tu peux en rajouter dès que y a besoin) et du load-balancing pour les serveurs frontaux. Le seul truc qui peut te poser problème, c’est les sessions mais bon y a toujours moyen de synchroniser ça (partage NFS, stockage en base de données ou démon de réplication).

Les services web c’est bien mais je pense que tu peux les mettre en parallèle si tu veux, t’es pas obligé d’appuyer toute ton appli dessus.
Et pour finir, si tu as besoin de Lucène, tu peux trouver une implémentation pour PHP dans le Zend Framework.

PHP / MySQL, ça a l’air ridicule pour un si gros site, mais quand tu vois Neowiz.com (150 k visiteurs par jour) ou Club Internet (600 k visiteurs par jour)…

PS : tu fais comme tu veux :wink:

merci mandarounet …

c claire que je vais pas tout faire en Web Service mais comme certain composant seront transversaux (base client, boutique, etc) y a un réel avantage…

donc si je résume :

  • n frontaux
  • n base répliquées en read
  • 1 base en read/write
  • n serveur de webservices (sur la base en read/write)

:wink:

Tu peux aussi soulager ta base en read / write en en mettant plusieurs, sinon tu risques d’avoir un goulot d’étranglement.
Tu peux par exemple mettre trois bases en read / write puis un niveau contenant n bases qui se synchronisent en lecture.
Sinon ça a l’air bien ! :slight_smile: