Description
This is mainly about gather the following information :
- How do the experiments think, they are using SRM.
- What it the SRM command subset the experiments are currently using.
- How can those operations being optimized.
How can the already planed modifications help :
- Asychronous SRM ls
- Return SRM_INTERNAL_ERROR is SRM or back end is busy.
- Client and server agree on a timeout for operations.
More improvements.
- Can we get rid of httpg ?
- What else can we do without breaking the SRM protocol ?
Dr
Akos Frohner
(CERN)
18/05/2009, 14:10
Akos did some investigations on the timing of the SRM of the various SRM SE flavors seen from the FTS perspecive. He will present first results.
Dr
Dirk Duellmann
(CERN)
18/05/2009, 14:20
Giuseppe has been digging into the CASTOR logs and produced timing statistics on SRM requests. Dirk is going to present the initial results.
Dr
Matt Crawford
(FERMI)
18/05/2009, 14:30
Several bottlenecks have been identified in the dCache's SRM. Some of these are purely implementation issues, while others are inherent in the protocol. Of the latter group, some can be solved with small protocol changes and others can only be improved cleanly with significant protocol changes. Observations of the usage and behavior of T1_US_FNAL will be included.
Prof.
Arie Shoshani
(LBL)
18/05/2009, 14:50
We will propose a way to jointly assess during the meeting the current SRM usage for various SRM implementations. This will be the basis for determining desired "core" functionality for SRM, as well as "optional" functionality. We then propose to discuss how to use the "core" and "optional functions/features in a future SRM v3.0 framework. The goal is to achieve guidelines for actions and...