Lors de la production d'un système de saisie de données basé sur le Web, le fait d'ajouter une demande de serveur supplémentaire par page est-il une préoccupation importante pour décider d'utiliser ou non un modèle de publication/redirection/réception?post/redirect/get
Oui, mais pas simplement pour des raisons de performance. Si vous avez un équilibrage de charge et une réplication de base de données, vous devez vous assurer que GET après le POST verra réellement les données qui ont été affichées, vous devez donc configurer l'équilibreur de charge pour rediriger les utilisateurs vers votre site Web "maître" ou exactement la même machine qui a reçu le POST (selon comment vous avez mis en place le stockage). La requête seule n'est pas un problème, en particulier cette alternative donne une expérience utilisateur assez mauvaise et peut entraîner des demandes encore plus superflues que la simple redirection.
La plupart du temps, les publications ne se produisent que lorsque les données sont modifiées. Le temps de trafic et de CPU le plus élevé sur les sites est généré par des requêtes (GETS) plutôt que par des changements, donc je pense que ces demandes supplémentaires ne sont pas très significatives.
Si je comprends bien votre question (et je ne suis pas tout à fait sûr que je fais), il est certainement une bonne conception de faire une redirection après un poste, même si vous êtes en leur montrant la même page avec les informations mises à jour. En effectuant la redirection, vous rompez la connexion entre la page visualisée et le POST qui a provoqué la modification. L'utilisateur peut mettre en signet et/ou actualiser la page sans aucune fenêtre demandant "Voulez-vous renvoyer les données?"
Pouvez-vous donner un exemple de travail? –
Je ne sais pas quel langage/framework/serveur vous utilisez, mais il y a des exemples gazillion sur le net dans un langage toujours possible. Il suffit de rechercher sur POST/REDIRECT/GET. [Voici la Wikipedia] (https://en.wikipedia.org/wiki/Post/Redirect/Get) page dessus. –
Je suis passé par tous ces articles, mais incapable de comprendre encore. Ce que je comprends ici est: Dans abc.php
Je pense que la facilité d'utilisation que cette offre l'emporte sur le petit succès de performance.
Testez-le en effectuant quelques tests de performances et vous serez en mesure de voir si cela va poser problème dans votre cas particulier. Voir this article pour plus d'informations.
Une autre option consiste à utiliser la mise en miroir de base de données au lieu de la réplication et memcached pour la mise en cache. Peu importe le frontal auquel l'utilisateur est redirigé. –
Merci pour les choses supplémentaires à penser! – Wes