Wie viel wissen Sie über die Prozesse und Threads von Swoole?

Die Kolumne

Swoole-Tutorial stellt den Prozess und den Faden von Swoole vor.

Empfohlen (kostenlos): Swoole-Tutorial

Prozesse

1. Es wird kein Status zwischen Prozessen geteilt
2. Die Prozessplanung wird vom Betriebssystem durchgeführt
3. Jeder Prozess verfügt über seinen eigenen unabhängigen Speicherbereich
4. Die Kommunikation zwischen Prozessen wird hauptsächlich durch Signalübertragung erreicht. Es gibt viele Implementierungsmethoden wie Semaphore, Pipes, Ereignisse usw. Die Kommunikationseffizienz jeder Methode erfordert den Kernel, was zu einer relativ geringen Kommunikationseffizienz führt ist ein unabhängiger Speicherplatz. Beim Kontextwechsel müssen die Informationen des ersten Aufrufstapels, die Informationen jedes CPU-Registers, des virtuellen Speichers und der zugehörigen geöffneten Handles usw. gespeichert werden, sodass der Wechsel zwischen Kontextprozessen sehr kostspielig ist Kommunikation mühsam.

Threads

1. Das Teilen von Variablen zwischen Threads löst das Problem der problematischen Kommunikation. Der Zugriff auf Variablen erfordert Sperren. 2. Ein Prozess kann mehrere Threads haben, aber jeder Thread teilt sich den übergeordneten Prozess und beantragt Ressourcen vom Betriebssystem. Dazu gehören virtueller Speicher, Dateien usw. Da es sich um eine gemeinsam genutzte Ressource handelt, sind die zum Erstellen eines Threads erforderlichen Systemressourcen viel kleiner als die eines Prozesses, und die entsprechende Anzahl an Threads, die erstellt werden können, wird relativ viel größer.

3. Darüber hinaus müssen in Bezug auf die Planung aufgrund der gemeinsamen Nutzung des Speichers beim Kontextwechsel weniger Dinge gespeichert werden, sodass der Kontextwechsel effizient wird.

Erläuterung

Durch PHP ist das Ausführen einer PHP-Datei gleichbedeutend damit, dass wir einen Prozess erstellen, der seinen eigenen Speicherplatz im System beansprucht und das entsprechende Programm ausführt. 1. Master-Prozess: Hauptprozess , Master-Prozess, dies ist der Hauptprozess von Swoole. Dieser Prozess wird durch das Kernereignis der Verarbeitung von Swoole gesteuert. In diesem Prozess können Sie sehen, dass es einen MainReactor [Thread] und mehrere Reactor [Threads] gibt swoole Die Überwachung von Ereignissen wird in diesen Threads implementiert, z. B. Verbindungen von Clients, Signalverarbeitung usw.

• 
  1.1, MainReactor (Hauptthread)
Der Hauptthread ist für die Überwachung des Server-Sockets verantwortlich. Wenn eine neue Verbindung angenommen wird, wertet der Hauptthread die Anzahl der Verbindungen für jeden Reactor-Thread aus. Weisen Sie diese Verbindung dem Reaktorthread mit der geringsten Anzahl von Verbindungen zu, um einen Lastausgleich durchzuführen.

1.2, Reactor-Thread-Gruppe Der Reactor-Thread ist für die Aufrechterhaltung der TCP-Verbindung des Client-Computers, die Verarbeitung von Netzwerk-E/A und das Senden und Empfangen von Daten in einem vollständig asynchronen und nicht blockierenden Modus verantwortlich.
Nach dem Akzeptieren einer neuen Verbindung weist der Hauptthread von swoole die Verbindung einem festen Reactor-Thread zu, liest die Daten, wenn der Socket lesbar ist, führt eine Protokollanalyse durch und übermittelt die Anfrage an den Worker-Prozess. Senden Sie Daten an den TCP-Client, wenn der Socket beschreibbar ist.

1.3. Heartbeat-Paketerkennungs-Thread (HeartbeatCheck)

