Laravel Rescue & Maintenance: How I Diagnose Slow Applications

Introduction

A slow Laravel application does not automatically need a rewrite.

That was the point behind my previous LinkedIn post about slow Laravel applications, which generated approximately 3,000 impressions. The more important question is what happens after someone reports that an application is slow, unreliable, or becoming difficult to maintain.

I do not start by changing the framework.

I start by finding evidence.

A Laravel application can become slow because of an inefficient database query, N+1 relationships, missing indexes, synchronous processing, poor caching, overloaded PHP-FPM workers, external API latency, queue configuration, infrastructure constraints, or several smaller problems interacting with each other.

Those problems require different solutions.

My general approach is:

Problem → Investigation → Evidence → Root Cause → Solution → Validation

The objective is not to make an application appear faster temporarily. The objective is to understand what is actually happening, fix the smallest meaningful problem, and verify that the change solved the underlying issue.

Why Diagnosis Comes Before a Rewrite

When an existing application becomes slow, rewriting it can appear attractive.

The reasoning is understandable:

“The codebase is old. Let’s rebuild it.”

But age alone does not establish that the architecture is incapable of meeting the requirement.

A rewrite introduces its own risks:

• New bugs
• Feature regression
• Data migration complexity
• Authentication and authorization differences
• Integration problems
• Business-rule inconsistencies
• New deployment processes
• Development cost
• Extended delivery time
• Loss of undocumented business knowledge

That does not mean rewrites are always wrong.

There are situations where an architectural change or rewrite is justified. The important point is that the decision should follow evidence.

If a request takes five seconds, I want to know where those five seconds are being spent before deciding what technology should replace the existing implementation.

A useful diagnostic question is:

Is the application fundamentally incapable of meeting the requirement, or is the current implementation simply inefficient?

Those are very different problems.

My Laravel Rescue & Maintenance Methodology

When investigating an existing Laravel/PHP system, I generally move through eight stages.

1. Understand the Symptom

What exactly is failing?

• Homepage takes several seconds
• API response is slow
• Reports time out
• Queue jobs remain pending
• Database CPU is high
• Production errors occur intermittently
• Deployment fails
• Memory usage keeps increasing

2. Reproduce

Can the problem be reproduced?

A reproducible problem gives us something measurable to investigate.

3. Measure

Collect evidence rather than relying on assumptions.

Depending on the problem, this could include:

• Request duration
• Query count
• Query duration
• CPU usage
• Memory usage
• Disk I/O
• Queue latency
• PHP execution time
• External API duration
• Error frequency

4. Trace

Follow the request through the system.

Client
  ↓
Nginx / Apache
  ↓
PHP-FPM
  ↓
Laravel middleware
  ↓
Controller
  ↓
Service / business logic
  ↓
Database / Redis / external APIs
  ↓
Serialization
  ↓
Response

5. Isolate

Determine which layer is actually responsible.

• Laravel
• PHP
• MySQL
• Redis
• Queue workers
• External APIs
• Nginx
• Apache
• PHP-FPM
• Infrastructure

6. Fix the Smallest Meaningful Problem

Do not redesign the entire application because one query is inefficient.

7. Test

Verify both functionality and performance.

8. Monitor

A fix is not fully validated merely because one test request became faster. The system needs to remain healthy after deployment.

Diagnosing a Slow Laravel Application

The first mistake I try to avoid is treating “slow” as a root cause.

Slow is a symptom.

The first question is:

What is consuming the time?

For a slow request, I want to separate the total latency into components.

Total request time
│
├── Application execution
├── Database queries
├── External API calls
├── Cache operations
├── Serialization
├── Network latency
└── Infrastructure / process waiting

A Laravel page could spend most of its time in the database.

Another endpoint could spend most of its time waiting for an external API.

Another might be waiting for an available PHP-FPM worker.

The solution changes depending on the evidence.

What I Investigate

Request Latency

How long does the request actually take?

Is it consistently slow or only slow under load?

Database Time

How many queries are executed?

How long do they take?

Are similar queries being repeated?

PHP Execution Time

Is the application spending significant CPU time executing business logic?

External API Latency

Is Laravel waiting for another service?

Queue Delays

Is work being performed synchronously that should happen asynchronously?

