Finally, the first post out of this series. I decided to start off with some basics. Basics about what Parent/Child profiles are, can do, and can’t do. In other words, I want to give you some idea to help you decide whether Parent/Child profiles can be useful to accomplish what you want to do.
- A Parent/Child profile, whether full-featured or basic, is a way to define a set of profiles (children) with the same configuration split up by some kind of rule starting from a given set of data.
- The parent won’t contain any data, nor aggregate of the children. It is a mere template, defining the configuration for each child.
- All children have strictly the same configuration, except access rights and the split rule.
- Access rights are set either globally at the parent’s level (each child will inherit the same access rights) or set individually on each child.
- If access rights are set on a child, the access rights of the parent will be ignored!
- Any filter set on the Parent/Child profile will be applied to each children after the data has been split.
- Children are analyzed sequentially on one CPU. One Parent won’t split analysis over multiple CPUs.
- By default, the split rule is based on the value of the parameter WT.sp, which can contain multiple values separated by space (default). The parameter and the separator can be changed.
- By default, the split values are compared as substrings, not exact match. Keep this in mind if you count on having 1000 children, you will have to reconfigure each one manually!
- Split can be defined with regular expressions.
If you have read this list and think that Parent/Child profiles are still for you, stay tuned for the following posts on more crusty details, like maximum length of split values, how to safely create, delete and deactivate children, case studies on performance issues, etc.
As always, feel free to comment or ask for specific information you would need. 