Reprise du message précédent :

Ce running gag date d'il y a combien de temps ? 10 ans maintenant non ? Ce topic de vieux

 
Du coup maintenant est-ce que t'as compris que j'ai compris ?

Vas y koskoz, fais toi respecter un peu

Est-ce que vous connaissez des formations de reconversion dans le dev web ?

Un ami avec un diplom d'ingénieur chimiste aimerait se reconvertir. Il habite Saint-Étienne.

J'ai pas trop idée si ça peut se faire 100% en ligne ou non.

Pourquoi pas se tourner plutôt vers une formation en data science? Y a plein de boulots avec du Python et du R en chimie, bio, pharma, etc.

C'était la boîte avec les éoliennes ou la carto ?

carto

dites, j'ai un programme julia qui appelle du C.
J'ai l'impression qu'il devient de plus en plus lent au fil du run, je soupçonne qu'il fait une tonne de mallocs et qu'ils sont pas libérés.
 
comment je peux mettre ça en évidence ?

analysé la gueule de la conso mémoire ?

Le problème c'est que les réponses semblent évidentes alors qu'on sait tous qu'il n'a arrêté le diagnostic que quand un papier de recherche de 2021 fait par 5 post doc n'allait pas assez loin sur le sujet ou a fait une mauvaise interprétation d'une sous règle de POSIX

vaguement, mais j'aimerai afficher une courbe qui monte pour ce process, y'a quoi comme outil pour ça sur le mac?

Je pense que Instruments a des probes pour faire ca en natif.
 
Tu peux aussi le faire via dtrace qui va être plus flexible en mettant les bonnes probes, mais tu peux être limité par SIP (sauf à en faire une désactivation partielle). Je sais plus trop quelles sont les limitations de SIP par contre, IIRC c’est juste que tu peux pas tracer les binaires “système” (/bin, /System, …) auquel cas c’est pas un problème pour ton utilitaire à toi, mais je sais plus si ça touche aussi les libs.
 
Edit: sinon regarde si Julia a pas un système de tracing à lui? Python en a progressivement ajouté un, donc tu peux avoir des évènements qui sont à un niveau plus haut et moins brut que l’interface avec la libc.

Intéressant comme piste

TIL: il y a des gens qui utilisent %i avec printf.

Dites, vous avez des idées de comment paginer le problème suivant :

