Deuxfleurs/aerogramme.deuxfleurs.fr
17
0
Fork 0
Code Pull requests Activity

formatting again

Browse source
This commit is contained in:
Quentin 2024-02-22 22:40:45 +01:00
parent 12a66ca062
commit 723cc14227
Signed by: quentin
GPG key ID: E9602264D639FF68
2 changed files with 18 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/blog/2024-fosdem/index.md
View file

@ -1,5 +1,5 @@
+++
title="Aerogramme in the modern email track at FOSDEM'24"
title="Aerogramme was at FOSDEM'24 modern email track"
date=2024-02-05
+++

28
content/blog/2024-predictability-and-correctness/index.md
View file

@ -3,7 +3,7 @@ title="Aerogramme 0.2.2: predictability & user testing"
date=2024-02-22
+++
*Let's review how Aerogramme performances became more predictable, why it's important, and showcase how user testing helped surface bugs.*
*Let's review how Aerogramme performances became more predictable, why it's important, and showcase how user testing helped surfacing bugs.*
<!-- more -->
@ -12,7 +12,7 @@ date=2024-02-22
This minor version of Aerogramme put the focus on 2 aspects of the software: predictable performances & collecting user feedbacks.
In the following, I describe both aspect in details.
## More predictable performances
## Improving predictability
In the previous blog post, we asked ourselves [Does Aerogramme use too much memory?](@/blog/2024-ram-usage-encryption-s3/index.md).
From the discussion, we surfaced it was not acceptable that some specific queries (FETCH FULL or SEARCH TEXT) where loading the
@ -31,8 +31,11 @@ Next, the first pictures is for FETCH FULL, the second one for SEARCH TEXT.
For both FETCH and SEARCH, the changes are identical. Before, the command was executed in ~5 seconds, allocated up to 300MB of RAM, and used up to 150% of CPU.
After, the command took ~30 to get executed, allocated up to 400MB of RAM, used up to 40MB of RAM, and used up to 80% of CPU sporadically.
Again, that's a positive thing, because now the memory consumption of Aerogramme is capped approximately by the biggest email accepted
by your system multiplied by a small constant. It has also other benefits: it prevents the file descriptor and other network ressource exhaustion,
Here is why it's a positive thing: now the memory consumption of Aerogramme is capped approximately by the biggest email accepted
by your system (25MB, multiplied by a small constant).
It has also other benefits: it prevents the file descriptor and other network ressource exhaustion,
and it adds fairness between users. Indeed, a user can't monopolize all the ressources of the servers (CPU, I/O, etc.) anymore, and thus multiple users
requests are thus intertwined by the server. And again, it leads to better predictability, as per-user requests completion will be less impacted
by other requests.
@ -54,9 +57,12 @@ Bumped to 64, will be watched in the next months.
*SASL Auth subtleties (reported by Nicolas)* - Authorization can be empty, or can be set to the same value as Authentication.
Second case not handled but required by Fair Email (thx Nicolas)
*Thunderbird Autodiscovery issues (reported by LX & Nicolas)* - K9 stable does not support `%EMAILLOCALPART%`.
*Thunderbird Autodiscovery issues (reported by LX & Nicolas)* - K9 stable does not support the `%EMAILLOCALPART%` placeholder.
K9 beta (6.714) does not support some values marked as obsolete in the `authentication` field: `plain` is not supported anymore, `password-cleartext` must be used instead.
Content-Type is important also, if a wrong one is sent, content is silently ignored by some clients.
Today autodiscovery is not part of Aerogramme, but due to these issues, and given that generating these files
on the fly could improve compatibility (email is passed a query parameter), so we could directly put the right username
instead of relying on placeholders that are not well supported.
*Broken LITERAL+ (reported by Maxime)* - It was not possible to copy more than one email at once to an Aerogramme mailbox.
It was due to the fact we were using an old version of imap-flow that was not correctly supporting LITERAL+.
@ -69,17 +75,17 @@ imap-flow supports IDLE out of the box, and thus Aerogramme code is now cleaner
Some others quality of life feedbacks not reported here have been made by MrFlos & Nicolas, thanks to all the people that took part in this debugging adventure.
## Conclusion: download and test the new version
## Conclusion: download and test this new version!
Do not get me wrong: Aerogramme is still not ready for prime time.
But by operating it for real, we start understanding better how it behaves, what are the rough edges, etc.
If you are interested in Aerogramme and put your personal touch to its development, it might be the good time to setup a new cluster, try it
to be ready for its public beta which will correspond to the moment where [Deuxfleurs](https://deuxfleurs.fr) will deploy it for their users.
But by operating it for real, we start understanding better how it behaves, what are the rough edges, what we want to improve, what we need, etc.
If you are interested in being an Aerogramme early adopter, it might be the good time to setup a test cluster, try Aerogramme,
share your use cases, in order to shape its future and be ready to go in production when its public beta will be announced.
In the mean time:
```
docker run -p 1143:1143 registry.deuxfleurs.org/aerogramme:0.2.2
```
[Download](/download/) - [Changelog](#)
[Download](/download/) - [Changelog](#) - [Getting started](/documentation/)