Performance in a high-volume environment

[camden]

We are currently evaluating solutions for auditing for a system we are developing, which (management believe!) will be a high volume deployment of Spring/Hibernate/JBoss AS.

We are set on not using database triggers for a variety of reasons, so have been exploring other options.  Envers looks great but the global revision strategy has raised a few questions.

Whilst I can see the attraction and benefits of it, doesn't this cause a problem in a system generating a high volume of database insert/updates?  By high-volume we assume we are talking about many hundreds of transactions per second.  How does Envers keep track of the latest revision number?

We are only looking to audit a limited number of our database tables which are key from a historical perspective and therefore the concept of a 'global' db revision doesn't make sense for us anyway.

Has anyone done any testing, or can they point me at a suitable resource?  It wouldn't surprise me that I have missed something obvious somewhere, it has been a long week....

Thanks,

Cam.

[adamw]

Hello,

there's a performance hit only when saving changes in audited entities/properties. If you are changing non-audited entities, there's almost no additional operations (only a couple of if-s in java).

That's true that the revisions are global, but that's needed for the relation auditing to work correctly.

More precisely, for each transaction there's:

* one insert for each changed entity into the corresponding _aud table

* one insert into the rev_info table

Adam

[camden]

Hi,

Thanks for the reply. I understand that on non-audited entities there is little impact, but I was wondering (or hoping!) if someone had measured the impact on the audited entities.

Our environment involves multiple JBoss instances in a cluster, with hundreds of transactions per second (we hope).  With the model used in Envers, how are you setting the revision number?

Presumably with a sequence or some form of max value on the REVINFO table?  How well does this scale across a number of boxes, that might all be making changes?  I'm concerned that this access to the REVINFO table and setting the revision number is a bottleneck.

Obviously I could (and probably should) test this myself but I don't have a lot of time to think about this right now.  If I get around to it I'll post some results here.

Camden

[adamw]

The way the revision id is generated is up to you. Normally it's a sequence (e.g. in Postgres) or an auto_increment field (e.g. in MySQL). But you can configure the id generator yourself, by creating a custom revision entity.

As to performance measurments, even if there were some, I doubt they would have much value to you, as I think this is very application-specific, so I guess you'll be best off by doing some the way you are going to use Envers .

Adam