Discussion :

[Nothus]

Bonjour à tous,

Dans le cadre de la réalisation perso d'une application web de statistiques locales, j'ai testé l'insertion de fichiers "lourds" (plus de 150 Mo) par le biais de JS. L'ensemble des calculs et des représentations sont réalisées par la page (merci Web Workers / Shareds Workers) et seuls les résultats pertinents sont transmis au serveur pour sauvegarde (quelques Mo max).

Après moultes essais, en passant par IndexedDB et localStorage, sur un fichier test (contenu aléatoire de 122 Mo), l'insertion échoue systématiquement. Je ne comprends pas, sous Linux normalement ça fonctionne toujours...

Bref : j'ai bien évidemment augmenté les autorisations de stockage manuellement. Mon navigateur est vierge (en tout cas d'après ce qu'il m'a dit, mais j'ai un doute, je le soupçonne de sortir en cachette) de tout composant parasite, j'ai 4Gg qui lui sont réservés.

Je n'ai pas vraiment "une erreur" manifeste mais un ralentissement global (normal me direz-vous ?) puis un arrêt de l'onglet qui crash. J'ai testé sous Firefox, Chrome, sur deux postes différents (un sous Linux/Ubuntu et l'autre sous W10).

L'objet FileReader me retourne correctement le fichier (et d'ailleurs les 122 Mo ne lui font pas peur dans l'absolu : le dump par console.log me donne un résultat correct et un temps record). Mieux : le transfert vers les Wrokers se fait sans difficulté (une ligne envoyée à chaque fois).

Pour les stockages locaux, j'ai testé soit un enregistrement unique (l'ensemble des lignes sont stockées dans un objet unique puis sérialisées - une mauvaise idée certes, mais une idée quand même) soit un en enregistrement par ligne (davantage dans l'esprit de la finalité de l'outil).

Exemple de fichiers à insérer une fois l'outil terminé : données INSEE par commune, avec une dizaine d'indicateurs (soit 32000 communes x 10 colonnes ou plus, avec plusieurs caractères par colonnes, l'ensemble est sérialisé par ligne en JSON...). Souvent avec des versions temporelles (une année par colonne : un indicateur pour 5 ans = 5 colonnes. Donc une dizaine d'indicateurs sur 5 ans = une cinquantaine de colonnes) -> impossible donc, de faire moins et les résultats combinatoires intermédiaires sont du même ordre.

le fichier de test fait plus de 100.000 lignes, j'en suis rendu à tester un setInterval pour réduire la fréquence des insertions, voir si ce n'est pas la cause du problème... ?!!
Toutes vos idées sur la meilleure manière de faire me serait très utile...

Merci d'avance et bonne journée !

-Nothus-

[headmax]

Idéalement si c'est du stockage tu pourrais t'orienter vers du nosql pour le stockage de tes données, l'avantage c'est fait pour le stockage de logs et bien entendu en Json, javascript n'est là que pour passer les requêtes a cette base de donnée qui pourrait être mongoDB ou bien plus robuste cassandra. Ici l'avantage et qu'il y a aussi la possibilité de savoir quel requête à échoué et de checker le soucis après coup. Le nosql n'est pas du relationnelle et n'a pas de contrainte d'insertion structurelle, on peut rajouté des nouveau champs à la volé, il est "scalable" peux augmenter ses performances juste en rajoutant de nouveaux disques de stockages. Je cache pas qu'il y a un petit moment de compréhension avant d'être à l'aise avec ce genre d'outils, mais c'est une orientation qui semble répondre a ton cas. petit benchmark https://academy.datastax.com/planet-...nce-benchmarks

[Nothus]

Merci de ton retour !

Tu as raison sur le fond, car tu libères ton navigateur et les possibilités du serveur sont plus grandes - mais je souhaite un processus complètement inverse.

Arguments :

(1) Le site s'accompagne d'une webExtension pour des requêtes sans les contraintes des cross-domains. Ce serait à lui d'ailleurs, de faire le stockage local sur le navigateur, gérer le téléchargement, etc. On reste donc sur du JS et ses possibilités.

(2) Si je dois télécharger d'abord sur le serveur une fichier de quelques centaines de Mo, pour rapatrier ensuite l'ensemble sur mon navigateur, traiter pour renvoyer encore les résultats... cela reste des échanges nombreux. Multiplié par plusieurs utilisateurs, voire des dizaines, oui, le système doit être fortement scalable car il sera constamment à gérer des gros volumes de données. Dans un monde idéal où j'aurais des moyens sans limite pour ce projet (#Licorne ), j'avais pensé initialement à Neo4J dont l'approche me plaît comme son pseudo-langage de requêtes (Cypher).
La seule autre possibilité c'est de ne rapatrier que les résultats tu me diras... oui mais...

(3) ... Cela (me) pose toujours des problèmes de sécurité car l'application ne sait pas quel calcul ou rapprochement elle doit faire (c'est à l'utilisateur de les définir -> donc à faire traiter par le serveur si l'on veut économiser de la bande passante). Cela crée une importante porte ouverte à des bugs et des failles. Au-delà même que mes ressources soient limitées actuellement à un hébergement mutualisé qui a déjà une belle charge par ailleurs !

