How to start/ load all the packages very fast

Hi team,

While Starting/Restarting the Integration server, taking a time to load all the packages.
Any idea like how can start the IS very fast.

Best Regards
K M , Varun

1 Like

Hi Varun,

only thing which comes into my mind is to reduce the number of packages available in each IS.
If you have a lot of packages you might want to consider to split them over several instances.

Regards,
Holger

1 Like

Hi,

Thanks for the response. But its a critical production instance, all the packages play a vital role, cant reduce.
Any other suggestion please ?

Thanks

Please have a look @ watt.server.package.parallel.threads and see if that property helps. Also, have you looked at what exactly / which package / startup service is adding a delay during the startup?

Regards,
Kalpesh

4 Likes

Hi Varun,

I will ask the question the other way round:
Do all the packages need to reside on the same IS instance or not?

How many packages are we talking about?

Can you check ther server.log upon next fresh start of the IS for the line “Server initialization completed in … seconds” (or similar).
Most likely you should rename the previous server.log so that IS will create a fresh one upon next start.

Make sure that you have assigned enough memory the JVM in which IS is running so that it does not need to dynamically adjust memory and that it will not have to run garbage collection very frequently.

In my project we are currently running 5 to 7 instances with each of them serving different integration parts.
There are some common utility packages, which are available on all instances, i.e. for monitoring, housekeeping and suppport stuff.

Regards,
Holger

4 Likes

On top of Kalpesh’s and Holger’s excellent suggestions, I just have a side question: did it always take a long time, or did this issue start happening only recently? If only recently, can you think of any changes to the system (hardware specs changes, or new packages added) that took place around the same time and could be related?

1 Like

Can you provide more info? Anything about the environment might help with suggestions. The only info available is “startup is slower than desired.” You’re making people guess at what the issue might be which could be just about anything.

3 Likes

@reamon @dzung.tran

There is no changes to the system. Usually it will take that amount of time , our idea is to improve the startup speed.

Yes all the packages will reside on the same IS.
We are talking about more that 60 packages.
2023-03-01 03:11:54 PST [ISS.0014.0002I] (tid=71) Initialization completed in 910 seconds.
We have the enough memory on JVM.

The only goal/idea is to improve the startup speed.

I have added the extended setting with 0 value and tried in our Dev System.
Before Watt setting 2023-03-01 03:11:54 PST [ISS.0014.0002I] (tid=71) Initialization completed in 910 seconds.
After adding 2023-03-01 03:32:53 PST [ISS.0014.0002I] (tid=68) Initialization completed in 1015 seconds.

Hi @varunkmv

  • A note about the watt property - watt.server.package.parallel.threads , by setting this property to zero, the packages are loaded sequentially which explains the server being started up in 1015 vs 910 seconds earlier
    More info about this property here - watt.server at documentation
    You can try setting this property to a higher value <10 and check the startup times. The default value is 6, so you may not get a significant reduction in time here.

  • The key here are the packages themselves, you can check what the packages contain and how much they take to load , you can look for messages in the server log such as

2022-07-01 08:54:26 [ISS.0028.0005I] Loading WmPublic package

and then check the time it takes to run the startup services of each of these packages.

  • It would be good to have a target, i.e., what is the time you are looking for. You may need to move packages around to different IS as suggested in the previous comments for this.

-NP

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.