Journalisation de l'effet JSON sur les performances

Je vois de plus en plus d'articles sur la connexion en JSON. Vous pouvez également en trouver un sur le blog NodeJS. Pourquoi tout le monde aime-t-il autant? Je ne vois que plus d'opérations s'impliquer:

• Quelques nouveaux objets en cours de création.
• Chaînage d'objets, ce qui implique soit le calcul de la longueur de chaîne, soit l'allocation de plusieurs chaînes.
• GCing toute la merde qui a été créée.

Existe-t-il un test de performances lors de l'utilisation de la journalisation JSON et de la journalisation de chaîne régulière? Les gens utilisent-ils JSON (pour la journalisation) dans les projets d'entreprise?

La journalisation JSON vous donne la possibilité d'analyser le fichier journal par programme même si le format a changé dans le temps .

Un bon exemple est les journaux Apache. Par défaut, Apache utilise le commonformat pour access.log:

"%h %l %u %t \"%r\" %>s %b"

Supposons que vous avez créé un analyseur hors ligne qui prend l'un de ces fichiers journaux et en calcule des statistiques.

À un certain moment, vous introduisez des sous-domaines dans votre application et les incluez virtual_hostdans vos journaux (juste pour pouvoir déboguer si des problèmes apparaissent avec l'un des sous-domaines):

"%v %h %l %u %t \"%r\" %>s %b"

Votre analyseur n'utilise pas le virtual_hosts, mais vous devez toujours adapter votre analyseur à:

• accepter le nouveau format de journal (notez le %ven tête du format de journal)
• supporte toujours l'ancien format de journal (pour les fichiers journaux plus anciens)

Mais si vous vous connectez à JSON , votre analyseur ne remarquera même pas le champ ajouté et pourra analyser avec plaisir les nouveaux journaux ainsi que les anciens journaux. Et un autre analyseur peut utiliser les champs ajoutés s'ils existent .

Et bien sûr pour vous , analyser JSON est plus facile que d'écrire regexpspour analyser les journaux de chaînes.

Si votre machine fonctionne si près de ses limites que de tels problèmes auraient vraiment de l'importance, vous avez probablement des problèmes plus graves. Bien qu'il puisse y avoir des situations exceptionnelles où cela fait une différence, de nombreuses applications (peut-être la plupart) s'exécutent sur des machines pour lesquelles la différence si vous connectez JSON, du texte simple ou des enregistrements à une base de données n'a aucune importance. Les objets, les chaînes et les autres conversions doivent être effectués dans la plupart des cas de toute façon (sauf si vous enregistrez un fichier binaire brut?), Peut-être que vous ne le verrez pas, car vous utilisez des classes par défaut qui le gèrent en arrière-plan (comme si vous écrivez dans une base de données).

Si vous avez besoin d'évaluations des performances pour cela, vous devrez les faire vous-même sur la machine sur laquelle vous souhaitez exécuter votre code et avec l'environnement de programmation que vous utilisez tous les jours. S'il y a un gros frais généraux ou tout dépend de beaucoup de choses. Si vous écrivez un site Web dans Ruby on Rails par exemple, vos données sont dans la plupart des cas un hachage, ce qui en convertit en JSON ne vous coûte presque rien, car la représentation interne n'est pas si loin de ce que vous voulez écrire (et c'est typique pour que le code Rails jette constamment de tels objets et structures de données).

Les avantages dépendent encore de vos outils. Si JSON est intégré dans vos bibliothèques, vous pouvez facilement le lire et l'afficher sous une forme ou une autre. Encore une fois à titre d'exemple: en supposant que vous disposiez d'une interface d'administration pour votre site Web et que vous souhaitez afficher certaines informations de journalisation stockées dans JSON, vous pouvez le faire lire et afficher en HTML dans Ruby dans une seule ligne de code dans certains cas.