Jclouds Performance issue

[Sumit Gaur <su...@gmail.com>]

Hi ,
I want to understand the modification for JClouds internal threads
properties. I saw below 3 major properties that can help to improve
the TPSfor SWIFT
Bloblstore connectivity via JClouds.

 Properties overrides = new Properties();
 overrides.setProperty(PROPERTY_IO_WORKER_THREADS, "40");
 overrides.setProperty(PROPERTY_SCHEDULER_THREADS, "20");
 overrides.setProperty(PROPERTY_USER_THREADS, "0"); //assuming unlimited

Please let me know from internal architecture point of view if my thinking
is correct ?  As I am not seeing any difference in number of requests
served by SWIFT through JClouds by increasing above propertie's value.

My client is able to get more TPS if I increase number of clients threads
(that means Jclouds+Swift can give me more bandwidth) But keeping client
threads as 1 and increasing above properties is not helping.
Am I missing something obvious ?

 *Java Client <-> Jclouds <-> openstack SWIFT Blobstore*

Also I assumes

Jclouds has internal architecture for processing requests as below

*User threads <----Queue---> Scheduler threds <----Queue-----> IO threads*


Thanks
sumit

Re: Jclouds Performance issue

[Sumit Gaur <su...@gmail.com>]

thanks for clarification. It helps a lot.
-sumit


On Fri, Jan 10, 2014 at 12:12 PM, Andrew Phillips <an...@apache.org>wrote:

> clients improve overall performance in my environment. So
>> incrementing PROPERTY_IO_WORKER_THREADS
>> and others similiar properties have no meaning in 1.7.0 and further ?
>>
>
> They are still used in certain places - async isn't quite gone yet ;-) For
> example, the base AsyncBlobStore implementation (AsyncBlobStore is
> deprecated, but still around) uses the "userExecutor" that is controlled by
> the property "jclouds.user-threads".
>
> So I wouldn't go so far as to say "they don't have meaning", and we could
> probably still achieve something by tuning them. I would more likely say
> that, for performance optimization, using the sync APIs and your own
> executors is a better option given the current plans.
>
> Hope that helps!
>
> ap
>
> [1] https://github.com/jclouds/jclouds/blob/master/blobstore/
> src/main/java/org/jclouds/blobstore/internal/BaseAsyncBlobStore.java#L66
>

Re: Jclouds Performance issue

[Andrew Phillips <an...@apache.org>]

> clients improve overall performance in my environment. So
> incrementing PROPERTY_IO_WORKER_THREADS
> and others similiar properties have no meaning in 1.7.0 and further ?

They are still used in certain places - async isn't quite gone yet ;-)  
For example, the base AsyncBlobStore implementation (AsyncBlobStore is  
deprecated, but still around) uses the "userExecutor" that is  
controlled by the property "jclouds.user-threads".

So I wouldn't go so far as to say "they don't have meaning", and we  
could probably still achieve something by tuning them. I would more  
likely say that, for performance optimization, using the sync APIs and  
your own executors is a better option given the current plans.

Hope that helps!

ap

[1]  
https://github.com/jclouds/jclouds/blob/master/blobstore/src/main/java/org/jclouds/blobstore/internal/BaseAsyncBlobStore.java#L66

Re: Jclouds Performance issue

[Sumit Gaur <su...@gmail.com>]

Thanks Andrew,
Got it, your answer explained the reason why multilple executor from
clients improve overall performance in my environment. So
incrementing PROPERTY_IO_WORKER_THREADS
and others similiar properties have no meaning in 1.7.0 and further ?

-sumit


On Fri, Jan 10, 2014 at 10:46 AM, Andrew Phillips <an...@apache.org>wrote:

> Hi Sumit
>
> As part of jclouds 1.7 and 1.8, quite a few things are changing on the
> thread management front in jclouds. Where previously there were both
> synchronous and asynchronous versions of APIs (such as the Swift API)
> running via executors managed by jclouds, we're now moving more towards an
> approach where thread and executor management will be handled by the caller.
>
> Blobstore will continue to support some asynchronous calls, but in terms
> of improving performance, my suggestion would be to stick to the
> synchronous calls and use your own executors. An example that could be
> relevant is here [1].
>
> I'm not the blobstore performance expert, though - hopefully, one of those
> will be able to contribute to this thread.
>
> Regards
>
> ap
>
> [1] https://github.com/jclouds/jclouds-cloud-storage-workshop/blob/master/
> exercise2/src/main/java/org/jclouds/labs/blobstore/
> exercise2/MultiFileUploaderC.java
>

Re: Jclouds Performance issue

[Andrew Phillips <an...@apache.org>]

Hi Sumit

As part of jclouds 1.7 and 1.8, quite a few things are changing on the  
thread management front in jclouds. Where previously there were both  
synchronous and asynchronous versions of APIs (such as the Swift API)  
running via executors managed by jclouds, we're now moving more  
towards an approach where thread and executor management will be  
handled by the caller.

Blobstore will continue to support some asynchronous calls, but in  
terms of improving performance, my suggestion would be to stick to the  
synchronous calls and use your own executors. An example that could be  
relevant is here [1].

I'm not the blobstore performance expert, though - hopefully, one of  
those will be able to contribute to this thread.

Regards

ap

[1]  
https://github.com/jclouds/jclouds-cloud-storage-workshop/blob/master/exercise2/src/main/java/org/jclouds/labs/blobstore/exercise2/MultiFileUploaderC.java