Je dois faire un site de vente aux enchères avec un décompte du temps restant.
Je dois afficher une vingtaine d'articles sur la page.
Le visiteur voit défiler les secondes. D'un clic il peut enchérir sur un produit -> le prix du produit augmente et le nom de l'utilisateur s'affiche comme étant le dernier enchérisseur.
Mon problème est le suivant :
Je ne pense pas que je puisse chaque seconde faire une requête sur la base de donnée pour actualiser les 20 articles.
Si 100 personnes regardent le site à ce moment ca fait 2'000 requêtes à la seconde, je pense que la base ne tiendra pas, je me trompe ?
La solution serait peut être d'avoir un script php qui chaque seconde se connecte à la base, met les données dans un fichier xml, et que les personnes connectées affichent ce fichier xml ?
Des idées, des commentaires, je suis un peu perdu...
Je viens de lire ton post et aucun moment tu n'as besoin de faire 1 requete par seconde et par article. La seul requete que tu fais c'est lorsque que quelqun clique pour encherir et lorsque le compteur arrive a zero
Il est possible techniquement que le serveur envoie les mises à jour si nécessaire au client, ça permet d'éviter de saturer le serveur de requètes alors que la plupart du temps il n'y aura rien à mettre à jour.
Pour ça on peut utilier les nouvelles solutions apportées avec HTML5 comme les websockets, et pour les navigateurs plus anciens, les techniques de "server push" comme le long polling marchent très bien, et évitent de surcharger les serveurs.
Citation : rotoclap
Comme sur eBay : c'est au visiteur d'avoir le doigt sur F5 si l'objet l'intéresse vraiment.
Si quelqu'un peut améliorer ça (et les technos pour le faire existent depuis longtemps), autant pas se priver
Ouais mais tu perds toute l'excitation du truc aussi. Et puis bon, celui qui a fait au moins une enchère sait comment ça marche : attendre les 3 dernières secondes et envoyer son prix max.
Je viens de lire ton post et aucun moment tu n'as besoin de faire 1 requete par seconde et par article. La seul requete que tu fais c'est lorsque que quelqun clique pour encherir et lorsque le compteur arrive a zero
Le problème c'est que si quelqu'un d'autre surenchéri, la base sera mise à jour, mais comme je ne regarde pas dans le base les autres personnes connectées ne verront pas le changement de prix, du nom du dernier enchérisseur, et du temps qui sera augmenté de 20 secondes.
Citation : LoupSolitaire
Il est possible techniquement que le serveur envoie les mises à jour si nécessaire au client
Avec ce système les clients pourraient avoir leur contenu mis à jour en cas d'update sur la base ?
C'est à dire que si une des personnes connectée enchéri sur un article et que je met à jour les champs dans la bd, les autres personnes verront le nom du nouvel enchérisseur, le nouveau montant et le nouveau temps avant la fin de l'enchère, le tout sans faire de requêtes à la bd ?
Ce système est conceptuellement identique à un système de chat type irc :
- un channel = un objet
- les gens dans le channel = les types qui ont la page affichée
L'architecture serveur typique (php/base de données) ne permet pas de résoudre ce problème (d'ailleurs aucun serveur de chat ou irc n'utilise ça) pour les raisons expliquées plus haut.
Si tu veux garder un client navigateur web, tu as deux solutions :
- soit : "La seul requete que tu fais c'est lorsque que quelqun clique pour encherir et lorsque le compteur arrive a zero"
- soit un serveur custom de type asynchrone (select/poll) qui est la seule chose capable de gérer le nombre de connexions que tu désires, ça se code pas trop difficilement, j'en avais fait un en python.
L'architecture serveur typique (php/base de données) ne permet pas de résoudre ce problème (d'ailleurs aucun serveur de chat ou irc n'utilise ça) pour les raisons expliquées plus haut.
Quel type d'architecture faudrait il mettre en place ?
Citation : Lord Casque Noir
"La seul requete que tu fais c'est lorsque que quelqun clique pour encherir et lorsque le compteur arrive a zero"
Mais comment faire pour que ca se mette à jour chez toutes les personnes connectées ?
Mais comment faire pour que ca se mette à jour chez toutes les personnes connectées ?
Avec un serveur web standard, tu peux pas. Sauf si tu as un nombre très petit de personnes connectées simultanément (mettons 50).
Citation
Quel type d'architecture faudrait il mettre en place ?
La meilleure architecture serait de l'UDP, mais là le client ne peut pas être un navigateur web. Donc, restons dans le domaine du client web.
L'architecture est la même qu'un serveur irc, c'est-à-dire :
- un serveur qui a une socket ouverte en permanence avec chaque client (donc un client = une socket = un port)
- quand le serveur a quelque chose à dire, il envoie
- quand le client a quelque chose à dire, il envoie
IL N'Y A PAS DE POLLING
Le serveur peut (et doit) stocker tout ce qui se passe dans la base de données (les enchères par exemple) mais quand quelqu'un envoie un message, il doit être automatiquement envoyé aux autres personnes qui attendent sur cet objet, bien évidemment sans passer par la base de données. Donc tout se passe en RAM dans ce type de serveur, il n'y a pas de polling, c'est de la gestion d'événements.
Bien sûr il est hors de question d'utiliser un process ou une thread par socket, ce genre de truc se fait avec un serveur asynchrone type select/poll (comme tous les serveurs chat, irc, jabber, et vrais serveurs web). En gros tu as un pool de sockets ouvertes, tu fais un select() (ou poll, epoll, sysepoll suivant l'OS) sur ton pool et le kernel te renvoie la liste des sockets sur lesquelles il y a de l'action. Tu traites ça, et tu recommences. Tu utilises une seule thread (une par core à la limite, mais ça complique). Ce n'est pas spécialement difficile à écrire... j'en avais fait un en python, tu peux atteindre plusieurs milliers de messages/s. Avec un langage plus rapide (C,C#) ou adapté (Erlang) tu peux multiplier ça par 10 ou 100.
Tu as une limite dans le protocole TCP à 64K ports ouverts simultanément : si tu veux gérer plus il te faudra diviser pour régner... (encore une fois, comme les serveurs irc !)
Voilà, c'est exactement le genre de truc que j'évoquais expliqué de façon plus précise.
Pour faire ça de façon simple il est possible d'utiliser des frameworks web asynchrones type tornadoweb pour Python. Couplé à une base de données type redis qui dispose de fonctionnalités de type "publish/subscribe", ça permet d'avoir une architecture relativement facile et rapide à mettre en place (pas besoin de toucher directement à select/poll, le framework fait l'abstraction) tout en étant performante.
Sinon si t'as envie de jouer avec un serveur jabber tu peux profiter des fonctions prévues comme BOSH qui permet de simuler une connexion permanente et bidirectionnelle entre une page web et un serveur de messagerie, ainsi que pubsub (genre avec un noeud pubsub par objet, il doit y avoir moyen de faire quelque chose de cette manière...). Ejabberd peut faire l'affaire à ce niveau.
Pour résumer et si j'ai bien compris (dans les grandes lignes) pour un système d'enchère actualisées chaque secondes :
- Le principe de fonctionnement est assez similaire à celui d'un tchat.
- Pour que ca fonctionne il faut côté client un script qui écoute, donc une boucle infinie. Du coup ca ne peut pas marcher chez un hébergeur qui limite le temps d'exécution des scripts.
- Du côté du serveur quelque chose qui envoie des informations à tout les clients connectés lorsque événement donné se produit.
Pour cela il faut aussi un script qui tourne en permanence.
Comme je suis chez un hébergeur mutualisé j'ai beaucoup de limitations.
Je ne peux pas utiliser des fonction comme create_socket.
J'ai regardé du côté de html5 et des websockets mais pour l'instant ca marche que sur de rares navigateurs.
Est ce que la solution ci-dessous vous semble viable :
- Je rafraichi la page avec les enchères chaque seconde.
- Cette page inclut un fichier encheres_en_cours.html.
- Le fichier encheres_en_cours.html contient les enchères en cours.
- Lorsque que quelqu'un enchéri cela provoque un update dans la base données et après l'update je fais un select de toutes les enchères en cours en j'écris le résultat formaté dans le fichier encheres_en_cours.html.
- Quand un nouveau client se connecte il provoque aussi l'actualisation du fichier encheres_en_cours.html.
Le site n'est pas directement pour moi...d'où la difficulté d'avoir le serveur que je voudrais...et après j'ai pas beaucoup de connaissances en serveur et en sécurisation des serveurs.
Je viens de voir APE (Ajax Push Engine). Vous connaissez ? Vous en pensez quoi ?
Le site n'est pas directement pour moi...d'où la difficulté d'avoir le serveur que je voudrais...et après j'ai pas beaucoup de connaissances en serveur et en sécurisation des serveurs.
Sinon tu peux essayer d'orienter ton "client" vers des hébergements type Google App Engine. Bon, ce dernier est limité au Java et Python côté serveur, mais il doit y avoir moyen de trouver des équivalents qui prennent en charge d'autres langages.
Sinon peut-être que du mutualisé style alwaysdata serait moins limité que les offres conventionnelles, ça peut valoir le coup de demander, je crois qu'ils répondent aux questions techniques sur leur forum.
Citation : marcskie
Je viens de voir APE (Ajax Push Engine). Vous connaissez ? Vous en pensez quoi ?
Jamais testé mais j'en ai déjà entendu parler en bien. Je pense que c'est plutôt une bonne idée de s'orienter vers ce genre de solution
Blond, bouclé, toujours le sourire aux lèvres...
Enchères avec actualisation chaque seconde et bdd
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...