Skip to main content

Your PHP app is slow.
See exactly why.

A slow PHP endpoint rarely has one obvious cause. Perfbase profiles every request, job, and command in production, then shows the exact function path, repeated queries, and host pressure behind the slow trace - so the next move is obvious.

Slow checkouts N+1 queries Cron blow-ups Queue regressions
console.perfbase.com - trace
Wall time
Every request, job, and command sized in milliseconds.
Call counts
Spot loops, repeated work, and runaway frameworks at a glance.
N+1 flags
Repeat-query shapes detected automatically per trace.

Does this sound familiar?

The slowness everyone keeps trying to pin down

A list of the PHP performance problems Perfbase exists to debug. If more than one looks familiar, this is built for you.

Checkout, login, or dashboard latency that customers notice before monitoring does
N+1 queries hiding inside an endpoint that looks fast at the route level
A queue worker that takes 4× longer after a deploy, with clean logs
Scheduled jobs and cron creeping past their window
"It is slow in production but fine locally"
An APM that tells you the endpoint is slow but not which line
Eloquent hydration, API resources, policies, and serialisers all stacked in one request
Plugins, themes, hooks, or package callbacks doing more work than expected

Why this is hard with what you already have

Generic monitoring tells you something is slow. It does not tell you what to change.

Logs and averages do not show the function path

Aggregate latency tells you a request is slow. It does not show which PHP function on which line spent the time.

Local repros rarely match production

The slow path usually depends on real data, real traffic, and real configuration. A clean local profile is not the answer.

xdebug.profile in production is not viable

Heavy profilers melt production. You need something built for production load with sampling and low overhead.

What you see in Perfbase

A real trace, from code paths to history

Every screenshot below is production trace data, not a mockup. Read one slow request in detail, then zoom out to historical stats per action, project, or organisation when the question is what changed over time.

flame graph
Flame graph

See the shape of the request, not just the latency number

Wide frames are expensive call paths. Vendor calls can be collapsed so framework and application cost stays visible without dependency internals dominating the first read.

Zoom into any subtree to chase a hotspot
Search for a function across the whole trace
Switch between flame, function, and query views without losing context
n+1 detection
N+1 detection

Stop reading SQL lists. Read query patterns.

Perfbase normalises SQL by replacing literal values with placeholders, then groups similar shapes. Five or more repeats of the same shape get flagged as a potential N+1 with total time and call counts attached.

Repeat-query shapes surface automatically
See total time per pattern, not just per statement
Jump from a query to the PHP call that issued it
call tree
Call tree

Turn a hotspot into the exact code path that caused it

A flame graph shows shape. A call tree shows the parent-child path that produced the cost - framework, app code, and database call, all in one hierarchy.

Walk from controller to PDO without leaving the trace
Per-node timing bars highlight where to start cutting
Works the same way for jobs, commands, and HTTP
host resources
Host resources

Tell "the script is expensive" apart from "the host was busy"

Compare host CPU, memory, disk, and network against the trace window. Same picture, same time scale - so you can separate code regressions from infrastructure pressure.

Host CPU plotted next to PHP process CPU
Memory, disk, and network sampled on the trace window
Catch the request that happened during a noisy neighbour
call graph
Call graph

Map a large trace before drilling into the path

The call graph gives a force-directed view of function relationships across framework, database, I/O, and user-code clusters. It is useful when a trace is too large to read linearly.

See clusters of framework, database, I/O, and user code
Use graph layout controls to simplify noisy traces
Move from orientation to flame graph or call tree detail
history per action
History per action

Track one action across historical traces

Action history keeps the top-level statistics for one endpoint, job, or command in view over time. You can see volume, average duration, p95, slow-request share, and error-rate movement before opening individual traces.

Watch p95 and slow-request share move across days
Filter the traces behind a spike by environment, user, IP, or host
Open the exact trace samples that explain the trend
history per project
History per project

See which project actions are getting slower

Project history rolls up trace volume and latency across every action in a project, then keeps the action table nearby so regressions can move from trend to culprit quickly.

Compare action volume, p50, p95, and error rates
Separate slow requests from broad project-level load
Jump from the project trend into the action that changed
history per organisation
History per organisation

Monitor top-level health across projects

Organisation history gives the broadest view: total trace volume, project activity, response-time trends, and recent activity across the account. It is the starting point when the question is "what changed?"

See trace volume and response-time trends across projects
Spot recent activity without opening every project
Use organisation-level history as the first triage screen

One trace shape, every surface

More than HTTP. Queues, cron, and CLI work the same way.

A lot of PHP pain lives outside browser traffic. Workers, scheduled jobs, and CLI commands get the same trace shape as HTTP requests, so the slow paths there stay visible too.

HTTP requests

Controllers, middleware, render, query work - every layer of the request lifecycle.

Queue jobs

Workers and scheduled work traced with the same shape as web requests.

CLI commands

Artisan, console, and cron commands profiled the same way as everything else.

Setup

From signup to first trace in minutes

Three steps. No long setup story, no manual instrumentation. The extension picks up your PHP version, OS, and architecture automatically.

Linux and macOS, x86_64 and ARM64. PHP 7.4 through 8.5.

01

Create your project

Sign up, create an organization and project, and grab your API key from project settings.

Register for free →
02

Install the extension

One command installs the PHP extension. Auto-detects your PHP version, OS, and architecture.

bash -c "$(curl -fsSL https://cdn.perfbase.com/install.sh)"
03

Add your framework package

Install the package, set your API key, and finish the framework setup.

composer require perfbase/laravel:^1.0
PERFBASE_ENABLED=true
PERFBASE_API_KEY=your-api-key
PERFBASE_SAMPLE_RATE=0.1

Built for production

Rust-based PHP extension. Typical overhead under 1%. Sampling defaults to 10% and is configurable per environment.

PHP 7.4 – 8.5

Linux and macOS. x86_64 and ARM64. First-party support for Laravel, WordPress, Symfony, Drupal, CakePHP, Slim, Joomla, CodeIgniter, and Yii.

Regional trace storage

Pick a region that matches compliance and customer requirements: Europe: France, Germany, London, Poland; APAC: India, Singapore, Sydney; America: Toronto.

FAQ

The questions people ask before they sign up

What is the production overhead?

The PHP extension is written in Rust and built for production use. Typical overhead is well under 1%. Sample rate defaults to 10% of requests and is configurable per environment, so you stay in control of the load.

Do I need to instrument every code path?

No. Framework integrations capture the request, job, and command lifecycle automatically. You can add manual spans through the PHP SDK later when you want extra precision around a specific block of code.

Does it cover queues, cron, and CLI commands?

Yes. Background work is a first-class citizen. Queue jobs, scheduled tasks, and Artisan or console commands are traced with the same shape as HTTP requests, so the slow paths outside web traffic stay visible too.

Which PHP versions and frameworks are supported?

PHP 7.4 through 8.5 on Linux and macOS, x86_64 and ARM64. First-party integrations cover Laravel, WordPress, Symfony, Drupal, CakePHP, Slim, Joomla, CodeIgniter, and Yii. The PHP SDK covers everything else.

Where is the trace data stored?

Trace data can be stored in regional locations: Europe: France, Germany, London, Poland; APAC: India, Singapore, Sydney; America: Toronto. Pick the region that fits your compliance requirements or customer contracts.

Is the free plan really free?

Yes. The free plan is free forever, not a trial. There is no card on signup and no countdown. Upgrade only when you want more trace volume, longer retention, or team collaboration.

Start profiling

Stop guessing where the slow paths are

Get to your first useful trace today. Free forever for one project - no card, no trial timer, no feature gates.