Nachdem Swoole die Heartbeat-Paketerkennung konfiguriert hat, sendet der Heartbeat-Paket-Thread innerhalb eines festgelegten Zeitraums Erkennungsdatenpakete an alle zuvor Online-Verbindungen Thread (UdpRecv)
• Client-UDP-Datenpakete empfangen und verarbeiten

• swoole Wenn Sie die beste Leistung erzielen möchten, müssen Sie mehrere Arbeitsprozesse erstellen, um die Verarbeitung von Aufgaben zu unterstützen ist unsicher. Wenn keine Verwaltung vorhanden ist, werden viele Zombie-Prozesse angezeigt, die die Serverleistung beeinträchtigen. Gleichzeitig wird der Arbeitsprozess aus Programmgründen versehentlich beendet oder beendet , muss der Arbeitsprozess neu erstellt werden.

  
  

Swoole erstellt während des Betriebs einen separaten Managementprozess, und alle Arbeitsprozesse und Aufgabenprozesse werden vom Managementprozess abgezweigt. Der Managementprozess überwacht die Exit-Ereignisse aller untergeordneten Prozesse. Wenn im Arbeitsprozess ein schwerwiegender Fehler auftritt oder der laufende Lebenszyklus endet, recycelt der Managementprozess den Prozess und erstellt einen neuen Prozess. Mit anderen Worten: Der „Nanny“-Manager-Prozess hat die volle Autorität, die Erstellung und Wiederverwendung von Arbeitskräften und Aufgabenprozessen zu verwalten

• Der Worker-Prozess gehört zum logischen Hauptprozess von swoole. Der Benutzer verarbeitet eine Reihe von Anforderungen vom Client, akzeptiert die vom Reactor-Thread übermittelten Anforderungspakete und führt die PHP-Rückruffunktion aus, um die Daten zu verarbeiten und Antwortdaten zu generieren und sendet es an den Reactor-Thread, der an den TCP-Client gesendet wird. Er kann sich im asynchronen, nicht blockierenden Modus oder im synchronen Blockierungsmodus befinden. Der TaskWorker-Prozess ist ein asynchroner Worker-Prozess, der von swoole bereitgestellt wird. Diese Prozesse werden hauptsächlich zur Verarbeitung verwendet Einige langfristige synchrone Aufgaben werden im Worker-Prozess bereitgestellt.

• Interaktion zwischen Client und Server:

1. Die Client-Anfrage erreicht den Hauptreaktor. Der Client stellt tatsächlich eine Verbindung zu einem Reaktor-Thread im Master-Prozess her.

2. Der Hauptreaktor registriert die Anfrage entsprechend der Situation des Reaktors (jeder Reaktor verfügt über Epoll. Es wird verwendet, um Änderungen im Client zu überwachen)

3. Wenn es Änderungen im Client gibt, übergibt der Reaktor die Daten an den Worker zur Verarbeitung

4. Nachdem der Worker die Verarbeitung abgeschlossen hat, wird sie über prozessübergreifende Kommunikation (z. B. Pipes, gemeinsam genutzter Speicher, Nachrichtenwarteschlangen) an den entsprechenden Reaktor gesendet.

5. Reactor sendet das Antwortergebnis an die entsprechende Verbindungsanforderung

Callback-Funktion im Master-Prozess

onStart Server startet und ruft diese Funktion im Hauptthread des Hauptprozesses zurück

onShutdown This Ereignis tritt auf, wenn der Server normal beendet wird

• Callback-Funktion im Manager-Prozess

onManagerStart wird aufgerufen, wenn der Verwaltungsprozess startet

onManagerStop wird aufgerufen, wenn der Verwaltungsprozess endet

• onWorkerError Wenn eine Ausnahme im worker/task_worker-Prozess auftritt , diese Funktion wird im Manager-Prozess zurückgerufen
• Callback-Funktion im Worker-Prozess

onWorkerStart Dieses Ereignis tritt auf, wenn der Worker-Prozess/Task-Prozess startet

onWorkerStop Dieses Ereignis tritt auf, wenn der Worker-Prozess beendet wird.

