Does anyone know of where I can find the maximum recommended size of a package. It can either be in kilobytes, or number of services. I know that the package size should be kept to a reasonable number based on the server it resides on, but was wondering if there was a general rule of thumb with a concrete number. I searched GEAR and wm developer guides to no avail.
Thanks
In one of our projects last year, we had an EDI package (in IS 4.6) with over 1MB size and had difficulties while installing the package - took over 2-3 mins to install and activate.
But the general rule of thumb that we had followed was to ensure that packages were quickly installable 
That response doesn’t make sense. Ensuring an individual package is quickly installable doesn’t have any impact. If you have 1 package that is 100MB, or 100 at 1MB, the total load time is going to be the same (relatively speaking…of course it will very slightly).
I think we have all seen instances where packages take different load times, but am looking more for a proven strategic approach that might have an impact on performance, as opposed to something that will minimize load times.
it is suggested to keep the size to 32 MB
Try going back to an older version of the gear documentation, I think there were some memory estimate templates in there that outlined how much memory overhead there was for each service and each package. Don’t think there were any recommendations for maximum size however.
We’ve found that the time-to-get-back-up starts running into the go get a coffee and maybe pick up a sandwich type time…
But aside from browser timeouts while waiting for a service to install (which you could get around by manually/writing some code to invoke the activate package service) there’s probably no upper limit aside from jvm memory constraints.
I generally recommend that the package be big enough to contain all the services/documents for functional area, which is an inherently wishy washy measure, but it’s all you can say. Set a fixed number and you’re always going to find exeptions or hurt your maintainability/understandability by artificially dividing up packages.
Guidelines/potential areas for division:
-avoid having separate teams working on the same package (makes deployment a mess if both teams are at different stages)
-put wrapper services for a legacy system or some sort of API into a separate package
-project or subproject boundaries
-sensible naming: if you can’t think of a name without using twenty ANDs then maybe the abstraction is wrong,
But definitely avoid having to do patches for deployment. So no two teams working on the same package (the exception being the commons package perhaps… but that should be pretty stable after a while anyhow).
regards,
Nathan Lee
Nathan has some valid explanations here.
I apologize, I should have been more explicit earlier.
The way we treat webMethods packages are very similar to Java packages and manage them clearly on the basis of collaborative development. Sizes does matter as the package gets bulkier and in a collaborative development wherein the team is spread over geographically, we follow the same pattern of managing Java application packages and isolate core functionalities from frameworks / reusable components.
Thank you,
Muthu.
by the way, your asking for a “number of services” is in itself an ambiguous question:
-what type of services? flow or java
-how complex are those services (3 lines of self contained java code up to 100line monster java services, with tonnes of shared methods and referring to tonnes of APIs included in the package in .jars) or (3 lines of flow code up to… etc etc)
There is no “standard proven approach” to performance tuning, performance tuning is by its very nature a case of try something, see the impact, try something else, etc
The answer to performance tuning should always be either qualified or with “it depends” stuck at the start of it…
If you want a performance tuning methodology: sort out first what it is you’re trying to achieve. Muthu gave an example of one type of aim, to have packages able to be installed in reasonable time. Some other goals/aims: maintainability, testability, realisability etc
By the way: I don’t really see how the package size matters that much, I mean, you still have the same amount of code to write overall for the app. So unless you’re considering trimming out code, pick a package division that makes sense from a development point of view and don’t concern yourself too much about the size in KB.
Nath
Thanks all for your help. I didn’t think there was any performance hits based on package size (i.e. lots of folders might make for longer process times), but wanted to confirm with others in the wm community in order to validate this.
As far as services, I was told that there might be a concrete number of services (of any kind) to put inside a package. I just wanted to confirm that the quantity of services and the size of the packages were irrevelant (outside of managability). Thanks all for your help, and I hope this thread will help others who encounter these questions in the future.