Performance on Brian Faust

When the Framework Sets the Latency Floor

Sat, 01 Aug 2026 00:00:00 +0000

By the time I considered moving the pricing backend to Go, the PHP version already had table-driven pricing, prepared runtime projections, candidate indexes, and substantial cache work. Those changes mattered. They didn’t remove the request cost I was still seeing before business processing: roughly 50–100 milliseconds on the conventional PHP/Laravel path, reduced to roughly 30–40 milliseconds with Octane in the setup I tested.

I didn’t want to spend the rest of the project squeezing a little more out of that same path. Go was a better fit for the request and computation work, particularly as the pricing datasets grew. Performance, resource consumption, and stability drove the choice. The interesting engineering question became how to replace the runtime without quietly replacing the application too.

Is Your Benchmark Doing New Work?

Wed, 01 Jul 2026 00:00:00 +0000

One of the rating engine’s early benchmark fixes made the results slower. That was the improvement. The runner had reused request identities across invocations, so later runs could return stored results instead of evaluating new quotes. The endpoint was doing its job. The benchmark wasn’t measuring the job I thought it was.

This is an awkward mistake because the output can look entirely healthy: successful HTTP responses, small latencies, no obvious application errors. It is also worth dealing with before celebrating a faster index or cache read . A replay can skip the calculation whose improvement you’re trying to measure.

A Cache Hit Still Has a Payload

Mon, 15 Jun 2026 00:00:00 +0000

The rules were cached. The expensive graph had already been compiled. A warm request should have been the easy case, yet loading that prepared data was still taking enough work to deserve its own investigation. The cache was working; the representation inside it was the problem.

One attempted fix was to cache a larger, ready-to-use pricing profile and skip reconstruction. That made cache-hit performance worse. Later, compacting rows helped, moving their expansion helped, and then keeping one expensive family expanded helped too. Apparently contradictory results, until you follow where each version made the request do its work.

Index Tariffs Without Losing Charges

Mon, 01 Jun 2026 00:00:00 +0000

Scanning ten thousand tariff rows for each of a hundred candidate services means a million candidate-row visits before doing much interesting pricing. Most visits may end with the same answer: this row belongs to another service. Putting that loop behind a cache doesn’t remove it.

I changed this part of my private logistics engine by preparing an in-memory index of rows by carrier and service match. This wasn’t a database index. The quote already had a restored runtime projection; the repeated work was inside that projection. The index moved some predicates out of the per-candidate loop, which made their preservation a correctness requirement rather than merely a performance detail.

Compile Published Rules Before the Quote Arrives

Fri, 01 May 2026 00:00:00 +0000

A cache flush shouldn’t make the next quote rebuild a price book that was already published. The shipment is new. The structure of the tariff isn’t. Yet “load the graph, prepare it, cache it” puts both jobs back on the request as soon as the cache disappears.

That boundary changed during development of my private rating engine. First, published rulesets gained a persisted runtime projection. Later, supporting configuration gained a separate persisted bundle. These changes didn’t precompute shipment prices. They gave repeated preparation somewhere to survive other than a volatile cache.

One Parcel Doesn't Have One Pricing Weight

Wed, 01 Apr 2026 00:00:00 +0000

A parcel weighs two kilograms. Its dimensions make its volumetric weight 4.8 kilograms. One service prices the larger measurement, rounded up to a whole kilogram; another prices actual weight. The same parcel gives those services pricing weights of five and two kilograms.

Calculating a weight once and sharing it across both candidates would save work. It would also calculate the wrong thing. The reusable fact is the parcel’s geometry, not whichever service’s policy happened to run first.

Not Every Pricing Rule Belongs in a Formula

Sun, 01 Feb 2026 00:00:00 +0000

The first parcel costs EUR 20. Parcels two through ten cost EUR 5 each. After that, each additional parcel costs EUR 3. Twelve parcels should cost 20 + 9 × 5 + 2 × 3 = 71 euros. There is nothing particularly exotic about that tariff. Turning it into three small programs still creates more work than the arithmetic suggests.

My first pricing model could express those programs. It knew about package scope, conditions, calculated amounts, and ordered adjustments. The problem wasn’t an inability to calculate the right price. It was that ordinary tariff structure kept arriving as another expression for the system to interpret. That affected editing, validation, and eventually execution.

A Cache Hit Is Not a Freshness Guarantee

Tue, 01 Apr 2025 00:00:00 +0000

A catalogue price is cached at revision 1. The database commits revision 2. Three seconds later, Laravel finds the key and returns revision 1 from inside its declared five-second fresh window.

The cache hit is real. So is the stale price.

