...@gmail.com
Reply-To: OpenStack Dev openstack-dev@lists.openstack.org
Date: Friday, September 12, 2014 at 1:45 PM
To: OpenStack Dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)
If zaqar is like amazon SQS, then the latency for a single
@lists.openstack.org
Subject: Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)
Can you further quantify what you would consider too slow, is it 100ms too slow.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)
If zaqar is like amazon SQS, then the latency for a single message and the
throughput for a single tenant is not important. I wouldn't expect anyone who
has latency sensitive work
On 09/12/2014 01:36 AM, Boris Pavlovic wrote:
Kurt,
Speaking generally, I’d like to see the project bake this in over
time as
part of the CI process. It’s definitely useful information not just for
the developers but also for operators in terms of capacity planning.
On Tue, Sep 9, 2014 at 12:19 PM, Kurt Griffiths
kurt.griffi...@rackspace.com wrote:
Hi folks,
In this second round of performance testing, I benchmarked the new Redis
driver. I used the same setup and tests as in Round 1 to make it easier to
compare the two drivers. I did not test Redis in
On Wed, Sep 10, 2014 at 6:09 PM, Kurt Griffiths
kurt.griffi...@rackspace.com wrote:
On 9/10/14, 3:58 PM, Devananda van der Veen devananda@gmail.com
wrote:
I'm going to assume that, for these benchmarks, you configured all the
services optimally.
Sorry for any confusion; I am not trying to
On 9/11/14, 2:11 PM, Devananda van der Veen devananda@gmail.com
wrote:
OK - those resource usages sound better. At least you generated enough
load to saturate the uWSGI process CPU, which is a good point to look
at performance of the system.
At that peak, what was the:
- average msgs/sec
-
Kurt,
Speaking generally, I’d like to see the project bake this in over time as
part of the CI process. It’s definitely useful information not just for
the developers but also for operators in terms of capacity planning. We’ve
talked as a team about doing this with Rally (and in fact, some
On 09/09/2014 09:19 PM, Kurt Griffiths wrote:
Hi folks,
In this second round of performance testing, I benchmarked the new Redis
driver. I used the same setup and tests as in Round 1 to make it easier to
compare the two drivers. I did not test Redis in master-slave mode, but
that likely
Thanks! Looks good. Only thing I noticed was that footnotes were still
referenced, but did not appear at the bottom of the page.
On 9/10/14, 6:16 AM, Flavio Percoco fla...@redhat.com wrote:
I've collected the information from both performance tests and put it in
the project's wiki[0] Please,
On Tue, Sep 9, 2014 at 12:19 PM, Kurt Griffiths
kurt.griffi...@rackspace.com wrote:
Hi folks,
In this second round of performance testing, I benchmarked the new Redis
driver. I used the same setup and tests as in Round 1 to make it easier to
compare the two drivers. I did not test Redis in
On 9/10/14, 3:58 PM, Devananda van der Veen devananda@gmail.com
wrote:
I'm going to assume that, for these benchmarks, you configured all the
services optimally.
Sorry for any confusion; I am not trying to hide anything about the setup.
I thought I was pretty transparent about the way uWSGI,
Hi folks,
In this second round of performance testing, I benchmarked the new Redis
driver. I used the same setup and tests as in Round 1 to make it easier to
compare the two drivers. I did not test Redis in master-slave mode, but
that likely would not make a significant difference in the results
13 matches
Mail list logo
