In the opposite of what announced before, each XWHEP deployment must have its own XWHEP->EGEE bridge due to performance problems. It appeared that it is too heavy to manage several XWHEP server on a single XWHEP->EGEE bridge. We then had to correct this bridge and implement a new version «V2» as member of activity «JRA1». As V2 was implemented and debugged, we deploy that new version in the context of this SA1 activity.
In V1, any job submitted with an X509 proxy had to be computed by an EGEE resource, and an EGEE resource only: an XWHEP resource had no chance to compute such a job. In V2, any job submitted with an X509 can be computed by any resource, including XWHEP (non secured resources) as well as EGEE ones (secured resources). The XWHEP logging and bookkeeping protocols and services ensure enough security to track any malicious behaviour. The end user X509 proxy security and integrity are still ensured because resources connected to XWHEP server never download X509 proxies. Their are exclusively and only downloaded and used by the bridge itself. This clearly means, in both versions, that the bridge must be run in a secured resource.
Figure «Fig 1 : XWHEP->EGEE bridge V1 Vs V2» shows the performances differences between V1 and V2. The blue line represent the amount of jobs submitted with an X509 certificate proxy -hence able to be computed by any EGEE resources. The green line represents the total amount of completed jobs, independently of their submission type (with or without X509 proxy), hence computed by XWHEP and EGEE resources. The red line represents job failures (data unavailable etc).
This figure also shows two different bar types: a black and a blue one. The black one represents the amount of connected EGEE resources.This resources are allocated when the XWHEP->EGEE bridge has found XWHEP jobs submitted with X509 proxy. When such a job is found, the bridge download the end user proxy and uses it to an XWHEP pilot job to EGEE (a pilot job being an XWHEP worker that will connect to the XWHEP server and request an XWHEP job to compute).
The blue bar represents the amount of job effectively computed by EGEE resources.
We can see two different periods in Figure 1: before october 2009 and since november 2009. In the first period, we were using the XWHEP->EGEE bridge version V1; since the second period, we use the bridge version V2. In first period we can see that the bridge unnecessarily overbooked EGEE resources which were really used in a 10% ratio only, which were just very bad. This was due to the fact that the bridge was designed to try to manage jobs from many XWHEP deployment connecting to all XWHEP server. In the second period, using the bridge V2, the average effective usage of connected EGEE resources is 75%, which is very good. this is due to the fact that the bridge does not connect to XWHEP servers, but directly to the database used by this server; of course the bridge does not modify the database itself : it only connects to the database in read only mode to ensure that it does not perturb the server. Connecting to the database ensures a better performance rates but does not allow the management of more than one XWHEP server per bridge since database accesses are usually not allowed outside an administrative domain.
Fig 1 : XWHEP->EGEE bridge V1 Vs V2