fix(perf): several backend performance improvements#1418
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Coverage Report for frontend
File CoverageNo changed files found. |
lwih
changed the title
| val actions = getEnvActionList(missionId = missionId) | ||
| // pass envActions when you don't want to refetch the whole mission | ||
| fun execute(missionId: Int, envActions: List<EnvActionEntity>? = null): List<MissionEnvActionEntity> { | ||
| val actions = envActions ?: getEnvMissionById2.execute(missionId = missionId)?.envActions ?: listOf() |
There was a problem hiding this comment.
En gros, pour chaque action, on allait chercher la mission pour avoir les actions alors qu'on les avait deja.
Autant réutiliser et fallback si necessaire
There was a problem hiding this comment.
les actions sont dans le cache, c'est pas in appel couteux.
En terme de logique pure, Pour une meilleure lisibilité, un useCase
Compute(missionId: Int, envActions: List)
Et dans le parent, if(envActions) compute(id, envActions) else getComputeEnvActionListByMissionId(id)
| val statusActions = navActions | ||
| .filterIsInstance<MissionNavActionEntity>() | ||
| .filter { it.actionType == ActionType.STATUS && it.startDateTimeUtc != null } | ||
|
|
||
| return (computedEnvActions + navActions + fishActions) | ||
| .sortedByDescending { it.startDateTimeUtc } | ||
| .map { action -> | ||
| // compute action status | ||
| action.status = getStatusForAction.execute(missionId = missionId, actionStartDateTimeUtc = action.startDateTimeUtc) | ||
| action.status = computeStatus(action.startDateTimeUtc, statusActions) |
There was a problem hiding this comment.
Ici pour le compute du status des actions, on a deja les actions donc autant les réutiliser alors qu'avant, on refaisait une db query à chaque fois
| @Entity | ||
| @EntityListeners(AuditingEntityListener::class) | ||
| @Table(name = "agent_2") | ||
| @BatchSize(size = 20) |
There was a problem hiding this comment.
BatchSize, ca te permet de grouper des queries.
Prends l'exemple de l'équipage PAM qui va return 16 crew. Au lieu de faire 16 queries, ca fait 1 seule batch query
| @OneToMany(fetch = FetchType.EAGER, cascade = [CascadeType.ALL], orphanRemoval = true) | ||
| @JoinColumn(name = "control_id") | ||
| @JsonIgnore | ||
| @BatchSize(size = 20) |
There was a problem hiding this comment.
pareil, batchSize ici aussi
Mais autant 20, ca se rapproche à peu près d'un crew de 16
mais ici, j'ai mis 20 alors qu'on fetch 4 controles, je sais pas torp. Au pire, on peut fine-tune plus tard
| val portsCache = buildCache(ports, ticker, TimeUnit.DAYS, 7) | ||
| val natinfsCache = buildCache(natinfs, ticker, TimeUnit.DAYS, 7) | ||
| val resourcesCache = buildCache(resources, ticker, TimeUnit.DAYS, 1) | ||
| val servicesCache = buildCache(services, ticker, TimeUnit.DAYS, 1) |
There was a problem hiding this comment.
Ca, je sais pas ce que t'en penses mais pour les data assez statiques de notre db, on peut aussi les cacher sur un temps relativement court, ca aide un peu
|
| val actions = getEnvActionList(missionId = missionId) | ||
| // pass envActions when you don't want to refetch the whole mission | ||
| fun execute(missionId: Int, envActions: List<EnvActionEntity>? = null): List<MissionEnvActionEntity> { | ||
| val actions = envActions ?: getEnvMissionById2.execute(missionId = missionId)?.envActions ?: listOf() |
There was a problem hiding this comment.
les actions sont dans le cache, c'est pas in appel couteux.
En terme de logique pure, Pour une meilleure lisibilité, un useCase
Compute(missionId: Int, envActions: List)
Et dans le parent, if(envActions) compute(id, envActions) else getComputeEnvActionListByMissionId(id)
lwih
force-pushed
the
validation-perf
branch
2 times, most recently
from
c586c35 to
e370abc
Compare
…f re-querying DB per action
+ AgentRoleModel to avoid N+1 crew queries
|
|
3 participants
… new validation