SGBD sur un serveur distant du site web

[vinse51]

Bonjour à tous,

Je voudrais avoir l'avis d'experts en base de données pour savoir s'il est envisageable ou pas d'avoir sa base de données sur un serveur distant (donc pas sur le même réseau local) que le serveur qui héberge l'application.

Pour entrer un peu dans les détails, j'ai un site Internet à fort trafic sur un serveur qui attaque une base de données sur un autre serveur. Il s'agit de SQL Server Express R2.

Mais les limitations de la mémoire deviennent ingérable (la bd totalise plus de 300 tables et traite entre 500 et 1000 requêtes par secondes) et je dois donc m'orienter vers une licence mais la version standard est hors de prix.

A mon grand regret mon hébergeur actuel ne me permet pas d'obtenir une version Web de SQL Server.

J'ai donc trouvé un hébergeur en France (OVH) qui propose une version Web pour 30€ par mois ce qui est vraiment ridicule je trouve!
Mais pour l'instant j'aimerais éviter de migrer tous mes sites et donc je me pose la question de la viabilité d'avoir la base de données chez un autre hébergeur.

Les ping ne sont pas trop différent : 4ms actuellement et 15ms en distant.
Mais si on multiplie 15ms par les millions de requêtes traitées par jour on obtient vite des chiffres qui font peur...

Est-ce que quelqu'un a déjà testé ce modèle ? Où est-ce que ce n'est même pas la peine d'y songer ?

Merci d'avance pour vos réponses.

[SQLpro]

De toutes façon ce ne sera qu'une solution provisoire... mais même à distance c'est gérable.
Le seule problèmes est que le risque de coupure de réseau est doublé.

Voyez aussi ASPserver, ils ont des solutions à partir de 4 € par mois avec SQL Server 2008 !!!!!!

http://www.aspserveur.com/hebergement-web.asp

A +

[mikedavem]

Vous avez également la solution de "cloudifier" vos bases avec SQL Azure

++

[vinse51]

Bonjour et merci pour vos réponses.

Concernant ASPserver je n'ai pas trouvé d'offres avec SQL Server 2008 et donc pas de licences Web. De plus les serveurs en eux même sont très chers comparé à OVH ou 1&1.

"Cloudifier" la base est une piste intéressante mais je ne suis pas certain que ce soit bien adapté. Car sans héberger aussi l'application sur Azure les temps de latences seront énorme (les datacenters sont aux US...).
Etant donné que la base en question est très sollicitée (1000 requêtes/s) je ne pense pas que ce soit viable.

Il m'arrive d'avoir des pages avec par exemple 20 requêtes.
Si on part du principe que chaque requête s'exécute en 20 ms et que le ping avec le serveur actuel est de 4 ms on a donc un total de 20*4 + 20*20 = 480 ms.
Maintenant si on passe à un ping de 20 ms (ce qui doit être encore très loin d'un cloud mais proche de ce que j'hésite de faire avec OVH) cela donne 20*20 + 20*20 = 800 ms, c'est à dire presque le double !

C'est précisément ceci qui me fait hésiter. En se basant sur ce genre de calcul on peut imaginer que tout le site web va se trouver fortement ralenti selon le nombre de requêtes sur les pages...

[mikedavem]

"Cloudifier" la base est une piste intéressante mais je ne suis pas certain que ce soit bien adapté. Car sans héberger aussi l'application sur Azure les temps de latences seront énorme (les datacenters sont aux US...).
Etant donné que la base en question est très sollicitée (1000 requêtes/s) je ne pense pas que ce soit viable.

Effectivement si vous ne mettez pas votre application sur Windows Azure cela ne vaut pas le coup de mettre SQL Server dans le Cloud .. bonjour la facture ...

Personnellement à la vue de votre architecture et de la charge que subit votre serveur cela me paraît difficile d'envisage de faire hoster votre serveur SQL en distant via une liaison de type internet sans ligne dédiée ...

++

[vinse51]

Merci pour votre réponse, je suis d'accord, dans une telle configuration le cloud n'est pas une bonne solution.

Cela me parait également difficile une liaison à distance mais par contre il s'agit bien d'une ligne dédiée. Enfin pas tout à fait mais presque : la liaison se fait entre 2 des plus gros hébergeurs de France et c'est donc de très grosses liaisons qui doivent être redondantes et sur lesquelles le risque de coupure doit être quasi nul.

D'ailleurs pour preuve le ping que je relève entre les 2 serveurs est de l'ordre de 15 ms, ce qui est très loin d'un ping "normal" sur Internet (plus vers 60-80 ms).

