DEV Community: Dario Zadro

Three PHP-FPM failure modes and how to actually diagnose them

Dario Zadro — Mon, 07 Sep 2026 15:15:15 +0000

Tuning guides talk about throughput. Nobody pages you about throughput. They page you about symptoms, and the useful skill is mapping a symptom back to a cause before you spend money on hardware.

Three failure modes account for most of what I find on inherited servers. Each has a distinct signature.

The 502 nobody can reproduce

Server has 8GB. PHP-FPM is set to 100 workers. Each worker uses 60MB under load. That's 6GB of PHP, plus MariaDB, plus Nginx, plus the OS.

Under normal traffic you never approach 100 workers, so it looks fine for months. Then a marketing email goes out, concurrency spikes, and the kernel runs out of memory. The OOM killer picks a process and terminates it, usually the biggest one, which is a PHP-FPM worker holding an in-flight request.

User gets a 502. The application log has nothing, because the process died before it could write anything. Nginx logs recv() failed (104: Connection reset by peer). Ten minutes later everything looks normal.

sudo dmesg -T | grep -i "killed process"
sudo journalctl -k | grep -i oom

Hits there mean you don't have a mystery. You have a pm.max_children value nobody checked against real memory.

The site that degrades all day and resets overnight

TTFB is 180ms at 8am. By 4pm it's 900ms. Nobody deployed. Overnight it's fast again because something restarted PHP-FPM.

That's OPcache running out of room. When the cache fills, it stops caching new scripts or wipes and rebuilds, and every miss pays full parse-and-compile again. It degrades gradually, which is why it goes unnoticed for months.

The counters are oom_restarts and hash_restarts from opcache_get_status().

Here's the part that trips people up. OPcache state is per SAPI. Run that function from the CLI and you're reading the CLI cache, which is empty, separate, and tells you nothing about your site. You have to ask through PHP-FPM.

<?php
// drop in webroot, lock to your IP, delete when done
$allowed = ['203.0.113.42'];
if (!in_array($_SERVER['REMOTE_ADDR'], $allowed, true)) {
    http_response_code(404);
    exit;
}

$s = opcache_get_status(false);
$hits = $s['opcache_statistics']['hits'];
$miss = $s['opcache_statistics']['misses'];

echo 'hit rate:      ', round($hits / max(1, $hits + $miss) * 100, 2), "%\n";
echo 'cached files:  ', $s['opcache_statistics']['num_cached_scripts'],
     ' / ', $s['opcache_statistics']['max_cached_keys'], "\n";
echo 'oom restarts:  ', $s['opcache_statistics']['oom_restarts'], "\n";
echo 'hash restarts: ', $s['opcache_statistics']['hash_restarts'], "\n";
echo 'cache full:    ', var_export($s['cache_full'], true), "\n";

Behind Cloudflare or a load balancer, check what REMOTE_ADDR actually contains first, or that guard is an open door. If you'd rather not touch the webroot, cachetool talks to the FPM socket directly.

The default opcache.max_accelerated_files is 10,000. A CI4 app with modest deps is around 1,500 to 3,000 files, fine. Laravel with a normal dependency tree runs 10,000 to 15,000. Nextcloud's own health check tells admins to set it above 80,000. Count yours with find . -name "*.php" | wc -l before assuming.

One app taking down five others

A default install creates a single pool, www.conf, shared by every site on the box. So when your least important app starts waiting on a slow third-party API, its requests occupy workers from the shared pool.

Those workers aren't available to anything else. Your customer portal queues behind a lead-capture form calling an unresponsive CRM endpoint.

One pool per app:

; /etc/php/8.5/fpm/pool.d/crm.conf
[crm]
user = www-data
group = www-data
listen = /run/php/php8.5-fpm-crm.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

pm.status_path = /fpm-status
slowlog = /var/log/php8.5-fpm-crm-slow.log
request_slowlog_timeout = 5s

php_admin_value[memory_limit] = 256M
php_admin_value[error_log] = /var/log/php8.5-fpm-crm-error.log

