Gearman Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Task Queue Paradigm: The bundle aligns with Symfony2’s event-driven architecture but introduces a Gearman-based job queue, which may conflict with modern Symfony (5.4+) ecosystems (e.g., Symfony Messenger, Symfony UX Turbo). Gearman’s shared-nothing, distributed task execution model is viable for CPU-heavy, parallelizable workloads (e.g., image processing, batch jobs) but not for real-time or transactional workflows.
• Symfony Version Gap: Targets Symfony2, which is EOL since 2023. Integration with Symfony 5/6/7 requires backward-compatibility layers (e.g., Symfony Flex, custom bridge bundles) or a rewrite.
• Monolithic Design: Bundle lacks modularity (e.g., no PSR-15 middleware support, no async event listeners). Tight coupling to Gearman’s PHP extension may limit future adaptability (e.g., switching to Redis Queue or RabbitMQ).

Integration Feasibility

• Dependencies:
  • Gearman Server: Requires external infrastructure (Docker/K8s setup for HA).
  • PECL Gearman: PHP extension must be installed (pecl install gearman), which complicates CI/CD pipelines and serverless environments (e.g., AWS Lambda).
  • Symfony2 Legacy: No native support for Symfony’s DependencyInjection Component (v5+), autowiring, or messenger component.
• Data Flow:
  • Worker Management: Manual worker spawning (e.g., php bin/console gearman:workers:start) introduces operational friction.
  • Error Handling: No built-in dead-letter queues (DLQ) or retry mechanisms (critical for production resilience).

Technical Risk

Key Questions

1. Why Gearman?
   • Does the use case require Gearman’s features (e.g., distributed workers), or could Symfony Messenger + Doctrine Messenger suffice?
   • Are there existing Gearman investments (e.g., legacy workers) that justify this bundle?
2. Symfony Version Strategy
   • Will this be a temporary solution (e.g., for a legacy system) or a long-term dependency?
   • If Symfony 5+, how will you handle DI container differences (e.g., ContainerInterface vs. ParameterBag)?
3. Failure Modes
   • How will you handle Gearman server failures (e.g., retries, circuit breakers)?
   • What’s the SLA for task completion? Gearman’s no-guarantee delivery may violate critical workflows.
4. Maintenance Burden
   • Who will refactor the "говнокод"? Is there a maintainer commitment?
   • How will you test this in CI (e.g., Gearman server mocking)?

Integration Approach

Stack Fit

• Symfony2 Projects: Direct integration possible with minimal effort (follows Symfony2 bundle conventions).
• Symfony 5+ Projects:
  • Option 1: Wrap the bundle in a custom bridge to adapt to Symfony’s DI system (e.g., using FrameworkBundle compatibility layer).
  • Option 2: Replace with Symfony Messenger + Gearman transport (e.g., symfony/messenger-gearman-transport).
• Non-Symfony PHP:
  • Use the underlying gearman/gearman library directly for tighter control.
• Infrastructure:
  • Gearman Server: Deploy via Docker (e.g., gearman/gearman-worker) or Kubernetes.
  • PHP Workers: Containerize with supervisor for process management.

Migration Path

1. Assessment Phase:
   • Audit existing job queues (e.g., cron, RabbitMQ) to identify Gearman-compatible workloads.
   • Benchmark Gearman vs. alternatives (e.g., Symfony Messenger + Redis).
2. Pilot Phase:
   • Isolate non-critical tasks (e.g., report generation) in a Symfony2 sub-project.
   • Test worker failover and task persistence.
3. Production Rollout:
   • Gradually migrate batch jobs to Gearman workers.
   • Implement feature flags to toggle between old/new systems.
4. Decommissioning:
   • Plan for Symfony Messenger migration if long-term support is needed.

Compatibility

Sequencing

1. Infrastructure Setup:
   • Deploy Gearman server cluster (e.g., 3 nodes for HA).
   • Configure PHP-FPM workers with gearman extension.
2. Bundle Integration:
   • Install via Composer (dev-master branch).
   • Configure app/config.yml for multiple servers (e.g., localhost, gearman-prod).
3. Worker Deployment:
   • Script worker startup (e.g., supervisord config for process management).
   • Implement health checks (e.g., /gearman/workers endpoint).
4. Task Implementation:
   • Create Symfony commands or event listeners to dispatch jobs.
   • Example:

     $client = $this->get('cimus_gearman.client');
     $client->addJob('background_task', $data, function ($job) { /* callback */ });
     

5. Observability:
   • Log worker metrics (e.g., tasks processed, failures).
   • Alert on stuck workers or high queue backlog.

Operational Impact

Maintenance

• Bundle-Specific:
  • Refactoring Risk: "Говнокод" may require ongoing fixes (e.g., memory leaks, race conditions).
  • Dependency Updates: PECL Gearman and Gearman server may deprecate features.
• Symfony Integration:
  • DI Container: Custom glue code may break across Symfony versions.
  • Testing: Lack of PHPUnit tests in the bundle → manual QA required.
• Worker Management:
  • Manual Scaling: No auto-scaling; requires K8s/HPA or custom scripts.
  • Configuration Drift: Worker configs (e.g., timeouts) may diverge across environments.

Support

• Community:
  • No maintainer (0 stars, no recent commits). Expect self-service troubleshooting.
  • Russian Documentation: May require translation for non-Russian teams.
• Vendor Lock-in:
  • Gearman-Specific: Skills required for debugging (e.g., gearman --stat commands).
  • No Official Support: Relies on community patches or paid consulting.
• Incident Response:
  • Worker Crashes: No built-in restart mechanisms (requires external tools like systemd).
  • Task Failures: No DLQ → lost tasks unless manually logged.

Scaling

• Horizontal Scaling:
  • Workers: Add more PHP processes (but single-threaded per worker).
  • Gearman Servers: Scale with load balancer (e.g., HAProxy) for failover.
• Performance Bottlenecks:
  • Network Latency: Gearman’s TCP protocol may add overhead vs. in-memory queues (e.g., Redis).
  • PHP Workers: Memory limits (memory_limit) may kill long-running tasks.
• Benchmarking:
  • Test throughput under load (e.g., 1000 tasks/sec).
  • Measure tail latency for critical paths.

**