En soi les traitement ne sont pas très compliqués et à la portée d'un JS côté navigateur pour peu que je sois malin. C'est vraiment le stockage une fois la page fermée ou abandonnée, qui pose des difficultés, afin de garder en local ce qui a déjà été fait / téléchargé. Encore une fois avec l'optique de n'envoyer que le minimum sur le serveur.

Quand le cadre des traitements distribués, le principe est similaire à ta proposition (qui reste certes une option intéressante) car pour traiter des données, il faut les envoyer... et du calcul distribué entre un seul navigateur (une instance = un utilisateur) et un serveur, ce n'est plus du traitement distribué... "Anonymiser" pour l'envoyer à n'importe qui, c'est rajouter une très grande couche de difficulté car les calculs doivent être revus et retraités avant l'intégration finale (principe du consensus).

Je ne sais pas si ma réponse t'apporte un autre éclairage ?

[headmax]

Je suis d'accord qu'il n'ait pas si aisé de procéder a une migration, total de la logique, comme la de mise en place d'une tel infrastructure j'en convient . Par contre tout les arguments et les contraintes d'on tu as mentionné a part une très pertinente "server mutalisé" qui enlève tout espoir de mettre en œuvre une tel infra, le reste n'est pas une problématique pour la partie "Cross domain", le nosql sont rôle c'est de stocké de façon sécurisé data sensible ou pas data API public cela se met en œuvre assez facilement et rapidement. L'avantage non des moindres la réplication des données, et la persistances des données, et qui peut allez jusqu'au téras ce qui laisse une marge. J'ai en 2012 fait un proxy basé sur nodejs capable d'outre passer le cross domain. L'enjeux devoir récupérer un maximum de données provenant des navigateurs des clients qui utilisaient nos scripts JS (nos publishers payé en retour) afin de passer notre pub pour nos "advertisers" (ceux qui nous payaient), ma mission récupérer un max d'info en vue de statistics sur les surfeurs et essayer d'augmenté le pourcentage de notre "tunnel de conversion". En moyennes 1000 vues pour 1/achat (billing). Nous avions a peu près de 2 millions voir 3 millions (en temps de fêtes) de vues par jour, j'alimentais "pooling" un datacenter sur lausanne.

Pour revenir sur ton problème qui est en gros la saturation du navigateur qui crash pour des raisons peut être accessible via les logs, ou via la console qui sature en output ou la saturation de la base donnée il faudrait investir dans se sens, sinon pour outrepasser le navigateur :

Soit utiliser les "browser based" comme https://www.npmjs.com/package/node-browser qui lui est capable d'ouvrir un brower et injecter du js pour qu'il exécute des tâches et le fermé, l'idéal dans ce contexte si ça, plante, tu saura pourquoi et a cause de quoi et comme tu est dans un contexte js tu pourra exécuté les autres dépendances toujours en asynchrone.
Aussi https://www.npmjs.com/package/browser-run plus complet possibilité d'utiliser des mocks pour tes tests unitaires... et la liste est longue, je te laisse le choix de rechercher dans se sens juste pour remplacer les dépendances navigateurs à cause de JS. Car tout pourrait bien se passer en console

Soit utiliser les stomps serveurs activeMQ et bien d'autre dans les dérivés serveur "The Simple Text Oriented Messaging Protocol" très en vogue et très puissant https://www.npmjs.com/package/stomp-client (client) https://stomp.github.io/implementations.html (serveurs)

[Nothus]

Tes deux solutions sont pas mal, particulièrement STOMP (qui a un arrière-goût de REST...?).

Entre temps j'ai tenté de comprendre les erreurs. Sur Window.localStorage, en réduisant "le rythme" d'insertion et avec une gestion plus sérieuse des erreurs, on peut pousser jusqu'à quelques dizaines de milliers de lignes et les quelques Mo par défaut du stockage. C'est toujours ça de pris : peut-être faut-il que je ne garde en local que la partie données, qui serait renvoyée ensuite au serveur pour diffusion et stockage plus définitif.

Pour IndexedDB, le problème est un problème de conception : comme il s'agit d'asynchrone, les erreurs ne sont pas ou mal récupérées dans mes premiers tests et le système dérape. Il n'y a pas vraiment de solution, sauf à revoir ma conception.
Par contre la documentation du MDN évoque des critères d'éviction un peu particulier pour l'utilisation de l'espace libre : aucune limite réelle en taille mais si il n'y a plus d'espace libre (correspondant à 50% de l'espace libre du DD du profil de l'utilisateur), les données des origines les moins utilisées (pas nécessairement les plus anciennes origines ?!) sont supprimées, sans respect de règles de cohérence : on peut donc avoir une base à moitié supprimée (il faut donc un hash pour vérifier l'intégrité lors d'un nouvel accès ?).

Bref il n'y a pas vraiment de bonnes manières de faire au-delà de quelques Mo, en tout cas facile et sans risque. Et le nombre de lignes et leur taille individuelle, jouent sur la qualité et la fluidité totale de l'onglet.

