Discuss streaming

content/blog/2024-predictability-and-correctness/index.md

@@ -20,12 +20,24 @@ full mailbox in memory. It's concerning as the mail server will be used by multi
 so we don't want a user allocating all the memory. In other words, we want to have a per-user resource usage that remain as stable as possible.
 These ideas are developed more in depth in the Amazon article [Reliability & Constant Work](https://aws.amazon.com/fr/builders-library/reliability-and-constant-work/).
 
-
+As part of the conclusion, we identified that streaming emails content would solve our problem.
+In practice, I rewrote the relevant part of the code to return a `futures::stream::Stream` instead of a `Vec`.
+Then, for both requests, I re-run the same benchmark to have a before/after comparison for both commands.
+Next, the first pictures is for FETCH FULL, the second one for SEARCH TEXT.
 
 ![Fetch resource usage for Aerograme 0.2.1 & 0.2.2](fetch-full.png)
 
 ![Search resource usage for Aerograme 0.2.1 & 0.2.2](search-full.png)
 
+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,
+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.
+
+
 *TODO AWS SDK*
 
 ## Users feedbacks