Intelligent cycles for polling and non-polling connectors

With

• any Identity Broker deployment
• polling or non-polling
• with or without Event Broker, and
• for whatever version
  as an implementor you are always making little more than an educated guess as to the appropriate cycle of full and/or delta imports for each of your connectors. This needs to be more scientific, and an opportunity may exist as part of Identity Broker 4 to take empirocal data and suggest refinements (thinking green/yellow/red dashboard style info here) on what would make optimal use of available CPU/network resources.
  Equally, with frequencies recently configured for CSODBB's Peoplesoft (polling) connector for PHRIS, we found that my initial values were on the over-ambitious side. Something to draw attention to the fact that the service was "spinning its wheels" trying to keep up with unrealistic cycles would be useful console feedback (i.e. I summised that the number of queued but unprocessed polling requests was growing because they couldn't be processed fast enough). Ryan had some trouble and called me about it during UAT last week, where memory for the Identity Broker service grew astronomically and delta imports started failing. In the end I think that the resolution was at least partly to do with setting realistic frequencies.