17
0
Fork 0

reword concl

This commit is contained in:
Quentin 2024-02-18 11:23:02 +01:00
parent 4c836dbd10
commit d46fc4ee01
Signed by: quentin
GPG Key ID: E9602264D639FF68
1 changed files with 8 additions and 5 deletions

View File

@ -404,11 +404,14 @@ and we will take decisions about these points when it will be *really* required.
Back to the question "Does Aerogramme use too much RAM?",
it of course depends on the context.
For now, we want to start with 1 000 users, a 1k email INBOX, and a server of 8GB of RAM,
and Aerogramme seems ready for a first deployment in this context. Of course, in the long term,
we expect better ressource usages.
We want to start with 1 000 users, a 1k email INBOX, and a server of 8GB of RAM,
and Aerogramme seems ready for a first deployment in this context.
So for now, the answer could be "No, it does not".
Based on this benchmark, I identify 3 low-hanging fruits to improve performances that do not require major design changes: 1) in FETCH+SEARCH queries, handling emails one after another instead of loading the full mailbox in memory, 2) streaming FETCH responses instead of aggregating them in memory, and 3) reducing the RAM usage of a base user by tweaking its Garage connectors configuration
Of course, in the long term,
we expect better ressource usages, and I am convinced that for many people, today the answer is still "Yes, it does".
Based on this benchmark, I identified 3 low-hanging fruits to improve performances that do not require major design changes: 1) in FETCH+SEARCH queries, handling emails one after another instead of loading the full mailbox in memory, 2) streaming FETCH responses instead of aggregating them in memory, and 3) reducing the RAM usage of a base user by tweaking its Garage connectors configuration.
Collecting production data will then help priorize other, more ambitious works, on the authentication side,
on the idling side, and on the email streaming side.
on the idling side, and on the email streaming side.