vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-04-13T12:36:06+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2494La liste des fichiers pour un compare patients/sets met trop de temps à s'aff...2018-04-13T12:36:06+02:00Ryan HerbertLa liste des fichiers pour un compare patients/sets met trop de temps à s'afficher.Lorsqu'on veut faire un compare patients/sets en tant qu'admin, il y a vraiment beaucoup de données à traiter (et actuellement prend environ 60s).
Il est donc très facile de saturer les threads du serveur car on a l'impression que rien n...Lorsqu'on veut faire un compare patients/sets en tant qu'admin, il y a vraiment beaucoup de données à traiter (et actuellement prend environ 60s).
Il est donc très facile de saturer les threads du serveur car on a l'impression que rien ne se passe alors que le thread lui n'est pas libéré au bout de 10s comme l'est le browser.
cc @flothoniRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2479Mettre un verrou tant que des fichiers sont en cours de run/upload pour ne pa...2021-11-26T11:38:50+01:00Mikaël SalsonMettre un verrou tant que des fichiers sont en cours de run/upload pour ne pas lancer fuse ?Comme l'illustre #2472 : on lance beaucoup fuse.py, et inutilement.
@RyanHerb se demande si on ne pourrait pas poser un verrou pour ne pas lancer fuse tant que des fichiers sont encore en train d'être analysés (voire en cours d'upload)....Comme l'illustre #2472 : on lance beaucoup fuse.py, et inutilement.
@RyanHerb se demande si on ne pourrait pas poser un verrou pour ne pas lancer fuse tant que des fichiers sont encore en train d'être analysés (voire en cours d'upload). Cela permettrait de ne lancer qu'un seul fuse, une bonne fois pour toute plutôt que de lancer un fuse à la suite de chaque lancement (c'est aussi une réponse possible à #2011).
Inconvénient : on ne peut pas commencer à voir des résultats partiels.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2747Organiser les sample_sets par projet pour accélérer les requêtes2020-09-23T17:32:47+02:00Ryan HerbertOrganiser les sample_sets par projet pour accélérer les requêtesActuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la no...Actuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la notion de hierarchie de groupes, on se retrouve avec des requêtes plutôt complexes pour déterminer si l'utilisateur a accès à un élément.
> Il faut chercher si l'utilisateur appartient à un groupe qui a la permission `access` ou à un groupe dont le parent a la permission `access`
Donc lister les sets d'un type particulier auxquels un utilisateur a accès revient au code suivant:
``` python
def vidjil_accessible_query(self, name, table, user_id=None):
"""
Returns a query with all accessible records for user_id or
the current logged in user
this method does not work on GAE because uses JOIN and IN
This is an adaptation of accessible_query that better fits
the current auth system with group associations
:param: name: The name of the query (eg. 'read')
:param: table: The table for accessibility
:param: user_id: ID of the user
Example:
Use as::
db(auth.vidjil_accessible_query('read', db.mytable, 1)).select(db.mytable.ALL)
"""
if not user_id:
user_id = self.user_id
db = self.db
if isinstance(table, str) and table in self.db.tables():
table = self.db[table]
elif isinstance(table, (Set, Query)):
# experimental: build a chained query for all tables
if isinstance(table, Set):
cquery = table.query
else:
cquery = table
tablenames = db._adapter.tables(cquery)
for tablename in tablenames:
cquery &= self.vidjil_accessible_query(name, tablename,
user_id=user_id)
return cquery
if not isinstance(table, str) and\
self.has_permission(name, table, 0, user_id):
return table.id > 0
membership = self.table_membership()
permission = self.table_permission()
perm_groups = self.get_permission_groups(name, user_id)
query = (table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)) |
table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == db.group_assoc.second_group_id) &
(db.group_assoc.first_group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)))
if self.settings.everybody_group_id:
query |= table.id.belongs(
db(permission.group_id == self.settings.everybody_group_id)
(permission.name == name)
(permission.table_name == table)
._select(permission.record_id))
return query
```
Ce qui produit la requête SQL suivante:
```sql
SELECT `patient`.`id`, `patient`.`first_name`, `patient`.`last_name`, `patient`.`birth`, `patient`.`info`, `patient`.`id_label`, `patient`.`creator`, `patient`.`sample_set_id` FROM `patient`
WHERE (
(`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`
WHERE (
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
))
)
OR (`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`, `group_assoc`
WHERE (
(
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `group_assoc`.`second_group_id`)
) AND (`group_assoc`.`first_group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
)
)
));
```
On a donc une requête composée de deux sous-requêtes chacune contenant un `IN` aussi long que le nombre de groupes auxquels l'utilisateur appartient, l'une avec un `join` et l'autre avec deux `join` (ici les joins sont implicites).
Et les autres primitives du model `VidjilAuth` sont composées de plusieurs `joins` et souvent plusieurs requêtes.
Avec une organisation par projet (avec une nouvelle table, et une clef étrangère dans la table `sample_set`) on pourrait se débarrasser complètement de la permission `access`, et par la même occasion on laisse tomber cette anbiguïté qu'on a avec les groupes de projets/hôpitaux et les groupes de rôles/permissions.
La requête "patient" deviendrait:
```python
def get_project_sets(type, project_id):
return db(
(db.sample_set.project_id == project_id) &
(db.sample_set.sample_type == type) &
(db[type].sample_set_id == db.sample_set.id)
).select(db[type].*)
```
Avec auparavant avoir vérifié que l'utilisateur ait accès à un groupe/rôle apparetenant au projet (2 joins sur relativement peu de données). Ce qui nous donne un total de 4 joins sur deux requêtes par rapport à un total de 3 joins répartis sur 3 requêtes, et on perd les `IN`
Il y a plusieurs autres endroits où des gains de jointures ou de requêtes seraient aussi envisageables (`get_permission(...)`, `can_view_sample_set(...)`, ...).
Ainsi que des endroits où les requêtes seraient plus complexes ?
J'aurais tendance à vouloir limiter les associations de samples à des sets du même projet car celà simplifierai certaines requêtes, comme l'autocompletiondes tags, et ainsi que celle des samples_sets à l'ajout d'un sample.
Ca éliminerait également l'impacte des grosses requêtes auxquelles nous les admins soumettons la BDD. Et donc on n'occuperait plus un (voire plus) de processus uwsgi pendant des durées prolongées (par exemple, plus d'une minute pour un compare patient).
Cette moification demanderait beaucoup de travail, donc ça ne serait pas pour tout de suite, mais je pense que celà réduirait le nombre de timeouts subis par nos utilisateurs. Celà demanderait peut-être plus d'analyse, de tests et de benchmarks.https://gitlab.inria.fr/vidjil/vidjil/-/issues/1446Priorités sur le serveur et 'Could not connect to database'2017-11-23T00:07:40+01:00Vidjil TeamPriorités sur le serveur et 'Could not connect to database'Comment faire pour que le côté database / browser fonctionne toujours bien, même quand c'est chargé ?
Faudrait-il mettre des priorités aux différentes tâches ?
Sans aller jusqu'à -20, mettre quelque chose
- pour les workers (avec le ser...Comment faire pour que le côté database / browser fonctionne toujours bien, même quand c'est chargé ?
Faudrait-il mettre des priorités aux différentes tâches ?
Sans aller jusqu'à -20, mettre quelque chose
- pour les workers (avec le serveur de dev, il peut y en avoir plus que 3 qui tournent au total)
- pour d'autre choses ?
https://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-mysqlhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/1507Mise en cache des requêtes, séparation requêtes affichage / droits2019-12-06T15:30:39+01:00Vidjil TeamMise en cache des requêtes, séparation requêtes affichage / droitsOptimiser les requêtes c'est bien, mais plus simplement est-ce que les mettre en cache ne suffirait pas à obtenir un gros gain de performance ?
cf. http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Caching-sele...Optimiser les requêtes c'est bien, mais plus simplement est-ce que les mettre en cache ne suffirait pas à obtenir un gros gain de performance ?
cf. http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Caching-selects
***
Intéressant. à voir comment on combine cela avec des modifs de la DB : un flag provenant du .js qui dit si l'utilisateur a modifié des choses ?
et peut-on utiliser `cacheable=True` indépendamment de cache, et est-ce que cela va plus vite ? Sur la liste des patients, on ne se sert des Row que comme affichage, pas comme modif.
***
ping
***
@Duez @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1719Analyse en profondeur du comportement du DAL web2py2022-06-20T15:47:17+02:00Vidjil TeamAnalyse en profondeur du comportement du DAL web2pyL'idée est de pouvoir se rendre compte de tout ce qu'il se passe au niveau du DAL lorsqu'une requête est lancée. Il semble y avoir des requêtes qui sont parfois lentes alors nous aimerions savoir si il s'agit d'un problème au niveau du D...L'idée est de pouvoir se rendre compte de tout ce qu'il se passe au niveau du DAL lorsqu'une requête est lancée. Il semble y avoir des requêtes qui sont parfois lentes alors nous aimerions savoir si il s'agit d'un problème au niveau du DAL ou non.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1818Priorités pour les tâches2022-03-09T11:24:49+01:00Vidjil TeamPriorités pour les tâchesLes fichiers de Sarah (4 Go RNA Seq) demandent souvent autour de 2h chacun (x 2, R1+R2)
J’ai par exemple relancé il y a quelques jours 16 jobs… et cela fait donc 32h / 3workers = 11 heures.
C’est dommage de bloquer tout le monde pendant ...Les fichiers de Sarah (4 Go RNA Seq) demandent souvent autour de 2h chacun (x 2, R1+R2)
J’ai par exemple relancé il y a quelques jours 16 jobs… et cela fait donc 32h / 3workers = 11 heures.
C’est dommage de bloquer tout le monde pendant ce temps.
Idéalement, il faudrait une priorité inverse au temps attendu de calcul (mais j’ai l’impression qu’il n’y a pas de priorités explicites dans web2py…)
***
@nobodyhttps://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/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/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/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/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/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.04