Memory ceiling per app, separate logs, independent restarts. pm.max_requests recycles workers so slow leaks in older code get contained instead of accumulating until the OOM killer steps in.

Measure per-worker memory, don't guess it

The pm.max_children formula everyone quotes needs a number most people invent. Measure it against warm production workers:

$ ps -ylC php-fpm8.5 --sort:rss | awk 'NR>1 {print $8/1024" MB"}' | tail -5
58.4 MB
61.2 MB
63.9 MB
71.5 MB
88.1 MB

Check the process name with ps -e | grep fpm first, since it's php-fpm8.5 on Debian and Ubuntu and plain php-fpm elsewhere.

Size for your heavy path, not your average, and leave headroom. If the math says 50, set 40. Being conservative costs you a slightly longer queue. Being aggressive costs you the OOM killer.

A read-only hour

Check	How	Act when
OOM kills	`dmesg -T \	grep -i "killed process"`
CPU steal	`vmstat 1 5`, `st` column	Above 5% sustained
OPcache	localhost script through FPM, not CLI	Hit rate under 95%, restarts non-zero
File count	`find . -name "*.php" \	wc -l`
Worker memory	`ps -ylC php-fpm8.5 --sort:rss`	Exceeds what max_children assumed
Pool isolation	`ls /etc/php/8.5/fpm/pool.d/`	Only www.conf, multiple sites

Nothing there changes anything or restarts anything. You end the hour knowing whether you have a configuration problem or a capacity problem, which is the distinction that decides whether you're making a config change or a permanent increase to your monthly bill.

Longer version with the status page setup, Nginx stub_status, FastCGI caching, and the cache bypass rule that burns people: Nginx and PHP-FPM Tuning for Mid-Market Infrastructure

The self-hosting math for LLMs quietly inverted this year

Dario Zadro — Mon, 07 Sep 2026 15:07:52 +0000

Most of the self-hosting advice you'll find was written against 2024 assumptions. API pricing is expensive and linear, hardware is fixed and amortizes, so past some volume you break even. Buy the GPU, stop paying rent.

Two things broke that this year, and they moved in opposite directions.

Inference got cheaper

OpenAI cut GPT-5.6 pricing twice over the summer, dropping Luna by 80% and Terra by 20% at the end of July, then Sol by over 20% in August. Claude Haiku 4.5 runs $1 per million input tokens and $5 per million output, with up to 90% off cached input.

Normal continuation of a multi-year trend. Nothing surprising.

Hardware got a lot more expensive

The NVIDIA RTX PRO 6000 Blackwell showed up in early US retail around $8,565 in March 2025. NVIDIA's Marketplace price hit $13,250 in June 2026, then $16,000 in August. Roughly 87% above launch, same silicon, driven by the memory shortage rather than anything about the card.

So if you're amortizing hardware over three years, you're betting a falling price curve stays above a fixed cost for 36 months, except the fixed cost isn't fixed either. Replacement and expansion both got more expensive while you weren't looking.

Measure your own workload first

Here's one real query from my production telemetry. Research task on Haiku 4.5 with web search enabled:

Component	Quantity	Cost
Input tokens	28,965	$0.0290
Output tokens	3,097	$0.0155
Web search calls	3	$0.0300
Cached tokens	0	$0.0000
Total	32,062 tokens, 57s	$0.0745

Two things in there matter more than the total.

Forty percent of that bill wasn't the model. Three tool calls at a cent each cost more than the input tokens did. Every cost comparison you'll read argues token price, which is the half that's been falling.

Cached tokens were zero. Most of that 29k input is a system prompt that barely changes between runs. Prompt caching would cut a large share of it. There was a cheaper optimization sitting right there, before any hardware conversation.

Before you model anything, pull thirty days of usage and separate token cost from tool cost. Your request shape is probably not the one in whatever blog post you're reading.

The local tier is smaller than people think