Or are queued jobs simply not being processed fast enough?

Cache Behavior

Is the cache actually being used?

Are cache misses frequent?

Is the application repeatedly calculating expensive data?

Server Resources

I also look at:

• CPU
• RAM
• Swap
• Disk I/O
• Network
• PHP-FPM capacity
• Database resources

Increasing server capacity can sometimes reduce the visible symptom. It does not necessarily remove the underlying bottleneck.

N+1 Database Queries

N+1 is one of the classic examples of a problem that can hide inside otherwise clean-looking Laravel code.

Consider:

$properties = Property::latest()->get();

foreach ($properties as $property) {
    echo $property->developer->name;
}

At first glance, this is straightforward.

But if developer is lazily loaded, Laravel may execute another query when accessing the relationship for each property.

Conceptually:

1 query → retrieve properties

+ 1 query → developer for property 1
+ 1 query → developer for property 2
+ 1 query → developer for property 3
...

The number of queries can therefore grow with the number of records being processed.

Improved Approach

$properties = Property::query()
    ->with('developer:id,name')
    ->latest()
    ->get();

foreach ($properties as $property) {
    echo $property->developer?->name;
}

Now the relationship is intentionally loaded rather than accidentally triggered one record at a time.

But eager loading is not automatically the answer to every relationship problem.

If an endpoint loads a large number of relationships that the response never uses, eager loading can create another performance problem.

That is why I look at:

• Which relationships are actually needed?
• How many records are involved?
• Which columns are required?
• How many queries are generated?
• How much memory does the resulting dataset consume?

Laravel provides tools such as with(), load(), and withCount() for deliberately controlling relationship loading.

The important distinction is between loading relationships intentionally and allowing relationship access to generate database traffic accidentally.

Missing or Ineffective MySQL Indexes

A query can be perfectly valid SQL and still perform badly at scale.

When investigating a slow query, I do not immediately add an index. I first inspect the query and its execution plan.

For example:

SELECT *
FROM properties
WHERE developer_id = 25
  AND status = 'published'
ORDER BY created_at DESC;

The investigation becomes:

Query
  ↓
EXPLAIN
  ↓
Execution plan
  ↓
Rows examined
  ↓
Indexes considered / used
  ↓
Finding
  ↓
Index decision
  ↓
Re-test

EXPLAIN helps reveal how MySQL intends to execute a query, while EXPLAIN ANALYZE can provide actual execution information for supported MySQL versions.

What I Look For

• Access type
• Possible indexes
• Chosen index
• Estimated rows
• Filtering
• Join behavior
• Temporary operations
• Sorting
• Table scans

I also consider the query’s:

• WHERE clauses
• JOIN conditions
• ORDER BY
• GROUP BY

An index must support the actual workload.

Composite Indexes

For a query involving multiple columns, a composite index may be more appropriate than several unrelated indexes.

Schema::table('properties', function (Blueprint $table) {
    $table->index(
        ['developer_id', 'status', 'created_at']
    );
});

But this should not be added simply because those three columns appear in a query.

Index order matters.

So the process should be:

Query
→ Execution plan
→ Data distribution
→ Existing indexes
→ Index design
→ Test

Indexes also have costs. They consume storage and add work to inserts, updates, and deletes.

The goal is not “more indexes.”

The goal is the right indexes for the actual workload.

Inefficient Eloquent Queries

Sometimes the database is not the fundamental problem.

The way the application constructs the query is.

Some common patterns I investigate include:

• Selecting unnecessary columns
• Loading nested relationships unnecessarily
• Repeating database queries
• Queries inside loops
• Filtering large datasets in PHP
• Excessive collection processing
• Calling get() when a smaller operation is sufficient
• Fetching an entire dataset instead of paginating
• Repeated existence checks
• Large in-memory result sets

For example:

$users = User::get();

$activeUsers = $users->filter(
    fn ($user) => $user->is_active
);

If the database can perform the filtering, it is generally more appropriate to express the condition in SQL:

$activeUsers = User::query()
    ->where('is_active', true)
    ->get();

The principle is simple:

Do not retrieve thousands of rows merely to discard most of them in PHP.

Choosing the Right Retrieval Strategy

select()

Use it when only specific columns are required.

