Eşzamanlı HTTP çağrıları için ham Fiber mı, ReactPHP/AMPHP mı, yoksa Swoole mu seçmeliyim?

Kısa cevap: Ham Fiber tek başına bu iş için size hiçbir şey kazandırmaz.

Kısa cevap

Fan-out HTTP’de gerçek seçim, FPM içinde kalacaksanız curl_multi/Guzzle Pool, ergonomik async isterseniz AMPHP v3, mimariyi baştan kuracaksanız Swoole arasında.

Neden

1. Ham Fiber bir primitive’tir, çözüm değil. Fiber sadece cooperative scheduling verir; kendi başına ne event loop ne de non-blocking I/O sağlar. HTTP çağrılarını gerçekten paralel çalıştırmak için soket katmanını, scheduler’ı ve promise mantığını sizin yazmanız gerekir — ki AMPHP ve ReactPHP zaten tam olarak bunu yapmak için var. Ham Fiber’a inmek, bu kütüphaneleri yeniden icat etmektir.

2. AMPHP v3 = Fiber üstüne kurulu ergonomik async/await. Zaten arka planda Fiber kullanır ama size temiz bir async/await API’si ve amphp/http-client verir. Callback cehennemi yok. Standart PHP kurulumunda çalışır; işler karmaşıklaşınca (birbirine bağlı çağrılar, streaming) burada ölçeklenir.

3. ReactPHP olgun ama promise/callback stilinde. Aynı işi görür, üretimde yıllardır sağlam. Ancak yeni kodda AMPHP’nin async/await’i çok daha okunur; ben yeni projede AMPHP’yi tercih ederim.

4. Swoole ayrı bir dünyadır. Extension ister, blocking I/O’yu hook’lar ve FPM modelini bırakıp long-running worker’a geçmenizi gerektirir. Throughput yüksektir ama operasyonel maliyet, state sızıntısı riski ve bazı extension’larla uyumsuzluk da yüksektir. Sırf 200 çağrı için bu bedeli ödemem.

Ne yapmalı

1. En sıkıcı çözüm çoğu zaman doğru olanı: curl_multi / Guzzle Pool. Yalnızca N tane HTTP çağrısını eşzamanlı yapmak istiyorsanız, curl_multi (veya onu saran Guzzle Pool) standart PHP-FPM içinde gerçek paralel istek yapar. Yeni bir extension kurulumu gerekmez, zaten var olan curl kullanılır; runtime değişikliği yok, deployment aynı kalır.

2. Asıl mesele runtime değil, o 200 sayısı. Aynı anda 200 açık bağlantı hem sizi hem upstream’i yorar. 20-50 pencereli bir concurrency cap koyun, her çağrıya timeout verin, partial failure’ı ele alın (biri düşünce hepsi düşmesin).

   use GuzzleHttp\Client;
   use GuzzleHttp\Pool;
   use GuzzleHttp\Psr7\Request;
   
   $client = new Client(['timeout' => 3.0]);
   $requests = static function (array $urls) {
       foreach ($urls as $u) {
           yield new Request('GET', $u);
       }
   };
   
   $pool = new Pool($client, $requests($urls), [
       'concurrency' => 25, // aynı anda en fazla 25 açık bağlantı
       'fulfilled'   => fn($res, $i) => $results[$i] = (string) $res->getBody(),
       'rejected'    => fn($reason, $i) => $errors[$i] = $reason, // partial failure
   ]);
   $pool->promise()->wait();

Sonuç: Ben olsam FPM’de kalıp Guzzle Pool ile başlar, concurrency’yi 20-50 arasında sabitler, timeout ve partial failure’ı düzgün yönetirdim — bu bugün deploy edilebilir en basit çözüm. Kod tabanı gerçekten async’e evrilirse AMPHP v3’e geçerdim. Swoole’u yalnızca servisi long-running bir modele taşıma kararı zaten masadaysa düşünürdüm. Ham Fiber’ı ise kütüphane yazmıyorsanız hiç düşünmezdim.