Une révision complète de mon code et son infrastructure, comme tu le soulignes, est nécessaire. Cela impose un modèle plus axé sur les serveur. Probablement avec SSE - Serve Send Event - pour retransmettre les résultats au navigateur, plus favorable à l'asynchrone et donc couplé à IndexedDB.

"Sujet résolu" : merci à toi !

[ABCIWEB]

Une révision complète de mon code et son infrastructure, comme tu le soulignes, est nécessaire. Cela impose un modèle plus axé sur les serveur.

Oui, compter principalement sur le local storage des navigateurs pour faire tourner une application est très risqué/aléatoire. On peut s'en servir pour éventuellement faciliter certains traitements mais il ne faut pas qu'il y ait de dépendance.

[Nothus]

Oui, compter principalement sur le local storage des navigateurs pour faire tourner une application est très risqué/aléatoire. On peut s'en servir pour éventuellement faciliter certains traitements mais il ne faut pas qu'il y ait de dépendance.

[aparté = on]

Une "indépendance" que je trouve un peu dommage... je ne m'étais jamais vraiment posé la question avant, mais c'est un manque dans la norme que je qualifie de sérieux. Déjà qu'on a "sacrifié" WebSQL sans vraiment se poser la question de la pertinence de cette suppression pour l'ensemble des "usagers" (développeurs), qu'on impose la tendance vers IndexedDB - en version asynchrone - qui est abscons et pas toujours utile (cf Web-Workers), et que certains navigateurs se base en partie sur du SQLite (cf doc du MDN) - donc moyen d'avoir du SQL et not-only-SQL, c'est n'avoir ni le beurre ni l'argent du beurre...

Je ne suis pas sûr que les applications web puissent se développer totalement sans avoir une véritable et variée boîte à outils sur la gestion de volume de données et pas seulement ce qui ressemble de loin à des hacks priorisé en JSON. Se faisant, on maintient la domination de la relation client/serveur au détriment d'un navigateur qui soit pour tous les usages et puisse être disponible et utile réellement en mode hors-ligne.

Dit autrement : sans des moyens de plus en plus lourds et une équipe chevronnée, les projets web ne peuvent plus devenir totalement innovants. La prime au plus imposant !

[aparté = off]

Merci de ton retour ABCIWEB.

[ABCIWEB]

[aparté = on]

Une "indépendance" que je trouve un peu dommage... je ne m'étais jamais vraiment posé la question avant, mais c'est un manque dans la norme que je qualifie de sérieux.
...
Je ne suis pas sûr que les applications web puissent se développer totalement sans avoir une véritable et variée boîte à outils sur la gestion de volume de données et pas seulement ce qui ressemble de loin à des hacks priorisé en JSON. Se faisant, on maintient la domination de la relation client/serveur au détriment d'un navigateur qui soit pour tous les usages et puisse être disponible et utile réellement en mode hors-ligne.

La boite à outil se complète avec le temps, mais même en cas de normes universelles et bien respectées par tous les navigateurs, quid des données en cas de réinitialisation du pc ? D'un point de vue pratique on ne peut pas faire confiance au local storage... et plus généralement à tout ce qui est côté client. Je ne vois pas bien comment se passer d'un serveur pour justement en être indépendant.

[Nothus]

(1)

(...) quid des données en cas de réinitialisation du pc ?

La question se pose pour tous les logiciels qui communiquent avec le web (ou même qui ont des besoin d'informations extérieures). La découpe en étapes résout le problème : l'initialisation, l'usage / la mise à jour, l'éventuelle désinstallation.

La vraie problématique n'est pas d'avoir des limites (il y en a forcément), mais la cohérence (dans l'espace et le temps) et l'accessibilité (volume, temps, complexité) des données.

(2)

(...)D'un point de vue pratique on ne peut pas faire confiance au local storage... et plus généralement à tout ce qui est côté client.

C'est une vision "de serveur". Si le client a des besoins locaux (exemple : LibreOffice qui édite des fichiers textes), c'est pas un problème de ce qu'il fait ou pas sur son poste. Mon besoin était une édition locale avec, à la marge comme expliqué, des besoins d'envoi au serveur pour diffusion. Le centre de mon projet est un traitement statistique, matriciel, local.

C'est l'absence de possibilités sur le navigateur qui me conduit (m'impose serait plus exact) à une approche client/serveur et donc, effectivement, à me méfier de ce qui est côté client.

(3)

(...) Je ne vois pas bien comment se passer d'un serveur pour justement en être indépendant.

Bref c'est le serpent qui se mort la queue : on reste sur des usages orientés "réseau" faute d'avoir une harmonisation des outils pour un usage local réel et développé.

[ABCIWEB]

Mon besoin était une édition locale avec, à la marge comme expliqué, des besoins d'envoi au serveur pour diffusion. Le centre de mon projet est un traitement statistique, matriciel, local.

Ok j'avais lu trop vite et pas saisi ça, réflexe application web serveur effectivement trop présent, excuses pour ma digression et bonne fin d'après midi