Open Stack

On 23/09/14 17:59, Joe Gordon wrote:
>> >>  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 think we're talking about two different kinds of latency - latency for 
a message passing end-to-end through the system, and latency for a 
request to the API (which also affects throughput, and may not be a 
great choice of word).

By not caring about the former, which Zaqar and SQS don't, you can add 
guarantees like "never loses your message", which Zaqar and SQS have.

By not caring about the latter you can add a lot of cost to operating 
the service and... that's about it. (Which is why *both* Zaqar and 
clearly SQS *do* care about it.) There's really no upside to doing more 
work than you need to on every API request, of which there will be *a 
lot*. The latency trade-off here is against using the same framework 
as... a handful of other OpenStack projects - I can't even say all other 
OpenStack projects, since there are at least 2 or 3 frameworks in use 
out there already. IMHO the whole Falcon vs. Pecan thing is a storm in a 
teacup.

cheers,
Zane.