On 09/23/2014 11:59 PM, Joe Gordon wrote: > > > On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <zbit...@redhat.com > <mailto:zbit...@redhat.com>> wrote: > > On 22/09/14 22:04, Joe Gordon wrote: > > To me this is less about valid or invalid choices. The Zaqar team is > comparing Zaqar to SQS, but after digging into the two of them, > zaqar > barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most > important parts of SQS: the message will be delivered and will > never be > lost by SQS. > > > I agree that this is the most important feature. Happily, Flavio has > clarified this in his other thread[1]: > > *Zaqar's vision is to provide a cross-cloud interoperable, > fully-reliable messaging service at scale that is both, easy and not > invasive, for deployers and users.* > > ... > > Zaqar aims to be a fully-reliable service, therefore messages should > never be lost under any circumstances except for when the message's > expiration time (ttl) is reached > > So Zaqar _will_ guarantee reliable delivery. > > Zaqar doesn't have the same scaling properties as SQS. > > > This is true. (That's not to say it won't scale, but it doesn't > scale in exactly the same way that SQS does because it has a > different architecture.) > > It appears that the main reason for this is the ordering guarantee, > which was introduced in response to feedback from users. So this is > clearly a different design choice: SQS chose reliability plus > effectively infinite scalability, while Zaqar chose reliability plus > FIFO. It's not feasible to satisfy all three simultaneously, so the > options are: > > 1) Implement two separate modes and allow the user to decide > 2) Continue to choose FIFO over infinite scalability > 3) Drop FIFO and choose infinite scalability instead > > This is one of the key points on which we need to get buy-in from > the community on selecting one of these as the long-term strategy. > > Zaqar is aiming for low latency per message, SQS doesn't appear > to be. > > > I've seen no evidence that Zaqar is actually aiming for that. There > are waaay lower-latency ways to implement messaging if you don't > care about durability (you wouldn't do store-and-forward, for a > start). If you see a lot of talk about low latency, it's probably > because for a long time people insisted on comparing Zaqar to > RabbitMQ instead of SQS. > > > I thought this was why Zaqar uses Falcon and not Pecan/WSME? > > "For an application like Marconi where throughput and latency is of > paramount importance, I recommend Falcon over > Pecan." https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation#Recommendation > > Yes that statement mentions throughput as well, but it does mention > latency as well.
Right, but that doesn't make low-latency the main goal and as I've already said, the fact that latency is not the main goal doesn't mean the team will overlook it. > > > > (Let's also be careful not to talk about high latency as if it were > a virtue in itself; it's simply something we would happily trade off > for other properties. Zaqar _is_ making that trade-off.) > > So if Zaqar isn't SQS what is Zaqar and why should I use it? > > > If you are a small-to-medium user of an SQS-like service, Zaqar is > like SQS but better because not only does it never lose your > messages but they always arrive in order, and you have the option to > fan them out to multiple subscribers. If you are a very large user > along one particular dimension (I believe it's number of messages > delivered from a single queue, but probably Gordon will correct me > :D) then Zaqar may not _yet_ have a good story for you. > > cheers, > Zane. > > [1] > > http://lists.openstack.org/__pipermail/openstack-dev/2014-__September/046809.html > > <http://lists.openstack.org/pipermail/openstack-dev/2014-September/046809.html> > > > _________________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.__org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- @flaper87 Flavio Percoco _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