De toutes façons je vais faire un test puisque cela devient vraiment intenable sans licence et que la version standard pour plusieurs processeurs est vraiment trop chère. Si cela n'est pas concluant je n'aurai d'autre choix que de transférer également l'application vers de nouveaux serveurs, ce que je souhaiterai éviter quand même...

[vinse51]

Bonjour à tous,

Je suis finalement passé à l'action et j'ai procédé à la migration de la base de données.

Après quelques semaines d'utilisation, les résultats sont assez conforme aux attentes. Les pages qui n'effectuent que très peu de requêtes sont très rapides (plus qu'avant car le nouveau serveur est environ 20 fois plus performant - vive le SSD !).

Par contre, les pages avec beaucoup de requêtes sont vraiment plus lentes et peu importe l'heure ou la charge du serveur impossible de faire baisser ce temps.
Mais au final tout ça est parfaitement cohérent avec les analyses faites plus haut dans ce topic.

Mais malheureusement le constat ne s'arrête pas là : un phénomène que je n'avais pas prévu du tout pointe son nez et je ne suis pas sûr de bien le comprendre.

De temps en temps, le serveur de l'application monte en charge au niveau du processeur et commence à ramer pour servir les pages. Les requêtes HTTP s'accumulent et le processeur atteint quasiment les 100% de moyenne pendant des fois assez longtemps.

Je n'avais jamais eu ce problème avant et je n'ai fait aucune grosse modification de l'application qui pourrait faire ça. Le processeur est normalement entre 20 et 60.% mais jamais 100%.

Du côté de la base de données c'est le contraire. Lors de ces phases le processeur baisse de moitié.

Donc la seule explication que j'ai trouvé pour le moment serait que des fois il doit apparaitre des lenteurs sur le réseau entre les 2 machines et comme les requêtes SQL sont plus longues, les requêtes HTTP s'accumulent puisqu’elles ne peuvent pas se terminer avant de compléter les requêtes SQL et au final le serveur Web se retrouve avec 10 fois plus de requêtes HTTP simultanées et rame.

Je vais donc être contraint de migrer entièrement l'application j'ai bien peur.

Si quelqu'un a une autre explication voir une solution à ce problème je suis preneur.

Merci d'avance.

[vinse51]

Bonjour,

Le problème que j'évoquais dans le précédent message est plus que jamais d'actualité ! Il y actuellement des centaines de périodes par jour allant de quelques secondes à quelques minutes durant lesquelles les pages se mettent à ramer. Je n'ai toujours pas trouvé la cause bien que je soupçonne fortement la latence entre les 2 serveurs.

Voila tous les éléments dont je dispose sur le problème :

• Le processeur passe de 20% à 70% de moyenne
• Les pages mettent entre 10 et 60 secondes à s'afficher
• Les requêtes HTTP s'accumulent de plus en plus
• L'utilisation du processeur sur la machine SQL tombe de moitié
• Le nombres de requêtes SQL passe de 500 à 100 par seconde
• A priori les pings entre les 2 machines sont toujours identiques (20ms)

Pour bien illustrer le souci, voici une capture des compteurs :

• Trait rouge = %processeur
• Trait bleu = Nombre de requêtes HTTP actives
• Pointillé rouge = Nombre de connexions ADO dans le pool
• Pointillé vert = SoftConnectPerSecond (Nombre de requêtes SQL par seconde)
• Pointillé bleu = Connexion du pool qui sont actives

On voit bien qu'en période normale seulement une dizaine de connexions sont utilisées pour effectuer les 400 requêtes par seconde. Le nombre de requêtes HTTP actives est très bas ce qui signifie que le serveur répond parfaitement.

On voit ensuite que le nombre de SoftConnect chute et que pour compenser plus de connexions sont utilisées. Pendant ce temps les requêtes HTTP s'accumulent et le processeur reste dans les 70%.

Et puis d'un coup tout redevient normal (on monte même à plus de 600 SoftConnect par seconde pour servir tout le monde qui s'était accumulé).


Je suis à cours de pistes et d'outils pour comprendre le problème. La question la plus importante est : est-ce que la montée en charge du processeur est la cause ou la conséquence ? A priori je penche pour la conséquence mais je trouve ça étrange qu'une simple latence dans les requêtes peut faire monter le processeur à ce point.

Je ne comprends pas comment les offres de Cloud se multiplient si des problèmes récurrents de latence peuvent causer de tels soucis.
Est-ce que quelqu'un à déjà été confronté à un problème similaire ou bien peut m'apporter des pistes pour en découvrir la vraie origine ?

Merci d'avance