There's a persistent assumption that self-hosting means running a 70B model. Qwen's lineup doesn't have that rung. The open-weight local tier is 27B dense, with Qwen3.8-27B on Hugging Face since August under Apache 2.0. Above that it jumps to Qwen3.8-Max at 2.4T parameters as a sparse MoE.

Reported memory for the 27B: roughly 56GB at BF16, about 28GB at FP8, and 14 to 17GB at 4-bit, plus KV cache. The 262k context window means budget real headroom above the weight figure.

Treat those as reported, not measured. Pull the quant and watch actual resident VRAM at a realistic context length before anyone signs a purchase order.

But the shape is clear: the local tier for narrow tasks runs on a 24GB card, not a $16,000 workstation card. Those were never the same purchase. Document classification, PII redaction, entity extraction, and ticket routing are not frontier problems, and a small model fine-tuned on your domain frequently beats a general-purpose giant on exactly that kind of narrow repetitive work.

If you're on PHP

Most PHP shops have historically had one option for AI work: bolt on a Python microservice and fragment the team.

Neuron AI is an agentic framework for PHP 8.1+ that keeps orchestration in the existing runtime. Multi-agent, RAG, structured outputs, built-in observability. The useful part for a mixed architecture is that swapping providers is a config change rather than a rewrite, which is the actual hedge against both lock-in and price moves. Not owning the hardware. Being able to move.

The short version

Don't self-host to save money right now. The token price is falling and the hardware price is climbing, so that trade is worse than it was eighteen months ago.

Self-host what can't leave the building, route the rest to an API, and size the local side to the task rather than the frontier. The hard part isn't the infrastructure. It's classifying which workloads are which, and that has to happen before anyone writes code.

Longer version with the compliance angle, the confidential computing middle path, and a decision table: Self-Hosted LLMs vs API Providers: Why the Math Changed

GEO Requires More Than SEO: The Technical Distinction Nobody Is Making

Dario Zadro — Wed, 29 Apr 2026 23:48:00 +0000

GEO is mostly SEO. But mostly is not all of it.

The conversation keeps collapsing into two useless camps. Camp one says GEO is just repackaged SEO with a shinier invoice. Camp two says SEO is dead. Both are wrong.

Here's the technical case for why.

Eligibility vs. Selection: The Distinction Nobody Is Making

Two completely separate problems are being treated as one.

Eligibility is whether an AI system can reach your content at all. Crawled, indexed, snippet-eligible. Google explicitly documents that to be considered for AI Overviews, a page must be indexed and eligible to show a snippet. If you don't clear that bar, nothing else matters.

Selection is what happens after retrieval fires. Of everything the system pulled in, which chunks actually end up in the LLM response?

SEO governs eligibility. GEO governs selection. These are sequential problems, not the same problem.

The data backs this up. A March 2026 Ahrefs analysis of 863,000 keywords and 4 million AI Overview URLs found that only 38% of cited pages ranked in the top 10 for the same query, down from 76% just seven months earlier. A separate BrightEdge analysis from February 2026 puts that overlap even lower, at around 17%.

So roughly two out of three AI citations come from pages a user would never see on page one. The AI is not drawing from what ranks. It's drawing from what it can use.

RAG: A Term the SEO Community Is Misusing

You can't open a LinkedIn feed right now without someone referencing RAG. Most of those posts are technically wrong.

Retrieval-Augmented Generation (Lewis et al., 2020) is a specific architecture. It combines what a model already knows from training (parametric knowledge) with documents pulled in at query time (non-parametric retrieved context). That's it.

RAG is not:

A synonym for "search API call"
The same thing as embeddings, which are a vector representation method used within retrieval, not the architecture itself
Something that always happens. Many queries get model-only responses with no retrieval at all

Retrieval is conditional, not constant. When someone tells you "rank well and you'll get retrieved," they're giving you advice that only applies to a subset of queries.

Not All Retrieval Runs Through Google or Bing

Each platform retrieves differently. This is where "just do SEO" advice collapses:

