jQuery ou javascript pour trouver l'utilisation de la mémoire de la page


98

Existe-t-il un moyen de savoir combien de mémoire est utilisée par une page Web ou par mon application jquery?

Voici ma situation:

Je construis une application Web lourde de données à l'aide d'un frontend jquery et d'un backend reposant qui sert des données en JSON. La page est chargée une fois, puis tout se passe via ajax.

L'interface utilisateur fournit aux utilisateurs un moyen de créer plusieurs onglets dans l'interface utilisateur, et chaque onglet peut contenir beaucoup de données. J'envisage de limiter le nombre d'onglets qu'ils peuvent créer, mais je pensais que ce serait bien de ne les limiter qu'une fois que l'utilisation de la mémoire a dépassé un certain seuil.

Sur la base des réponses, j'aimerais apporter quelques clarfications:

  • Je recherche une solution d'exécution (pas seulement des outils de développement), afin que mon application puisse déterminer les actions en fonction de l'utilisation de la mémoire dans le navigateur d'un utilisateur.
  • Le comptage des éléments DOM ou de la taille du document peut être une bonne estimation, mais cela pourrait être assez inexact car il n'inclurait pas la liaison d'événement, les données (), les plugins et autres structures de données en mémoire.

Vous devez rechercher le type d'utilisateurs de votre application Web pour déterminer s'ils ont ou non des problèmes de mémoire lors de l'utilisation de votre application Web. Ou avez-vous vous-même des problèmes de mémoire / performances avec votre application Web?
Prutswonder

@Prutswonder: Non, je n'ai pas de problèmes, mais j'étais simplement curieux de savoir si un tel outil existe. Je pensais juste qu'au lieu de simplement définir une limite fixe sur les onglets, une méthode dynamique pourrait être cool.
Tauren

Je viens d'ajouter quelques détails supplémentaires à la question pour aider à clarifier que je recherche une solution d'exécution, pas une solution de construction.
Tauren

2
Juste une question, si quelque chose était déjà mis en cache, cela comptera-t-il toujours?
ajax333221

Réponses:


65

Mise à jour 2015

En 2012, cela n'était pas possible si vous vouliez prendre en charge tous les principaux navigateurs en cours d'utilisation. Malheureusement, pour le moment, il s'agit toujours d'une fonctionnalité uniquement Chrome (une extension non standard de window.performance).

window.performance.memory

Prise en charge du navigateur: Chrome 6+


Réponse 2012

Existe-t-il un moyen de savoir combien de mémoire est utilisée par une page Web ou par mon application jquery? Je recherche une solution d'exécution (pas seulement des outils de développement), afin que mon application puisse déterminer les actions en fonction de l'utilisation de la mémoire dans le navigateur d'un utilisateur.

La réponse simple mais correcte est non . Tous les navigateurs ne vous exposent pas ces données. Et je pense que vous devriez abandonner l'idée simplement parce que la complexité et l'inexactitude d'une solution «artisanale» peuvent introduire plus de problèmes qu'elle n'en résout.

Le comptage des éléments DOM ou de la taille du document peut être une bonne estimation, mais cela pourrait être assez inexact car il n'inclurait pas la liaison d'événement, les données (), les plugins et autres structures de données en mémoire.

Si vous voulez vraiment vous en tenir à votre idée, vous devez séparer le contenu fixe et dynamique.

Le contenu fixe ne dépend pas des actions de l'utilisateur (mémoire utilisée par les fichiers de script, les plugins, etc.)
Tout le reste est considéré comme dynamique et devrait être votre objectif principal lors de la détermination de votre limite.

Mais il n'y a pas de moyen facile de les résumer. Vous pouvez mettre en place un système de suivi qui rassemble toutes ces informations. Toutes les opérations doivent appeler les méthodes de suivi appropriées. par exemple:

jQuery.dataMéthode d' enveloppement ou d'écrasement pour informer le suivi système de de vos allocations de données.

Enveloppez les manipulations html afin que l'ajout ou la suppression de contenu soit également suivi ( innerHTML.lengthc'est la meilleure estimation).

Si vous conservez de gros objets en mémoire, ils doivent également être surveillés.

En ce qui concerne la liaison d'événements, vous devez utiliser la délégation d'événements et cela pourrait également être considéré comme un facteur quelque peu fixe.

Un autre aspect qui rend difficile l'estimation correcte de vos besoins en mémoire est que différents navigateurs peuvent allouer de la mémoire différemment (pour les objets Javascript et les éléments DOM).


