<snip>
there could be problems with alerts if you have a lot of
MATCHING conditions.  The alerts cache is fast.  So, as long as most
pieces of data do NOT trigger conditions to become true we'll stay
standing no problem.  Issues arise when users create conditions that
always fire each time the metric is collected.  Realistically speaking,
conditions like that have no meaning.  Alerts SHOULD be used for
exceptional cases, not as a new form of logging.  ; )

That said, I have tested high volume alert on postgres 8.3 then the db
and server were colocated and with NO other appreciable load being
applied to the server machine at that time.  I saw that the system was
handling about ~1500 matches / second.  This will certainly decrease
when the server is remote to the db, and will certainly go down further
when the system is loaded, but what do we think is an acceptable /
reasonable figure to shoot for?
<snip>

From the above 1500matches/second sounds pretty fast. With 30 second metric collection intervals, a single condition per alert definition and a single alert definition per resource, this is equivalent to firing an alert every 30seconds on every resource in a 45k resource inventory. The other side of this equation is how well its possible to select and purge from the alert tables once this volume of data has been inserted.