Local development environment configuration

[Simone Nardi]

Hi,

I’m setting up the local development environment with VS Code + Docker. The environment is already configured and partially working, but I have a question about the database and wanted to understand how you handle it.

I imported the official SQL dump into the Docker volume, but with the full database the queries become extremely slow locally: without Elasticsearch, some queries take 2–3 minutes to run.

So I wanted to ask how you normally configure the development environment:

• Do you use the full SQL dump or the minimal database version, without data?
• Do you also use Elasticsearch in the local environment?
  

Thanks

Simone

[Jochen G.]

Am 16.09.26 um 19:33 schrieb Simone Nardi:

> I imported the official SQL dump into the Docker volume, but with the
> full database the queries become extremely slow locally: without
> Elasticsearch, some queries take 2–3 minutes to run.

Long query times I observe for some complex queries, but most are
reasonably fine ? Maybe your MySQL / MariaDB settings are off ?

> So I wanted to ask how you normally configure the development environment:
>

> * Do you use the full SQL dump or the minimal database version,
> without data?
> * Do you also use Elasticsearch in the local environment?

I don't use Elasticsearch locally.

Jochen

[Simone Nardi]

Hi Jochen,

yes, it's definitely a configuration issue on my side.

I've tried the latest Docker / Docker Compose configuration and performance has improved considerably. In the past, when I tried to address the performance issue with AI assistance, it tended to make rather extensive changes to the Docker setup in an attempt to improve performance, which probably complicated things unnecessarily.

I'll keep investigating the MariaDB/MySQL settings on my side.

The important information for me was knowing that you don't use Elasticsearch locally. That gives me a useful reference point for how to configure my environment.

Thanks, Simone

--
You received this message because you are subscribed to the Google Groups "gcd-tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gcd-tech+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gcd-tech/e895861d-3dc3-4321-97bf-4359c7b5056e%40garcke.de.

[Simone Nardi]

My bad! I was taking an old approach and doing a lot of things manually. I hadn't seen Adam H.'s updates with 

./bin/dev setup --dump ~/Downloads/current.zip --replace --yes

I completely wiped all files, cleaned up Docker, and started a fresh setup from scratch. 

If I don't reply back, it means everything is working fine now.

Thanks

Simone

[Adam Hernandez]

Simone, 

If you run into any problems, let me know and we can figure it out together. 

Adam

[Simone Nardi]

Hi,

The entire environment was installed without any issues, but the slowness persists.

For example, a search for "Batman" with the default "Series Name" filter takes about a minute and a half:

2026-09-21 14:18:16  gcd-django-dev/web  [21/Sep/2026 12:18:16] "GET /search/?search_type=series&query=batman&sort=alpha HTTP/1.1" 302 0

Direct links to the results open quickly.

Simone

[Simone Nardi]

Analysis

Astra was asked to analyze the installation, starting with the bind mount and Docker, because it seemed possible that the problem was there. In reality, the bind mount was not the main cause: MySQL uses the gcd-django-dev_mysql_data volume, so the data is outside the Windows mount. The evidence is pretty clear: with exactly the same environment, the homepage goes from 19.3 s to 89 ms simply by removing the authors timeline calculation, which queried five tables and counted authors/comics even when that section was not displayed (USE_TEMPLATESADMIN=False).

The second issue is MySQL: the database is about 7.4 GiB, while innodb_buffer_pool_size was only 128 MiB. During the tests there were around 195,000 cache misses and 88,000 waits for buffer pages.

At the same time, a “Nathan Never” search was still running in the browser. It also searched the titles of around 2.3 million issues using LIKE '%nathan never%', increasing the pressure on MySQL. The same search also exposed a missing reference to an issue from “Nathan Never gigante”, which caused the page to fail. This is now handled without modifying the catalog: if the issue is missing, the series years are used instead.

The first version changed 9 files; after reviewing them, only the changes that were actually necessary were kept, without removing any functionality. The search still returns the same 47 results and goes from 7.8 s to about 3.2 s.

Final result: 50 tests passed, the homepage is around 100 ms, and the search is 3.23 s after the cache is warmed up (17.6 s for the first search after a restart).

The increase of the buffer pool to 1 GiB was deliberately left out of the application changes; it remains a separate configuration decision.

Simone

[Adam Hernandez]

Simone, 

I'll address this issue in a follow up PR shortly. 

Adam