- What is cesurapp/swoole-bundle used for?
- It replaces Symfony’s built-in HTTP server with Swoole and adds background task workers, cron workers, process workers, and optional WebSocket handling. It targets high-traffic, I/O-bound Symfony apps such as APIs, real-time systems, and microservices. It is configured through config/packages/swoole.yaml and environment variables.
- How do I install cesurapp/swoole-bundle in a Symfony app?
- Run composer req cesurapp/swoole-bundle, then add the bundle entrypoint require lines to public/index.php before autoload_runtime.php. Configure options in config/packages/swoole.yaml and server environment values in .env. It requires Symfony 8.
- Does cesurapp/swoole-bundle support Laravel?
- No, it is a Symfony bundle built for Symfony 8+, not a Laravel package. Laravel developers would need a different Swoole integration such as Laravel Octane or a custom setup. The package’s DI, configuration, and commands are Symfony-specific.
- Which Symfony versions are supported by cesurapp/swoole-bundle?
- The README states it requires Symfony 8. The evaluation also describes it as designed for Symfony 8+. Check the repository’s composer constraints before upgrading or using it in older Symfony projects.
- How do I enable WebSockets with cesurapp/swoole-bundle?
- Set websocket_handler to your handler class in config/packages/swoole.yaml and enable the WebSocket socket option as needed. The handler is resolved through Symfony’s DI, so it can use services cleanly. WebSocket connections are server-bound, so horizontal scaling needs sticky sessions or an external pub/sub solution.
- How do background tasks and failed task retries work?
- The bundle provides task workers, and failed jobs are saved in the database with retry logic controlled by failed_task_retry and failed_task_attempt. Tasks should receive serializable data such as arrays and primitives; objects must be serialized manually. Task workers are best for short-lived jobs, while long-running work may need an external queue.
- Can I run cron jobs on multiple servers with this bundle?
- Scheduled tasks run on all servers, but file-based locking prevents the same task from running at the same time. In multi-server or Kubernetes deployments, file locks may not coordinate across nodes, so you need shared locking or a single scheduler instance. Review this carefully before scaling horizontally.
- What production concerns should I check before using Swoole with Symfony?
- Swoole coroutines share memory, so global state and service state must be handled carefully to avoid cross-request bugs. Monitor coroutine stats and task queue depth, and plan graceful shutdowns and health checks for Docker or Kubernetes. There is no built-in fallback to PHP-FPM, so failover would require custom logic.
- Is cesurapp/swoole-bundle good for CPU-bound workloads?
- It is optimized for I/O-bound, asynchronous workloads like APIs, WebSockets, and event-driven services. CPU-heavy tasks such as image processing or ML inference may not outperform PHP-FPM and can block workers. Use external workers or queues for CPU-bound jobs.
- How can I test or evaluate cesurapp/swoole-bundle safely?
- Start with a non-critical Symfony 8 app and modify only public/index.php plus swoole.yaml as documented. Test HTTP behavior, task serialization, cron locking, and WebSocket handling under load before production. Check the GitHub Actions testing badge and repository for current test coverage and maintenance activity.