In the LAR-06 fixture , the cached JSON is well formed and its SHA-256 hash matches its body. Nothing has expired or become corrupt. The failure is semantic: current-price requires the acknowledged source revision, while the cache only knows that a key still contains bytes.

Octane Removes Repeated Boot and Adds State

Sat, 01 Mar 2025 00:00:00 +0000

A catalogue endpoint returns the same 249-byte JSON response from two Laravel runtimes. One boots a fresh CLI process for every request. The other sends every request through one Octane RoadRunner worker.

In the LAR-05 fixture , their local median latencies at concurrency one are 43.2 ms and 1.3 ms. That is the tempting part of Octane.

Now send tenant A and then tenant B through the Octane worker. A mutable singleton returns tenant A twice. A singleton holding the configuration repository remembers tenant A twice. A singleton created with Laravel’s bootstrap request never sees either tenant.

Eager Loading Is Not a Query Shape

Sat, 01 Feb 2025 00:00:00 +0000

A catalogue endpoint returns 25 names and the number of active variants behind each one. The first implementation runs 26 queries. Adding with('activeVariants') reduces that to two.

The N+1 defect is gone. The new implementation still hydrates 1,250 Variant models, including a synthetic 4 KiB metadata column, to produce 25 integers.

Eager loading solved the repeated-query shape. It did not ask what the response needed. That is the larger decision: queries, selected rows and columns, hydrated models, serialization, and the database plan all belong to one read path.

A Worker Count Is Not a Throughput Plan

Wed, 01 Jan 2025 00:00:00 +0000

Four Laravel queue workers complete 114 waiting jobs per second where one worker completes 37. Keep the worker count at four, make every job update the same database row, and the rate falls to 32. Make each job fail twice before succeeding, and those four workers perform 540 attempts to produce 180 effects.

Nothing is wrong with the worker setting. It is answering three different workloads.

A worker count describes available executors. It says nothing about whether a job can run in parallel, which dependency must absorb the concurrency, or how many attempts are needed for one business effect. A throughput plan needs those parts too.

Cache the Deployment, Not the Assumption

Sun, 01 Dec 2024 00:00:00 +0000

Release B serves /inventory and labels its catalogue green. The code is correct. The environment is correct. Yet the application answers /catalogue with blue, while /inventory returns 404.

Nothing corrupted Laravel’s generated files. They contain release A’s configuration and route table because release A created them. The deployment combined those files with release B and produced a system which is consistently wrong.

config:cache and route:cache are often introduced as performance switches. That description misses their more important property: each command turns a set of inputs into a generated artifact. If the artifact is deployed, it must carry the same release identity as the code and environment which produced it.

A Slow Request Is Not a Capacity Plan

Fri, 01 Nov 2024 00:00:00 +0000

Five request profiles return the same catalogue data. A sixth path accepts a background rebuild.

One profile is the control. One repeats six database calls. One recomputes a value behind a unique cache key. One spends its time hashing in PHP. One uses a warm cache and stays close to the control. The rebuild responds 202 Accepted quickly while ten jobs wait behind one worker.

“The application is slow” fits the three deliberately expensive catalogue paths. “Work is delayed” fits the queue. “Add another server” addresses only one of them, and even there it is a hypothesis.

An Index Must Serve a Real Query

Sun, 01 Oct 2017 00:00:00 +0000

A production query needed a small page of recent records requiring operational attention. The table already had an index which looked relevant. The measured scan still discarded 84,003 historical index entries and recorded 122,936 shared-buffer reads before finding 83 eligible rows.

The table did not need another vaguely relevant index. It needed an index for this query:

one tenant
active records with zero price
created during the last three months
newest creation time first
stable identifier as the tie-breaker
first page only

That is the actual starting point: the access path, not a list of columns which sound important in isolation.

Debugging Ends with an Explanation, Not a Green Build

Thu, 01 Dec 2016 00:00:00 +0000

A cryptography-heavy application kept its CPUs near 100 percent. We found several cryptographic paths worth improving, so the diagnosis felt obvious: expensive mathematics was consuming the machine. How could logging possibly be more expensive than the work the application existed to do?

Then we measured the log stream. It was writing roughly a thousand lines per second to local disk. We reduced the emitted logging without changing the cryptographic work, and CPU use settled around 10–20 percent.

Logging Is a Workload, Not a Side Effect

Tue, 01 Mar 2016 00:00:00 +0000

One system was writing roughly a thousand log lines per second to local disk. Debug records were part of that stream. The individual call sites were small; the combined stream was not.

It was not cheap in aggregate. Every record still had to be constructed, serialized, copied through handlers, written, rotated, and eventually removed or archived. Whether anyone queried it later did not change that work. Calling the record debug did not exempt it from arithmetic.