TG for DLS using WCS (generic sections to cull or slash): Quality of Service
In the recently uploaded 'Technical Guidance for the implementation of INSPIRE Download Services using WCS' straw-man document based on the existing 'Technical Guidance for the Implementation of INSPIRE Download Services (version 3.1)' I have kept in several sections that appear to be generic, so for example I have kept in (currently chapter 7) the Quality of Service section. As far as I can see this is completely generic. I don't see any reason why a download service using WCS should have any different expectations put upon it for quality of service than for example a download service using WFS; it is essentially a question of transferring some number of bits of data across a network in a reasonable set of time.
Looking at the language of the section it appears to be mostly generic, the only change that I think we might want to reflect WCS operataions over say WFS operations is in:
TG Requirement 13 For Get Spatial Object operations, the sample reference request shall Contain a BBOX parameter. and
TG Recommendation 3 For Get Spatial Object operations, the sample reference request is recommended to return at least 1 MB.
For the Get Spatial Object operation, if the BBOX parameter is random it is recommended that the last 100 responses to a reference request have an average of at least 1 MB
The use of the term BBOX here (which is undefined in the section) is aligned to a WFS request parameter, and it might be better to change this to something more generic like simply a bounding box or one (or more) coordinate subsetting parameters...
For the Quality of Service section do we want to:
- cull this section altogether (and not request any changes to the generic text that will apear in the generic downlaod service TG
- cull this section altogether (and request changes suchas BBOX to the generic text that will apear in the generic downlaod service TG
- keep the section and make slight changes as required
#1 Updated by Jukka Rahkonen almost 5 years ago
I was trying to think what some parts in the Quality of service mean in practice if each GetCoverage is, let's say 1 GB.
- Initial response time must be 10 seconds at maximum
- Download speed must by 0.5 MB/sec at minimum
- The maximum allowed duration till complete download is 34 minutes
- The minimum number of simultaneous requests to a download service to be served in accordance with the quality of service performance criteria shall be 10 requests per second. The number of requests processed in parallel may be limited to 50
- Should the total throughput of the download service be at least 10 x 0.5 = 5 MB/s or 50 x 0.5 = 25 MB/sec?
- It can be hard and inefficient for some servers to handle 50 or even 10 requests of 1 GB in parallel because each process can take quite a lot of memory. However, maintaining a steady throughput rate 25 MB/sec should not be any problem if requests are processed serially or only a few in parallel.
- When the first burst of requests are getting served, during the 34 minutes, what should happen to the new incoming requests? Should they be put into a queue or would it be better to send a service exception "Service full"?
- Knowing how MapServer and GeoServer WCS work, the initial 10 s response time for any bigger output size is impossible for those servers because they are creating the whole output on the server side before they start sending it out.
I guess that clever programmers could develop an Inspire download service frontal that is putting the requests into a queue and sends some initial response within 10 seconds to fulfill the letter of the requirements but is it necessary? Some of the problems must occur also with WFS. Processing vectors may not require as much memory but the whole output must still be ready on the server side before the first bit is sent. That's because there is a compulsory feature count element in the beginning of the GML file which prevents streaming while the process is still running because the feature count is known only after the output is ready.
#2 Updated by James Passmore almost 5 years ago
- Status changed from New to Feedback
No answers just a few more questions...
Unless a service provider publishes their maintenance schedule, how will an external tester know when they should test? Does this mean that testing will always be initiated by the service provider?
Does this mean that a service operator can effectively modify their service for testing, test, then revert the system post testing...
Is the intention here that ALL of these operations must be used to test a service, or just that tests will be run on a collection of some of these operations (as appropriate). If the former then how do you test an Atom service (it doesn't have any Spatial Object operations), if the latter who chooses?
If we say that Spatial Object operations are part of a direct access service, and Spatial Data set operations are part of a pre-defined service (like Atom), does that mean that BBOX operations are not part of a predefined WCS service.
#3 Updated by Jukka Rahkonen almost 5 years ago
About , there seems to be TG recommendation 18:
The structure of the sample reference request packages is recommended to be composed of:
10% Get Download Service Metadata requests,
10% Describe Spatial Data Set or Describe Spatial Object Type and
80% Get Spatial Data Set or Get Spatial Object.
At least 2% of the requests should be Get Spatial Data Set.
Did we already define what is Get Spatial Object in WCS context?
#4 Updated by James Passmore almost 5 years ago
Jukka Rahkonen wrote:
Did we already define what is Get Spatial Object in WCS context?
I think this is still up for discussion but looking at the existing technical guidelines, Get Spatial Object is an optional conformance class related to a direct access service, allowing for the retrieval of spatial objects based upon a query. As we have said that a core WCS service maps to a predefined-dataset service (not a direct access service), we COULD argue that a Get Spatial Object operation cannot be part of a core WCS service.
#5 Updated by Jukka Rahkonen almost 5 years ago
The recommandation about the test request packages in Quality of service says that the package contains:
80% Get Spatial Data Set or Get Spatial Object, At least 2% of the requests should be Get Spatial Data Set.
If WCS download service will not have equivalent to Get Spatial Object this recommendation would mean that all these 80% of the test requests would be Get Spatial Data Set. That could be quite a heavy test if coverages are big. It seems that either the recommendation about the test packages should be edited to suit WCS, or we should somehow map reasonably sized WCS subsets as Get Spatial Object.