|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : mars 2006 Messages : 2 ![]() |
Bonjour,
je suis indépendant et je dois faire un outil d'emailing pour un des mes clients. Cet outil fonctionne en mode ASP (chaque utilisateur crée son compte et envoi ses propres newsletter) et doit permettre d'envoyer 1 000 000 d'emails par jour minimum. Je me demande qu'elle type d'architecture vous conseillerait : en sachant qu'il me faut un système très rapide permettant de supporter une lourde charge (on sait très bien que les gens ouvre leur newsletter tous le matin à 8h en arrivant au boulot j'ai des connaissance en PHP+MySQL ou ASP+SQL Server mais les 2 solutions me semblent un peu limité : - MySQL+PHP : je ne pense pas que MySQL puisse supporter 1 millions de click en 1 heures - SQL Server+ASP : SQL Server me semblent très lent il supporte la charge mais l'ouverture d'une session me semble très longue dès que le serveur est un peu surchargé. Si il faut prendre un autre language, cela ne me pose aucun problème pour apprendre. Si quelqu'un a de l'expérience dans le domaine ? Merci d'avance |
|
|
00
|
|
|
#2 |
|
Expert Confirmé
![]() Inscription : mai 2005 Messages : 3 633 ![]() |
Pour ce qui est de la couche de données. Les gros SGBDR comme SqlServer ou Oracle ne seront pas impressionner par le volume dont tu parles. Ce qui va à mon avis être un point important sera le matériel qui accueille ton SGBDR et/ou l'application/service Web >> soit les serveurs, ce qui n'est pas à proprement parlé la question que tu poses.
Pour l'interface Web, une programmation ASP.Net est envisageable avec une programmation très rigoureuse (C#) de la gestion des objets générés sur le serveur afin de correctement libérer les ressources. L'utilisation des WebUserControl devrait également économiser en ressources, ainsi que peut être le javascript nécessaire pour reporter certaines opérations côté client.
__________________
Pour le bien de ceux qui vous lisent, ayez à coeur le respect du forum et de ses règles |
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Inscription : mars 2006 Messages : 2 ![]() |
il est vrai que je n'ai pas parlé des serveurs car ceux-ci ne seront pas vraiement un problème : plusieurs bi-processeurs en RAID SCSI.
je ne pense qu'il poseront des problèmes. Par contre, je tiens à limiter aux max les ressources serveurs afin de ne pas devoir investir à la suite d'un mauvaix choix techniques. La plupart des opérations seront uniquement des INSERT et en cherchant sur internet je n'es pas trouvé de benchmark très parlant (non payé par le numéro 1 du benchmark :p) souvent MySQL est gagnant sur ce genre de benchmark alors que je doute de la fiabilité en charge de celui-ci. si vous avez aussi quelques beau graph sous la main pour étayer tout ça ? ou un lien m'expliquant comment faire ce genre de test de monter en charge, ça pourrait m'aider beaucoup. Merci d'avance |
|
|
00
|
|
|
#4 |
|
Expert Confirmé
![]() Inscription : mai 2005 Messages : 3 633 ![]() |
Dans ce cas SQLServer devrait s'en sortir. Le truc c'est que du côté SGBDR tu ais déjà préparé les procédures stockées adéquates (les insert paramétrées par exemple) et que du côté applicatif tu ne gères que le passage des paramètres attendus (ma référence est toujours celle que j'ai cité plus haut soit DotNet
__________________
Pour le bien de ceux qui vous lisent, ayez à coeur le respect du forum et de ses règles |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com