HI JVV,

Take a look at:  https://pdn.pega.com/performance-alerts-security-alerts-and-autonomic-event-services/performance-alerts-security-alerts​  Adding PegaRULES Log Analyzer (PLA) would help out.

Also, this is a good resource for Pega development practices: https://docs-previous.pega.com/implementation-methodology-and-dco/developer-best-practices-using-pega-platform

Keep in mind that AES/PDC work off of alerts - at run-time, things were slow was slow or used more resources than we consider to be best practice [page list too large; a lot of DB IO; etc]. Absence of alerts in a dev system does not mean a good application as

a- many of the default alert thresholds are high. The DBQuery threshold in particular defaults to 500ms when in reality queries should be below 100ms.
b- Most of the time 'slow' or 'resource-heavy' is a combination of design plus actual production data. In dev systems you don't have enough data to trigger a performance hit from 'all but awful' rules.

Pega Consulting had offered an engagement 'predictive performance analysis'. Basically, run application with profiler and db tracing enabled and harvest the data. The profiler trace (which is different than tracer) gives step-by-step execution time and optionally cpu usage for activity steps and streams. DB trace gives you each and every query that ran. Find slow/hot rules; minimize the number of db queries; find the queries that are not rule-related and review them to ensure that they have sensible where clauses that can be satisfied by indexes, do not use pr_read_from_stream functions and will return a meaningful and not huge result set.