97 lines
4.3 KiB
Plaintext
97 lines
4.3 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Mon Mar 9 23:06:19 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <CAP1qinZucoU_5SPgKQB0cAu6iCRjhAzMwz7e38kgaKNuSzJ9wQ@mail.gmail.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com> <54FBF289.3010202@psaux.com>
|
|
<7164.1425831184@parc.com>
|
|
<1425907661.1215497.237833469.1EDA571D@webmail.messagingengine.com>
|
|
<6506.1425915329@parc.com> <B03452330F6149E180E449A493F28C2B@gmail.com>
|
|
<CAP1qinZdV1LW6XiWfqfk2A+TC6HsYsAWtT-KSffTNdOFqG_Tjw@mail.gmail.com>
|
|
<7782A916-12BB-488C-BD57-697FDB5D47E2@orthanc.ca>
|
|
<CAP1qinY-d_fpmfwJ=04GUZhAnkZpPxzwMGfVdn8--4z=tJT5_w@mail.gmail.com>
|
|
<0C18524D-28EC-4DF9-A888-678E7DD4E56A@orthanc.ca>
|
|
<CAP1qinZT9xkSAJ1QoaPK_S6V7PLw59i6J4MpyU3Sn7TMq0ZiTg@mail.gmail.com>
|
|
<C6695A01-E9CB-436D-8E28-55503224CAEC@getboxer.com>
|
|
<CAP1qinZucoU_5SPgKQB0cAu6iCRjhAzMwz7e38kgaKNuSzJ9wQ@mail.gmail.com>
|
|
Message-ID: <1425967579.1849414.238222149.3EB9CA30@webmail.messagingengine.com>
|
|
|
|
On Tue, Mar 10, 2015, at 04:55 PM, Imants Cekusins wrote:
|
|
> > Please go ahead.
|
|
>
|
|
> .. i.e., write an RFC up? are there no more qualified takers? I could
|
|
> write up a page to start the discussion - if anyone else were
|
|
> interested.
|
|
|
|
I don't think there are very many people who think that byte optimising
|
|
the mail flow is the thing that's holding email back. Particularly
|
|
without any science to back up the assertion.
|
|
|
|
> > chat messages are delivered faster than email most of the time
|
|
> > because the protocols were designed for real-time delivery, not
|
|
> > because the protocols are more efficient or easier to implement.
|
|
>
|
|
> Is this possible that if we eliminate all activities but those
|
|
> essential to byte delivery to the right place, email servers would do
|
|
> more in less time and message recipients would enjoy faster, more
|
|
> robust communication experience?
|
|
|
|
Well, obviously. It might be horrible to write code for, which is going
|
|
to mean nobody wants to do it. Or maybe not, depends what you're
|
|
actually proposing.
|
|
|
|
> a bad example: a compliant SMTP server sends all messages encoded
|
|
> entirely as quoted-printable and shortens line length to 40 chars. I
|
|
> am pretty certain that this would slow things down. In other words, it
|
|
> is possible to comply with the protocol yet require recipient server
|
|
> to do something that could be avoided.
|
|
>
|
|
> a better example: performance web servers are known to run faster when
|
|
> serving static content vs dynamic content (page generation per-
|
|
> request). Arguably, reducing or eliminating dynamic content processing
|
|
> of email messages by SMTP servers (current protocol) in favour of
|
|
> static message processing (no-frills byte delivery), performance SMTP
|
|
> servers would serve more concurrent requests.
|
|
|
|
Sure. Again, SMTP is not IMAP. And it's harder to replace, because
|
|
SMTP is server-to-server, whereas replacing the client/server protocol
|
|
only needs two instances to change, while replacing SMTP needs everyone
|
|
to change.
|
|
|
|
I'll tell you what does make things faster - and just about every server
|
|
does it. Calculate commonly requested items like ENVELOPE at
|
|
delivery/append time so that they can answer immediately when requested.
|
|
Or at least cache them the first time they are requested over IMAP so
|
|
they don't need to be calculated again. That's a real win.
|
|
|
|
I'll tell you what's faster than everything you've proposed. Not sending
|
|
the email in the first place!
|
|
|
|
> It is possible that SMTP server performance aligns with web server
|
|
> performance.
|
|
>
|
|
> why not?
|
|
|
|
Why? You're the one bringing unsupported assertions about how
|
|
performance works.
|
|
|
|
I can tell you that SELECT is expensive because it needs to create a COW
|
|
state. You can make it cheaper by pre-computing and only actually
|
|
storing any state when there is a second client that cares. We read the
|
|
whole bloody thing into memory with Cyrus, and we get acceptable
|
|
performance with a 1 million email mailbox. That's our design goal.
|
|
|
|
You know what our biggest headache is. Disk IO. Even with a ton of
|
|
SSD-based optimisation, things that reduce IO win every time over
|
|
reducing computation. lowercasing, decoding subjects - they don't
|
|
even show up in the heat map. It's not where time is going.
|
|
|
|
Bron.
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|