• onConnect Diese Funktion wird im Worker-Prozess zurückgerufen, wenn eine neue Verbindung eingeht.
• onClose Nachdem die TCP-Client-Verbindung geschlossen wurde, wird diese Funktion im Worker-Prozess zurückgerufen.
• onReceive Diese Funktion wird zurückgerufen, wenn Daten empfangen werden , was im Worker-Prozess auftritt
• onPacket Diese Funktion wird zurückgerufen, wenn ein UDP-Paket empfangen wird, was im Worker-Prozess auftritt
• onFinish Wenn die vom Worker-Prozess übermittelte Aufgabe in task_worker abgeschlossen ist, sendet der Task-Prozess Übertragen Sie das Ergebnis der Aufgabenverarbeitung über die Methode „finish()“ an den Arbeitsprozess.
• onWorkerExit ist nur gültig, nachdem die reload_async-Funktion aktiviert ist. Asynchrone Neustartfunktion
• onPipeMessage Das Ereignis wird ausgelöst, wenn der Arbeitsprozess die von sendMessage gesendete Pipe-Nachricht empfängt
• Die Rückruffunktion im Task-Prozess

onTask wird im task_worker-Prozess aufgerufen. Der Worker-Prozess kann die Funktion swoole_server_task verwenden, um neue Aufgaben an den task_worker-Prozess zu übermitteln

onWorkerStart Dieses Ereignis tritt auf, wenn der Worker-Prozess/Task-Prozess startet

• onPipeMessage Das Ereignis wird ausgelöst, wenn der Worker-Prozess die von sendMessage gesendete Pipe-Nachricht empfängt
Einfache Beschreibung:

1. Das letzte Ereignis, wenn das Server-Shutdown-Programm beendet wird, ist onShutdown.

2. Nachdem der Server erfolgreich gestartet wurde, werden onStart/onManagerStart/onWorkerStart gleichzeitig in verschiedenen Prozessen und nicht nacheinander ausgeführt.

• 3. Alle Ereignisrückrufe erfolgen nach $server->start. Der nach dem Start geschriebene Code ist ungültig.
• 4. Die Ausführungsreihenfolge von onStart/onManagerStart/onWorkerStart 3-Ereignissen ist ungewiss.
• Swoole-Operationsablaufdiagramm . Die Prozessplanung wird vom Betriebssystem durchgeführt
• 3. Jeder Prozess verfügt über seinen eigenen unabhängigen Speicherbereich
4. Die Kommunikation zwischen Prozessen wird hauptsächlich durch Signalübertragung erreicht. Es gibt viele Implementierungsmethoden, wie z. B. Semaphore, Ereignisse usw. Die Kommunikationseffizienz jeder Methode muss über den Kernel erfolgen, was zu einer relativ geringen Kommunikationseffizienz führt. 5. Da es sich um einen unabhängigen Speicherplatz handelt, müssen die Informationen des ersten Aufrufstapels, die Informationen jedes CPU-Registers und der virtuelle Speicher berücksichtigt werden Beim Kontextwechsel werden Speicher, offene verwandte Handles und andere Informationen gespeichert, sodass das Wechseln zwischen Kontextprozessen sehr kostspielig und mühsam ist.

Threads

1. Das Teilen von Variablen zwischen Threads löst das Problem von Kommunikationsproblemen. Der Zugriff auf Variablen erfordert Sperren. 2. Ein Prozess kann mehrere Threads haben, aber jeder Thread teilt sich den übergeordneten Prozess und beansprucht Ressourcen wie das Betriebssystem umfasst virtuellen Speicher, Dateien usw. Da es sich um eine gemeinsam genutzte Ressource handelt, sind die zum Erstellen eines Threads erforderlichen Systemressourcen viel kleiner als die eines Prozesses, und die entsprechende Anzahl an Threads, die erstellt werden können, ist ebenfalls relativ größer geworden.
3. Darüber hinaus müssen in Bezug auf die Planung aufgrund der gemeinsamen Nutzung des Speichers beim Kontextwechsel weniger Dinge gespeichert werden, sodass der Kontextwechsel effizient wird.

Erläuterung