Ne innerHTML.lengthprend pas de mémoire, de RAM ou de CPU (ou autre chose, je n'ai aucune idée) pour traiter également?
mrReiha

La prise en charge du navigateur pour cette fonctionnalité n'est PAS IE9 + ou autre chose que Chrome. Window.performance.memory est uniquement Chrome. docs.webplatform.org/wiki/apis/timing/properties/memory
Blunderfest

Vous avez raison, je pensais que la mémoire faisait partie de la norme de synchronisation de navigation et de l' window.performanceobjet. Les anciennes entrées «pris en charge par» étaient applicables pour cette norme. window.performance.memoryest considérée comme une extension non standard par Chrome.
gblazex

Pour activer la surveillance de la mémoire en temps réel via window.performance.memory, vous devez démarrer Chrome avec l'indicateur --enable-precise-memory-info.
kluverua

Mise à jour: Opera prend également en charge cela. Source: Mozilla. developer.mozilla.org/en-US/docs/Web/API/…
HoldOffHunger

39

Vous pouvez utiliser l' API de synchronisation de navigation .

Navigation Timing est une API JavaScript permettant de mesurer avec précision les performances sur le Web. L'API fournit un moyen simple d'obtenir des statistiques de minutage précises et détaillées - en mode natif - pour la navigation dans les pages et les événements de chargement.

window.performance.memory donne accès aux données d'utilisation de la mémoire JavaScript.


Lecture recommandée


Excellente suggestion. Je vous remercie.
MaximOrlovsky

21

Cette question a 5 ans, et javascript et les navigateurs ont évolué incroyablement à cette époque. Puisque c'est maintenant possible (dans au moins certains navigateurs), et que cette question est le premier résultat lorsque vous Google "javascript show memory useage", j'ai pensé offrir une solution moderne.

memory-stats.js: https://github.com/paulirish/memory-stats.js/tree/master

Ce script (que vous pouvez exécuter à tout moment sur n'importe quelle page) affichera l'utilisation actuelle de la mémoire de la page:

var script=document.createElement('script');
script.src='https://rawgit.com/paulirish/memory-stats.js/master/bookmarklet.js';
document.head.appendChild(script);


1
Cela semble signaler l'utilisation de la mémoire JS et non l'utilisation de la mémoire de la page, le gestionnaire de tâches intégré de Chrome indique que Gmail utilise 250 Mo tandis que memory-stats.js rapporte 33,7 Mo
Brandito

Il n'y a pas de licence répertoriée pour la page github de bookmarklet.js, c'est donc vraisemblablement une propriété intellectuelle protégée par des droits d'auteur. Cela laisse une certaine incertitude en fonction de ce projet.
HoldOffHunger

8

Je ne connais aucun moyen de savoir quelle quantité de mémoire est utilisée par le navigateur, mais vous pourrez peut-être utiliser une heuristique basée sur le nombre d'éléments sur la page. Uinsg jQuery, vous pourriez le faire $('*').lengthet il vous donnera le décompte du nombre d'éléments DOM. Honnêtement, cependant, il est probablement plus facile de faire des tests d'utilisabilité et de proposer un nombre fixe d'onglets à prendre en charge.


3
@tvanfosson: ce n'est pas une mauvaise idée, mais cela ne me donnera pas d'informations sur la mémoire non DOM, comme .data () et les structures de données en mémoire. Mais cela pourrait donner une bonne estimation du poids global que je pourrais utiliser.
Tauren

4

Utilisez l' outil Instantané de segment de mémoire Chrome

Il existe également un outil Firebug appelé MemoryBug, mais il semble qu'il n'est pas encore très mature.


@Pablo: Merci. J'utiliserai certainement des outils de développement, mais j'espérais trouver quelque chose que je pourrais utiliser pendant l'exécution pour trouver l'utilisation de la mémoire dans le navigateur de chaque utilisateur.
Tauren

3

Si vous voulez juste voir pour le test, il existe un moyen dans Chrome via la page des développeurs pour suivre l'utilisation de la mémoire, mais vous ne savez pas comment le faire directement en javascript.


@Zachary: Merci. J'utiliserai certainement des outils de développement, mais j'espérais trouver une solution d'analyse d'exécution.
Tauren

1
Si vous en trouvez un, faites le moi savoir, j'aimerais bien en avoir un à portée de main
Zachary K

3

Je voudrais suggérer une solution entièrement différente des autres réponses, à savoir observer la vitesse de votre application et une fois qu'elle tombe en dessous des niveaux définis, soit montrer des conseils à l'utilisateur pour fermer les onglets, soit désactiver l'ouverture de nouveaux onglets. Une classe simple qui fournit ce type d'informations est par exemple https://github.com/mrdoob/stats.js . En dehors de cela, il n'est peut-être pas judicieux pour une application aussi intensive de garder tous les onglets en mémoire en premier lieu. Par exemple, conserver uniquement l'état de l'utilisateur (défilement) et charger toutes les données à chaque fois que tous les onglets sauf les deux derniers s'ouvrent peut être une option plus sûre.

Enfin, les développeurs Webkit ont discuté de l'ajout d'informations sur la mémoire à javascript, mais ils ont obtenu un certain nombre d'arguments sur ce qui et ce qui ne devrait pas être exposé. Quoi qu'il en soit, il n'est pas improbable que ce type d'informations soit disponible dans quelques années (bien que ces informations ne soient pas trop utiles pour le moment).


1

Moment parfait pour les questions avec moi qui commence un projet similaire!

Il n'existe aucun moyen précis de surveiller l'utilisation de la mémoire JS dans l'application, car cela nécessiterait des privilèges de niveau supérieur. Comme mentionné dans les commentaires, vérifier le nombre de tous les éléments, etc. serait une perte de temps car il ignore les événements liés, etc.

Ce serait un problème d'architecture si le manifeste de fuite de mémoire ou si des éléments inutilisés persistent. S'assurer que le contenu des onglets fermés est complètement supprimé sans les gestionnaires d'événements persistants, etc. serait parfait; en supposant que cela soit fait, vous pouvez simplement simuler une utilisation intensive dans un navigateur et extrapoler les résultats de la surveillance de la mémoire (tapez about: memory dans la barre d'adresse)

Protip: si vous ouvrez la même page dans IE, FF, Safari ... et Chrome; et que de naviguer vers about: memory dans Chrome, il signalera l'utilisation de la mémoire sur tous les autres navigateurs. Soigné!


0

Ce que vous voudrez peut-être faire, c'est que le serveur garde une trace de sa bande passante pour cette session (combien d'octets de données lui ont été envoyés). Lorsqu'ils dépassent la limite, au lieu d'envoyer des données via ajax, le serveur doit envoyer un code d'erreur que javascript utilisera pour indiquer à l'utilisateur qu'il a utilisé trop de données.


