Nuxeo performance, part 1: queries and response serialization

Measure the request before changing the infrastructure

A slow content page can spend time in several places: executing the query, loading matching documents, resolving references, serializing the response or rendering the interface. Measure those stages before choosing a database or search change.

The original June 2022 account focused on page providers and document-reference serialization. Its results described a particular project. Use the diagnostic sequence below without treating that project's improvement as a forecast for another repository.

Establish a repeatable baseline

Select a slow request and record the user permissions, query, page size, requested schemas and result size. Capture more than one run so cache effects are visible. Keep the same representative data and access level when comparing a proposed change.

Check whether the browser is issuing repeated requests or asking for fields it never displays. A faster server response will not resolve redundant client work.

Review the query path and freshness requirements

Nuxeo page providers package query and pagination behavior. Review the configured provider rather than assuming every listing follows the same backend path. Page providers

The older article discusses Elasticsearch-specific configuration. Nuxeo LTS 2025 removed ElasticSearchService in favor of SearchService, so those older class and configuration examples must not be copied unchanged into an LTS 2025 upgrade. Search migration guide

Test immediate changes as well as steady-state queries. Agree how quickly an edited document must appear in the results, and validate the selected search path against that requirement.

Inspect response serialization

The original case also described extra work when document-reference fields were resolved during JSON serialization. Inspect the returned payload and trace the work needed to construct it, particularly for results containing many references.

Nuxeo's marshalling documentation explains request context, properties and parameters. Use that reference to identify what the consumer actually requires before narrowing a response. Re-test callers that rely on the omitted fields. Parameterizing marshallers

Validate the complete user task

Compare request latency, response size, error rate and the time needed to complete the task. Include restricted users and recently changed documents. Report the data size, release and configuration with any improvement, so the result remains reproducible.

Continue with part 2, or bring a representative slow request to Maretha's performance optimization team.