1.5 Upgradeführung

Sichern Sie vor dem Upgrade Ihre Daten und führen Sie dann die folgenden Befehle aus, um ein Upgrade durchzuführen
composer require workerman/webman-framework ^1.5 -W && composer require webman/console ^1.2.12 && php webman install

Funktionen und Änderungen

Unterstützung von Workerman v5 coroutine

Hinweis
Workerman v5 erfordert PHP>=8.1
Um Workerman zu aktualisieren, verwenden Sie den Befehl composer require workerman/workerman ^5.0.0 -W
Die Faser-Coroutine erfordert die Installation von composer require revolt/event-loop ^1.0.0

Beispiele

Verzögerte Antwort

<?php

namespace app\controller;

use support\Request;
use Workerman\Timer;

class TestController
{
    public function index(Request $request)
    {
        // Schlafen für 1,5 Sekunden
        Timer::sleep(1.5);
        return $request->getRemoteIp();
    }
}

Timer::sleep() ist ähnlich wie die integrierte sleep()-Funktion in PHP, mit dem Unterschied, dass Timer::sleep() den Prozess nicht blockiert.

Initiiere HTTP-Anfragen

Hinweis
Sie müssen composer require workerman/http-client ^2.0.0 installieren.

<?php

namespace app\controller;

use support\Request;
use Workerman\Http\Client;

class TestController
{
    public function index(Request $request)
    {
        static $client;
        $client = $client ?: new Client();
        $response = $client->get('http://example.com'); // Initiieren sie eine asynchrone Anfrage mit einer synchronen Methode
        return $response->getBody()->getContents();
    }
}

Auch die Anfrage $client->get() ist nicht blockierend, was in webman für die nicht blockierende Bearbeitung von HTTP-Anfragen zur Leistungssteigerung verwendet werden kann.

Weitere Informationen finden Sie unter workerman/http-client.

Hinzufügen der support\Context Klasse

Die support\Context Klasse wird für die Speicherung von datenspezifischen Anfragen verwendet. Wenn die Anfrage abgeschlossen ist, werden die entsprechenden Kontextdaten automatisch gelöscht. Das bedeutet, dass die Lebensdauer der Kontextdaten der Anfragelebensdauer folgt.

Verunreinigung globaler Variablen

In einer Coroutine-Umgebung ist es verboten, anfragebezogene Statusinformationen in globalen oder statischen Variablen zu speichern, da dies zu einer Verunreinigung globaler Variablen führen kann, z.B.

<?php

namespace app\controller;

use support\Request;
use Workerman\Timer;

class TestController
{
    protected static $name = '';

    public function index(Request $request)
    {
        static::$name = $request->get('name');
        Timer::sleep(5);
        return static::$name;
    }
}

Wenn die Anzahl der Prozesse auf 1 gesetzt wird, und wir zwei aufeinander folgende Anfragen machen:
http://127.0.0.1:8787/test?name=lilei
http://127.0.0.1:8787/test?name=hanmeimei
Erwarten wir, dass die Ergebnisse der beiden Anfragen jeweils lilei und hanmeimei sind, aber tatsächlich sind beide Ergebnisse hanmeimei.
Dies liegt daran, dass die zweite Anfrage die statische Variable $name überschreibt, und wenn die erste Anfrage beendet ist, ist die statische Variable $name bereits hanmeimei.

Die korrekte Methode ist die Verwendung des Context, um Anfragestatusdaten zu speichern

<?php

namespace app\controller;

use support\Request;
use support\Context;
use Workerman\Timer;

class TestController
{
    public function index(Request $request)
    {
        Context::set('name', $request->get('name'));
        Timer::sleep(5);
        return Context::get('name');
    }
}

Lokale Variablen verursachen keine Datenverunreinigung

<?php

namespace app\controller;

use support\Request;
use support\Context;
use Workerman\Timer;

class TestController
{
    public function index(Request $request)
    {
        $name = $request->get('name');
        Timer::sleep(5);
        return $name;
    }
}

Da $name eine lokale Variable ist, können Coroutinen nicht auf lokale Variablen in anderen Coroutinen zugreifen, daher ist die Verwendung einer lokalen Variable coroutine-sicher.

Über Coroutinen

Coroutinen sind kein Allheilmittel. Die Einführung von Coroutinen bedeutet, dass auf die Verunreinigung globaler Variablen/Statikvariablen geachtet werden muss und der Kontext festgelegt werden muss. Darüber hinaus ist das Debuggen von Fehlern in einer Coroutine-Umgebung komplexer als in einer blockierenden Programmierung.

Webman blockierende Programmiertechniken sind bereits schnell genug. Basierend auf den Benchmark-Daten der letzten drei Jahre auf techempower.com sind die blockierenden Webman-Datenbankgeschäfte fast doppelt so schnell wie die go-Web-Frameworks Gin, Echo und um fast das 40-fache schneller als herkömmliche Frameworks wie Laravel.

Wenn Datenbank, Redis usw. im internen Netzwerk sind, ist die Leistungsfähigkeit der blockierenden Programmierung möglicherweise höher als die der Coroutinen, da bei schneller Datenbank, Redis usw. die Kosten für das Erstellen, Planen und Auflösen von coroutines möglicherweise höher sind als die Kosten für den Prozesswechsel, und die Einführung von coroutines führt möglicherweise nicht zu einer signifikanten Leistungssteigerung.

Wann sollte man Coroutinen verwenden?

Wenn es langsame Zugriffe im Geschäft gibt, wie z.B. den Zugriff auf APIs von Drittanbietern, können Sie mit workerman/http-client asynchron Anfragen initiieren, um die Parallelität der Anwendungsfähigkeiten zu erhöhen.