User::select('id', 'name', 'email')->get();

whereHas()

Useful when filtering records based on relationships.

whereExists()

Useful when the requirement is fundamentally an existence condition rather than retrieving related records.

with()

Useful for intentional eager loading.

withCount()

Useful when the requirement is a count rather than the complete relationship.

Pagination

Useful for user-facing datasets where only one page needs to be returned.

chunk() and chunkById()

Useful when processing large datasets without loading everything into memory.

cursor() and lazy()

Useful for certain streaming or incremental processing scenarios, with their own trade-offs.

There is no universal “fastest” method.

The correct choice depends on:

• Dataset size
• Access pattern
• Ordering requirements
• Memory constraints
• Consistency requirements
• Whether records are being modified during processing

Diagnosing Slow API Responses

When an API endpoint takes too long, I do not begin with the controller.

I trace the entire request.

Client
 ↓
Web server
 ↓
PHP-FPM
 ↓
Laravel middleware
 ↓
Controller
 ↓
Service
 ↓
Database
 ↓
External API
 ↓
Serialization
 ↓
Response

The question is:

Which layer is consuming the time?

An API might have an efficient controller but a slow database query.

Or the database might be fast while an external API takes two seconds.

Or the actual problem might be a huge response payload.

Things I Inspect

Database Queries

• Query count
• Query duration
• N+1 behavior
• Index usage
• Result size

External APIs

• Connection time
• Response time
• Timeout configuration
• Retry behavior
• Failure handling

Serialization

Returning thousands of nested objects can create substantial processing and payload overhead.

Pagination

If an endpoint returns an entire table, the database and application may both be doing unnecessary work.

Resource Classes

API resources should expose what the consumer actually needs rather than accidentally creating enormous response structures.

Caching

Frequently requested, relatively stable data may be a caching candidate.

Compression

For appropriate response types and infrastructure configurations, compression can reduce network transfer costs.

The objective is not to optimize every layer.

It is to identify the layer that matters.

Heavy Jobs Running Synchronously

A common architectural problem is performing expensive work during the HTTP request.

For example:

User request
   ↓
Generate report
   ↓
Process images
   ↓
Send email
   ↓
Call external API
   ↓
Import data
   ↓
Return response

The user waits for everything.

Laravel’s queue architecture allows this to become:

HTTP request
   ↓
Dispatch job
   ↓
Queue
   ↓
Worker
   ↓
Background processing

Potential candidates include:

• Emails
• Reports
• Large file processing
• Image manipulation
• Notifications
• Imports
• Webhook processing
• External API synchronization

But asynchronous processing should not become a reflex.

Some operations genuinely need to happen before the response can be returned.

For each job, I consider:

• Does the user need the result immediately?
• Can the operation safely happen later?
• What happens if it fails?
• Is the operation idempotent?
• How should it be retried?
• How long can it run?
• How will failed jobs be investigated?

The architectural improvement is not simply “use queues.”

It is to move work that does not need to block the request into an operationally reliable background workflow.

Poor Caching Strategy

Caching is often presented as:

“Add Redis.”

That is not a caching strategy.

Before introducing or expanding caching, I want to understand:

1. What is expensive?
2. How frequently is it requested?
3. How frequently does it change?
4. Can stale data be tolerated?
5. How long can it remain cached?
6. How will it be invalidated?
7. What happens when the cache is unavailable?

A simple example:

$developers = Cache::remember(
    'developers.active',
    now()->addMinutes(10),
    fn () => Developer::where('active', true)->get()
);

The code is easy.

The difficult part is deciding whether this is actually the correct cache boundary.

Cache Invalidation

The application needs to know what happens when the underlying data changes.

If a developer is deactivated, should the cached result remain?

For how long?

Should the application explicitly invalidate it?

Those questions matter more than simply installing Redis.

Cache Stampede

Consider an expensive cache entry that expires.

If hundreds of requests arrive at approximately the same time, they may all attempt to regenerate the same expensive value.

That can create a thundering-herd effect.

The cache then becomes part of the load problem rather than the solution.

A practical caching strategy needs:

• Deliberate keys
• Appropriate TTLs
• Invalidation strategy
• Failure behavior
• Concurrency awareness
• Monitoring