@incrediman: c'est aussi une bonne idée, mais je ne pense pas que cela fonctionnerait sans intégrer de nombreuses fonctionnalités de suivi - juste un nombre d'octets ne fonctionnerait pas. Le problème est que les données d'un onglet sont une liste que l'utilisateur filtrera et triera de différentes manières. Chaque fois qu'ils apportent des modifications, de nouvelles données seront extraites du serveur et remplaceront les éléments dom actuels. De plus, qu'est-ce qui dit qu'ils ne cliquent pas sur "recharger" et commencent avec une nouvelle page? Je devrais suivre les 304 et autres, mais j'ai l'intention de simplement servir du html statique, toutes les données proviennent d'un service REST.
Tauren

Cette approche ne tient pas compte des éléments créés ou détruits avec createElement () ou remove (), ce qui affecterait l'utilisation de la mémoire du client. Mais c'est intéressant de manière différente des autres réponses (en mesurant côté serveur et non côté client, vos mesures ne changent pas la mémoire, comme le feraient d'autres réponses).
HoldOffHunger

0

Vous pouvez obtenir le document.documentElement.innerHTML et vérifier sa longueur. Cela vous donnerait le nombre d'octets utilisés par votre page Web.

Cela peut ne pas fonctionner dans tous les navigateurs. Vous pouvez donc enfermer tous les éléments de votre corps dans un div géant et appeler innerhtml sur ce div. Quelque chose comme<body><div id="giantDiv">...</div></body>


4
Il innerHTMLest peu probable que la longueur de la chaîne générée soit utilement corrolée avec la mémoire que le navigateur utilise (par exemple, dans son modèle d'objet interne) pour rendre ce HTML.
TJ Crowder

et pourquoi est-ce que? Mon raisonnement est que si du texte est chargé dans le navigateur, il doit être stocké dans la mémoire. Donc, cela donne une certaine mesure de la mémoire utilisée par le navigateur pour rendre la page.
Midhat

4
Pensez-y de cette façon. Si vous dites "Je voudrais vous donner 10 millions de dollars", c'est 8 mots. Par contre, si vous dites "j'aimerais éternuer sur votre serviette", c'est 7. Le premier seulement 8/7 est-il plus précieux que le second?
intuité

1
Ceci est similaire à la suggestion de @tvanfosson d'obtenir le nombre d'éléments DOM. Le vôtre est probablement un peu plus précis car différents éléments dom peuvent contenir différentes quantités de texte. Mais il n'obtient toujours aucune information sur les données (), les gestionnaires de clics, les structures de données et les objets en mémoire, etc. Mon application utilise beaucoup de ces fonctionnalités.
Tauren

1
Il peut y avoir des variables JS dans la portée qui pointent vers des nœuds DOM détachés, qui ne feront pas partie de l'élément de document. Vous pouvez également écrire du code pour charger simplement une chaîne très longue dans une variable, consommant des gigaoctets de mémoire, sans affecter le texte de la page.
Josh Ribakoff
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.