it-swarm.com.de

Wie finde ich heraus, was das Limit für den "Einstiegsprozess" verursacht?

Wir verwenden ein benutzerdefiniertes OpenCart 1.5.5.1-Design für unsere Website.

Nun, es war kein reibungsloses Segeln für uns und wir stehen vor einem Problem nach dem anderen. Bisher ist der Kern davon, dass wir derzeit auf einem Business-SSD-Host (nach wie vor freigegeben, glaube ich) sind, um die Leistung der Site (uniqpcs.co.uk) zu testen. Es ist eine Testphase, damit wir den testen können Website (unter Verwendung der Last Auswirkungen). In jeder einzelnen Instanz, in der der Test ausgeführt wird, scheint das Limit für den Einstiegsprozess erreicht zu sein, was dazu führt, dass die Site nicht mehr reagiert und schließlich abstürzt (das Limit für den Einstiegsprozess ist in unserem cPanel auf 20 festgelegt - es wurden sogar 40, aber immer noch das gleiche Problem versucht).

Ich bin leider ohne echte Hilfe per E-Mail und Live-Chat mit dem Host-Anbieter (NameCheap) in Kontakt getreten, aber sie haben mir ein paar Dinge angesprochen, die Sie hoffentlich klären können:

Soweit ich weiß, ist die Grenze des Eintrittsprozesses erreicht, wenn ein Prozess (höchstwahrscheinlich PHP Skripte) viel länger als erwartet hängt und der Verzögerung führt dazu, dass sich immer mehr Prozesse häufen und die Website nicht mehr reagiert und schließlich an ihre Grenzen stößt.

In ihrem MySQL-Fehlerprotokoll stellten sie fest, dass die Datenbank mit 126 Tabellen und insgesamt 26791 Zeilen 'anscheinend' nicht sehr gut optimiert ist, und sagten, dass es in MySQL eine SELECT-Abfrage gibt, die aufgrund einer großen Anzahl von Zeilen zu lange verarbeitet:

Nachfolgend finden Sie die MySQL-Serverprotokolle:

# Time: 140501  8:37:23
# [email protected]: auniqpcs_uniqpc[auniqpcs_uniqpc] @ localhost []
# Query_time: 12.059221  Lock_time: 0.004748 Rows_sent: 1 Rows_examined: 26731
SET timestamp=1398947843;
SELECT COUNT(DISTINCT p.product_id) AS total FROM category_path cp LEFT JOIN product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN product p ON (p2c.product_id = p.product_id) LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '211';

# [email protected]: auniqpcs_uniqpc[auniqpcs_uniqpc] @ localhost []
# Query_time: 12.081561  Lock_time: 0.004338 Rows_sent: 1 Rows_examined: 26746
SET timestamp=1398947843;
SELECT COUNT(DISTINCT p.product_id) AS total FROM category_path cp LEFT JOIN product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN product p ON (p2c.product_id = p.product_id) LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '258';
# Time: 140501  8:37:26

# [email protected]: auniqpcs_uniqpc[auniqpcs_uniqpc] @ localhost []
# Query_time: 13.821338  Lock_time: 0.005288 Rows_sent: 1 Rows_examined: 26746
SET timestamp=1398947846;
SELECT COUNT(DISTINCT p.product_id) AS total FROM category_path cp LEFT JOIN product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN product p ON (p2c.product_id = p.product_id) LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '245';
# Time: 140501  8:37:32

# [email protected]: auniqpcs_uniqpc[auniqpcs_uniqpc] @ localhost []
# Query_time: 16.426658  Lock_time: 0.010242 Rows_sent: 1 Rows_examined: 26746
SET timestamp=1398947852;
SELECT COUNT(DISTINCT p.product_id) AS total FROM category_path cp LEFT JOIN product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN product p ON (p2c.product_id = p.product_id) LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '245'; 

Während der Verarbeitung sendet load tool eine weitere PHP -Anforderung, die die Anforderung an MySQL "weiterleitet" (während die erste SQL-Abfrage noch verarbeitet wird). Es ist auch möglich, dass PHP Anfragen, die an MySQL weitergeleitet werden, falsch codiert sind.

pingdom: http://tools.pingdom.com/fpt/#!/bzzDid/uniqpcs.co.uk

Ich würde wirklich gerne wissen, was genau die Ursache für dieses Problem ist. Ist es ein schlecht codiertes PHP -Skript, sind es die MySQL-Datenbankabfragen oder ist es der Host?

