# workerman-bundle **Repository Path**: mickeywaugh/workerman-bundle ## Basic Information - **Project Name**: workerman-bundle - **Description**: Workerman runtime for symfony applications - **Primary Language**: PHP - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-04-23 - **Last Updated**: 2026-04-23 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # Workerman runtime for symfony applications ![PHP ^8.2](https://img.shields.io/badge/PHP-^8.2-777bb3.svg?style=flat) ![Symfony ^6.4|^7.0](https://img.shields.io/badge/Symfony-^6.4|^7.0-374151.svg?style=flat) [![Tests Status](https://img.shields.io/github/actions/workflow/status/crazy-goat/workerman-bundle/tests.yaml?branch=master)](../../actions/workflows/tests.yaml) [Workerman](https://github.com/walkor/workerman) is a high-performance, asynchronous event-driven PHP framework written in pure PHP. This bundle provides a Workerman integration in Symfony, allowing you to easily create a http server, scheduler and supervisor all in one place. This bundle allows you to replace a traditional web application stack like php-fpm + nginx + cron + supervisord, all written in pure PHP (no Go, no external binaries). The request handler works in an event loop which means the Symfony kernel and the dependency injection container are preserved between requests, making your application faster with less (or no) code changes. ## Contributing Please see [CONTRIBUTING.md](https://github.com/crazy-goat/workerman-bundle/blob/master/CONTRIBUTING.md) for information about branch protection rules and development workflow. ## What new in this fork * `servers.reuse_port` - on linux machines u can use kernel load balancer if `SO_REUSEPORT` is enabled * `servers.serve_files` - set to `false` to disable serving file. Use this option for RestAPI projects. Default: `false` * By default `luzrain/workerman-bundle` parse data to `psr7` request and then to symfony `Request`. This `workerman-bundle` will create symfony request without psr7 it increase performance, but it is still experimental. ## Getting started ### Install composer packages ```bash composer require crazy-goat/workerman-bundle ``` ### Enable the bundle ```php ['all' => true], ]; ``` ### Configure the bundle A minimal configuration might look like this. For all available options with documentation, see the command output. ```bash $ bin/console config:dump-reference workerman ``` ```yaml # config/packages/workerman.yaml workerman: servers: - name: 'Symfony webserver' listen: http://0.0.0.0:80 processes: 4 reload_strategy: exception: active: true file_monitor: active: true ``` ### Start application Using the Symfony console command: ```bash $ bin/console workerman:server start $ bin/console workerman:server start -d # daemon mode ``` Or using the runtime directly: ```bash $ APP_RUNTIME=CrazyGoat\\WorkermanBundle\\Runtime php public/index.php start ``` ### Manage the server ```bash $ bin/console workerman:server stop # stop the server $ bin/console workerman:server stop -g # graceful stop $ bin/console workerman:server restart # restart $ bin/console workerman:server restart -d # restart in daemon mode $ bin/console workerman:server reload # reload workers (hot reload) $ bin/console workerman:server reload -g # graceful reload $ bin/console workerman:server status # show server status $ bin/console workerman:server connections # show active connections ``` \* For better performance, Workerman recommends installing the _php-event_ extension. > **Note:** If you have the `grpc` PHP extension installed, you must set the environment variable `GRPC_ENABLE_FORK_SUPPORT=1` before starting the server. The grpc extension spawns background threads that deadlock in forked child processes (e.g. scheduler tasks) unless fork support is explicitly enabled. See [grpc/grpc#31241](https://github.com/grpc/grpc/issues/31241) for details. ## Reload strategies Because of the asynchronous nature of the server, the workers reuse loaded resources on each request. This means that in some cases we need to restart workers. For example, after an exception is thrown, to prevent services from being in an unrecoverable state. Or every time you change the code in the IDE. There are a few restart strategies that are implemented and can be enabled or disabled depending on the environment. - **exception** Reload worker each time that an exception is thrown during the request handling. - **max_requests** Reload worker on every N request to prevent memory leaks. - **file_monitor** Reload all workers each time you change the files**. - **always** Reload worker after each request. ** It is highly recommended to install the _php-inotify_ extension for file monitoring. Without it, monitoring will work in polling mode, which can be very cpu and disk intensive for large projects. See all available options for each strategy in the command output. ```bash $ bin/console config:dump-reference workerman reload_strategy ``` ### Implement your own reload strategies You can create reload strategy with your own logic by implementing the RebootStrategyInterface and adding the `workerman.reboot_strategy` tag to the service. ```php