Memory leak in SSR (ex. using Nuxt)

Bug 🐞

I’m using the default example from the documentation.

What is the current behavior?

Visiting pages with Algolia components cause the memory to continue to grow up without stopping. After ~ 1000 urls (depends on how much HTML there is in page) the server is out of memory.

<— Last few GCs —> [10712:0000019808B1C120] 4706234 ms: Scavenge 1361.0 (1423.8) -> 1360.1 (1424.3) MB, 3.0 / 0.0 ms (average mu = 0.270, current mu = 0.276) allocation failure [10712:0000019808B1C120] 4706244 ms: Scavenge 1361.2 (1424.3) -> 1360.4 (1424.8) MB, 3.2 / 0.0 ms (average mu = 0.270, current mu = 0.276) allocation failure

==== JS stack trace ========================================= FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

What is the expected behavior?

The GarbageCollector can free up the memory after every page reload.

Does this happen only in specific situations?

Placing components (ex. like <ais-hits />) inside <ais-instant-search-ssr />.

What is the version you are using?

• “nuxt”: “^2.4.5”,
• “algoliasearch”: “^3.32.0”,
• “vue-instantsearch”: “^2.0.0”

The bug persist updating to

• “nuxt”: “^2.8.1”,
• “algoliasearch”: “^3.33.0”,
• “vue-instantsearch”: “^2.2.1”
• “instantsearch.js”: “^3.5.3”,

[samouss]

Thanks a lot for the issue! Indeed we have a problem inside our SSR documentation example. The issue comes from the fact that only one instance is created for all the requests made to the server. It means that everything is always added to the exact same instance. This only happens with Nuxt though. The plain SSR example correctly scopes the instance of InstantSearch to each request.

You can definitely avoid this memory leak with the API provided by Vue InstantSearch, but it will require some manual plumbing for the moment. It’s definitely not the best solution but the advantage is that you can use this solution right away. We’ll investigate a solution to provide better integration with Nuxt in the next weeks (probably through a Nuxt module).

The first step is to move the creation of the InstantSearch outside of the main module. We’ll create a Nuxt plugin for that. The plugin is called on each request and allow us to inject values into the App.

// plugins/vue-instantsearch.js

import algoliasearch from "algoliasearch/lite";
import { createInstantSearch } from "vue-instantsearch";

export default function VueInstantSearchPlugin(_, inject) {
  const searchClient = algoliasearch("YOUR_APP_ID", "YOUR_API_KEY");

  const { instantsearch } = createInstantSearch({
    indexName: "YOUR_INDEX_NAME",
    searchClient
  });

  inject("instantsearch", instantsearch);
}

Now that we have the plugin, we have to add it to the nuxt.config.js.

// nuxt.config.js

module.exports = {
  // ... 
  plugins: ['~/plugins/vue-instantsearch.js'],
};

The final part is to update how the data is retrieved from the page component.

// pages/search.vue

export default {
  // ...
  provide() {
    return {
      // It was provided by the `rootMixin` but it's not possible to have access
      // to it anymore. That's why we have to provide it manually. The plugin
      // is in charge of exposing `$instantsearch` on the App instance.
      $_ais: this.$instantsearch
    };
  },
  asyncData(context) {
    // We are now able to access the instance through the context
    const $instantsearch = context.app.$instantsearch;

    return $instantsearch
      .findResultsState({
        // ...
      })
      .then(() => ({
        algoliaState: $instantsearch.getState()
      }));
  },
  beforeMount() {
    this.$instantsearch.hydrate(this.algoliaState);
  }
};

I’ve run some tests on the two different implementations. I monitor the usage of the memory after some request to the server (1 request, 1000 requests, see below). I hope this solution will fix the problem.

	1 request	1000 requests
With the issue	29.6MB	301MB
Without the issue	29.7MB	31.6MB

You can find the complete example on GitHub.

[Haroenv]

That makes sense, however I’d rather have a fresh issue for v3 with reproduction, there could be some unrelated issues