Reorder Email Handlers based on traffic pattern
What does this MR do?
This MR changes the order of Email Handlers, as per the observed traffic patterns of incoming emails on GitLab.com in the last 90 days, so as to optimize for the best-case scenario.
Background
GitLab handles multiple types of incoming emails - ie, users can send an email to create an issue, a merge request, unsubscribe from a disucssion etc.
Each type of this email are handled by a separate email handler: The current list can be seen here: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/email/handler.rb#L10
When a email arrives to our servers, it needs to be parsed, so that the appropriate handler can process the email. To make this easier, each email handler does regex matching on the to address of the email. This is done using the can_handle? method in each email handler. An example
Details
The ordering of handlers become important because, each time an email arrives, all the handlers are checked sequentially to figure out which handler can handle the email that arrived, by calling can_handle? on each of these handlers.
This is done here
Traffic pattern on .com
Based on my (very limited) understanding of checking our metrics, I tried to figure out the traffic pattern of the emails we got on .com for the last 90 days. (We already track the metrics around the kinds of emails received. An example)
Based on the traffic pattern observed here, I tried to reorder the email handlers, so that we optimize for the most frequent kind of emails first.
As an example, from the graph it is clear that we hardly get any Service desk emails, but it is still in the top of our list of handlers.
Benchmarking
I also tried to do some benchmarking to see how the new and old order compares for each kind of email.
This shows(?) that for a frequently received email, like for creating a new note via email, the appropriate handler can be figured out 3x faster than before. (however, the whole parsing process happens inside a background job EmailReceiverWorker, so this improvement would be hard to observe. )
Screenshots
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team