Google AI Mode / AI Overviews. Query fan-out across subtopics and data sources, with supporting pages identified during response generation. The citation set extends well beyond what ranked for the original query.
Claude. Runs on Brave Search, not Google or Bing. A 2025 analysis by Profound found 86.7% overlap between Claude citations and Brave's top organic results. Not indexed by Brave? Claude won't cite you. Doesn't matter where you rank on Google.
Perplexity. Runs its own continuously refreshed index using two distinct crawlers, after moving away from Bing Web Search API in 2022. Strong freshness bias: 90% of top cited sources answer the core question within the first 100 words (BLUF pattern).
Microsoft Copilot. Grounds through Bing APIs across three distinct modes.
OpenAI Assistants. Documents hybrid keyword plus semantic vector retrieval, query rewriting, parallel searches, and reranking. No search API involved.

Two distinct mechanisms underlie all of this that most agencies never separate.

The first is training data inclusion. Being present in the sources models learned from. Wikipedia, major publications, Reddit, high-authority industry sites. You build toward it through long-term brand authority and earning mentions across those sources. That's digital PR and link outreach. SEO under the hood. And Google has been parsing contextual relevance and brand mentions longer than most realize. But the real divergence is sentiment parsing across trained data and RAG methods. Feeding those systems is where SEO ends and GEO begins.

The second is retrieval-time inclusion. What happens when an LLM does live web retrieval during a prompt response. Results get re-ranked by the model based on probability and relevance. That retrieval step does not care much about rankings.

That second mechanism is what 90% of GEO tactics actually target. Even when practitioners claim otherwise.

Your brand appearing as a citation is an output address. It's not a retrieval receipt. It doesn't tell you how the content got there.

Fan-Out Coverage: The Most Underrated GEO Signal

A single user query gets decomposed into multiple sub-queries before retrieval even happens. Your content has to survive that fan-out, showing up across several rewritten versions of the original question, not just one.

A 2025 Surfer SEO study analyzing 173,902 URLs found that pages ranking for fan-out queries are 161% more likely to be cited in AI Overviews than pages ranking only for the main query. The Spearman correlation between fan-out coverage and citation likelihood was 0.77. And ranking for fan-out sub-queries alone was 49% more likely to earn a citation than ranking exclusively for the head term.

You can actually see fan-out in action. Open dev tools on any AI chat interface, fire a query, and inspect the Network tab. In Claude, you'll see sequential tool_use blocks in the JSON response payload showing your single query decomposed into multiple sub-queries in real time.

{
  "tool_use_blocks": [
    {
      "type": "tool_use",
      "name": "web_search",
      "input": { "query": "top SEO agencies Chicago 2026" },
      "sequence": 1
    },
    {
      "type": "tool_use",
      "name": "web_search",
      "input": { "query": "generative engine optimization GEO agency Chicago" },
      "sequence": 2
    }
  ]
}

One user query. Two retrieval events. Two separate source pools. Your content needs to be present across all of them.

The Real Model

Here's how most of the SEO community is currently thinking about this:

Rank. Get retrieved. Get cited.

Here's what's actually happening:

Be indexable. Be verifiable. Be extractable at the chunk level. Have fan-out coverage. Increase selection probability.

Those are not the same instructions.

Here's a realistic split: 70% of effective GEO is SEO. 20% is new tactical work around extractability and entity signals. And 10% is genuinely novel. AI visibility monitoring, citation tracking, scrubbing fan-outs, and earning brand mentions inside answers users actually trust.

GEOs who close that gap now won't need to scramble when it becomes obvious to everyone else.

Full article with selection signals, platform breakdown, and measurement guidance: zadroweb.com/blog/seo-vs-geo/

Move Over Python: PHP Is the Sleeping Giant of AI Agents

Dario Zadro — Wed, 29 Apr 2026 23:26:59 +0000

I've been coding in PHP for over 20 years. I've watched it get declared dead at least a dozen times. And every time, it just keeps running more of the internet.

So when AI started entering project needs, I didn't reach for Python. I didn't buy a seat in some workflow builder. I simply opened my existing codebase, wrote a service, and made an API call.

