Calculer Girl
  1. Calculer Girl
  3. Beaucoup de petites ou une plus grande demande POST?
Intereting Posts
Envoi d’un tableau de caractères C sur un socket Comment savoir si un script bash s’exécute avec nohup? ctypes: printf renvoie la longueur qui est int à la place de la chaîne Unix: enregistrer une commande sed dans une variable, pour lui faire écho, puis l’exécuter Ressources associées à un aio_context Curseur de suivi C ++ Linux empêche le descripteur de fichier de se fermer à la sortie du programme Mac OS High sierra vhost Enregistrement des données VMStat dans un fichier “Org.apache.http.client.NonRepeatableRequestException” lors du téléchargement d’une image depuis Android Mon script shell s’arrête après exec Stratégie d’ouverture / fermeture pour le pseudo-fichier / proc localhost locking du dossier htdocs, est-ce possible? bibliothèque partagée de lien cmake sur Windows Rendre un graphique vectoriel (.svg) en C ++

Beaucoup de petites ou une plus grande demande POST?

Je dois rassembler des informations lorsque l’utilisateur voit un article. L’utilisateur parcourra 1 à 30 articles en une minute (peut-être même plus si l’utilisateur fait simplement défiler tout ce qui semble spécifique). Je me demandais de quelle façon je pouvais garder mes coûts de serveur au minimum:

  1. Au niveau du client, javascript, je pousse les identifiants d’article dans un tableau et les envoie au serveur quand il ya 30 à 60 identifiants. Au serveur, je passe en boucle tous les identifiants et les insère dans la firebase database.

  2. Chaque fois que l’utilisateur voit un article, j’envoie un identifiant d’article au serveur. Dans certains cas, cela peut provoquer plus de 60 requêtes en une minute. Au serveur, j’insère l’identifiant dans la firebase database.

Dans la plupart des cas, il y a toujours un compromis. Et souvent, la solution optimale se situe entre les deux. Je pense que vous devriez soutenir les deux et les utiliser indifféremment en fonction de la situation. Veuillez passer par les scénarios suivants:

  • Votre utilisateur final aura-t-il des problèmes de bande passante? Si oui, il peut être judicieux d’utiliser l’option 2 ou de réduire le nombre d’articles à un nombre tel qu’il puisse être facilement récupéré à une bande passante inférieure.
  • En supposant que l’utilisateur n’a pas de problèmes de bande passante tels que le chargement de 30 à 60 articles ne prend pas beaucoup de temps pour l’utilisateur, vous pouvez utiliser l’option 1 et continuer à utiliser cette option pour la récupération ultérieure.
  • Il est souvent judicieux d’utiliser l’option 1 pour la récupération initiale, puis de récupérer un nombre inférieur d’articles.
  • En ce qui concerne le coût du serveur, il serait judicieux d’envoyer 30 à 60 articles, à condition que les utilisateurs les lisent tous. Si vous sentez qu’il ne les lira pas tous, trouvez un nombre optimal en utilisant les parsings de votre application et envoyez ces articles en une fois, à condition que la bande passante ne soit pas un problème pour l’utilisateur.

tl; dr; Dans les données, vous devez avoir confiance. Utilisez votre intuition, les modèles d’utilisation des applications existants et la disponibilité de la bande passante de l’utilisateur pour prendre une décision éclairée. En outre, le coût du serveur n’est pas la seule chose. L’expérience compte plus, je pense.