Download the PHP package webparking/laravel-queue-garbage-collection without Composer
On this page you can find all versions of the php package webparking/laravel-queue-garbage-collection. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download webparking/laravel-queue-garbage-collection
More information about webparking/laravel-queue-garbage-collection
Files in webparking/laravel-queue-garbage-collection
Package laravel-queue-garbage-collection
Short Description Collect PHP reference cycles after every queue job to keep long-running workers from leaking off-heap memory.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-queue-garbage-collection
Collect garbage cycles after every queue job
A zero-config Laravel package that runs gc_collect_cycles() after every queue job.
Why this exists
Long-running queue workers accumulate PHP reference cycles that pin off-heap memory: the native buffers behind libcurl and OpenSSL (any HTTP client or SDK), DOM trees, image resources, and similar extension-backed objects. That memory is invisible to memory_get_usage(), so queue:work --memory never trips on it. Meanwhile PHP's adaptive cyclic garbage collector backs off precisely in this situation — the cycles hold only a handful of PHP objects while pinning a lot of native memory, so the collector's object-count heuristic sees nothing worth collecting. The result: resident memory (RSS) climbs job after job until the worker is OOM-killed.
Forcing a collection at each job boundary releases those cycles immediately and keeps memory flat. It is safe to force per job because queue workers share no state between jobs, so nothing you'd want to keep is ever collected.
Installation
That's it. The service provider auto-registers via Laravel's package discovery and hooks a listener onto both JobProcessed (success) and JobExceptionOccurred (each failed attempt). The listener calls gc_collect_cycles() and nothing else.
When you might not want it
The only profile where this is pure overhead is a very high-throughput queue of tiny, cycle-free jobs under no memory pressure — there, each collection scans the GC root buffer and frees nothing. Everywhere else the cost is negligible, and it is never a correctness risk (workers share no state across jobs, so a forced collection can only reclaim genuine garbage).
Supported versions
Every combination below is exercised in CI:
| PHP | Laravel | Testbench |
|---|---|---|
| 8.1 | 9 | 7 |
| 8.2 | 10 | 8 |
| 8.3 | 11 | 9 |
| 8.4 | 12 | 10 |
| 8.5 | 13 | 11 |
Testing & local development
The full PHP × Laravel matrix runs locally via act, executing the exact CI workflow in Docker:
For day-to-day work there's a Docker workspace pinned to the newest supported combination (PHP 8.5 / Laravel 13):
Prefer running things yourself? composer install && composer test works too.
License
The MIT License (MIT). Please see the License File for more information.
All versions of laravel-queue-garbage-collection with dependencies
illuminate/queue Version ^9.0 || ^10.0 || ^11.0 || ^12.0 || ^13.0
illuminate/support Version ^9.0 || ^10.0 || ^11.0 || ^12.0 || ^13.0