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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
