[vz-users] Performance vzlogger / middleware.php

[Oliver Lehmann]

Hallo Andreas,

Andreas Goetz <cpuidle at gmail.com> wrote:

> Aha. Ich denke dann solltest Du erstmal rausfinden welcher Kram den Load
> überhaupt verursacht. Wirklich die MW-Speicherung?

Ohne vzlogger liege ich bei 0%.

>> Aufgrund der Interpretergeschichte ist PHP halt leider einfach lahm...
>>
>
> Ganz ehrlich- ich kann die (blöden) Kommentare nicht mehr hören. Das Web
> läuft auf PHP und neuerweise auch Node. Bisher ist die Welt dabei nicht
> zusammengebrochen. Und Facebook ist doch wsa ganz anderes als Dein
> Stromzähler.
>
> Nebenbei ist die Aussage auch noch völlig falsch. Problematisch ist nicht
> der Interpreter sondern die Tatsache dass PHP stateless ist und bei jedem
> Request von vorne anfängt.

War nicht meine Intention dich in irgendeiner Art und Weise anzugreifen. Es
kam mir jedoch so vor, als ob es bei dir so angekommen wäre...
Ich denke auch, Facebook läuft sicherlich auf etwas anderer Hardware als mein
kleiner Stromzähler.
Ich kann ausserdem nur von meinen eigenen Beobachtungen (xdebug + KCacheGrid
vs. JProfiler) berichten und dabei erkennen das bei gleichem  
Architekturdesign,
PHP (ohne opcache) merklich langsamer bei kleinen Usecases performt, und mit
der Größe des Usecases der Unterschied kleiner wird. Ich interpretiere  
hier die
von mir genannte Ramp-Up-Time rein unter die auch so Sachen wie File-Loading,
Bytecode Generierung, Parsing, Objekterzeugung usw fallen wohingegen bei Java
ich einen persistenten Applikationskontext mit Singletons habe (die auch
stateless sind).
Ohne so Sachen wie opcache wird bei PHP halt auch der Bytecode immer und
immer wieder erzeugt wenn ich da falsch liege, korrigiere mich bitte. Und ja,
auch vor fast 15 Jahren gab es schon einen "Bytecode compiler" von Zend. Der
Name ist mir inzw. jedoch entfallen. Das scheint ja nun - auf andere Art und
Weise - opcache abzubilden durch Caching des Bytecodes.

> Wie gesagt- rumposen kann jeder- am Ende zählt geschriebene Software. Wenn
> Du etwas beitragen kannst und willst- herzlich willkommen!

"Rumposen" war nicht meine Intention....

Ich habe nun einmal mittels xdebug die threads welche middleware.php ausführen
profiled. Die  meiste Zeit (ca. 30%) verliert das ermitteln von Annotations
durch Doctrine.

Gesamtlaufzeit des Profilings 585.732 ms
Die meiste Zeit davon verbraucht der Function Cycle der den DocParser.php
laufen lässt mit 291.854 ms welcher sich um die Annotations usw. kümmert.

Was mich halt wundert... ich glaube nicht, das mein Stromzähler der im 2
Sekunden Takt redet, die CPU dermaßen auslastet, wo an anderer Stelle ein
RasPi das ganze offensichtlich mühelos wegsteckt... ausser xdebug auf PHP
Seite fällt mir jetzt aber auch nicht mehr ein wie ich da was rausfinden
könnte. Die eigentlich DB-Arbeit erledigt die Middleware in 0.04% der
Gesamtzeit.

Wenn du Interesse hast, kann ich dir den Output von xdebug auch gerne
einmal zukommen lassen wenn du bessere Tools an der Hand hast als KCacheGrid.

Sehe ich das richtig, das eigentlich nur folgende 2 Statements ausgeführt
werden je uuid?

2620104 Connect vz at ... on volkszaehler
2620104 Query   SELECT e0_.id AS id0, e0_.uuid AS uuid1, e0_.type AS type2
                      , p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5
                      , e0_.class AS class6, p1_.entity_id AS entity_id7
                   FROM entities e0_
              LEFT JOIN properties p1_
                     ON e0_.id = p1_.entity_id
                  WHERE (e0_.uuid = '20f9d230-c405-11e4-a45e-0b5862d37579')
                    AND e0_.class IN ('channel', 'aggregator')
                  ORDER BY p1_.pkey ASC
2620104 Query   INSERT INTO data (channel_id, timestamp, value)
                           VALUES (8,'1442597720286.8','3424187.6')
2620104 Quit

Weisst du was er von den selektierten Daten benötigt? entities.id scheint
die channel_id zu sein die man für den Insert benötigt. Timestamp kommt
denke ich im JSON mit, value der Rohwert aus dem JSON, oder auf Basis der
selektierten Daten ein modifizierter Wert?

Grüße, Oliver