Misconfigured Queues

A Laravel application can have jobs and still have a queue problem.

Seeing:

Job dispatched

does not mean:

Job successfully processed

When investigating queue delays, I look at:

• Queue connection
• Queue name
• Worker processes
• Worker concurrency
• Queue priority
• Retry configuration
• Backoff
• Timeout
• Failed jobs
• Long-running workers
• Memory consumption
• Supervisor/systemd configuration
• Deployment restart behavior
• Monitoring

The diagnostic question becomes:

Is the problem in:
    Application code?
        ↓
    Queue configuration?
        ↓
    Worker process management?
        ↓
    Server resources?

A job could be correctly dispatched but never processed because the worker is not running.

Alternatively, the worker could be running but repeatedly failing the job.

Or the queue may be healthy but a single long-running job could consume worker capacity.

The symptom may be identical:

“The job is delayed.”

The root cause can be completely different.

PHP-FPM and Server Limitations

Not every performance problem is an application-code problem.

Sometimes infrastructure is the bottleneck.

I investigate:

• CPU
• RAM
• Swap
• Disk I/O
• PHP-FPM workers
• pm.max_children
• pm.start_servers
• pm.min_spare_servers
• pm.max_spare_servers
• Request queueing
• Nginx
• Apache
• PHP version
• OPcache
• Database resources

One important relationship is:

More PHP-FPM workers
        ↓
More concurrent application execution
        ↓
Potentially more concurrent database queries
        ↓
Potentially higher database contention

So simply increasing pm.max_children is not automatically an optimization.

If MySQL is already saturated, increasing application concurrency can increase pressure on the database.

The same applies to CPU and memory.

The correct question is:

Which resource is actually constrained?

Production Errors

Production errors should be investigated, not hidden.

A recurring exception gives us information.

I typically move through:

Symptom
 ↓
Application log
 ↓
PHP / web-server log
 ↓
Stack trace
 ↓
Pattern
 ↓
Root cause
 ↓
Fix
 ↓
Regression prevention

I look for:

• Exception frequency
• Stack traces
• Error patterns
• Database errors
• PHP errors
• Web-server errors
• Environment differences
• Configuration differences
• Deployment changes
• Recent code changes

One error occurring once may require a different investigation from an exception occurring thousands of times per hour.

I do not consider suppressing the error a fix.

If the application stops displaying an exception but the underlying transaction continues failing, the system has not become healthier.

The error has simply become harder to see.

API Failures

Broken APIs can originate at several different layers.

Authentication

Is the request authenticated correctly?

Authorization

Does the authenticated user have permission?

Validation

Is the input valid?

Database

Did the required database operation fail?

External Services

Is another dependency unavailable?

Timeouts

Is a dependency exceeding its expected response time?

HTTP Status Codes

Does the API communicate the actual failure correctly?

Serialization

Can the response be transformed into the expected format?

Unexpected Payloads

What happens if an external service changes or returns incomplete data?

Versioning

Is the client calling an API contract that has changed?

Again, I isolate the layer before changing code.

An authentication failure and a database timeout may both appear to the frontend as “API failed.”

They are not the same problem.

Deployment Problems

Deployment troubleshooting is different from application-code debugging.

A Laravel application may work correctly in development and fail after deployment because of:

• PHP version differences
• Composer dependencies
• Missing environment configuration
• Database migrations
• Storage permissions
• Cached configuration
• Route caching
• Queue workers
• PHP-FPM state
• Nginx/Apache configuration
• File permissions
• Deployment ordering

A typical deployment investigation may include:

Git revision
 ↓
Composer dependencies
 ↓
PHP version
 ↓
Environment configuration
 ↓
Database migrations
 ↓
Storage / permissions
 ↓
Config cache
 ↓
Route cache
 ↓
Queue workers
 ↓
PHP-FPM
 ↓
Nginx / Apache
 ↓
Application health

Deployment also needs a rollback strategy.

A production deployment is not complete simply because git pull succeeds.

The application, database, workers, caches, and infrastructure need to remain compatible.

Technical Debt: Fix, Refactor, Architect or Rewrite?

This is where diagnosis becomes an engineering decision.

I generally think about technical debt in four categories.

Category A — Quick Fix

