jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Hildrew <simon.hild...@theguardian.com>
Subject Re: Security group listing on nova slow
Date Mon, 03 Feb 2014 21:01:33 GMT
On 3 February 2014 20:51, Andrew Phillips <andrewp@apache.org> wrote:

> Making a call to listSecurityGroupsInLocation and passing in the single
>> zone I'm interested in has made no difference - it is still making the
>> underlying call to the API many many times before the jclouds API call
>> returns. It is always exactly 92 calls to the underlying API
>>
>
> Does this include things like authentication calls, or is this the
> "straight" call for security groups? If so, is there any obvious variation
> in parameters or other request characteristics? Or is it literally always
> the same call?
>

There are two other calls to start with - one to keystone to auth and then
another to get the extensions in order to locate the security group
endpoint. The following 92 calls are always identical and get an identical
response each time (as observed via both tcpdump and today using the
jclouds.wire logging). It's really odd behaviour!


> Hopefully, one of the OpenStack experts on the list can shed more light on
> where these might be coming from.
>

That would be great - I'm happy to post some of my logs or carry out any
experiments that might help shed more light. The problem seems to be worse
in some region / tenants than others so I'm going to try the same
experiment in some other places tomorrow and see if there is a pattern.

As regards the sync vs. async: the sync API in most cases is just a dynamic
> proxy around the async API that waits for the futures to return, so I
> suspect this is unfortunately unlikely to affect the calls made. Although
> Nova *may* of course be an exception in this case - I'm not the expert on
> that point.
>

OK - well it's good to have that ruled out (or at least made less likely).
I wasn't sure how it was implemented, hence my move to eliminate other
environmental variables like akka.

Thanks for picking up the out-of-date group ID in the docs - hopefully
> fixed soon [1].
>

You're welcome - I had a quick hunt to see whether I could do a pull
request but it wasn't immediately obvious. Maybe a link on each page to the
file in github with a 'can you improve this page' or similar text on it?

Many thanks,
Simon

Please consider the environment before printing this email.
------------------------------------------------------------------
Visit theguardian.com   

On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition
theguardian.com/iPad   
Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and
get full digital access.
Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
 
Guardian News & Media Limited
 
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
 
Registered in England Number 908396

--------------------------------------------------------------------------

Mime
View raw message