Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

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
  [email protected]
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol