Quality of Service Provisioning¶
The Dydra service provides a quality of service settings in order to isolate graph store service requests from other processing and to guarantee and/or limit resource for applications by identity and class. These provisions are governed by settings in the account settings repository
https://dydra.com/<account>/system
The repository includes two graphs are present to contain the quality of service settings:
<http://dydra.com/quality-of-service><http://dydra.com/quality-of-service/views>
As this is an internal repeository, managing these settings is mediated through another account repository
https://dydra.com/<account>/quality-of-service
Its contents correspond to a simple schema
<http://dydra.com/quality-of-service/class>
rdf:type rdf:Property ;
rdfs:domain <urn:dydra:View> ;
rdfs:domain <http://dydra.com/quality-of-service/class>;
rdfs:range <http://dydra.com/quality-of-service/class> .
For example (with qos: <http://dydra.com/quality-of-service/> )
<http://dydra.com/quality-of-service/views> {
<http://dydra.com/accounts/nxp/repositories/plm__rev/views/ebi_lz> qos:class qos:class/EBI .
<http://dydra.com/accounts/nxp/repositories/plm__rev/views/getListOfItemsForType> qos:class qos:class/PLM-VIEWS .
<http://dydra.com/accounts/nxp/repositories/plm__rev/views/plm_die_search> qos:class qos:class/PLM-VIEWS .
<http://dydra.com/accounts/nxp/repositories/plm__rev/views/ebiz_select_sales_item> qos:class qos:class/EBIZ .
<http://dydra.com/accounts/nxp/repositories/plm__rev/views/vcp_wafertestsheet-teststage-udm_redline> qos:class qos:class/VCP .
}
<http://dydra.com/quality-of-service> {
qos:class/EBI qos:class qos:class/Application .
qos:class/PLM-VIEWS qos:class qos:class/Application .
qos:class/VCP qos:class qos:class/HighResource .
qos:class/EBIZ qos:class qos:class/Application .
qos:class/HighResource qos:quality qos:class/Queued .
qos:class/Reporting qos:quality qos:class/Scheduled .
qos:class/Application qos:quality qos:class/SPARQL .
}
The quality-of-service repository is available through the standard service API.
This permits update query operations and imports through the graph store protocol.
https://dydra.com/<account>/quality-of-service/service
PUT¶
A PUT operation to this repository replaces all view service quality settings.
A PATCH operation propagates changes to the repository content to the respective <account>/system repository,
from where they are used to generate the nginx request routing locations which determine service response priority.
Headers¶
Content-Type: text/csv
Among the alternative is TARQL import via the repository qos-import view:
## this is a csv import view for qos settings
construct {
graph <http://dydra.com/quality-of-service/views> {
?view qos:class ?class .
}
}
where {
{ select ?Classification ?APPLICATION ?ViewName ?FREQUENCY ?SAMPLE_URL
where {} }
bind(uri(concat('http://dydra.com/accounts/nxp/repositories/plm__rev/views/', ?ViewName)) as ?view)
bind(uri(concat('http://dydra.com/quality-of-service/class/', replace(if(contains(?APPLICATION, '('), strbefore(?APPLICATION, '('), ?APPLICATION), ' ', '-'))) as ?class)
}
| Content-Type: application/n-quads, application/trig
The standard quad media types can be used to import content into the repository.
POST¶
A POST request contributes additional view classifications or augments the classification hierarchy.
GET¶
A GET operations retrieves
The repository also backs a SPARQL endpoint, to which standard queries can be set.
These view settings are combined with the specifications for available service resources are described in the system configuration,
in the system/system``repositors, where entries in the ``<http://dydra.com/quality-of-service> graph follow the schema
qos:server>
rdf:type rdf:Property ;
rdfs:domain qos:class ;
rdfs:range rdfs:Literal .
These combined settings translate into a configuration which governs the operation of the service interface proxy by specifying routing locations and associating each with processing resources. These appear, for example, as
location ~ ^/nxp/plm__rev/vcp_wafertestsheet-teststage-udm_redline $ {
limit_req zone=api burst=8;
proxy_pass http://Queued;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
client_max_body_size 256m;
}
upstream Queued {
server 127.0.0.1:8101;
}
upstream Administration {
server 127.0.0.1:8199;
}
upstream SPARQL {
least_conn;
server 127.0.0.1:8104;
server 127.0.0.1:8103;
server 127.0.0.1:8102;
}
upstream Scheduled {
least_conn;
server 127.0.0.1:8106;
server 127.0.0.1:8105;
}
upstream Service {
least_conn;
server 127.0.0.1:8107;
}