Excerpts from Joe Gordon's message of 2014-09-23 14:59:33 -0700: > On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <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. >
I definitely see where that may have subtly suggested the wrong thing, if indeed latency isn't a top concern. I think what it probably should say is something like this: "For an application like Marconi where there will be many repetitive, small requests, a lighter weight solution such as Falcon is preferred over Pecan." As in, we care about the cost of all those requests, not so much about the latency. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