That's it. That was the whole unlock.

The Assumption Nobody Is Questioning

Python owns AI. Everybody knows this. If you're training models or building research pipelines, Python is the right tool. Not up for debate.

But here's the thing most teams aren't asking: are you actually training a model? Or are you calling an API?

Because those are wildly different problems. Most businesses building "AI features" today are doing the latter. They're sending a prompt to Claude, GPT, or Gemini and doing something useful with the response. That's a REST call. REST calls are language-agnostic. And PHP has been making REST calls since before most AI startups existed.

You Already Have the Stack

PHP powers over 71% of all websites with a known server-side language. Your CRM, your CMS, your admin panel -- already PHP. And AI agents at the production layer aren't exotic research software. They're authenticated API calls, database reads, webhook handlers, queue workers.

Here's something the AI industry won't tell you: most "agents" are just good old services. Strip away the marketing, and a typical AI agent is a class that accepts input, calls an external API, applies some logic, and returns output. We've been writing those since the early 2000s.

The agentic wrapper adds planning, memory, and tool-calling on top. Real, and it matters. But the underlying pattern is not foreign to anyone who has spent time in an MVC framework.

So why spin up a Python microservice to sit next to your PHP application, duplicate your data context across a process boundary, and introduce an entirely new runtime to maintain, just to make an HTTP request to an LLM?

The Overkill Problem

I've seen teams reach for AWS Bedrock to summarize a support ticket. I've seen n8n workflows with 14 nodes to do what is functionally a single API call. Make.com is a fantastic tool for connecting SaaS apps without code, but it is not the right answer for embedding an AI feature in a PHP application you already control.

A working Claude integration in PHP:

$client = new \GuzzleHttp\Client();

$response = $client->post('https://api.anthropic.com/v1/messages', [
    'headers' => [
        'x-api-key'         => $_ENV['ANTHROPIC_API_KEY'],
        'anthropic-version' => '2023-06-01',
        'content-type'      => 'application/json',
    ],
    'json' => [
        'model'      => 'claude-haiku-4-5-20251001',
        'max_tokens' => 1024,
        'messages'   => [
            ['role' => 'user', 'content' => $userPrompt]
        ],
    ],
]);

$data  = json_decode($response->getBody(), true);
$reply = $data['content'][0]['text'];

No platform. No monthly seat. No new infrastructure. Composer, Guzzle, an API key, and you're live.

What an Actual Agent Looks Like

An API call waits for a response and returns it. An agent decides what to do next, calls tools, checks its own output, and loops until the task is done. Here's that shift in PHP using Neuron AI:

namespace App\Neuron;

use NeuronAI\Agent\Agent;
use NeuronAI\Agent\SystemPrompt;
use NeuronAI\Chat\Messages\UserMessage;
use NeuronAI\Providers\AIProviderInterface;
use NeuronAI\Providers\Anthropic\Anthropic;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;

class FitnessAgent extends Agent
{
    protected function provider(): AIProviderInterface
    {
        return new Anthropic(
            key:   $_ENV['ANTHROPIC_API_KEY'],
            model: 'claude-haiku-4-5-20251001',
        );
    }

    protected function instructions(): string
    {
        return (string) new SystemPrompt(
            background: ['You are a knowledgeable fitness assistant.'],
            steps:      ['Use available tools to look up workout plans before answering questions about them.'],
            output:     ['Give clear, practical guidance based on the workout data returned.']
        );
    }

    protected function tools(): array
    {
        return [
            Tool::make('get_workout', 'Look up a workout plan by name or muscle group.')
                ->addProperty(
                    new ToolProperty(
                        name:        'workout_name',
                        type:        PropertyType::STRING,
                        description: 'The name or muscle group of the workout to retrieve.',
                        required:    true
                    )
                )
                ->setCallable(function (string $workout_name) {
                    $pdo  = new \PDO($_ENV['DB_DSN'], $_ENV['DB_USER'], $_ENV['DB_PASS']);
                    $stmt = $pdo->prepare("SELECT exercises, sets, reps FROM workouts WHERE name = ?");
                    $stmt->execute([$workout_name]);
                    $row  = $stmt->fetch(\PDO::FETCH_ASSOC);
                    return $row ? json_encode($row) : 'Workout not found.';
                }),
        ];
    }
}