Jetzt bin ich mir nicht sicher, was ich tun soll. Jeder Rat ist willkommen.

2
abab

Demzufolge:

http://docs.cloudlinux.com/entry_processes_limit.html

Die Grenzwerte für den Einstiegsprozess sollen verhindern, dass Hacker den Server verlangsamen.

Was Sie tun sollten, ist einen genaueren Blick auf Ihre Bearbeitungszeit.

Führen Sie einen Test auf webpagetest.org durch und überprüfen Sie die Werte für "time to first byte". Wenn es mehr als eine Fünftelsekunde ist, ist es ein Verarbeitungsproblem und die ersten Dinge, die untersucht werden sollten, sind welche Komponenten die Webseite selbst benötigt UND von welchem ​​Teil der Datenbank Sie Daten benötigen und wann.

Wenn Sie also eine Webseite ausführen, auf der ein externes Stylesheet, eine externe Javascript-Datei und eine Reihe externer Bilder (insbesondere große, qualitativ hochwertige Bilder) geladen werden, deren URLs auf denselben Server wie die Webseite selbst verweisen, kann dies zu einer Verlangsamung führen Dies ist zu erwarten, da sich die Anzahl der Anfragen pro Benutzer relativ schnell vervielfachen kann.

Überprüfen Sie auch die Datenbank. Wenn der Code, der immer ausgeführt wird, darin besteht, nach etwas Komplexem mit der größten Tabelle zu suchen, z. B. nach einer Anzahl von Zeilen im laufenden Betrieb, müssen Sie mit einer Wartezeit von 200 ms pro Elementanforderung rechnen. Versuchen Sie, dies zu beheben, indem Sie häufig angeforderte Daten in einer separaten Tabelle speichern und daraus lesen.

Beispiel:

Angenommen, es gibt eine Tabelle mit dem Namen CFG, in der zufällige Konfigurationsdaten mit den Feldnamen "Name" und "Wert" gespeichert werden, und eine Tabelle mit dem Namen ABC mit über 1.000.000 Einträgen, und Sie wissen nicht genau, wie viele es gibt.

Natürlich könnte man ausführen:

Select count(*) as Total from ABC;

Um die Anzahl der Elemente abzurufen und das Ergebnis in einer temporären neuen Spalte mit dem Namen Total zu speichern. Ich habe das gerade auf einem Tisch mit über 900.000 Datensätzen auf einem Pentium 4 gemacht und es dauerte ungefähr 4 Sekunden, um eine Zählung zu erhalten.

In diesem Beispiel möchten Sie stattdessen einen neuen Konfigurationswert hinzufügen, nach dem ständig gesucht werden kann:

Insert Into CFG(Name,Value) Values("tabletotal","0");
Update CFG set Value=(Select count(*) as Total from ABC) where CFG.Name="tabletotal";

Überprüfen Sie anschließend, ob die Nummer hinzugefügt wurde, indem Sie die gesamte Konfigurationstabelle mit der folgenden Anweisung durchsuchen:

Select * from CFG;

Wenn Sie in Ihrem Skript ein Beispiel wie dieses verwendet haben, ändern Sie Folgendes:

Select count(*) as Total from ABC;

Zu:

Select Value from CFG where Name="tabletotal";

Dann sparen Sie einen großen Teil der Verarbeitungszeit und die Wahrscheinlichkeit, dass das Limit für die Eingabeverarbeitung erreicht wird, ist erheblich geringer.

1
Mike

"Von dem, was ich verstehe....."

Nicht wirklich. Sicher bedeutet mehr Anforderungen mehr Prozess und längere Anforderungen bedeuten mehr gleichzeitige Prozesse. Dies sollte jedoch nicht Ihr Ausgangspunkt für die Verwaltung der Kapazität auf einem Server sein, es sei denn, Ihr Geschäftsmodell besteht darin, durch den Verkauf von Verarbeitungskapazität Geld zu verdienen.

Es ist ein komplexes Problem, genau zu bestimmen, wie viele gleichzeitige Anforderungen Ihr Stack verarbeiten kann. Dies erfordert einen wesentlich tieferen Zugriff auf Ihr System als in cpanel. Sie haben keine Details zur Spezifikation der Hardware angegeben, aber ich würde davon ausgehen, dass etwas Vergleichbares wie ein Desktop mit niedrigen Spezifikationen (2 Kerne/2 GB) in der Lage ist, ungefähr 70-130 Anforderungen gleichzeitig zu verarbeiten. Dies kann jedoch je nach Hardware stark variieren Code.

