<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 2:40 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 09/23/2014 05:13 AM, Clint Byrum wrote:<br>
> Excerpts from Joe Gordon's message of 2014-09-22 19:04:03 -0700:<br>
<br>
</span>[snip]<br>
<span class=""><br>
>><br>
>> To me this is less about valid or invalid choices. The Zaqar team is<br>
>> comparing Zaqar to SQS, but after digging into the two of them, zaqar<br>
>> barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most<br>
>> important parts of SQS: the message will be delivered and will never be<br>
>> lost by SQS. Zaqar doesn't have the same scaling properties as SQS. Zaqar<br>
>> is aiming for low latency per message, SQS doesn't appear to be. So if<br>
>> Zaqar isn't SQS what is Zaqar and why should I use it?<br>
>><br>
><br>
> I have to agree. I'd like to see a simple, non-ordered, high latency,<br>
> high scale messaging service that can be used cheaply by cloud operators<br>
> and users. What I see instead is a very powerful, ordered, low latency,<br>
> medium scale messaging service that will likely cost a lot to scale out<br>
> to the thousands of users level.<br>
<br>
</span>I don't fully agree :D<br>
<br>
Let me break the above down into several points:<br>
<br>
* Zaqar team is comparing Zaqar to SQS: True, we're comparing to the<br>
*type* of service SQS is but not *all* the guarantees it gives. We're<br>
not working on an exact copy of the service but on a service capable of<br>
addressing the same use cases.<br>
<br>
* Zaqar is not guaranteeing reliability: This is not true. Yes, the<br>
current default write concern for the mongodb driver is `acknowledge`<br>
but that's a bug, not a feature [0] ;)<br>
<br>
* Zaqar doesn't have the same scaling properties as SQS: What are SQS<br>
scaling properties? We know they have a big user base, we know they have<br>
lots of connections, queues and what not but we don't have numbers to<br>
compare ourselves with.<br></blockquote><div> </div><div>Here is *a* number</div><div>30k messages per second on a single queue: <a href="http://java.dzone.com/articles/benchmarking-sqs">http://java.dzone.com/articles/benchmarking-sqs</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* Zaqar is aiming for low latency per message: This is not true and I'd<br>
be curious to know where did this come from. A couple of things to consider:<br>
<br>
        - First and foremost, low latency is a very relative measure  and it<br>
depends on each use-case.<br>
        - The benchmarks Kurt did were purely informative. I believe it's good<br>
to do them every once in a while but this doesn't mean the team is<br>
mainly focused on that.<br>
        - Not being focused on 'low-latency' does not mean the team will<br>
overlook performance.<br>
<br>
* Zaqar has FIFO and SQS doesn't: FIFO won't hurt *your use-case* if<br>
ordering is not a requirement but the lack of it does when ordering is a<br>
must.<br>
<br>
* Scaling out Zaqar will cost a lot: In terms of what? I'm pretty sure<br>
it's not for free but I'd like to understand better this point and<br>
figure out a way to improve it, if possible.<br>
<br>
* If Zaqar isn't SQS then what is it? Why should I use it?: I don't<br>
believe Zaqar is SQS as I don't believe nova is EC2. Do they share<br>
similar features and provide similar services? Yes, does that mean you<br>
can address similar use cases, hence a similar users? Yes.<br>
<br>
In addition to the above, I believe Zaqar is a simple service, easy to<br>
install and to interact with. From a user perspective the semantics are<br>
few and the concepts are neither new nor difficult to grasp. From an<br>
operators perspective, I don't believe it adds tons of complexity. It<br>
does require the operator to deploy a replicated storage environment but<br>
I believe all services require that.<br>
<br>
Cheers,<br>
Flavio<br>
<br>
P.S: Sorry for my late answer or lack of it. I lost *all* my emails<br>
yesterday and I'm working on recovering them.<br>
<br>
[0] <a href="https://bugs.launchpad.net/zaqar/+bug/1372335" target="_blank">https://bugs.launchpad.net/zaqar/+bug/1372335</a><br>
<span class=""><font color="#888888"><br>
--<br>
@flaper87<br>
Flavio Percoco<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>