Durch PHP ist das Ausführen einer PHP-Datei gleichbedeutend damit, dass wir einen Prozess erstellen, der seinen eigenen Speicherplatz im System beansprucht und das entsprechende Programm ausführt. 1. Master-Prozess: Hauptprozess , Master-Prozess, dies ist der Hauptprozess von Swoole. Dieser Prozess wird durch das Kernereignis der Verarbeitung von Swoole gesteuert. In diesem Prozess können Sie sehen, dass es einen MainReactor [Thread] und mehrere Reactor [Threads] gibt swoole Die Überwachung von Ereignissen wird in diesen Threads implementiert, z. B. Verbindungen von Clients, Signalverarbeitung usw.
• 
  
1.1, MainReactor (Hauptthread)

Der Hauptthread ist für die Überwachung des Server-Sockets verantwortlich. Wenn eine neue Verbindung angenommen wird, wertet der Hauptthread die Anzahl der Verbindungen für jeden Reactor-Thread aus. Weisen Sie diese Verbindung dem Reaktorthread mit der geringsten Anzahl von Verbindungen zu, um einen Lastausgleich durchzuführen.

1.2, Reactor-Thread-Gruppe
Der Reactor-Thread ist für die Aufrechterhaltung der TCP-Verbindung des Client-Computers, die Verarbeitung von Netzwerk-E/A sowie das Senden und Empfangen von Daten in einem vollständig asynchronen und nicht blockierenden Modus verantwortlich.
Nach dem Akzeptieren einer neuen Verbindung weist der Hauptthread von swoole die Verbindung einem festen Reactor-Thread zu, liest die Daten, wenn der Socket lesbar ist, führt eine Protokollanalyse durch und übermittelt die Anfrage an den Worker-Prozess. Senden Sie Daten an den TCP-Client, wenn der Socket beschreibbar ist.

1.3. Heartbeat-Paketerkennungs-Thread (HeartbeatCheck)
• Nachdem Swoole die Heartbeat-Paketerkennung konfiguriert hat, sendet der Heartbeat-Paket-Thread innerhalb eines festgelegten Zeitraums Erkennungsdatenpakete an alle zuvor Online-Verbindungen Thread (UdpRecv)

  Client-UDP-Datenpakete empfangen und verarbeiten

• swoole Wenn Sie die beste Leistung erzielen möchten, müssen Sie mehrere Arbeitsprozesse erstellen, um die Verarbeitung von Aufgaben zu unterstützen ist unsicher. Wenn keine Verwaltung vorhanden ist, werden viele Zombie-Prozesse angezeigt, die sich auf die Serverleistung auswirken. Gleichzeitig wird der Arbeitsprozess aus Programmgründen versehentlich beendet oder beendet , muss der Arbeitsprozess neu erstellt werden.
  

• Swoole erstellt während des Betriebs einen separaten Managementprozess, und alle Arbeitsprozesse und Aufgabenprozesse werden vom Managementprozess abgezweigt. Der Managementprozess überwacht die Exit-Ereignisse aller untergeordneten Prozesse. Wenn im Arbeitsprozess ein schwerwiegender Fehler auftritt oder der laufende Lebenszyklus endet, recycelt der Managementprozess den Prozess und erstellt einen neuen Prozess. Mit anderen Worten: Der „Nanny“-Manager-Prozess hat die volle Befugnis, die Erstellung und Wiederverwendung von Workern und Aufgabenprozessen zu verwalten. Der Worker-Prozess gehört zum logischen Hauptprozess von swoole. Der Benutzer verarbeitet eine Reihe von Anfragen vom Client vom Client. Das vom Reactor-Thread gelieferte Anforderungspaket führt die PHP-Callback-Funktion aus, um die Daten zu verarbeiten, um Antwortdaten zu generieren und sie an den Reactor-Thread zu senden oder synchroner Blockierungsmodus

  
  
  

  taskWorker-Prozess Dieser Eintrag ist der von swoole bereitgestellte asynchrone Arbeitsprozess. Diese Prozesse werden hauptsächlich verwendet, um einige langfristige Synchronisationsaufgaben zu verarbeiten und im Arbeitsprozess bereitzustellen.

• 
  Interaktion zwischen Client und Server:
  

  1. Die Client-Anfrage erreicht den Hauptreaktor. Der Client stellt tatsächlich eine Verbindung zu einem Reaktor-Thread im Master-Prozess her.
