Andreas,

I have not thought about it in detail, but having in mind differences in
dataset implementation at Freiburg and ours, I think part of the problem is
(AFAIK) your implementation makes full copy of the dataset on each run,
regardless of using same URIs (e.g. as same records in the database)

So may be this is just an implementation specific?

Nina

On 25 February 2011 13:02, Andreas Maunz <andreas at maunz.de> wrote:

> Dear all,
>
> since a single validation of a model on a dataset creates multiple
> ressources (currently > 50), and by the fact that everything is
> decentralized (i.e. linked via URIs) and referenceable in OpenTox, we are
> facing the problem that currently prohibitively high load is placed on the
> AA services, because a policy must be created and requested multiple times
> (and eventually deleted) for each of the resources.
>
> For example the spike in http://tinyurl.com/6amuo8x to the very right is
> produced by a single validation. Moreover, the validation service is very
> slow, the AA related part alone takes at least several minutes. All this is
> induced by the amount of single policies that have to be created.
>
> Martin argues that currently there seems no API compliant way of improving
> performance: One way could be to collect all URIs and create a policy
> covering all of them at the end of the validation. However, there is no way
> of notifying validation-involved services to not create policies in the
> first place. Also, without policies, there would be no way for validation to
> access the resource, since default (without associated policy) is "deny".
>
> We consider this issue high priority, which should be dealt with before
> everyone starts using validation in production. Perhaps we would need an API
> extension that allows the collection strategy discussed before, or are there
> other suggestions?
>
> Best regards
> Andreas
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>