vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-02-06T12:01:30+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/5243Speed up users page2024-02-06T12:01:30+01:00CHESNIN ClementSpeed up users pagePour le moment, l'ouverture de la page users sur app met 30s...
Quelques idées :
- voir si on peut optimiser les requêtes sb
- paginer la réponse (cf ce qu'on a fait pour les sample_sets)
- avoir un chargement dynamique des infos sur les...Pour le moment, l'ouverture de la page users sur app met 30s...
Quelques idées :
- voir si on peut optimiser les requêtes sb
- paginer la réponse (cf ce qu'on a fait pour les sample_sets)
- avoir un chargement dynamique des infos sur les users
- ...Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5160Py4Web: changement de comportement de VidjilAuth2023-08-31T16:09:25+02:00Mikaël SalsonPy4Web: changement de comportement de VidjilAuthOn a vu avec @fthonier que VidjilAuth est désormais défini une fois pour toute dans Py4Web, alors qu'auparavant il était redéfini à chaque requête.
On stockait dans VidjilAuth des permissions pour ne pas avoir à les recharger plein de f...On a vu avec @fthonier que VidjilAuth est désormais défini une fois pour toute dans Py4Web, alors qu'auparavant il était redéfini à chaque requête.
On stockait dans VidjilAuth des permissions pour ne pas avoir à les recharger plein de fois lors d'un même appel à un contrôleur. Ce n'est plus possible puisque VidjilAuth sert désormais à la fois pour tous les utilisateurs.
Il faudra donc virer `self.permissions` dans `VidjilAuth` et voir l'impact en ressources.https://gitlab.inria.fr/vidjil/vidjil/-/issues/5109get reads; use zgrep before to minimize process2023-11-09T11:18:46+01:00Thonier Florianget reads; use zgrep before to minimize processLancé d'abord un `zgrep -B1 -A2 --no-group-separator $seq` (et son reverse) avant de faire le vidjil-algo permettrait de réduire le temps de processus.
@mikael-s : "Voir aussi si on spécifie le locus"Lancé d'abord un `zgrep -B1 -A2 --no-group-separator $seq` (et son reverse) avant de faire le vidjil-algo permettrait de réduire le temps de processus.
@mikael-s : "Voir aussi si on spécifie le locus"https://gitlab.inria.fr/vidjil/vidjil/-/issues/4831Page patients2021-10-01T07:46:44+02:00Mathieu GiraudPage patients
@duez: Trop d'infos sur la page principale ?
- enlever taille des samples ? (mais on veut garder le nb de samples par set)
- rajouter une entrée pour tri ordre #4573 ?
@duez: Trop d'infos sur la page principale ?
- enlever taille des samples ? (mais on veut garder le nb de samples par set)
- rajouter une entrée pour tri ordre #4573 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4559Simplifier voir limiter/interdire la requête SampleSet pour les admins ?2021-02-09T16:11:39+01:00Mathieu GiraudSimplifier voir limiter/interdire la requête SampleSet pour les admins ?Ne bloque pas !832.
Depuis https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/832#note_405028 :
> en tant qu'admin : 11s (\~1,4s sur app actuellement)
Comme en tant qu'admin on arrive souvent sur cette page, ne pourrait-on pas avo...Ne bloque pas !832.
Depuis https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/832#note_405028 :
> en tant qu'admin : 11s (\~1,4s sur app actuellement)
Comme en tant qu'admin on arrive souvent sur cette page, ne pourrait-on pas avoir une requête simplifiée pour les admins... voire pas de requête du tout ?
Ou... faire avec !837 que "My Account" soit la page par défaut (à voir combien de temps met la requête...)
Si un admin veut vraiment aller voir des données, il peut faire un impersonnate ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4533compare & qc-stats depuis la page principale : un clic lorsque beaucoup de pa...2024-02-21T14:12:33+01:00Mathieu Giraudcompare & qc-stats depuis la page principale : un clic lorsque beaucoup de patients sont accessibles ne devrait pas bloquer le serveurAppuyer sur le bouton "stats" avec beaucoup de sets peut mettre à plat un serveur. Les admins ont beaucoup de sets, mais certains usagers aussi.
Si #3530 n'est vraiment pas un souci, rajouter tout de même une limite dure (50 ? 100 ? 500...Appuyer sur le bouton "stats" avec beaucoup de sets peut mettre à plat un serveur. Les admins ont beaucoup de sets, mais certains usagers aussi.
Si #3530 n'est vraiment pas un souci, rajouter tout de même une limite dure (50 ? 100 ? 500 dernier sets ?) pour qu'un simple clic ne bloque pas toutWeb 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4348Le web2py trackè_changes peut-il dégrader les performances en prod ?2020-06-15T18:14:45+02:00Mathieu GiraudLe web2py trackè_changes peut-il dégrader les performances en prod ?
dans `models/db.py`: `from gluon.custom_import import track_changes; track_changes(True)`
introduit par de7ce3c7e
@mikael-s : "On a aussi, dans `docker/vidjil-server/conf/uwsgi.ini`
```
touch-reload = /usr/share/vidjil/server/web2py/...
dans `models/db.py`: `from gluon.custom_import import track_changes; track_changes(True)`
introduit par de7ce3c7e
@mikael-s : "On a aussi, dans `docker/vidjil-server/conf/uwsgi.ini`
```
touch-reload = /usr/share/vidjil/server/web2py/applications/vidjil/modules/defs.py
```
@duez : "sur doc de web2py, disent que pas de soucis"https://gitlab.inria.fr/vidjil/vidjil/-/issues/4037Savoir quelle est la charge du serveur2022-05-12T11:42:48+02:00Mathieu GiraudSavoir quelle est la charge du serveurSuggéré par @Anne : ses analyses qui prennent quelques minutes. Mais, selon la charge du serveur, ses jobs peuvent attendre de quasiment rien à... plusieurs heures. Il serait intéressant pour les utilisateurs de savoir par exemple combie...Suggéré par @Anne : ses analyses qui prennent quelques minutes. Mais, selon la charge du serveur, ses jobs peuvent attendre de quasiment rien à... plusieurs heures. Il serait intéressant pour les utilisateurs de savoir par exemple combien de jobs sont en attente.
cc @duez https://gitlab.inria.fr/vidjil/vidjil/-/issues/3974Indexation de la base de données2019-08-23T14:53:06+02:00Mathieu GiraudIndexation de la base de donnéesEst-ce que cela vaudrait le coup d'utiliser quelque chose type Lucene (ou Solr, ou ElasticSearch) pour indexer la DB, que ce soit pour améliorer #2295 ou pour d'autres types de requêtes ?Est-ce que cela vaudrait le coup d'utiliser quelque chose type Lucene (ou Solr, ou ElasticSearch) pour indexer la DB, que ce soit pour améliorer #2295 ou pour d'autres types de requêtes ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3947Proposer le mécanisme d'autocomplétion dans la recherche des sample sets2020-11-20T11:46:25+01:00Mikaël SalsonProposer le mécanisme d'autocomplétion dans la recherche des sample setsLe mécanisme d'autocomplétion utilisé lorsqu'on ajoute de nouveaux samples (pour l'attribuer à un sample set) devrait être réutilisé pour permettre la recherche rapide d'un patient/run/set.
Dans la barre de recherche, on propose l'autoc...Le mécanisme d'autocomplétion utilisé lorsqu'on ajoute de nouveaux samples (pour l'attribuer à un sample set) devrait être réutilisé pour permettre la recherche rapide d'un patient/run/set.
Dans la barre de recherche, on propose l'autocomplétion, si l'utilisatrice trouve l'entrée qui l'intéresse, elle la sélectionne et est redirigée vers cette entrée. Sinon il suffit de valider la recherche et cela lance la recherche normale.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3447Tests fonctionnels / d'intégration de performance/saturation2018-09-04T09:34:20+02:00Mathieu GiraudTests fonctionnels / d'intégration de performance/saturationDepuis https://gitlab.inria.fr/vidjil/vidjil/issues/2323#note_114506 :
> Je ne suis pas encore complètement convaincu que le [Chaos Monkey](https://en.wikipedia.org/wiki/Chaos_Monkey) s'applique à nous... :-)
Plus généralement, et déjà...Depuis https://gitlab.inria.fr/vidjil/vidjil/issues/2323#note_114506 :
> Je ne suis pas encore complètement convaincu que le [Chaos Monkey](https://en.wikipedia.org/wiki/Chaos_Monkey) s'applique à nous... :-)
Plus généralement, et déjà sur l'architecture de test (même si ensuite #2323 pourrait se poser), faudrait-il avoir des tests de performance / saturation ?
Par exemple 3, 5, 10 pseudo-clients qui veulent en même temps ou presque se connecter et faire des choses de #3401, peut-être en lançant chacun plusieurs runs. Même si c'est normal que le serveur ralentisse, on devrait en théorie ne rien perdre (ou avoir des messages d'erreurs pertinents à certains moments).https://gitlab.inria.fr/vidjil/vidjil/-/issues/3375La page des logs est trop longue à charger : la paginer2019-02-28T12:39:28+01:00Mikaël SalsonLa page des logs est trop longue à charger : la paginer@RyanHerb le mécanisme utilisé pour la liste des sample sets est-il généralisable facilement ?
En lien avec #3374@RyanHerb le mécanisme utilisé pour la liste des sample sets est-il généralisable facilement ?
En lien avec #3374https://gitlab.inria.fr/vidjil/vidjil/-/issues/3236fuse.py / ijson: merge de gros fichiers en O(top) en mémoire2018-07-23T13:53:48+02:00Mathieu Giraudfuse.py / ijson: merge de gros fichiers en O(top) en mémoireAprès #3235, on pourra implémenter fuse en deux passes (quand besoin pour des gros fichiers):
- une passe lire tous les top 100 de tous les points
- on fusionne ces tops
- une autre passe pour récupérer/fusionner tous les clones de c...Après #3235, on pourra implémenter fuse en deux passes (quand besoin pour des gros fichiers):
- une passe lire tous les top 100 de tous les points
- on fusionne ces tops
- une autre passe pour récupérer/fusionner tous les clones de cette liste, encore dans tous les points
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3235Chargement partiel de .vidjil avec ijson2018-08-07T10:31:05+02:00Mathieu GiraudChargement partiel de .vidjil avec ijsonDiscuté ensemble : plus raffiné que #3234, charger un gros fichier de clones, mais ne garder que les clones
- qui ont `top` en-dessous de 100 (note: il peut y en avoir plus/moins que 100).
Cas d'usage (pour plus tard) : #3236
Voir...Discuté ensemble : plus raffiné que #3234, charger un gros fichier de clones, mais ne garder que les clones
- qui ont `top` en-dessous de 100 (note: il peut y en avoir plus/moins que 100).
Cas d'usage (pour plus tard) : #3236
Voir #2240.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3185Requêtes SQL imbriquées2018-04-17T13:36:59+02:00Mathieu GiraudRequêtes SQL imbriquéesDepuis https://gitlab.inria.fr/vidjil/vidjil/issues/3169#note_85381 :
> @mikael-s : Il se trouve que le `IN ( SELECT ...` ne semble pas être la solution recommandée. Il vaut mieux préférer des `INNER JOIN` : https://dba.stackexchange.co...Depuis https://gitlab.inria.fr/vidjil/vidjil/issues/3169#note_85381 :
> @mikael-s : Il se trouve que le `IN ( SELECT ...` ne semble pas être la solution recommandée. Il vaut mieux préférer des `INNER JOIN` : https://dba.stackexchange.com/questions/14565/mysql-subquery-slows-down-drastically-but-they-work-fine-independently
Y aurait-il d'autres requêtes de ce type que !189 dans notre code ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3181Lancer CloneDB depuis fuse.py ou en offline2019-02-14T18:19:54+01:00Mathieu GiraudLancer CloneDB depuis fuse.py ou en offlineExtrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #...Extrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #1744 (qui pourrait être fait séparément).
À voir aussi comment on indique que cela a été fait "à une certain moment" (et donc, si on revient plus tard, pas forcément à jour). Et/ou relancer périodiquement CloneDB sur le serveur ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3173Pagination par défaut de la reqûete patients2020-06-18T16:52:44+02:00Mathieu GiraudPagination par défaut de la reqûete patientsDepuis !186 :
> > @magiraud: En voyant les différents commits où on a "oublié" d'appeler la pagination, ne pourrait-on pas faire que `'page': 0` soit la valeur par défaut lorsqu'on ne met rien (et un `'page': None` ferait une requête no...Depuis !186 :
> > @magiraud: En voyant les différents commits où on a "oublié" d'appeler la pagination, ne pourrait-on pas faire que `'page': 0` soit la valeur par défaut lorsqu'on ne met rien (et un `'page': None` ferait une requête non paginée) ?
> @mikael-s : si, c'est ce que je me suis dit aussi, mais je ne suis pas sûr des endroits à modifierhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3110ajouter des exceptions aux timeout2018-03-28T14:56:46+02:00Thonier Florianajouter des exceptions aux timeoutDepuis quelques jours, j'ai un utilisateur qui lance des jobs sur des gros fichiers de RNAseq (~4GO). Ses jobs finissent toujours en timeout (preprocess coupé à 4h, vidjil à 2h).
Est-il possible d'assigner des jobs lourds à un worker sp...Depuis quelques jours, j'ai un utilisateur qui lance des jobs sur des gros fichiers de RNAseq (~4GO). Ses jobs finissent toujours en timeout (preprocess coupé à 4h, vidjil à 2h).
Est-il possible d'assigner des jobs lourds à un worker spécifique pour lequel le timeout serait bien plus élevé, ou bien d'assigner dynamiquement un timeout plus long quand on peux prévoir qu'un tel job est en cours ?
Tel que je le vois, il faudrait être capable de détecter avant son lancement si un job risque le timeout :
* Poids des fichiers en entrée (automatique pour tous) ?
* Déclaration de l'utilisateur dans une liste blanche ?
* une case à cocher par l'utilisateur pour signifier qu'un fichier risque d'être lourd (j'y crois pas trop). Cependant, on pourrait alors avoir une liste des jobs pour lesquels nous validons les lancements avec exceptions.
Ensuite, il ne faut pas non plus bloquer le serveur :
* n'autoriser qu'un seul jobs sans timeout, 2 max ?
Que faire d'un job long qui finalement dépasserait le timeout sans être prévu:
* si le seul en cours, le laisser et le passer en exception à la volée (laisserai 2 ou 3 workers pour les jobs plus rapide) ?
* si déjà d'autres jobs en exception il faudrait le tuer et le relancer automatiquement dès qu'un place en exception de timeout se libère ?
Voilà, beaucoup de questions. Je ne sais pas si c'est aisé ou non, et ça demande peut-être beaucoup mise au point.
cc @magiraud @mikael-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3069Empecher la modifications d'un patient lorsque des analyses sont en attente2019-03-15T09:50:50+01:00Thonier FlorianEmpecher la modifications d'un patient lorsque des analyses sont en attenteUn utilisateur m'a fait remonté des délais récurrents dans l'analyses de leur données.
Après avoir regarder plus en détail, je m'aperçois qu'ils lancent des jobs lourds (sur de gros fichiers) et si rien ne bouge au bout de 2h, ils recha...Un utilisateur m'a fait remonté des délais récurrents dans l'analyses de leur données.
Après avoir regarder plus en détail, je m'aperçois qu'ils lancent des jobs lourds (sur de gros fichiers) et si rien ne bouge au bout de 2h, ils rechargent toutes les données et relances , pensant que notre serveur est dans les choux.
Je leur ai donc expliqué que ce comportement entraîne une surcharge du serveur et que ça n'améliore pas la situation. Cependant, je n'ai pas de possibilité de leur montrer la charge serveur pour le moment. (cf #2945).
En attendant, peut-on bloquer une nouvelle demande d'analyses, le changement des données fasta voir la déétion d'un patient si il en a déjà une en attente ? Je pense que nous avions déjà fait ce qu'il fallait pour les analyses, mais comme ici les données sont rechargées (et le patient précédent supprimé puis recrée dans la foulée) je ne pense pas que notre filtre fonctionne.
En tous cas l'idée ici est d’empêcher la délétion/création de patients lorsque les gens ont l’impression que rien ne bouge côté frontend. Cela peux passer par un simple message d'alerte lorsqu'il tente de supprimer un patient (Une analyse est en attente sur ce patient. Êtes-vous certain de vouloir le supprimé ? ).
On pourrait aussi signaler un ordre dans la file d'attente du scheduler pour qu'ils puissent voir que ça avance.
Vous en pensez-quoi ? Vous avez des propositions la dessus ?
@magiraud @mikael-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2957Avoir un mysql.log2017-12-19T20:28:42+01:00Mathieu GiraudAvoir un mysql.logSera utile en post-mortem, mais aussi en ~"server-speed".
https://stackoverflow.com/questions/650238/how-to-show-the-last-queries-executed-on-mysql
https://stackoverflow.com/questions/303994/log-all-queries-in-mysqlSera utile en post-mortem, mais aussi en ~"server-speed".
https://stackoverflow.com/questions/650238/how-to-show-the-last-queries-executed-on-mysql
https://stackoverflow.com/questions/303994/log-all-queries-in-mysql