On Fri, Aug 25, 2017, at 11:59, Evgeny Khramtsov wrote: > Maybe a significant reduction in RTT, but this is a little part of the > whole session traffic (the large part of which are pointless presences > and some PEP). So you will connect in 1 second instead of 2. No? Then > do you have benchmarking?
This is not about reducing bandwidth costs or overall traffic, it's about reducing startup latency. A "connection" (defined by the time a user clicks on an icon on their desktop or wherever to the time they can send a message) that takes longer than 100ms is noticeable to the user. The longer your connection takes after 100ms, the more likely it is that users will close your application. It is *more* important to make connection times faster than it is to make any other part of the stream fast, because this is the most noticeable place where things might be slow. Unfortunately, I no longer work somewhere that makes a large commercial chat product, so I don't have access to our data, but we had quite a lot of it that showed that the first few seconds of using an app are the time when a user makes a judgement about the application. There was a direct correlation between increased startup times and users hitting the close button. Similarly, as we reduced startup times our NPS went up by several points compared to users that did not have the version with reduced startup times. It's important. FWIW, an implementation I attempted also uses a state machine, and I found it trivial to add support for this profile after already having an implementation of the RFC 6120 SASL profile. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
