Ankündigung

Einklappen
Keine Ankündigung bisher.

Performance Fragen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Performance Fragen

    Hallo,

    ich sitzte gerade an einer größeres Softwarelösung. Das ganze Arbeitet sehr viel mit Reflection.

    Das nur zur Vorgeschichte.

    Jetzt bin ich an einem Punkt angekommen, an dem ich einige Dinge optimieren muss, um die Datenbankabfragenanzahl gering zu halten.
    Dafür muss ich natürlich irgendwas schlaues basteln bzw. Daten cachen etc.

    Die Frage(n):

    Was ist effektiver:

    a)
    PHP-Code:
    $myCache[$propName][$rowId] = $myHelper->HoleMirDasLabel(...);
    //hier wird also evt. ein Eintrag überbraten und $myHelper->HoleMirLabel(...) unötigerweise ausgeführt 
    b)
    Vorher array_search_key oder ähnliches in einer If-Abfrage. Wenns den Key schon gibt, keine Ausführung des "HoleMirLabel".
    Der Key wäre hier $rowId und $propName wäre an der stelle des Codes schon bekannt.

    Sprich ich müsste im array $myCache[$propName] nach dem Key $rowId suchen...

    Die Funktion "HoleMirLabel" behinhaltet lediglich etwa sowas:
    PHP-Code:
    class MyClass{

    public 
    $Name
    public $Kundennummer

    public HoleMirLabel()
    {
        return 
    $this->Name." (".$this->Kundennummer.")";
    }


    Kann mir da jemand auf die schnelle einen guten Link nennen?

    Oder kennt jemand gute Testmethoden außer "echo microtime();"

    Naja also generell wäre es gut wenn mir einer sagen kann ob die array funktionen von php zuverlässig und schnell arbeiten. So eine Suche könnte bis zu 100 Einträge beinhalten, in den aber jeweils nur nach dem Key gesucht wird.

    Bei zb SQL macht es ja kaum unterschied, ob ich in 200.000 Einträgen nach einem Index suche oder in 10... also jedenfalls hab ich da fürs Menschenauge bzw die Sekundenstoppuhr "time()" keine Unterschiede gesehen.

    Legt PHP da auch irgendwelche Indextabellen an intern?

    Falls jemand Rat weiß, wäre ich sehr dankbar!!

  • #2
    Wo ist den nun dein Performance-Problem?

    Übermässige Reflection?
    Problem Queries?
    Zuviele mini Queries?
    Zuviele Methoden aufrufe?

    Oder kennt jemand gute Testmethoden außer "echo microtime();"
    Ja ein Profiler... kostenlos z.B. xdebug mit KCacheGrind.

    Kommentar


    • #3
      oh das ging ja fix.

      Also generell ist das Probelm tatsächlich viele miniQueries rausbekommen.

      Bei vielen Feldern könnte ich die Information direkt mit ziehen, dann wäre aber die Verteilung wieder recht komplex und demnach viel Logik nötig.
      Wenn ich aber Felder habe, in den mehre Verweise stehen, dann geht das nicht mehr, soweit ich weiß. Oder kann ich mit zu jeder Zeile auch noch ein zusammengebautet Objekt mitziehen? Das wäre natürlich die Optimallösung.

      Das ganze sieht so aus: Manche Felder in einer SQL Tabelle sind ja meistens Verweise auf andere Datansätze. So und da will der Benutzer natürlich nicht die ID sehen sonder eben meinetwegen den Namen des Kunden plus Kundennummer. Sprich, ich muss für jedes Feld, dass ein Beziehungsfeld ist, eine Abfrage machen.

      Bei ner Ergebnissmenge von 50 Datensätzen mit etwa jeweils 4 beziehungsfeldern sind das 200 miniqueries.

      Ich bin da noch zu unerfahren, ist das generell eigentlich überhaupt ein Problem? Also schnell gehen tuts jedenfalls, ich frage mich nur was passiert, wenn da viele User gleichzeit andauernt 200 Minqueries schicken...

      DB Server und Webserver sind entweder beide auf der gleichen Maschine oder über Netzwerk "schnell" verbunden...

      Zitat von erc Beitrag anzeigen
      Wo ist den nun dein Performance-Problem?
      Ja ein Profiler... kostenlos z.B. xdebug mit KCacheGrind.
      XDebug hab ich schon an, wo kann ich da genau schauen? Komme aus der .Net Welt und bin noch nicht soo lange mit dem xDebugging unterwegs

      Kommentar


      • #4
        Zitat von mr.nice Beitrag anzeigen
        Bei ner Ergebnissmenge von 50 Datensätzen mit etwa jeweils 4 beziehungsfeldern sind das 200 miniqueries.
        JOINs sind dir ein Begriff?

        Zitat von mr.nice Beitrag anzeigen
        XDebug hab ich schon an, wo kann ich da genau schauen? Komme aus der .Net Welt und bin noch nicht soo lange mit dem xDebugging unterwegs
        Einfach mal googlen. Das ist nicht sonderlich schwer. Xdebug erzeugt für jeden aufruf eine Datei mit einem Log, das Log kann man dann mit kcachegrind auswerten.

        Kommentar


        • #5
          Zitat von erc Beitrag anzeigen
          JOINs sind dir ein Begriff?
          Die Abragen laufen schon längst mit Join, jedenfalls die eingrenzung des Datensatzen, sprich die Suche selbst.

          Wie schon geschrieben, bei Feldner wie "Erstellt von" oder so ist das natürlich mittels Join kein Problem.

          Was ist aber mit einem Feld wie "Kunden" in dem die ids der Kunden mit Komma getrennt stehen? Suchen und so kann man ja prima mit

          "SELECT tabelle t .... WHERE 4 IN (t.Kunden)"

          Wenn ich jetzt aber quasi sowas machen wollte:

          "Select t.*, Kundenobjektiste WHERE ...."

          Da ist die Frage ob das überhaupt mit einer Query geht??

          Kommentar


          • #6
            Zitat von mr.nice Beitrag anzeigen
            Was ist aber mit einem Feld wie "Kunden" in dem die ids der Kunden mit Komma getrennt stehen?
            Das ist schlicht und einfach fehlerhafte Datenmodellierung.
            [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

            Kommentar


            • #7
              Zitat von ChrisB Beitrag anzeigen
              Das ist schlicht und einfach fehlerhafte Datenmodellierung.
              Ja, dass hab ich mir auch schon gedacht. Natürlich war das mit den Kunden auch ein dummes Beispiel.

              Nehmen wir mal lieber ne Produktliste die an einer Bestellung hängt.

              WIe macht man sowas schlau??

              Kommentar


              • #8
                Stichwort Normalisierung.
                [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                Kommentar


                • #9
                  ich danke das kann geschlossen werden. ich hab mich wohl etwas unpräzise ausgedrückt, aber das Stichwort Normalisierung wars letztendlich..

                  Danke für die Hilfe

                  Kommentar

                  Lädt...
                  X