Is the long
processing time for the Engine caused by limitations of hardware
resources?
o Identify whether long
query time is caused by CPU, memory, or disk I/O utilization.
Is a high number of records being returned by the MDEX
Engine?
o Identify how many records are being returned per query by
looking for large nbins values in queries as reported by
Cheetah(Performance Monitoring Tool). If this number is high, this can be
expensive to compute and affects performance.
Are all dimension refinements (dimension values) exposed for
navigation?
o Identify whether all dimension refinements are exposed by
looking forallgroups=1 in the Dgraph request log (request URL
parameter) or in Cheetah reports
Are your longest queries similar?
o Check the longest queries for similarities, such as whether
they all use the same search interface with relevance ranking, wildcard search,
or record filters.
Is record search being used?
o Identify whether a record search is being used by any queries
by looking for “attrs=search_interface_name” in a query. This indicates that
a record search is being used which means that possibly expensive relevance
ranking modules can be contributing to high computation time
Which relevance ranking strategies are being used?
o Check the CRS.relrank_strategies.xml file for the
presence of Exact, Phrase and Proximity ranking modules and test the same query
with these modules removed.
Is sorting enabled for properties or dimensions?
o Identify whether sorting with sort keys is enabled, for which
properties and dimensions it is being used and whether it is needed.
o The first time a sort key is issued to a Dgraph after startup
the key must be computed which can slow down performance. To isolate this
problem, test the query in the staging environment by removing the sort
key.
o If you confirm sort keys are the issue, consider using sort
keys in a representative batch of queries used to warm up the Dgraph after
startup.
o The sorts will become cached and these queries will be
faster.