Ihr derzeit größtes Problem ist Ihr DBMS - Ihr Datensatz ist zwar winzig, die Ausführung Ihrer Abfragen dauert jedoch enorm lange. Ihre Datenbank ist so klein, dass Sie wahrscheinlich keinen nennenswerten Nutzen aus der Verwendung einer SSD ziehen - Ihre Daten sollten alle in den Arbeitsspeicher passen. Aber diese Abfragezeiten sind wirklich schrecklich. Leider gibt es dafür keine schnelle Lösung. Sie müssen wissen, wie Sie das Schema analysieren und ändern.

Ich würde Ihnen auf jeden Fall empfehlen, Ihre eigene Maschine zum Testen einzurichten. Sie sollten zwar über ausreichenden Zugriff verfügen, um die Ursache der meisten Datenbankprobleme zu ermitteln, ohne vollständigen Administratorzugriff zu benötigen, dies ist jedoch für einige der Korrekturen erforderlich. Und Sie benötigen Root-Zugriff, um den Problemen auf dem PHP und dem Webserver auf den Grund zu gehen.

Sie haben noch viel zu lernen. Das Empfehlen bestimmter Produkte ist hier verpönt, daher empfehle ich Ihnen Google für Bücher über Linux, Apache, MySQL und PHP Leistungsoptimierung.

pdate

Ich habe mir gerade Ihre Seite angesehen. Auf der Titelseite werden keine Symptome von DBMS-Problemen angezeigt. Bei den oben genannten Protokolleinträgen handelt es sich möglicherweise um Anomalien. Es gibt jedoch einige schreckliche Probleme beim Rendern des Frontends. Nicht zuletzt die Tatsache, dass die Titelseite über 400 Bilder hat.

1
symcbean

Laut meinem Webbrowser ist eine HTML-Seite allein ungefähr 35 KB in HTML, was ungefähr 15 KB mehr ist, als es sein sollte. Außerdem wurden 458 Elemente geladen, wofür mehr als 6,4 MB Daten erforderlich waren. Eine arme Seele da draußen, die möglicherweise immer noch eine 56K-DFÜ-Verbindung mit maximaler Geschwindigkeit verwendet, müsste mindestens 19 Minuten warten, bis die Hauptseite vollständig geladen ist.

Eine Sache, die sehr helfen kann, ist die Konsolidierung Ihrer Bilder und Skripte.

Schauen Sie sich CSS-Sprites an. Es ist eine einfache Methode, um das Laden von Bildern zu beschleunigen, und es hat den Vorteil, dass Ihr Server weniger häufig getroffen wird, wodurch er insgesamt schneller wird.

Führen Sie alle Ihre CSS-Stile zusammen und entfernen Sie unnötige Leerzeichen. Um die Geschwindigkeit zu erhöhen, entfernen Sie Kommentare. Versuchen Sie, nur EINE CSS-Datei pro Seite zu haben, nicht mehr als 20.

Machen Sie dasselbe mit Javascript-Dateien. Konsolidieren Sie sie zu einem.

Beim Laden Ihrer Website ist mir ein Hintergrundbild aufgefallen, das geladen wurde, bevor alles andere geladen wurde. Ich sehe keinen wirklichen Vorteil darin, und das Entfernen würde dazu beitragen, die Website schneller zu machen.

Ich bemerkte auch eine schlechte Header-Ausgabe, als ich mir die Header ansah:

HTTP/1.1 200 OK
Date: Mon, 02 Feb 2015 01:39:12 GMT
Server: Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
X-Powered-By: PHP/5.3.28
Pragma: no-cache
Nitro-Cache: Enabled
Cache-Control: public, max-age=31536000
Expires: Wed, 04 Mar 2015 01:39:12 GMT
Set-Cookie: PHPSESSID=c37c0a5a0d115149b494fae5cf5b1d78; path=/
Last-Modified: Sun, 01 Feb 2015 23:41:06 GMT
Vary: Accept-Encoding,User-Agent
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache
Content-Type: text/html; charset=utf-8

Mit einem solchen Header fordern Browser die Seite wahrscheinlich erneut an, selbst wenn die neueste Kopie lokal gespeichert ist. Um dies zu beheben, müssen diese Zeilen entfernt werden:

Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache

Ich habe das Kommandozeilen-Tool CURL benutzt, um die Überschriften zu überprüfen.

0
Mike