No. As I said earlier, there are many factors that can influence the
time to start a cluster, including the speed and memory of the machines
being used, the number of instances per machine, the speed of the
network, the size of the applications, what the applications actually
do, the amount of data to be synchronized (docroot, etc.)
Clearly, if the asadmin command times out after 10 minutes with the size
cluster you are testing, then there is a problem. The times that are are
seeing seem reasonable to me.
Tom
On 9/24/2010 1:19 PM, Elena Asarina wrote:
> Hi Tom,
>
> Do we have any guideline regrading start-cluster time?
>
> Thank you,
> Elena
>
> Elena Asarina wrote:
>> Hi Tom,
>>
>> I'm using ten SuSE machines, each machine has one node with two
>> instances. Were created two clusters, each of them has ten instances
>> that are located on ten machines. I've executed the same script for
>> one instance, the average start-instance time was 28 seconds. Then
>> I've executed start/stop cluster again, the average start-cluster
>> time was the same 65 seconds. The 19 Mb application is a war file
>> that uses grails.
>>
>> But it looks for me that the most important an application size. When
>> I've deployed not only this app, but also two additional apps, each
>> of them about 10 Mb, the average start-cluster time became 82 seconds.
>>
>> Thank you,
>>
>> Elena
>>
>> Tom Mueller wrote:
>>> There are lots of possible reasons for the increase in time. How
>>> many nodes host the 10 instances? What does the application
>>> actually do? How much time does it take to start one instance when
>>> it has the application deployed?
>>>
>>> I expect that the time to start one instance is probably about 65
>>> seconds too.
>>>
>>> Tom
>>>
>>> On 9/23/2010 9:20 PM, Elena Asarina wrote:
>>>> Hi Tom,
>>>>
>>>> I've deployed an app when instance were up. Then executed a simple
>>>> script that did:
>>>>
>>>> asadmin stop-cluster <cluster_name>
>>>> sleep 10
>>>> asadmin start-cluster <cluster_name>
>>>> sleep 10
>>>>
>>>> and so on 4 times. I've measured start/stop time for each
>>>> start/stop command. Then took an average start time and stop time
>>>> (really the time was stable). I did it before and after the
>>>> deployment. And before the deployment the average start time was
>>>> 15 second, after the deployment - 65 seconds.
>>>>
>>>> Thank you,
>>>>
>>>> Elena
>>>>
>>>> Tom Mueller wrote:
>>>>> To clarify what you did...you deployed the application to the
>>>>> cluster while the instances were down, and then the time for
>>>>> start-cluster on the first start of the cluster was 65 seconds?
>>>>> That would seem to be reasonable, as this start-cluster requires
>>>>> synchronizing the application to all of the instances. The actual
>>>>> sync time depends on the network bandwidth you have and the speed
>>>>> of your DAS, but 65 seconds would seem reasonable for a 19MB
>>>>> application. I expect that if you stop the cluster and restart
>>>>> it, the start time should go down, probably not to the original 15
>>>>> seconds, because the instances need to load the application, but
>>>>> it should go down to something below 65 seconds.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> On 9/23/2010 7:00 PM, Elena Asarina wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've deployed to the 10-instances cluster one 19 Mb application.
>>>>>> After that start cluster time changed from 15 seconds to 65
>>>>>> seconds. It it OK or not?
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Elena
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>