Warning, /Utilities/XrdAdaptor/README.md is written in an unsupported language. File is not indexed.
0001 # XrdAdaptor
0002
0003 ## Introduction
0004
0005 The `XrdAdaptor` package is the CMSSW implementation of CMS' AAA infrastructure. The main features on top of the stock XRootD client library are
0006 * Recovery from some errors via re-tries
0007 * Use of multiple XRootD sources (described further [here](doc/multisource_algorithm_design.md))
0008
0009 The `XrdAdaptor` behavior can be simulated to some extent with local files with
0010 ```py
0011 # application-only cache hint implies similar edm::storage::Storage::prefetch()
0012 # behavior as in XrdFile::prefetch()
0013 process.add_(cms.Service("SiteLocalConfigService",
0014 overrideSourceCacheHintDir = cms.untracked.string("application-only")
0015 ))
0016
0017 # Add e.g. 10-millisecond latency to singular and vector reads
0018 # If the job reads local files via TFile::Open() in addition to PoolSource,
0019 # you want to exclude those from the latency addition
0020 process.add_(cms.Service("AdaptorConfig",
0021 storageProxies = cms.untracked.VPSet(
0022 cms.PSet(
0023 type = cms.untracked.string("StorageAddLatencyProxy"),
0024 read = cms.untracked.uint32(10000), # microseconds
0025 readv = cms.untracked.uint32(10000), # microseconds
0026 exclude = cms.untracked.vstring(...),
0027 )
0028 )
0029 ))
0030 ```
0031 The `StorageAddLatencyProxy` is described in [`Utilities/StorageFactory/README.md`](../../Utilities/StorageFactory/README.md). Another useful component in this context is `StorageTracerProxy` (e.g. to find out the other-than-`PoolSource`-accessed files mentioned above)
0032
0033
0034 ## Short description of components
0035
0036 ### `ClientRequest`
0037
0038 The `ClientRequest` implements `XrdCl::ResponseHandler`, and represents a single read request(?).
0039
0040 ### `QualityMetric`
0041
0042 The `QualityMetric` implements a measurement of the server's recent performance for the client. It's based on the time taken to service requests (under the assumption that, since requests are split into potentially smaller-chunks by the request manager, the time to service them should be roughly the same) with a small amount of exponential weighting to prefer data points from the most recent request.
0043
0044 Since the metric is based on time to serve requests, a lower value is better.
0045
0046 Potential improvements include:
0047 * Actually weighting the scores based on the size (or complexity) of the reads. The assumption that latency dominates transfer time may be OK in some cases -- but we've seen for large files (e.g., heavy ion), that bandwidth really is relevant and that large vector reads can cause much more server stress due to read amplification for erasure-coded systems than a simple read.
0048 * Switching from the hand-calculated exponential weighting to a more typical exponentially weighted moving average setup.
0049
0050
0051 ### `RequestManager`
0052
0053 The `RequestManager` containes the actual implementation of the retries and the multi-source algorithm. There is one `RequestManager` object for one PFN, and it contains one or more `Source` objects.
0054
0055 #### `RequestManager::OpenHandler`
0056
0057 The `OpenHandler` implements XRootD's `XrdCl::ResponseHandler` in an asynchronous way. An instance is created in `RequestManager::initialize()`, and used when additional Sources are opened, either as part of the multi-source comparisons (`RequestManager::checkSourcesImpl()`) or read error recovery (`RequestManager::requestFailure()`).
0058
0059 Most of the internal operations for the xrootd client are asynchronous while ROOT expects a synchronous interface from the adaptor. The difference between the two here is the asynchronous one is used for "background probing" to find additional sources.
0060
0061 ### `Source`
0062
0063 The `Source` represents a connection to one storage server. There can be more than one `Source` for one PFN.
0064
0065 ### `SyncHostResponseHandler`
0066
0067 The `SyncHostResponseHandler` implements XRootD's `XrdCl::ResponseHandler` in a synchronous way(?). It is used in `RequestManager::initialize()` for the initial file open.
0068
0069 ### `XrdFile`
0070
0071 The `XrdFile` implements `edm::storage::Storage` (see [Utilities/StorageFactory/README.md](../../Utilities/StorageFactory/README.md). In CMS' terminology it represents one Physical File Name (PFN), and acts as a glue between the `edm::storage::Storage` API and `RequestManager`.
0072
0073 ### `XrdStatistics`
0074
0075 The `XrdStatistics` provides per-"site" counters (bytes read, total time), providing the `XrdStatisticsService` with a viewpoint of how individual sites are performing for a given client. The intent is to provide more visibility into the performance encountered by grouping I/O operations into a per-site basis, under the theory that performance within a site is similar but could differ between two different sites.
0076
0077 ### `XrdStatisticsService`
0078
0079 The `XrdStatisticsService` is a Service to report XrootD-related statistics centrally. It is one of the default Services that are enabled in `cmsRun`.
0080
0081 ### `XrdStorageMaker`
0082
0083 The `XrdStorageMaker` is a plugin in the `StorageMaker` hierarchy. See [Utilities/StorageFactory/README.md](../../Utilities/StorageFactory/README.md) for more information. Among other things it creates `XrdFile` objects.
