logo
podcast Podcast
get help Get Unstuck

Find out what's slow BEFORE you deploy to prod

The earlier you find an issue, the better! How can we improve our chances of finding slow code before it reaches production?

Joel Clermont
Joel Clermont
2023-08-15

Yesterday's email was a tip about how to make an Eloquent query faster, but this raises an important issue: How do you know something is slow and needs to be optimized?

Usually, when a developer is working on features, they're using a local environment which has a very minimal database. The schema is identical to production, but the amount of data in the tables is usually very small, and not at all representative of how big the production tables are (or will become over time).

For example, a query might run in 2 ms locally with 100 records, but if the production table has 2 million records, that same query could easily take several seconds. Even worse, some queries become so inefficient with large datasets, they might run long enough to encounter connection timeouts and the request fails completely.

One option for preventing this is to periodically grab a snapshot of production data to use for local testing. This option is great, if you can do it, because it's a near-perfect replication of that production environment. But depending on your industry, and the type of data stored in the database, this may bring security and privacy challenges. You could have a process to "anonymize" or "sanitize" these production data dumps, or you may just not be able to use this approach at all for your project.

If you can't obtain a production snapshot of data, you can still create a production-like dataset locally using Laravel seeders. With a seeder, you can just as easily create 1 million records as you can create a single record, so get some statistics from production, and build your seeders to create roughly the same amount of records locally. It's also useful to use Laravel factories with different states to create some variety to this data. If you're querying or filtering on a status field, you probably don't want all 1 million rows to have the exact same status.

Setting this up does take some effort, but it's worth it when it helps you identify a missing database index or an inefficient query before that gets shipped to production and affects your users.

Here to help,

Joel

P.S. You think this tip is good? You should try our free book of even more Laravel tips to make your application a little bit better.

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼
email
No spam. Only real-world advice you can use.