ça veut dire au mieux 5000 commandes par secondes
Deux choses... ce n'est pas 5000 commandes par secondes toutes les secondes de la journée
et deuxièmement, le site ne sert pas qu'à faire des commandes, donc il y a de la charge de l'autre coté.
l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
Je ne parle pas d'un email simpe...j'envoi parfois des mails très compliqué... numéro de suivi, liste des commandes en cours, vérification de l'encours, contact avec le service expedition.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
ah si tu pars du principe que tu as une BDD qui peut encaisser toutes les charges sans dégrader les performances du reste du site.. Beh en effet, balance lui tout dans la gueule
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
beh ça rajoute..
Je ne dis pas qu'il est impossible de faire ça sans messagerie asychrones.. je dis juste que ca réduit la charge.
Autre avantage... des trucs comme JMS permettent de réduire le couplage des développements.. (nottament entre développeurs / ou équipes de développeurs)
Pour mon exemple, on va créer une file d'attente "commandesCrees"...
Le développeur qui génère le mail s'abonne à cette liste et génère ces emails..
L'équipe de développeur qui s'occupe du réaprovisionnement s'abonne lui aussi et développe son système...
[^] # Re: Le php
Posté par Stéphane Traumat . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 1.
Deux choses... ce n'est pas 5000 commandes par secondes toutes les secondes de la journée
et deuxièmement, le site ne sert pas qu'à faire des commandes, donc il y a de la charge de l'autre coté.
l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
Je ne parle pas d'un email simpe...j'envoi parfois des mails très compliqué... numéro de suivi, liste des commandes en cours, vérification de l'encours, contact avec le service expedition.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
ah si tu pars du principe que tu as une BDD qui peut encaisser toutes les charges sans dégrader les performances du reste du site.. Beh en effet, balance lui tout dans la gueule
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
beh ça rajoute..
Je ne dis pas qu'il est impossible de faire ça sans messagerie asychrones.. je dis juste que ca réduit la charge.
Autre avantage... des trucs comme JMS permettent de réduire le couplage des développements.. (nottament entre développeurs / ou équipes de développeurs)
Pour mon exemple, on va créer une file d'attente "commandesCrees"...
Le développeur qui génère le mail s'abonne à cette liste et génère ces emails..
L'équipe de développeur qui s'occupe du réaprovisionnement s'abonne lui aussi et développe son système...
Tout le monde peut donc développer indépendament.
http://about.me/straumat