You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Soumya <so...@yahoo.co.in> on 2010/10/13 11:00:26 UTC
Servicemix 3.3.2 threads
Hello fellow Smix users,
We have recently upgraded to Smix 3.3.2 and have questiong regarding the
following 3 configurations in conf/servicemix.properties
servicemix.corePoolSize = 16
servicemix.maximumPoolSize = 32
servicemix.queueSize = 256
Before for 3.2.1 corePoolSize used to be 4 by default and we used to use that.
Now since it has been increased to 16 already I guess it would be improved
scalability ..i.e. more threads to work on simultaneously.
However we have setup where we have a Servicemix HTTP deployment which is
deployed on DMZ, which then passes on the request over AMQ 61616 port a
clustered (over 2 machines) Servicemix LWC deployment inside the company network
over the firewall.
a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32 so that
it can take in 32 simultaneous requests and then there would be 16 + 16
corresponding threads in the clustered LWC deployment where corepoolsize for
each machine's Smix has been set as 16. Is that right? But is it bad to be equal
to maximumPoolSize and moreover can we increase maximumPoolsize to say 64?
b) Other high volume webservices can service say upto 500 concurrent requests
but in this case we are tied to 32 - Is there a way to scale that up or
Servicemix wont be robust beyond that?
Please if experts can pour in their thoughts I would be obliged.
Thanks
Re: Servicemix 3.3.2 threads
Posted by "Aida ." <ai...@gmail.com>.
Apologies for the previous mail, I confused the mail I wanted to reply
Greetings and sorry again.
2010/10/29 Aida . <ai...@gmail.com>
> voy a estar en el chat no te escribo directamente por si te pillase mal o
> algo
>
> 2010/10/29 Soumya <so...@yahoo.co.in>
>
> Hi Gert and other experts -
>>
>> Any confirmation on my queries below?
>>
>> Thanks in advance
>> Soumya
>>
>>
>>
>>
>>
>> ________________________________
>> From: Soumya <so...@yahoo.co.in>
>> To: users@servicemix.apache.org
>> Sent: Fri, 22 October, 2010 2:55:10 PM
>> Subject: Re: Servicemix 3.3.2 threads
>>
>> Thanks Gert.
>>
>> Just another question - is 32 the best (rather Max) possible value to have
>> in
>> the max Pool Size?
>>
>> The reason I am asking this is traditional webservers can easily support
>> more
>> than 100 concurrent requests. In this case, even if I reduce the
>> maxQueueSize to
>>
>> say 5 - so after 16+5 ie.e 21 requests it will start creating a new thread
>> to
>> service calls and can only go upto 32 parallel processes I guess.
>>
>> Also from your experience for a high availibity system what do you reckon
>> should
>>
>> be a reasonable setting for QueueSize? Is it ok to have like 10?
>>
>> Thanks a lot
>> Soumya
>>
>>
>> ________________________________
>> From: Gert Vanthienen <ge...@gmail.com>
>> To: users@servicemix.apache.org
>> Sent: Wed, 13 October, 2010 10:57:39 AM
>> Subject: Re: Servicemix 3.3.2 threads
>>
>> L.S.,
>>
>> In ServiceMix, we try to use asynchronous sends as much as possible.
>> This mean that the sending thread is not blocked while waiting for the
>> response from the other component. For example, we recently upgraded
>> servicemix-camel to leverage this feature (cfr.
>>
>> http://gertvanthienen.blogspot.com/2010/07/camel-async-routing-in-servicemix.html
>> ).
>>
>>
>>
>> So, in order to handle the two machines with 16 core threads' load,
>> you don't necessarily have to assign the double amount of threads at
>> the back-end. If all the components are using asynchronous sends, a
>> lot of load can be handled by the default thread pool sizes. As long
>> as there's enough memory to support the thread pool size you
>> configure, ServiceMix should keep behaving properly whatever the size
>> of the thread pool is though.
>>
>> About the corePoolSize and maxPoolSize: the thread pool will only
>> increase beyond the core pool size if there are more tasks waiting
>> than configure with the queue size parameter (so, in this case, more
>> than 256 pending tasks). Instead of configuring core pool size to
>> equal the max pool size, you might want to consider reducing the queue
>> size instead. With a smaller queue size, the executor will start
>> adding threads quicker to handle an increased workload, while still
>> allowing it to reduce to a smaller size in quieter times.
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> Open Source SOA: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Wed, Oct 13, 2010 at 11:00 AM, Soumya <so...@yahoo.co.in> wrote:
>> > Hello fellow Smix users,
>> >
>> > We have recently upgraded to Smix 3.3.2 and have questiong regarding
>> the
>> > following 3 configurations in conf/servicemix.properties
>> >
>> > servicemix.corePoolSize = 16
>> > servicemix.maximumPoolSize = 32
>> > servicemix.queueSize = 256
>> >
>> > Before for 3.2.1 corePoolSize used to be 4 by default and we used to use
>> that.
>> > Now since it has been increased to 16 already I guess it would be
>> improved
>> > scalability ..i.e. more threads to work on simultaneously.
>> > However we have setup where we have a Servicemix HTTP deployment which
>> is
>> > deployed on DMZ, which then passes on the request over AMQ 61616 port a
>> > clustered (over 2 machines) Servicemix LWC deployment inside the company
>> >network
>> > over the firewall.
>> >
>> > a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32
>> so that
>> > it can take in 32 simultaneous requests and then there would be 16 + 16
>> > corresponding threads in the clustered LWC deployment where corepoolsize
>> for
>> > each machine's Smix has been set as 16. Is that right? But is it bad to
>> be
>> >equal
>> > to maximumPoolSize and moreover can we increase maximumPoolsize to say
>> 64?
>> >
>> > b) Other high volume webservices can service say upto 500 concurrent
>> requests
>> > but in this case we are tied to 32 - Is there a way to scale that up or
>> > Servicemix wont be robust beyond that?
>> >
>> >
>> > Please if experts can pour in their thoughts I would be obliged.
>> >
>> > Thanks
>> >
>> >
>> >
>>
>>
>
Re: Servicemix 3.3.2 threads
Posted by "Aida ." <ai...@gmail.com>.
voy a estar en el chat no te escribo directamente por si te pillase mal o
algo
2010/10/29 Soumya <so...@yahoo.co.in>
> Hi Gert and other experts -
>
> Any confirmation on my queries below?
>
> Thanks in advance
> Soumya
>
>
>
>
>
> ________________________________
> From: Soumya <so...@yahoo.co.in>
> To: users@servicemix.apache.org
> Sent: Fri, 22 October, 2010 2:55:10 PM
> Subject: Re: Servicemix 3.3.2 threads
>
> Thanks Gert.
>
> Just another question - is 32 the best (rather Max) possible value to have
> in
> the max Pool Size?
>
> The reason I am asking this is traditional webservers can easily support
> more
> than 100 concurrent requests. In this case, even if I reduce the
> maxQueueSize to
>
> say 5 - so after 16+5 ie.e 21 requests it will start creating a new thread
> to
> service calls and can only go upto 32 parallel processes I guess.
>
> Also from your experience for a high availibity system what do you reckon
> should
>
> be a reasonable setting for QueueSize? Is it ok to have like 10?
>
> Thanks a lot
> Soumya
>
>
> ________________________________
> From: Gert Vanthienen <ge...@gmail.com>
> To: users@servicemix.apache.org
> Sent: Wed, 13 October, 2010 10:57:39 AM
> Subject: Re: Servicemix 3.3.2 threads
>
> L.S.,
>
> In ServiceMix, we try to use asynchronous sends as much as possible.
> This mean that the sending thread is not blocked while waiting for the
> response from the other component. For example, we recently upgraded
> servicemix-camel to leverage this feature (cfr.
>
> http://gertvanthienen.blogspot.com/2010/07/camel-async-routing-in-servicemix.html
> ).
>
>
>
> So, in order to handle the two machines with 16 core threads' load,
> you don't necessarily have to assign the double amount of threads at
> the back-end. If all the components are using asynchronous sends, a
> lot of load can be handled by the default thread pool sizes. As long
> as there's enough memory to support the thread pool size you
> configure, ServiceMix should keep behaving properly whatever the size
> of the thread pool is though.
>
> About the corePoolSize and maxPoolSize: the thread pool will only
> increase beyond the core pool size if there are more tasks waiting
> than configure with the queue size parameter (so, in this case, more
> than 256 pending tasks). Instead of configuring core pool size to
> equal the max pool size, you might want to consider reducing the queue
> size instead. With a smaller queue size, the executor will start
> adding threads quicker to handle an increased workload, while still
> allowing it to reduce to a smaller size in quieter times.
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Oct 13, 2010 at 11:00 AM, Soumya <so...@yahoo.co.in> wrote:
> > Hello fellow Smix users,
> >
> > We have recently upgraded to Smix 3.3.2 and have questiong regarding the
> > following 3 configurations in conf/servicemix.properties
> >
> > servicemix.corePoolSize = 16
> > servicemix.maximumPoolSize = 32
> > servicemix.queueSize = 256
> >
> > Before for 3.2.1 corePoolSize used to be 4 by default and we used to use
> that.
> > Now since it has been increased to 16 already I guess it would be
> improved
> > scalability ..i.e. more threads to work on simultaneously.
> > However we have setup where we have a Servicemix HTTP deployment which
> is
> > deployed on DMZ, which then passes on the request over AMQ 61616 port a
> > clustered (over 2 machines) Servicemix LWC deployment inside the company
> >network
> > over the firewall.
> >
> > a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32 so
> that
> > it can take in 32 simultaneous requests and then there would be 16 + 16
> > corresponding threads in the clustered LWC deployment where corepoolsize
> for
> > each machine's Smix has been set as 16. Is that right? But is it bad to
> be
> >equal
> > to maximumPoolSize and moreover can we increase maximumPoolsize to say
> 64?
> >
> > b) Other high volume webservices can service say upto 500 concurrent
> requests
> > but in this case we are tied to 32 - Is there a way to scale that up or
> > Servicemix wont be robust beyond that?
> >
> >
> > Please if experts can pour in their thoughts I would be obliged.
> >
> > Thanks
> >
> >
> >
>
>
Re: Servicemix 3.3.2 threads
Posted by Soumya <so...@yahoo.co.in>.
Hi Gert and other experts -
Any confirmation on my queries below?
Thanks in advance
Soumya
________________________________
From: Soumya <so...@yahoo.co.in>
To: users@servicemix.apache.org
Sent: Fri, 22 October, 2010 2:55:10 PM
Subject: Re: Servicemix 3.3.2 threads
Thanks Gert.
Just another question - is 32 the best (rather Max) possible value to have in
the max Pool Size?
The reason I am asking this is traditional webservers can easily support more
than 100 concurrent requests. In this case, even if I reduce the maxQueueSize to
say 5 - so after 16+5 ie.e 21 requests it will start creating a new thread to
service calls and can only go upto 32 parallel processes I guess.
Also from your experience for a high availibity system what do you reckon should
be a reasonable setting for QueueSize? Is it ok to have like 10?
Thanks a lot
Soumya
________________________________
From: Gert Vanthienen <ge...@gmail.com>
To: users@servicemix.apache.org
Sent: Wed, 13 October, 2010 10:57:39 AM
Subject: Re: Servicemix 3.3.2 threads
L.S.,
In ServiceMix, we try to use asynchronous sends as much as possible.
This mean that the sending thread is not blocked while waiting for the
response from the other component. For example, we recently upgraded
servicemix-camel to leverage this feature (cfr.
http://gertvanthienen.blogspot.com/2010/07/camel-async-routing-in-servicemix.html).
So, in order to handle the two machines with 16 core threads' load,
you don't necessarily have to assign the double amount of threads at
the back-end. If all the components are using asynchronous sends, a
lot of load can be handled by the default thread pool sizes. As long
as there's enough memory to support the thread pool size you
configure, ServiceMix should keep behaving properly whatever the size
of the thread pool is though.
About the corePoolSize and maxPoolSize: the thread pool will only
increase beyond the core pool size if there are more tasks waiting
than configure with the queue size parameter (so, in this case, more
than 256 pending tasks). Instead of configuring core pool size to
equal the max pool size, you might want to consider reducing the queue
size instead. With a smaller queue size, the executor will start
adding threads quicker to handle an increased workload, while still
allowing it to reduce to a smaller size in quieter times.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Oct 13, 2010 at 11:00 AM, Soumya <so...@yahoo.co.in> wrote:
> Hello fellow Smix users,
>
> We have recently upgraded to Smix 3.3.2 and have questiong regarding the
> following 3 configurations in conf/servicemix.properties
>
> servicemix.corePoolSize = 16
> servicemix.maximumPoolSize = 32
> servicemix.queueSize = 256
>
> Before for 3.2.1 corePoolSize used to be 4 by default and we used to use that.
> Now since it has been increased to 16 already I guess it would be improved
> scalability ..i.e. more threads to work on simultaneously.
> However we have setup where we have a Servicemix HTTP deployment which is
> deployed on DMZ, which then passes on the request over AMQ 61616 port a
> clustered (over 2 machines) Servicemix LWC deployment inside the company
>network
> over the firewall.
>
> a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32 so that
> it can take in 32 simultaneous requests and then there would be 16 + 16
> corresponding threads in the clustered LWC deployment where corepoolsize for
> each machine's Smix has been set as 16. Is that right? But is it bad to be
>equal
> to maximumPoolSize and moreover can we increase maximumPoolsize to say 64?
>
> b) Other high volume webservices can service say upto 500 concurrent requests
> but in this case we are tied to 32 - Is there a way to scale that up or
> Servicemix wont be robust beyond that?
>
>
> Please if experts can pour in their thoughts I would be obliged.
>
> Thanks
>
>
>
Re: Servicemix 3.3.2 threads
Posted by Soumya <so...@yahoo.co.in>.
Thanks Gert.
Just another question - is 32 the best (rather Max) possible value to have in
the max Pool Size?
The reason I am asking this is traditional webservers can easily support more
than 100 concurrent requests. In this case, even if I reduce the maxQueueSize to
say 5 - so after 16+5 ie.e 21 requests it will start creating a new thread to
service calls and can only go upto 32 parallel processes I guess.
Also from your experience for a high availibity system what do you reckon should
be a reasonable setting for QueueSize? Is it ok to have like 10?
Thanks a lot
Soumya
________________________________
From: Gert Vanthienen <ge...@gmail.com>
To: users@servicemix.apache.org
Sent: Wed, 13 October, 2010 10:57:39 AM
Subject: Re: Servicemix 3.3.2 threads
L.S.,
In ServiceMix, we try to use asynchronous sends as much as possible.
This mean that the sending thread is not blocked while waiting for the
response from the other component. For example, we recently upgraded
servicemix-camel to leverage this feature (cfr.
http://gertvanthienen.blogspot.com/2010/07/camel-async-routing-in-servicemix.html).
So, in order to handle the two machines with 16 core threads' load,
you don't necessarily have to assign the double amount of threads at
the back-end. If all the components are using asynchronous sends, a
lot of load can be handled by the default thread pool sizes. As long
as there's enough memory to support the thread pool size you
configure, ServiceMix should keep behaving properly whatever the size
of the thread pool is though.
About the corePoolSize and maxPoolSize: the thread pool will only
increase beyond the core pool size if there are more tasks waiting
than configure with the queue size parameter (so, in this case, more
than 256 pending tasks). Instead of configuring core pool size to
equal the max pool size, you might want to consider reducing the queue
size instead. With a smaller queue size, the executor will start
adding threads quicker to handle an increased workload, while still
allowing it to reduce to a smaller size in quieter times.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Oct 13, 2010 at 11:00 AM, Soumya <so...@yahoo.co.in> wrote:
> Hello fellow Smix users,
>
> We have recently upgraded to Smix 3.3.2 and have questiong regarding the
> following 3 configurations in conf/servicemix.properties
>
> servicemix.corePoolSize = 16
> servicemix.maximumPoolSize = 32
> servicemix.queueSize = 256
>
> Before for 3.2.1 corePoolSize used to be 4 by default and we used to use that.
> Now since it has been increased to 16 already I guess it would be improved
> scalability ..i.e. more threads to work on simultaneously.
> However we have setup where we have a Servicemix HTTP deployment which is
> deployed on DMZ, which then passes on the request over AMQ 61616 port a
> clustered (over 2 machines) Servicemix LWC deployment inside the company
>network
> over the firewall.
>
> a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32 so that
> it can take in 32 simultaneous requests and then there would be 16 + 16
> corresponding threads in the clustered LWC deployment where corepoolsize for
> each machine's Smix has been set as 16. Is that right? But is it bad to be
>equal
> to maximumPoolSize and moreover can we increase maximumPoolsize to say 64?
>
> b) Other high volume webservices can service say upto 500 concurrent requests
> but in this case we are tied to 32 - Is there a way to scale that up or
> Servicemix wont be robust beyond that?
>
>
> Please if experts can pour in their thoughts I would be obliged.
>
> Thanks
>
>
>
Re: Servicemix 3.3.2 threads
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
In ServiceMix, we try to use asynchronous sends as much as possible.
This mean that the sending thread is not blocked while waiting for the
response from the other component. For example, we recently upgraded
servicemix-camel to leverage this feature (cfr.
http://gertvanthienen.blogspot.com/2010/07/camel-async-routing-in-servicemix.html).
So, in order to handle the two machines with 16 core threads' load,
you don't necessarily have to assign the double amount of threads at
the back-end. If all the components are using asynchronous sends, a
lot of load can be handled by the default thread pool sizes. As long
as there's enough memory to support the thread pool size you
configure, ServiceMix should keep behaving properly whatever the size
of the thread pool is though.
About the corePoolSize and maxPoolSize: the thread pool will only
increase beyond the core pool size if there are more tasks waiting
than configure with the queue size parameter (so, in this case, more
than 256 pending tasks). Instead of configuring core pool size to
equal the max pool size, you might want to consider reducing the queue
size instead. With a smaller queue size, the executor will start
adding threads quicker to handle an increased workload, while still
allowing it to reduce to a smaller size in quieter times.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Oct 13, 2010 at 11:00 AM, Soumya <so...@yahoo.co.in> wrote:
> Hello fellow Smix users,
>
> We have recently upgraded to Smix 3.3.2 and have questiong regarding the
> following 3 configurations in conf/servicemix.properties
>
> servicemix.corePoolSize = 16
> servicemix.maximumPoolSize = 32
> servicemix.queueSize = 256
>
> Before for 3.2.1 corePoolSize used to be 4 by default and we used to use that.
> Now since it has been increased to 16 already I guess it would be improved
> scalability ..i.e. more threads to work on simultaneously.
> However we have setup where we have a Servicemix HTTP deployment which is
> deployed on DMZ, which then passes on the request over AMQ 61616 port a
> clustered (over 2 machines) Servicemix LWC deployment inside the company network
> over the firewall.
>
> a) Do we need to scale up the corePoolSize in the DZM Http SMix to 32 so that
> it can take in 32 simultaneous requests and then there would be 16 + 16
> corresponding threads in the clustered LWC deployment where corepoolsize for
> each machine's Smix has been set as 16. Is that right? But is it bad to be equal
> to maximumPoolSize and moreover can we increase maximumPoolsize to say 64?
>
> b) Other high volume webservices can service say upto 500 concurrent requests
> but in this case we are tied to 32 - Is there a way to scale that up or
> Servicemix wont be robust beyond that?
>
>
> Please if experts can pour in their thoughts I would be obliged.
>
> Thanks
>
>
>