Low-risk, measurable improvements.

Examples:

• Correct an inefficient query
• Add an appropriate index
• Fix an N+1 relationship
• Correct a configuration problem
• Add pagination

Category B — Refactoring

The application architecture is workable, but parts of the implementation need structural improvement.

Examples:

• Extracting business logic from controllers
• Consolidating duplicated code
• Improving service boundaries
• Reworking poorly structured database access

The system remains fundamentally usable.

Category C — Architectural Change

The existing architecture creates a systemic limitation.

Examples might include:

• An application architecture that cannot support required workloads
• A processing model that fundamentally blocks required throughput
• A tightly coupled subsystem that prevents necessary scaling

At this point, the solution may involve significant architectural change.

Category D — Rewrite Candidate

A rewrite becomes a candidate only when there is sufficient evidence that continuing to maintain the current system is no longer technically or economically reasonable.

That assessment should consider:

• Business requirements
• Operational cost
• Development cost
• Security requirements
• Maintainability
• Scalability
• Integration constraints
• Technical feasibility
• Migration complexity
• Data migration risk
• Opportunity cost

The important distinction is:

A difficult codebase is not automatically a rewrite candidate.

And a rewrite is not automatically a bad decision either.

The decision should follow evidence.

Illustrative Production Scenario

Important: This is an illustrative example, not a client case study or claimed production result.

Consider a property-management Laravel application with:

• Slow property listing pages
• Slow API responses
• Increasing database CPU
• Response time increasing as property and user counts grow

Step 1 — Initial Symptom

The business reports:

“Property listings are getting slower.”

That tells me the symptom.

It does not tell me the root cause.

Step 2 — Measurement

I would measure:

• Request duration
• Query count
• Query duration
• Database CPU
• Response payload
• Memory consumption
• External API timing

Suppose the measurements show significant database activity.

Now the investigation moves toward the database.

Step 3 — Query Inspection

I inspect the generated SQL and identify repeated relationship queries.

Property query
+
Developer query
+
Developer query
+
Developer query
+
...

That creates an N+1 pattern.

Step 4 — N+1 Discovery

The relationship is being loaded lazily during iteration.

The query strategy is changed to intentional eager loading.

Step 5 — EXPLAIN Analysis

Another listing query still consumes significant database resources.

I inspect its execution plan using EXPLAIN and, where appropriate, EXPLAIN ANALYZE.

Step 6 — Index Investigation

The query filters by several fields and sorts the results.

I inspect existing indexes and the execution plan.

The question is not:

“Which index can I add?”

It is:

“Does the existing index structure support this query pattern?”

If an appropriate composite index is justified by the workload and execution plan, it can be introduced.

Step 7 — Eloquent Optimization

The listing endpoint is then reviewed for:

• Unnecessary columns
• Unnecessary relationships
• Repeated queries
• Filtering in PHP
• Large result sets

Step 8 — Pagination

If the application is returning hundreds or thousands of properties to a user-facing page, pagination becomes part of the solution.

The goal is to retrieve the data required for the current request rather than unnecessarily loading the entire dataset.

Step 9 — Caching Decision

Only now do I ask whether caching is appropriate.

If certain property metadata is expensive to calculate but changes infrequently, it may be a caching candidate.

If the data changes constantly, aggressive caching may introduce invalidation complexity without enough benefit.

Step 10 — Background Jobs

Suppose the property listing also triggers an expensive synchronization with another service.

That operation may not belong inside the HTTP request.

It could become a queued job.

Step 11 — Re-test

After each meaningful change, I compare the measurements again.

Before
 ↓
Change
 ↓
After

The goal is not to say “it feels faster.”

The goal is to verify the change using appropriate measurements.

Step 12 — Monitoring

Finally, the application should be observed after deployment.

Otherwise, an improvement observed during testing may disappear as:

• Data grows
• Traffic changes
• New features are deployed
• Queue volume increases
• Database workload changes

This is why performance work is a process rather than a single optimization.

Diagnostic Tooling

There is no requirement that every Laravel application needs every monitoring tool.

The tool should answer a diagnostic question.

Laravel Telescope

Useful for inspecting application activity during appropriate development, staging, or controlled environments.

Laravel Pulse

