Open Swoole 4.9.0 released: Server Metrics, Cloud Native OpenMetrics support and more


Open Swoole v4.9.0 is released with new server metrics, Cloud Native OpenMetrics support, Open Swoole Dashboard solutions and enhancements. This is the latest release of Open Swoole before the Christmas holidays in 2021.

As a part of the effect to support the Cloud Native ecosystem to enhance the Observability of the OpenSwoole server. OpenSwoole v4.9.0 started to support metrics in JSON and OpenMetrics formats.

New Open Swoole Metrics API

In the previous version of Open Swoole, you can get some metrics with API $server->stats(). In v4.9.0, there are more server-internal metrics are exposed to userspace for open source framework authors and developers.

You can get three types of format of the metrics output: PHP array, JSON, OpenMetrics format for Prometheus.

$server->stats(\OPENSWOOLE_STATS_DEFAULT); // get PHP array output metrics
$server->stats(\OPENSWOOLE_STATS_JSON); // get JSON output metrics
$server->stats(\OPENSWOOLE_STATS_OPENMETRICS); // get OpenMetrics output metrics

You can find more details of Open Swoole Metrics API and the sample output at /docs/modules/swoole-server-stats.

Potential BC break at $server->stats()

If you have been using the API $server->stats() before v4.9.0 within your framework or application, the output and key-value pairs are redesigned. So please make sure to run through tests before upgrading to v4.9.0.

OpenMetrics integration and support

OpenMetrics is a standard for transmitting cloud-native metrics based on Prometheus' wire format for metrics. You can use the output with Prometheus and many other monitoring services or software such as DataDog, Sysdig Monitor etc.

An example OpenMetrics output looks like this:

# TYPE openswoole_info gauge
openswoole_info{version="OpenSwoole-4.9.0"} 1
# TYPE openswoole_up gauge
openswoole_up 1
# TYPE openswoole_reactor_num gauge
openswoole_reactor_threads_num 4
# TYPE openswoole_requests counter
openswoole_requests_total 0
# TYPE openswoole_start_time gauge
openswoole_start_time 1639922085
# TYPE openswoole_max_conn gauge
openswoole_max_conn 256
# .....

You can find mroe details of the Open Swoole Metrics OpenMetrics output at /docs/modules/swoole-server-stats.

Open Swoole Dashboard

You can find the Open Swoole Dashboard template for Grafana at and import it into your Grafana server.

There is an step by step example repo at to help you get started with Open Swoole Dashboard using Open Swoole Metrics API, Grafana and Prometheus.

You can run the docker-compose stack at the same host as your Open Swoole server, then see the metrics graph in real time.

Dealing with Memory Leaks

Variables in the Open Swoole server has different life cycle compared with PHP-FPM. Misusing global or static variables within the Open Swoole server was a common issue for developers.

To better support the mainstream developers with PHP-FPM background, Open Swoole started working on exposing metrics of memory usage and allowing developers to get the top used classes with PHP API.

You can get the memory usage of a sample Worker process with PHP API:


If there are potential memory leaks, you may see the memory usage of a worker is growing when serving more and more requests.

You can get PHP VM internal metrics such as worker_vm_object_num and worker_vm_resource_num with PHP API:


If there are potential memory leaks, you may see these two metrics are growing when serving more and more requests.

You can find the top 10 used classes in the Open Swoole server with PHP API:


The sample output looks this:


[top_classes] => Array
        [Closure] => 4
        [Swoole\Connection\Iterator] => 2
        [Swoole\Table] => 2
        [Swoole\Process] => 1
        [Swoole\Http\Request] => 1
        [Swoole\Http\Server] => 1
        [Swoole\Server\Port] => 1
        [Swoole\Http\Response] => 1

You may see the counter of some classes growing when serving more requests. These classes are staying within the server when the lifecycle of the request is ended causing memory leaks.

Fallback memory usage safety

Your application or framework may be too complex to identify the place where memory leaks are happening.

In this case, you can set a max_request number to retire the worker process after it has served N requests.

So even memory leaks happen, but you can cap the memory usage within a reasonable amount. The memory is freed at the worker process level but not the request level.

Other changes

Remove support of stats_file

In the previous version, you can output stats into a local file by enabling a server option. We have removed this feature in v4.9.0.

Tests added for Laravel Octane

To better support downstream PHP frameworks working with Open Swoole, we started to add tests against the popular PHP frameworks. Laravel Octane tests are added within our testing pipeline in the first batch. All the Laravel Octane tests are passed before we release new versions.

Bug report and features request

You can report bugs and submit features requests at

List of changes in v4.9.0

- OpenMetrics and JSON format server metrics support
- Added Laravel Octane tests
- Added CentOS build tests
- Fix CurlMulti bugs
- Fix type bug in Process->wait
- Added more OpenSwoole server metrics
- Updated $server->stats() API
- Support disable Postgres with --with-postgres=n

OpenSwoole v4.9.1 released

OpenSwoole v4.9.1 is a bug fixes release without new features or major changes:

A major bug is fixed at Swoole Table may silently cause corrupted data when the value length exceeds the allocated column length.

Data type checking is also added for the Swoole Table.

- Bug fixed: Added type validation and value length validation at Swoole Table
- Fix build with old libcurl, thanks @remicollet

You can upgrade to Open Swoole v4.9.1 now:

pecl install openswoole

Or use Docker images:

docker pull openswoole/swoole:latest

If you need to install Open Swoole or look at other update methods, checkout the installation documentation and how to update Open Swoole.

🎄 Happy coding Christmas Holidays 2021.