I partially agree with fml2.
Having 10 packages with 10 nodes (not only services are recognized as nodes) should require the same amount of memory as 1 package with 100 nodes or 100 packages with each 1 node for example.
All of these scenarios are still 100 nodes.
Additionally the complexity of the services is a factor here.
Having large, complex flow services requires more memory than i.e. some small trigger nodes.
When having more packages, the loading time is also affected by the complexity of the inter-dependency of the packages.
In the first run, all the packages are scanned for their manifest.v3 files containing the dependency information.
When packages depend on each other they have to be loaded in the right order in the same ClassLoader Thread whereas packages being completely undepended on others (except i.e. WmPublic et al.) are each loaded in separate ClassLoader threads.
At least for me it turned out to have the following grouping/splitting of nodes is a good practice:
- One package for each IS containing environment specific data as AdapterConnections and AdapterListeners
- Some packages (dependent on purpose) which are the same for all ISes containing general Utilities and HouseKeeping functions.
- Per project/Interface:
– One Package with specific AdapterService, AdapterNotifications, DocTypes, Logic, ModelLogic Implementation, Triggers, WSDs
– One Package with the generated part for the process models invoking the appropriate ModelLogic Implementation service in the above package.