Useful for application-level operational and performance visibility where appropriate.

Laravel Debugbar

Useful during development for inspecting queries, requests, and application behavior. It should not simply be enabled indiscriminately on production systems.

Laravel Logs

Useful for application exceptions, warnings, and recurring patterns.

MySQL EXPLAIN

Useful for understanding query execution plans.

EXPLAIN ANALYZE

Useful when actual execution behavior needs to be compared with the optimizer’s estimates.

Slow Query Logs

Useful for identifying database queries that deserve investigation.

Redis Monitoring

Useful when caching or queue infrastructure depends on Redis.

Linux Monitoring

Useful for understanding CPU, RAM, swap, disk, and processes.

Nginx / Apache Logs

Useful for request-level infrastructure information.

PHP-FPM Logs and Metrics

Useful for identifying process capacity and request handling issues.

APM

Useful when broader request tracing and application-level observability are required.

The principle remains:

Choose the tool that helps answer the question.

Practical Laravel Troubleshooting Checklist

When I receive an existing Laravel application that has performance or reliability problems, I want answers to these questions.

Application

• What exactly is slow?
• Can it be reproduced?
• When did the problem start?
• Is it consistent?
• Does it happen only under load?

Database

• How many queries execute?
• Which queries are slow?
• Are there N+1 queries?
• Are appropriate indexes available?
• What does EXPLAIN show?
• Are large datasets being loaded unnecessarily?

Eloquent

• Are relationships loaded intentionally?
• Are unnecessary columns selected?
• Are queries running inside loops?
• Is filtering happening in SQL or PHP?
• Is pagination appropriate?

API

• How large is the response?
• Is serialization expensive?
• Are external APIs involved?
• Are timeouts configured?
• Can some data be cached?

Queues

• Are workers running?
• Are jobs failing?
• Are retries configured?
• Are timeouts appropriate?
• Are workers consuming excessive memory?
• Is worker capacity sufficient?

Infrastructure

• Is CPU constrained?
• Is RAM constrained?
• Is swap being used?
• Is disk I/O high?
• Is PHP-FPM saturated?
• Is the database saturated?

Production

• What do the logs show?
• What changed recently?
• Does production differ from staging?
• Are configuration caches current?
• Are queue workers running the correct code?

Deployment

• Is the PHP version compatible?
• Are Composer dependencies correct?
• Did migrations run?
• Are permissions correct?
• Were workers restarted appropriately?
• Is rollback possible?

Fix, Refactor, Architectural Change or Rewrite?

The final decision should come from the evidence collected during diagnosis.

                 PROBLEM
                    │
                    ▼
              INVESTIGATE
                    │
                    ▼
                MEASURE
                    │
                    ▼
             IDENTIFY ROOT CAUSE
                    │
          ┌─────────┼─────────┐
          │         │         │
          ▼         ▼         ▼
       Quick      Refactor   Architectural
        Fix                    Change
          │         │         │
          └─────────┴─────────┘
                    │
                    ▼
              RE-TEST / MONITOR
                    │
                    ▼
          Does the architecture still
          prevent the requirement?
                    │
                    ▼
             Rewrite candidate

A rewrite should be the conclusion of an engineering assessment, not the first reaction to an old codebase.

Conclusion

Existing Laravel applications often contain years of business rules, integrations, workflows, and domain knowledge.

That makes them worth understanding before replacing.

Sometimes the solution is a query optimization.

Sometimes it is an index.

Sometimes it is an Eloquent refactor.

Sometimes it is pagination.

Sometimes it is a queue.

Sometimes it is caching.

Sometimes the application is healthy and the infrastructure is the actual constraint.

And sometimes the evidence really does point toward a larger architectural change.

The important part is knowing which problem you actually have.

That is the basis of my PHP/Laravel Rescue & Maintenance approach.

I work around problems such as:

• Slow Laravel applications
• Production errors
• API failures
• Deployment issues
• Database performance
• Queue problems
• Technical debt
• Existing Laravel/PHP systems that need investigation

If you have an existing Laravel/PHP application that is slow, unreliable, difficult to deploy, or becoming harder to maintain, feel free to message me with the problem you are seeing.

The first step is usually not a rewrite.

It is finding the evidence.