• 2. Der Hauptreaktor registriert die Anfrage entsprechend der Situation des Reaktors (jeder Reaktor verfügt über Epoll. Es wird verwendet, um Änderungen im Client zu überwachen)

  
  3. Wenn es Änderungen im Client gibt, übergibt der Reaktor die Daten an den Worker zur Verarbeitung

4. Nachdem der Worker die Verarbeitung abgeschlossen hat, wird sie über prozessübergreifende Kommunikation (z. B. Pipes, gemeinsam genutzter Speicher, Nachrichtenwarteschlangen) an den entsprechenden Reaktor gesendet.

• 5. Der Reaktor sendet das Antwortergebnis an die entsprechende Verbindungsanfrage und die Verarbeitung ist abgeschlossen

  Callback-Funktion im Master-Prozess

  • onStart Wenn der Server startet, wird diese Funktion im Hauptthread des Hauptprozesses zurückgerufen
  • onShutdown Dieses Ereignis tritt ein, wenn der Server normal beendet wird

  Callback-Funktion im Manager-Prozess

  • onManagerStart Wenn der Verwaltungsprozess startet. Wird aufgerufen, wenn
  • onManagerStop aufgerufen wird, wenn der Verwaltungsprozess endet.
  • onWorkerError. Wenn eine Ausnahme im Worker-/Task_Worker-Prozess auftritt, wird diese Funktion im Manager-Prozess zurückgerufen.

  Callback Funktion im Worker-Prozess

  • onWorkerStart Dieses Ereignis wird im Worker-Prozess aufgerufen / Tritt auf, wenn der Task-Prozess startet
  • onWorkerStop Dieses Ereignis tritt auf, wenn der Worker-Prozess beendet wird.
  • onConnect Diese Funktion wird im Worker-Prozess zurückgerufen, wenn eine neue Verbindung eingeht.
  • onClose Nachdem die TCP-Client-Verbindung geschlossen wurde, wird diese Funktion im Worker-Prozess zurückgerufen.
  • onReceive Diese Funktion wird zurückgerufen, wenn Daten empfangen werden , was im Worker-Prozess auftritt
  • onPacket Diese Funktion wird zurückgerufen, wenn ein UDP-Paket empfangen wird, was im Worker-Prozess auftritt
  • onFinish Wenn die vom Worker-Prozess gelieferte Aufgabe in task_worker abgeschlossen ist, sendet der Task-Prozess Übertragen Sie das Ergebnis der Aufgabenverarbeitung über die Methode „finish()“ an den Arbeitsprozess.
  • onWorkerExit ist nur gültig, nachdem die reload_async-Funktion aktiviert ist. Asynchrone Neustartfunktion
  • onPipeMessage Das Ereignis wird ausgelöst, wenn der Arbeitsprozess die von sendMessage gesendete Pipe-Nachricht empfängt

  Die Rückruffunktion im Task-Prozess

  • onTask wird im task_worker-Prozess aufgerufen. Der Worker-Prozess kann die Funktion swoole_server_task verwenden, um neue Aufgaben an den task_worker-Prozess zu übermitteln
  • onWorkerStart Dieses Ereignis tritt auf, wenn der Worker-Prozess/Task-Prozess startet
  • onPipeMessage Das Ereignis wird ausgelöst, wenn der Worker-Prozess die von sendMessage gesendete Pipe-Nachricht empfängt

  Einfache Beschreibung:

  • 1. Das letzte Ereignis, wenn das Server-Shutdown-Programm beendet wird, ist onShutdown.
  • 2. Nachdem der Server erfolgreich gestartet wurde, werden onStart/onManagerStart/onWorkerStart gleichzeitig in verschiedenen Prozessen und nicht nacheinander ausgeführt.
  • 3. Alle Ereignisrückrufe erfolgen nach $server->start. Der nach dem Start geschriebene Code ist ungültig.
  • 4. Die Ausführungsreihenfolge der Ereignisse onStart/onManagerStart/onWorkerStart 3 ist ungewiss

Das obige ist der detaillierte Inhalt vonWie viel wissen Sie über die Prozesse und Threads von Swoole?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!