<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="gmail_quote">Guten Abend...<br>
      <br>
      <br>
      > 1 Kanal, nur den Middlewarerequest anschauen. Im Browser, mit
      &debug=1. Dann schauen was/wo das wie lange dauert. <br>
      <br>
      Ok. Für einen Kanal sind ja offenbar 3 Queries nötig:
      von-Timestamp, bis-Timestamp und dann die eigentlichen Werte.<br>
      Rattert gnadenlos schnell durch. Schmidts Katze ist ne Schildkröte
      im Vergleich ;)<br>
      <br>
      <div>> d.h. Dein Raspi ist von endlosen S0-Ereignnisse
        zugemüllt? Wieviele pro Minute? <br>
        <br>
        Ich fürchte ja. Attack of the killer s0-events. Ich hab "leider"
        einige s0-Zähler: PV-Wechselrichter (erzeugt wohl am meisten),
        Wärmepumpe (ist im Winter auch gut dabei, 20kWh am Tag?) und
        dann noch Stromzähler für Ferienwohnung und Hauptwohnung. Kommt
        insgesamt schon einiges zusammen.<br>
        <br>
      </div>
      <div>> Es ist laaaaaaaangsam- aber anscheinend nicht Problem
        der Aggregation.<br>
        <br>
        Zustimmung.<br>
         <br>
      </div>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <br>
        Kleine Anmerkung zu den s0-Ereignissen - ist aber andere
        Baustelle: im log fällt mir auf, dass das sehr häufig vorkommt:<br>
                          911 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 = '90da22c0-f2dc-11e2-a59d-e9b55d71b128')
        AND e0_.class IN ('channel', 'aggregator') ORDER BY p1_.pkey ASC<br>
                          911 Query     START TRANSACTION<br>
                          911 Query     INSERT INTO data (timestamp,
        value, channel_id) VALUES ('1389302896063', '1', 14)<br>
                          911 Query     UPDATE properties SET value =
        '1' WHERE id = 71<br>
                          911 Query     UPDATE properties SET value =
        '1' WHERE id = 69<br>
                          911 Query     UPDATE properties SET value =
        '1000' WHERE id = 67<br>
                          911 Query     commit<br>
      </blockquote>
      <br>
      <div>> Den Join braucht Doctrine, das scheint auch mit Query
        Cache nicht weg optimierbar zu sein da es immer einen aktuellen
        Stand aus der DB haben will, die Abfrage ist auch schnell.<br>
        <br>
        Ok.<br>
        <br>
      </div>
      > Da liegt m.E. das Grundproblem. s0vz scheint nicht wie
      vzlogger eine eingebaute Datenaggregation zu haben bevor es an die
      Middleware geht. Das Thema gabs auch in anderen Threads schon.<br>
      <div>Aus meiner Sicht ist das das Hauptproblem für die
        Perfprobleme wenn s0 ordentlich Impulse liefert. Da müsste
        allerdigns der Autor ran, C ist nicht meine Welt...<br>
        <br>
        Ja, und genau diese Situation habe ich, dass s0 ordentlich Last
        erzeugt. Heeeeeeeendriiiiik, kommst du mal eben bitte...? ;)<br>
        <br>
        Ich hoff mal er liest mit und meldet sich, sonst werd ich ihn
        mal direkt anmailen.<br>
      </div>
    </div>
    <br>
    > schau doch mal ob Du mit diesem PR hier <a
      moz-do-not-send="true"
      href="https://github.com/volkszaehler/volkszaehler.org/pull/95">https://github.com/volkszaehler/volkszaehler.org/pull/95</a>
    die überflüssigen SQLs für die properties Tabelle loswerden kannst.<br>
    <br>
    Probier ich gern aus...ähhhh... wenn du mir sagst, wie ich das
    mache?<br>
    <br>
    > Löst aber nicht die (wichtigeren...) Probleme mit s0vz.<br>
    <br>
    Na jeder Fortschritt ist willkommen ;)<br>
    <br>
    cu.. Heiko<br>
    <br>
  </body>
</html>