Latest revision as of 18:39, 6 July 2016

Introduction

In this section a number of varied queries submitted in the production infrastructure, along with the response times of the gCube system are recorded. The target is to evaluate the performance of the search functionality provided by D4science services.

When submitting a query from the D4science portal, the procedure that is followed until the first results are retrieved is the following:

• The Application Support Layer constructs the query according to the SearchMaster Syntax
• It communicates with IS, in order to retrieve the EPRs for the search master running instances
• The query is submitted to the SearchMaster
• SearchMaster finds and returns a ResultSet EPR
• The results are retrieved

Available Resources

During the time the testing was performed, the available resources in the infrastructure were the following:

• AATSR Products
  • EM Advanced Along-Track Scanning Radiometer (AATSR) Data Set: Daily Products
    • Number of records: 1320
  • EM Advanced Along-Track Scanning Radiometer (AATSR) Data Set: Monthly Products
    • Number of records: 46
  • EM Advanced Along-Track Scanning Radiometer (AATSR) Data Set: Products
    • Number of records: 18.032
  • EM Advanced Along-Track Scanning Radiometer (AATSR) Data Set: Yearly Products
    • Number of records: 5
• Earth Images
  • EM ESA Earth Images
    • Number of records: 1270
• Key Documents and Reports
  • EM ESA special issues Living Planet Programme and Earth Observation Handbook
    • Number of records: 4
  • EM Mediterranean Action Plan (MAP) Technical Reports
    • Number of records: 178
• Meris Level-3 Products
  • EM MERIS Level-3 Chlorophyll in water
    • Number of records: 7
  • EM MERIS Level-3 Global Vegetation Index
    • Number of records: 7
• Landsat7 Products
  • EM Landsat7
    • Number of records: 12
• European Environment Agency Reports
  • European Environment Agency: Brochures
    • Number of records: 12
  • European Environment Agency: Corporate Documents
    • Number of records: 38
  • European Environment Agency: EEA Briefings
    • Number of records: 16
  • European Environment Agency: EEA Reports
    • Number of records: 38
  • European Environment Agency: Environmental Assessment Reports
    • Number of records: 12
  • European Environment Agency: Environmental Issue Reports
    • Number of records: 45
  • European Environment Agency: Environmental Monographs
    • Number of records: 5
  • European Environment Agency: Expert's Corners
    • Number of records: 3
  • European Environment Agency: Other Reports
    • Number of records: 90
  • European Environment Agency: State of the Environment Reports
    • Number of records: 7
  • European Environment Agency: Technical Reports
    • Number of records: 100
  • European Environment Agency: Topic Reports
    • Number of records: 100

Query Response Times Sum-up Table

Query Response Times Sum-up Table v2 - SearchMaster readings (rel1.7)

Testing environment

VRE

/EM/GCM

Search GHN

node19.p.d4science.research-infrastructures.eu

log4j default level

INFO

RS EPR Cache

disabled

Readings procedure

Median of three readings, taken in a hot search status (not currently performing any reharvest or garbage collection)

Readings

Time until a result set endpoint reference is returned as response. Note that this does not mean that the actual data are generated.

Readings

Comments

Specific Services

XMLIndexer

Faster than FTIndex in most cases. Very good in low load. Problem in multiple, parallel invocations in the same node. At heavy loads, it gets stuck for some minutes until some cleaning procedure takes place. E.g. XMLIndexer service stuck after 6 parallel invocations. MMFactory, running at the node node, was also stuck.

FTIndex

In some nodes it's extremely slow (more than one second). In other nodes it is faster but again not as fast as it should be. This means that there is CPU or memory overload. Further analysis is necessary. FTIndex resources can cope with huge loads but with large delays (@query no13, each FTIndex resource responded after 30sec).

DIR

Not as fast as it should be. It may not operate in non-blocking mode so its delay may be the result of waiting for the full input RS payload to become available.

Merge

Shows significant delay at producing the first result set part.

General

• Irregularities in performance, especially in large queries (such as No 13). We got back execution times that range from 17 seconds up to INF (resources didn't respond at all).
• Irregular response time of RS. Significant delay of reading the first RS part.
• We still need to stress-test IndexFuse operator.
• Rarely IS seem to be stuck (completely unresponsive). IS Monitoring did not show any RIs or resources. IS comes back after some minutes (usually 15').
• Parallelization of MMFactory (merge of many MMFactory invocations instead of a single invocation) leads to great performance enhancement.
• In the current scheme, FTIndexes are more or less useless, since XMLIndexer resources deliver data much faster than the FTIndexer (let alone the combination of MMFactory and FTIndexer).

Search Framework

See here