[vz-users] Performance vzlogger / middleware.php

[Andreas Goetz]

Hi Oliver,

2015-09-18 15:55 GMT+02:00 Oliver Lehmann <lehmann at ans-netz.de>:

>
> Andreas Goetz <cpuidle at gmail.com> wrote:
>
> Prinzipiell wundere ich mich aber schon warum das auf einem Raspi mit
>> SD-Karte möglich ist, auf einem 4-Kern Atom aber nicht. Wenn Du alle
>> offensichtlichen Maßnahmen getroffen hast müsste man mal in die Details
>> einsteigen und einfach mal messen wielange so ein Speicheraufruf dauert
>> und
>> wo die Zeit liegen bleibt.
>>
>
> Nun... könnte daran liegen, das in meinem PHP so einige extensions
> geladen werden. Das vergrößert natürlich den Mem-Footprint, ob das aber
> zu der erhöhten Ausführungsdauer führt... keine Ahnung.
>
> Ansonsten ist PHP 5.5.29 im Einsatz - nicht mehr ganz bleeding edge, aber
> DEN Performance-Boost wird 5.6 auch nicht bringen. Klar, ich kann jetzt
> mit xdebug ran und mal den Aufruf profilen... wenns hilft... aber ich
> frage mich auch, warum das middleware.php so ist wie es ist (ORM usw.)
> und kein simples "get and store" - was sicherlich performanter wäre.
>

Tja. Weil ORM eben auch Vorteile hat. Spricht ja nix dagegen dass Du Dir
selber ein Skript schreibst das es anders macht. The sky is the limit.


>
> Mit opcache dümpelt er so bei 7% rum aktuell. Findet man auf der ML auch
> nix zu... ;)
> Ich muss sehen ob opcache ggf. andere Probleme mit sich bringt bei meinen
> anderen PHP-Projekten. Ist halt kein dedizierter Apache für den Kram.
>

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


> Gibt es Beispiele für den local httpd was man dort als Script laufen
> lassen kann?
>

Nein.


> Gibt es im wiki ne Referenz des JSON was da aktuell an middleware.php
> geht? Bzw. wo in der DB das dann landet? Also quasi eine "Theory of
>

Ja, das API ist dokumentiert.


> Operation" Da könnte ich mir evtl. eine schnelle Lösung selber basteln.
>

Genau.


> http://wiki.volkszaehler.org/development/api/reference#antwort
>
> Da finde ich jetzt direkt nichts über das JSON des Hinwegs bzw wie
> das in der DB abgelegt wird. Ein simples Insert in einer Tabelle der
> DB oder findet bereits irgendeine Art von Aggregation von "Altdaten"
> statt?
>

Dann schau Dir einfach den DataController an- der liest das Json und
speichert es.


> 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.


> Ich stelle gerade eine eigene Mehrschichten-REST-JSON-Architektur von
> PHP auf Java um und habe teilweise Performanceboosts von 100% - vor
> allem bei Usecases die wenig machen da die "ramp up time" von PHP
> einfach so "hoch" ist (im ms Bereich).
>

Toll. Ich wusste gar nicht dass Java nicht mit Interpreter bzw. JIT
arbeitet wie PHP das neuerdings auch tut? Als Antwort auf mein Argument
jedenfalls volkszaehler/httpd ohne Rampup.

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

Viele Grüße,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150918/0c3a60ff/attachment.html>