Zum Hauptinhalt springen

Parallele Ausführung mit Laravel Concurrency

Im stdio-Modus

Für jede Ausführung einen eigenen Prozess zu starten ist ineffizient, doch nur so hat es funktioniert. Da Concurrency intern eine komplexe Serialisierung vornimmt, wird statt der Klasse SessionEvent nur der String aus content() zurückgegeben.
use Revolution\Copilot\Facades\Copilot;
use Illuminate\Support\Facades\Concurrency;

$prompt = 'Tell me something about Copilot.';

[$gpt5_response, $sonnet_response] = Concurrency::run([
    fn () => Copilot::run($prompt, config: ['model' => 'gpt-5.2'])->content(),
    fn () => Copilot::run($prompt, config: ['model' => 'claude-sonnet-4.5'])->content(),
]);

echo 'GPT-5 Response: '.$gpt5_response;
echo 'Claude Sonnet Response: '.$sonnet_response;

Im TCP-Modus

Ohne Prozessstart wirkt es zunächst schneller, praktisch war der Unterschied jedoch gering. Beim Process-Treiber kommt es in beiden Fällen häufig nach 60 Sekunden zu Timeouts. Beim CLI-spezifischen fork-Treiber war nur eine Seite erfolgreich. Es kommt nicht zu einem Ausnahmefall, in dem alles fehlschlägt. Da nur gpt-5 fehlschlug, wurde auf gpt-5.2 umgestellt, worauf beide erfolgreich waren. Möglicherweise lag es schlicht an der Antwortzeit des Modells. Concurrency existiert als Funktion, ob es praxistauglich ist, ist jedoch unklar. Für zeitaufwendige Verarbeitungen sind grundsätzlich Queues zu bevorzugen.
Aktuelle Informationen finden Sie im GitHub-Repository.
Zuletzt geändert am 13. Juli 2026