J'ai des données publiées JSON avec un modèle ci-dessous et sur le côté Java, j'ai une API de repos comme ceci: questions 1) Dois-je aller avec la pagination. 2) Si je divisais Json en une moitié, chaque moitié ne sera pas valide JSON. Donc, devrais-je accepter des chaînes et concerner sur le côté serveur? 3) Existe-t-il de bons exemples pour gérer ce scénario 4) à la recherche d'une approche pouvant gérer des données JSON de taille inférieure ou supérieure à 2 Mo < / p>
5 Réponses :
2 Mo est plutôt petit et je pense que l'approche pour télécharger le fichier JSON en tant que multipart, puis traiter normalement le fichier JSON peut gérer le fichier de taille maximum de 50 Mo. Un exemple de chargement de fichier de traitement peut être trouvé ici .
Pour les fichiers JSON supérieurs à cent de MBS, nous devons trouver un moyen de traiter en streaming ou de scinder le fichier en fichiers plus petits.
La pagination sera la bonne option, mais il aura besoin d'une intervention manuelle. Au lieu de cela, vous pouvez envoyer plusieurs demandes ASYNC à récupérer des données (c.-à-d. Fetch 1-200 enregistrements dans une demande et la demande suivante va chercher 200-400) comme celle-ci, mais elle n'est pas recommandée car votre serveur aura plus de demande sur la base de votre serveur. le nombre d'enregistrements.
La pagination ne vous résoudra pas de problème car vous envoyez des données au serveur et ne recevez pas.
Quel récipient de servlet utilisez-vous? On dirait que la taille de la limite de la limite de Post Tomcat par défaut.
Si vous utilisez Standalone Tomcat, vous devez définir le paramètre maxpostssize pour votre connecteur : voir ici ou ( ici )
J'utilise WebSphere.
Quelle version utilisez-vous? Pouvez-vous essayer de le configurer comme décrit ici: serverfault.com/q/311610 ?
WLP-JAVAEE7-8.5.5.9
La pagination est non seulement appliquée sur l'envoi de données de serveur, mais également recevoir des données. La pagination signifie que les données de pagination envoient d'un côté à l'autre.
Javaman, s'il existe des paramètres tels que décrits ici: ibm.com/support/wnowledgecenter/ss7jfu_7.0.0/... Publier d'origine ici: Stackoverflow.com/a/16593022/2003797
Les fichiers JSON sont parfaits pour la compression. Vous devriez y penser.
Oui, vous devriez aller avec pagination. Mais il y aura un inconvénient. Comme la cohérence.
Vous devez les envoyer en ne divisant pas en chaînes. Je vous suggère d'envoyer des données significatives. Alors la pagination sera significative. Si l'une des parties (blocs) du message est manquante, vous ne devez éventuellement renvoyer cette partie. Pas la part des parties.
"Comment pouvez-vous manger un très gros poisson? - en tranchant mince".
Essayez de poster des pièces plus petites et significatives. Sinon, vos serveurs auront besoin de plus de temps d'informatique pour traiter les données, vos clients ont besoin de plus de mémoire pour traiter.
Y a-t-il une raison pour laquelle vous n'envoyez pas les données dans une seule demande? Envoyez le 50 Mo comme une demande. Il n'y a pas de limite sur la taille des données dans JSON ou Spécification de poteau HTTP, comme indiqué dans ci-dessous des questions ci-dessous
Y a-t-il une limite sur la quantité de JSON peut contenir?
est HTTP POST SLUMLUBLE SAUMLESS?
Si vous êtes inquiet pour la performance de votre serveur. Une option possible consiste à diviser votre JSON logiquement de sorte que l'action puisse être effectuée dans des morceaux plus petits.
Pour par exemple, considérez votre tableau de tables, vous pouvez envisager de diviser le tableau des tables dans des morceaux plus petits. 50/20 par demande. demande suivante Si vous n'avez pas besoin des données complètes pour le traitement de la demande, vous pouvez effectuer le action sur les données comme elle arrive. Sinon, ajoutez la matrice Tableaux à certains dB / fichier / mémoire jusqu'à ce que la dernière page soit reçue et que la dernière demande fusionnez le JSON et traitez la demande et renvoyez la réponse appropriée. Si c'est le deuxième cas, il n'y a pas beaucoup d'amélioration de la performance.
Avez-vous essayé avec BSON ?
Je n'ai pas essayé que la taille totale de la carte postale sera comme 50 Mo. N'a-t-elle pas une limite à BSON?
Pour être honnête, il s'agit simplement d'une suggestion qui pourrait optimiser un peu la taille. Avec une charge utile totale de 50 Mo, vous pourriez toujours avoir besoin d'une forme de pagination de toute façon.
Optez pour un échange de données moins monolithique, postez des articles plus petits, chaque enregistrement ou vous. Même avec la compression (en-tête
Accepter-coding: gzip ), tandis que 50 Mo (compressé peut-être ~ 1 Mo) est trop large.essayez-vous de télécharger un fichier
Non, ce n'est pas un fichier.
Besoin de définir une certaine valeur de seuil et après avoir atteint cela, postez simplement vos données sur le serveur.avec, vous pouvez minimiser le nombre d'appels de serveur dans une approche de pagination.