Facebook XHP. Objektvorlage

    Trotz der Tatsache, dass Facebook XHP bereits im Februar 2010 angekündigt hat, gibt es immer noch sehr wenige Informationen über diese Template-Engine, obwohl XHP selbst als Idee sehr, sehr interessant ist.

    In diesem Artikel werde ich versuchen, einen kurzen Überblick über XHP zu geben, die wichtigsten Vor- und Nachteile, und auch Leistungsprobleme ansprechen.


    XHP ist eine PHP-Erweiterung, die die Sprachsyntax ergänzt, um einerseits die Wahrnehmung von Front-End-Code zu verbessern und andererseits XSS-Angriffe zu vermeiden. [1]



    Also, was brauchen wir, um ein bisschen HTML (XML) Markup auszugeben?

    Wenn unhöflich, dann ist Folgendes erforderlich:
    // генерируем HTML
    $html = '

    Привет, Хабр!

    '; echo $html;


    Nun dasselbe mit XHP:
    $html = 

    Привет, Хабр!

    ; echo $html;


    oder so:
    $html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет, Хабр!'));
    echo $html;
    


    Ich denke, dass nach diesen Beispielen den meisten bereits klar geworden ist, dass das XML von der XHP-Erweiterung in bestimmte Klassen übersetzt wird, die das HTML-Element beschreiben.
    Dies ist im Großen und Ganzen der springende Punkt der XHP-Template-Engine. Jetzt arbeiten Sie nicht mit "String HTML". Ab dem Wort "vollständig", da jeder Knoten ein Objekt mit eigenen Eigenschaften ist.

    Zusätzlich zu allen wird jeglicher vom Benutzer erzeugter Inhalt ausgeblendet, d. H. Für jedes untergeordnete Element, das kein HTML-Element ist, wird HTML- Sonderzeichen automatisch verarbeitet . Ja, und Ihre aus der Datenbank empfangenen Inhalte werden standardmäßig ausgeblendet. Glauben Sie mir, es ist besser für Sie.

    PHP:
    $html = "
    {$_POST['xss_content']}
    "; // не безопасно


    XHP:
    $html = 
    {$_POST['xss_content']}
    ; // безопасно


    Ein weiteres Merkmal von XHP ist die integrierte HTML-Validierung (XML). Sie können eine Klasse nicht auf folgende Weise instanziieren:
    $html = new myHtml(;
    

    Daher können HTML-Elemente bei falscher Verschachtelung nicht geschlossen bleiben (kurze Tags werden unterstützt).

    Nun zu den Nachteilen


    Der einzige offensichtliche Nachteil des obigen Schemas ist, woraus sich seine Pluspunkte ergeben - jedes Element ist ein Objekt .
    Dementsprechend besteht ein Layout aus 2000 verschachtelten Tags aus 2000 verschachtelten Objekten.

    Was wir in der Ausgabe erhalten, ist klar:
    • Erhöhter Speicherverbrauch
    • Leistungsabfall


    Ich sehe nicht, dass der erhöhte Speicherverbrauch einen Großteil dieses Artikels betrifft, weil XHP-Objekte sind recht einfach und es wird viel Speicher für den Prozess reserviert (640 Kilobyte reichen für alle (n)).
    Das Erstellen vieler verschachtelter Objekte und das Konvertieren von XHP-Markups in Objekte sollte jedoch die Renderzeit verlängern. Die Frage ist, wie viel?

    Glücklicherweise führte jemand 2010 bei Rasmus Lerdorf eine vergleichende Analyse der "Feuerrate" von XHP gegenüber PHP-native durch und erhielt die folgenden Ergebnisse [2]:

    • PHP: ~ 97% Degradation (30 U / min - 1300 U / min)
    • PHP + APC: ~ 75% Degradation (330 U / min - 1460 U / min)


    Da dies lange her ist und die Tests etwas synthetisch waren, wurde das spärliche HTML-Fragment (Formular) generiert, und ich entschied, dass ich Vergleichstests mit HHVM durchführen musste (in das die XHP-Unterstützung „out of the box“ integriert ist, für PHP muss ein separates Modul erstellt werden).

    Leider blieb die Beschreibung aller XHP-Klassen in den PHP-Dateien (Rasmus schrieb, dass das Problem der schlechten Leistung möglicherweise teilweise behoben werden kann, indem die Basisklassen-Deklarationen in das kompilierte Modul übertragen werden), denn die Hack- Autoren schlagen vor, nur Und zu rendern, was ich genommen habe keine 4-5 Tags, sondern ein vollwertiges Layout. Die Belagerungseinstellungen ähneln denen im Beispiel von Rasmus. HHVM + XHP



    siege -c 3 -b -t30s http://****.ru
    Transactions:                   6003 hits
    Availability:                 100.00 %
    Elapsed time:                  29.54 secs
    Data transferred:               8.80 MB
    Response time:                  0.01 secs
    Transaction rate:             203.22 trans/sec
    Throughput:                     0.30 MB/sec
    Concurrency:                    3.00
    Successful transactions:        6003
    Failed transactions:               0
    Longest transaction:            0.03
    Shortest transaction:           0.00
    


    HHVM + PHP
    siege -c 3 -b -t30s http://****.ru
    Transactions:                  19583 hits
    Availability:                 100.00 %
    Elapsed time:                  29.96 secs
    Data transferred:              33.22 MB
    Response time:                  0.00 secs
    Transaction rate:             653.64 trans/sec
    Throughput:                     1.11 MB/sec
    Concurrency:                    2.99
    Successful transactions:       19583
    Failed transactions:               0
    Longest transaction:            0.02
    Shortest transaction:           0.00
    


    Abbau von ca. 68%. Besser als 75%, aber immer noch relativ viele.
    Warum ist es relativ? Denn die Test- "Anwendung" bestand nur aus View, ohne Zugriff auf die Datenbank, ohne Geschäftslogik und andere Dinge.
    In der Realität kann sich herausstellen, dass die prozentuale Beeinträchtigung der Leistung beim Rendern von Ansicht im Vergleich zum Rest der Anwendung vernachlässigbar ist.

    Letztendlich bleibt die Wahl der einen oder anderen Template-Engine beim Systemarchitekten.

    Informationen als Referenz:
    1. XHP: Eine neue Art PHP von Facebook zu schreiben
    2. Ein kurzer Blick auf XHP von Rasmus Lerdorf
    3. XHP auf Github

    Jetzt auch beliebt: