Observe execution.
Request hooks plus mysqli, PDO and cURL capture what happens inside PHP. A separate Observer API layer supplies sampled function profiles.
PHPRAY / HOW IT WORKS
Every request.
Context you can act on.
PHPRay is a tool for observing and diagnosing PHP applications. It connects execution time, CPU, memory, SQL, HTTP calls and errors to a specific request.
See what slows down a store or an API. Inspect plugin and component costs on profiled requests. Start on your own server; add Cloud when you need a fleet-wide view.
Apache-2.0 Local core, no account Cloud optional
Built by IQgroup Adam BuhlIQhost brand · OpoleFrom code to data
01
Inside PHP. On your server.
The extension records events. The collector builds a history. The dashboard lets you investigate it. Each layer has a distinct job.
Keep the context.
A single Go binary reads shared memory or JSONL files. It writes SQLite, computes aggregates and manages retention.
Investigate the cause.
The local dashboard and REST API expose traces, SQL and components. Inspect one request in context instead of piecing it together from separate logs.
YOUR SERVER / LOCAL BOUNDARY
PHP processRINIT / RSHUTDOWN · mysqli / PDO · cURL
phpray.so captures request, SQL, HTTP, file and error events. Observer API powers a separate, sampled profiling layer.
request record
RING BUFFER · /dev/shm/phprayand/orJSONL · /var/lib/phpray/traces
phpray-collectorGo binary · systemd
Reads the stream, stores SQLite data, applies retention and local alerts. Defaults: 30 days of history and a 4 GB database cap.
SQLiteTraces · SQL · 1-minute aggregates
Persistent local history. Retention windows and size limits are independent; the oldest records are pruned when either limit is reached.
REST API/api/v1/*
Local collector interface for the dashboard and CLI. It is distinct from the Cloud /v1/aggregates and /v1/traces protocol.
Local dashboard127.0.0.1:9191 · JWT
Sites, traces and component views. Loopback by default, with JWT access control. The local core needs no Cloud account.
PHPRay CloudOPTIONAL
Disconnected by default. Data stays local until you configure the connection.
Architecture diagram — the switch does not change server configuration.Expand any node to inspect its scope. Full data protocol →
Data stays on the server until you configure Cloud. The local dashboard listens on loopback by default and uses JWT.
Collector configuration02
Know what you see. And at what depth.
A request summary, a detailed trace and a function profile are different levels of data. Their coverage is not interchangeable.
OVERHEAD / THE FULL PICTURE
Two layers.
Two different costs.
Always-on observes request events. Function profiling goes deeper and is sampled by default.
100%summaries of eligible requests
3%default function-profile sample
The remaining 97% collect no function samples. Detailed traces and Cloud export have separate rules and quotas.
What was measured, and what remains unverified
Test conditionsPreliminary measurements used WooCommerce, Storefront, 22 plugins, PHP 8.3 and OPcache. Alternating runs with and without the extension, on a laptop. Always-on fell within measurement noise. Profiling every request cost measurably more, but far below a classic execute_ex hook.
Interpretation limitsThis is not a certified benchmark or an overhead guarantee for your server. Full methodology and raw data from a dedicated host are planned before 1.0. Profiling a single URL or time window limits the diagnostic scope.
Source and measurement limitations →Eligible request summaries
Always-on covers requests included in observation. Excluded URIs and CLI tracing, disabled by default, remain outside that scope.
Detailed traces
Mode and duration thresholds determine recording detail. Errors have their own rule. Cloud export has separate selection rules and plan quotas.
Function and component profiles
A 3% sample by default. For a focused investigation, you can profile a specific URL. More detail adds measurement overhead.
03
From “the store is slow” to a specific trace.
Follow this workflow with the WooCommerce demo dataset. The same questions guide an investigation of PHP applications and APIs.
- 01
Find the request.
Start with the URL, status and response time. In the example, POST /checkout/ returns a 500 error after 842 ms.
- 02
Find where the time goes.
The timeline separates PHP, SQL and HTTP. In the SQL tab, inspect fingerprints, repeated queries and the N+1 pattern. Then check the component context.
- 03
Change the code. Verify the result.
After a change, compare the same metric under comparable traffic. Before/after views start at Studio; in the demo you can compare two time windows (p95 per URI, components).
Open the comparison in the demo
04
One method. Different environments.
Keep the same diagnostic context, whether you build a store, develop an API or manage client sites.
WordPress & WooCommerce
Checkout, admin-ajax and product queries. Inspect page requests, SQL fingerprints and N+1 patterns; use profiled requests to investigate plugin and theme costs.
Without .so access: the WordPress plugin captures application-level data, without visibility inside PHP or C extensions.
WordPress setupPHP applications and teams
Connect endpoint context with errors, mysqli/PDO query timing and outbound cURL calls. Use the local REST API and CLI in your diagnostic workflow.
VPS, server or container: match the extension build to the PHP version, ABI and system architecture.
Request diagnosticsHosting providers and agencies
From one client to an entire portfolio. One console for stores, applications and environments. Show the client the site, URL and component that needs attention.
Cloud: one subscription per fleet, comparisons from Studio, white-label reports and API — planned (Agency). Separately: a self-hosted Host Edition console.
05
Start with your environment.
Run the local core first, or explore the product with demo data. Local operation does not require a Cloud account or subscription.
LINUX / VPS / ROOTLOCAL CORE · $0
Extension, collector and dashboard.
Download the installer and review its contents before running it. The documentation covers requirements, installation and verification of the first records.
01 / DOWNLOAD
phpray-install.shcurl -fsSL https://phpray.dev/install.sh -o phpray-install.sh
Linux / VPS: review the script and run02 → 03
Review the installation script.
Open the downloaded file. Press Q to exit the viewer.
less phpray-install.sh
Install on your own server.
After reviewing it, run the installer on your server.
sudo bash phpray-install.sh
NEXT STEP / OPTIONAL
PHPRay Cloud AVAILABLE
Multiple sites, longer history and a shared fleet view. You explicitly enable the connection; the collector sends data over outbound HTTPS. Coverage and retention depend on the plan.