$reply = FitnessAgent::make()
    ->chat(new UserMessage('How many sets should I do for a beginner chest workout?'))
    ->getMessage()
    ->getContent();

echo $reply;

The agent receives the question, decides it needs the get_workout tool, calls it with the extracted muscle group or plan name, and folds the result into its response. All without you wiring that logic manually. That's the shift from API wrapper to agent.

PHP's Territory

Python wins at model training, ML research, data science pipelines, and computer vision. Uncontested. Go use Python for that.

PHP's territory is the production web layer. CRMs, dashboards, ecommerce platforms, CMS systems, admin panels, business workflow tools. That layer is already PHP. The agents should be too.

Your agent needs access to your authenticated user session, your database schema, your business rules, your caching layer. Transferring all of that to an external Python service isn't just overhead. It's a technical debt liability.

You need an API key, a service class, and the PHP codebase you've probably already been running in production.

The giant was never asleep. Everyone else just has their eyes closed.

For the full breakdown including RAG in PHP, MCP, FrankenPHP, and the complete ecosystem rundown, read the full article at zadroweb.com.

Missing Database Indexes Are Killing Your Page Speed

Dario Zadro — Thu, 12 Mar 2026 15:54:21 +0000

I provide SEO. I also build apps. And the performance problem I see most often has nothing to do with meta tags, Core Web Vitals scores, or caching plugins.

It's missing database indexes.

Everyone chases the green scores. Images get lazy-loaded. Fonts get preloaded. Someone installs a caching plugin and calls it done. Green across the board. Screenshot posted on LinkedIn. Everybody claps.

But the uncached request still exists. The logged-in user still exists. The admin dashboard still exists. The report page pulling from six tables still exists. Caching hides the problem. It doesn't fix it.

The Fast Diagnostic

Enable MySQL's slow query log:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SHOW VARIABLES LIKE 'slow_query_log_file';

Reproduce the slow page. Check the log. Then run EXPLAIN on whatever shows up:

EXPLAIN
SELECT * FROM parent_table p
JOIN child_table c ON c.parent_id = p.id
WHERE p.account_id = 42 AND p.status = 1;

Four columns tell the whole story: type, key, rows, and Extra.

ALL in type with NULL in key is the thing you don't want to see. Especially inside a subquery running once per parent row. Not mysterious. Just waste.

The Fixes

Foreign key columns — index every column used in a JOIN:

ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id);

Composite indexes — column order matters. Most-filtered column goes first:

ALTER TABLE parent_table
ADD INDEX idx_account_status_created (account_id, status, created_at);

JSON extractions — can't index a computed expression directly. Use a generated column:

ALTER TABLE event_log
ADD COLUMN event_source VARCHAR(100)
GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(payload, '$.source'))) VIRTUAL,
ADD INDEX idx_event_source (event_source);

Don't overdo it — every index slows writes. Index what you actually query. That's it.

WordPress Specifically

WordPress runs 42.5% of the web (W3Techs, March 2026). And wp_postmeta does not scale gracefully under plugin pressure. Don't even get me started on RankMath's database bloat.

The Index WP MySQL For Speed plugin by Ollie Jones is a solid first move for standard installs. Heavily customized sites need a manual EXPLAIN review.

Real Result

A dashboard recently: 3+ seconds to load, 120,000 records, correlated subqueries hitting unindexed join columns. Thousands of row reads per load, every single request.

Three index statements. Instant. Same server, same code, same database.

Check the DB structure before you blame the host or code. The answer is usually closer than you think.

Full breakdown on the Zadro Web blog: https://zadroweb.com/blog/database-indexes-slow-website/