On utilise leveldb en prod (avec la lib levelup qui nous permet de manipuler plus facilement les data) donc pour recup une liste d'utilisateurs par exemple: on fait des db.createReadStream() qu'on borne selon le token des utilisateurs.
Sauf qu'on commence à avoir des paquets d'objets à stream. Certaines pages admin mettent beaucoup de temps à répondre (30 secondes pour les plus lourdes ~1millions d'entrée). Certains n'ont pas la fibre donc en plus de stream toute la bdd, je dois gérer les payloads.
L'idée est donc d'ajouter une pagination.

Je voyais ça comme ceci :
On stream la base, on recup les éléments qu'on veut renvoyer, imaginons les 20 premiers éléments qu'on stock dans une variable, on fait un stream.destroy() pour casser le stream et on renvoie les 20 éléments. Si jamais on veut la page 2, on skip les 20 premiers etc.

Ca marche MAIS :
- Je n'ai plus le nombre total d'éléments. Ce qui m'oblige à avoir une autre méthode pour recup juste le nombre d'éléments. Ou alors je ne destroy pas le stream et renvoie un count avec ma réponse. Ca corrige le problème du count, mais le fait de parser toute la base rallonge un peu le temps évidemment.
- Si je veux ajouter des critères de recherches, je suis quand même obligé de parser toute la bdd et ensuite appliquer mes filtres.

En gros, à part améliorer la taille de l'objet que je renvoie (ce qui est déjà pas mal), j'ai pas de solution miracle.

Si vous avez de meilleur idées, je maitrise pas à fond les streams. Pour info, on est en bloqué en node 8 pour le moment.

Dites, s’il y a des dev front / React ici, à combien on peut prétendre en province comme premier salaire / junior ? Niveau bac+3.
 
Je pensais a 35k, ça vous semble déconnant ?

Le contenu de ce message a été effacé par son auteur

le parcours pour avoir le nombre total doit etre assez rapide ,  donc je ne me ferai pas chier dans un premier temps : parcours de la collection complète, mais retourne uniquemnt la page courante + les metadatas ( offset, size, ... )  
 
Si les données ne bougent pas trop ( ou que tu peux savoir quand elles sont modifiées et invalider le cache) , tu peux aussi mettre le nombre en cache et ne faire que le parcours de 20 records depuis le dernier reçu

9 secondes quand même le parcours, en local. Après j'ai d'autres optis pour réduire un peu ce parcours. Au mieux j'ai ~3/4 secondes pour le million de ligne.

 
Ca fait bien 20 ans que j'ai pas vu ça  

Et c'est mal ? J'ai un vague souvenir que %i et %d sont équivalents

 
ça divise déjà le temps de chargement par 10 au mini : o
sinon, il y a de vrais bases de données qui font ça pour toi
 
côté front tu peux aussi récupérer un volume intermédiare ( genre 5 pages , quelques centaines de lignes )

Passer à une DB relationnelle?
 
Ou bien implémenter vos métadonnée à côté, genre des compteurs, indexes, …?
 
Et skip/limit ça me semble encore moins adapté pour un KVs que pour une DB classique, faut vraiment faire de l’itération par curseur (donc quand tu demandes une page, tu donnes le dernier objet de la page précédente, comme ça la DB peut redémarrer de cet objet, ça va pas se voir pour la 5e page, mais pour la 2500e si)

Bah c’est juste bizarre / confus, personne utilise %i avec printf donc t’arrives dedans et il te faut 30s pour te souvenir de ce que ça fait
 
En plus ça fait probablement pas ce que tu veux quand tu l’utilises avec sprintf (ça va parser les 0x/0o en entrée et pas juste le décimal).

 
Oui c'est une décision dont on devra discuter. Car 30 secondes de load mais tu as toutes tes datas donc les filtres coté front etc. c'est rapide.
Si on passe sur de la pagination, c'est 3/4 secondes à chaque requêtes/filtres car on placera les filtres côtés serveur évidemment. On demandera aux admins s'ils font plus de 10 recherches par jour.

J'ai un ancien collègue qui était passé par Le Wagon, il en était plutôt content (et le résultat était plutôt OK).
Par contre il le disait lui même, ça fait pas de toi un dev en 3 mois; faut être bien motivé, parce que sans travail perso à coté, c'est trop juste (lui était déjà pas mal autodidacte en dev, il a principalement fait la formation pour avoir "le papier" ce qui lui a permis de décrocher ses premiers entretiens assez facilement)

 
C'est en discutions pour c'est pas envisageable pour le moment.
 
Le problème c'est que tu dois refresh des metadonnées à chaque ajouts/delete d'objets. Ca implique beaucoup de modif de code dans notre bdd.
 
J'ai pas compris ta dernière phrase. leveldb parcourt, toute la base. Je peux pas lui dire de démarrer à un certain points car nos key sont de la forme "user_blablablabla" donc on borne sur "user_".

Sinon t’as essayé de compresser ton stream? Plus de compression => moins de données => plus de vitesse

 
C'est une piste. Même si on renvoie pas le stream directement. On stream la base, et on recup un objet user par exemple qu'on renvoie. Quand je parlais de payload, c'est que nos objets user contiennent BEAUCOUP de data. On a implémenté un parser graphql pour justement recup seulement les props qu'on veut dans un objet. Ce qui allège l'objet user, et donc le payload.

Serait probablement une bonne chose d’avoir une couche frontale unifiée pour pas taper directement dedans comme des sauvages non?
 

La doc de levelup liste des options gt/lt sur createReadStream, et de ce que j’ai compris d’une recherche rapide sur leveldb c’est une structure en arbre trié sur la clé (comme on pourrait s’y attendre), donc logiquement démarrer une itération à une clé donnée c’est O(log(n)), tu trouves la clé puis tu continues à traverser normalement.
 
Si par “bornes” tu veux dire que vous utilisez `gt=user_` pour filtrer sur les utilisateurs, bah sur la première page tu fais ça, puis disons que le dernier utilisateur c’est `user_jeanpaul` being pour la page suivant tu mets `gt=user_jeanpaul`, comme ça tu démarres de là au lieu de devoir retraverser toute la première page dont t’as plus rien à foutre.

Mais sauf si les objets font 15k, tu peux juste gzipper et tu vas probablement avoir chiée de redondance dans tes collections quand tu renvoies des listes d’objets.

Oui je peux borner comme ça mais du coup ça me solutionne pas facilement le fait d'avoir le count total (qui se recup facilement si tu parcours tous les objets).

Bref, je vais voir. Merci.

Recup tous les utilisateurs c'est environ 140 MB actuellement et c'est pas le pire. D'où ma recherche de solution. Soit on pagine, soit on allège les objets, soit on gzip, soit on fait les trois.

Oui non c’est pas une suggestion pour le comptage, c’est pour la pagination
 

Faut clairement les 3.

Comment tu vends l'upgrade vers la prochaine version majeure si tu règles le problème entièrement d'un seul coup ?    
C'est un coup à se retrouver avec un stock de cd-rom sur les bras...

Sans blockchain c'est pas sûr que ça suffise.

 
La blockchain c’est l’inverse, c’est pour que ça aille moins vite.

 
Dans un monde idéal oui. Là c'est pour deux admins qui vont DE TEMPS EN TEMPS voir ces pages. C'est pas qu'on veut pas les aider mais disons qu'on cherche le meilleur moyen qui implique peu de modif de code.

 
Et tu peux pas leur faire un rapport journalier?

 
Non. C'est une page admin qui affiche tous les élements dont on a besoin pour ensuite ajouter des filtres etc.

Faudrait avoir un archi chez vous, car ça me semble bancal de tout gérer côté front (wtf)
Tu dis que les filtres côté front c'est rapide mais à mon avis ça irait + vite même avec un appel réseau (et vu les 30 secondes de ton loading initial actuel, t'as largement de quoi amortir le délai total d'un scénario d'utilisation classique).
Je vois pas pourquoi ça prendrait 3/4 secondes avec du filtrage côté serveur.
Et pour voir ce que vos admins font, vous n'avez pas de métriques d'utilisation de vos applis ?
 
Plam : c'est quoi ce bordel ?