10000 création de commandes simultanées ? waouh, ... considérant que la création d'une commande (ou l'envoi de la commande de création) prend au maximum 1s ou 2s .... ça veut dire au mieux 5000 commandes par secondes. Tu connais un magasin en ligne qui génère ça ? je pense que même les plus gros magasins en ligne n'ont pas ça.
Maintenant il est où ton problème ?
- 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.
- 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.
- 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.
Si réellement tu as un problème de ce coté là tu fais une file avec ton SGBD ou avec un programme externe qui gère la file de commande. Tu n'as peut être pas un objet qui s'appelle "asynchrone" et qui présente une méthode toute jolie mais ça ne prend pas deux heures à faire.
Et comme je le répète, quand bien même ton exemple poserait problème, vu le nombre de gens qui ont besoin de gérer 10000 commandes simultanément via une interface Web ... ça voudrait dire que Java peut tout à fait être réservé à une niche très réduite, 99.99% du Web restant avec un outil simple comme PHP, même pas capable de gérer une dizaine de millier de commande simultanées ;)
> - tu gères la montée en charge.
Grande question. Java "supporte" la charge, PHP permet une scallabilité. En PHP tu n'as pas tout ce qui est résident en mémoire, tout ce qui est commun, transactionnel et tout ça. Le propre du modèle c'est que pour monter en charge il suffit de rajouter un serveur en parralèle, et l'essentiel des problèmes de concurence ou de charge se retrouvent coté SGBD. Comme les bons SGBD savent aussi se gérer en cluster avec plusieurs frontaux ... il n'y a pas de réels problèmes de scalabilité.
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 5.
Maintenant il est où ton problème ?
- 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.
- 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.
- 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.
Si réellement tu as un problème de ce coté là tu fais une file avec ton SGBD ou avec un programme externe qui gère la file de commande. Tu n'as peut être pas un objet qui s'appelle "asynchrone" et qui présente une méthode toute jolie mais ça ne prend pas deux heures à faire.
Et comme je le répète, quand bien même ton exemple poserait problème, vu le nombre de gens qui ont besoin de gérer 10000 commandes simultanément via une interface Web ... ça voudrait dire que Java peut tout à fait être réservé à une niche très réduite, 99.99% du Web restant avec un outil simple comme PHP, même pas capable de gérer une dizaine de millier de commande simultanées ;)
> - tu gères la montée en charge.
Grande question. Java "supporte" la charge, PHP permet une scallabilité. En PHP tu n'as pas tout ce qui est résident en mémoire, tout ce qui est commun, transactionnel et tout ça. Le propre du modèle c'est que pour monter en charge il suffit de rajouter un serveur en parralèle, et l'essentiel des problèmes de concurence ou de charge se retrouvent coté SGBD. Comme les bons SGBD savent aussi se gérer en cluster avec plusieurs frontaux ... il n'y a pas de réels problèmes de scalabilité.