Ladezeiten zu groß... wie besser werden?

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

  • #31
    mehrmaliges Aufrufen des Cron?
    Bei einer Einprozessor Maschine wird das wohl herzlich wenig bringen.. 100% Last sind und bleiben 100% Last.

    Bei einer Mehrprozessor Maschine könnte das ganz anders aussehen....
    Wir werden alle sterben

    Kommentar


    • #32
      Dann versuche ich das mal in aller Deutlichkeit zu beantworten:

      1. Es gibt "schnellere Sprachen" als PHP, allen voran C/C++.

      2. "Mehrmaliges Aufrufen des Cron" kann die Sache beschleunigen. Beispiel:
      /user/bin/php /path/to/cron.php start=0 end=50000
      /user/bin/php /path/to/cron.php start=50000
      Ebenso gut oder sogar besser wäre sowas:
      /user/bin/php /path/to/cron.php instances=2
      (Falls du den Unterschied nicht erkennst, frag nach und ich erläutere es genauer.)
      Die Gesamtzahl der Berechnungen bleibt gleich, aber wenn mehrere Prozesse auf CPU, Disk und Hauptspeicher (DB!) rumrödeln, kann die Sache insgesamt auch langsamer werden! Das hängt vom (geheimen) Algorithmus und deinem System ab und ist nur durch Tests herauszufinden.

      3. Mehrere Server helfen definitiv. Die Rechung ist ziemlich einfach (Baugleichheit angenommen): Zwei Server lösen ein Problem in etwas mehr als der Hälfte der Zeit, die ein einzelner Server braucht. Vier Server verkürzen die Rechenzeit auf etwas mehr als 25% usw.

      4. Weitere Möglichkeiten:
      4.1. Umzug auf stärkere(n) Server
      4.2. Berechnung auslagern auf externe(n), speziell dafür ausgelegte(n) Server
      4.3. Reduktion der Komplexität der Berechnung, Änderung des Algorithmus (s.o.)
      4.4. Reduktion der Anzahl der Berechnungen, Änderung der Applikation (s.o.)


      Aus Erfahrung rate ich dringend zu 4.3/4.4. Keep it simple!


      @combie: Jain, zwei Prozesse können durch diverse Effekte durchaus schneller zum selben Ergebnis kommen als einer.
      Zuletzt geändert von onemorenerd; 17.08.2007, 14:37.

      Kommentar


      • #33
        Hi,

        es ist sowieso unsinnig den Cron mehrmals auf ein Script zu setzen, da dann das Script jedes Mal von vorne anfängt mit der Berechnung.

        Du sagtest da was von über 100 DB Abfragen, es wäre eine Überlegung Wert, die Querys zu optimieren und eventuell Ergenisse in Variablen/Arrays zu speichern um dann die Berechnung im Arbeitsspeicher durchzuführen.

        Gruß Sven

        Kommentar


        • #34
          full ack@onemorenerd.
          (Vor allem zum letzten Satz)

          Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

          bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
          Wie man Fragen richtig stellt

          Kommentar


          • #35
            Ist doch eigentlich alles gesagt, müsste der TO eigentlich mal aktiv werden.

            Kommentar


            • #36
              OffTopic:
              Hmm... evtl. eins noch...

              Aus meinem Nähkästchen in Punkto Optimierung:

              Es drehte sich um die Anordnung von 9 Karten. Diese Karten waren mit Bildern versehen und konnten nur in bestimmten (erstmal unbekannten) Drehungen und Positionen gültige Anordnungen ergeben. Durch 4maliges drehen und durch Permutierung aller Positionen ergab sich die eine riesige potentielle Lösungsmenge: (4 hoch 9)* 9Faklultät.

              Die erste BruteForce Anwendung brauchte geschlagene 8 Stunden um alle Anordnungen durchzuprobieen.

              Durch Optimierung gelang es die Laufzeit auf unter 0.3 Sekunden zu drücken.

              Ob das auf diese BrowserSpiel Anwendung übertragbar ist, naja... Aber es zeigt doch wieviel Optimierungspotenial so manchmal drinsteckt.
              Wir werden alle sterben

              Kommentar


              • #37
                wenn deine user die daten unbedingt brauchen, warum baust du die daten nicht je user beim login auf ?
                wer die daten braucht kann auch mal 1 sekunde warten. user die sich nicht einloggen, brauchen auch keine daten, der aufbau ist also unnötig.

                Kommentar


                • #38
                  @sysop123, hast du jemals in diesem Thread den korrekten Bezug getroffen? Schon wieder daneben. TO hat doch schon erwähnt, dass er dir Werte für die Berechnung des Rankings braucht.

                  Kommentar


                  • #39
                    Original geschrieben von TobiaZ
                    @sysop123, hast du jemals in diesem Thread den korrekten Bezug getroffen? Schon wieder daneben. TO hat doch schon erwähnt, dass er dir Werte für die Berechnung des Rankings braucht.
                    ich könnte genauso fragen, ob du jemals die informationen erfasst hast, die vom ersteller des themas preisgegeben werden. von einem ranking ist hier aber auch garnichts zu lesen, genannt wird das ganze STAATSBERECHNUNG nicht ranking und das kann vieles sein.

                    offen ist auch die frage, wieso bei 500.000 usern das script 500.000 mal (also für jeden besucher der da war) angestossen werden muss?

                    Original geschrieben von comfreak

                    dennoch stehe ich vor dem problem... dass wenn ich bei 100.000+ (nehmen wir mal blöde an es werden 500.000) user und ich schaffe einen durchlauf in 0,1sec --> dann würde ein script 13,9 Stunden dafür benötigen... ich habe allerdings maximal 2 Stunden Zeit...
                    da werden 500.000 user mit der script-laufzeit multipliziert oder sehe ich das falsch ??

                    dazu fallen mir mehrere ansätze ein:

                    statische daten (und ich gehe davon aus, dass es davon sehr viele geben wird) muss man nicht neu berechnen (da sehe ich auch das grösste optimierungspotenzial). ich kann mir nicht vorstellen, dass ein einzelner user alle anderen 500.000 user in ihren daten direkt beeinflusst sprich deren daten dahingehend verändert, dass sie sofort alle neu berechnet werden müssen.
                    sollte dem DOCH so sein, ist immernoch die frage offen, ob man nicht einen gemeinsamen teil an daten in einem cronjob laufen lassen kann und den rest macht man dann je user wenn er die seite aufruft.

                    wenn ich hier 500.000 mal (anzahl der user) das script durchlaufen lasse, wieso sollte ich es dann nicht 1 mal je useraufruf starten ? mir fehlen die informationen, wieso das nicht gehen soll, es ist nur die information vorhanden, dass es nicht geht.
                    verknüpfe ich einen user mit der tabelle (150 zeilen mit zig hundert formeln) verstehe ich es so, dass sich zwar an den userdaten des aktiven users etwas ändert, aber die anderen 499.999 bleiben davon unberührt (oder auch nicht, eine information, die mir ebenfalls fehlt).
                    ist sicher, dass ein user A mit seinen eingaben, aufrufen oder was auch immer direkten einfluss auf die daten des users XYZ nimmt (also dessen daten wirklich verändert). sonst ist ein kompletter durchlauf für 500.000 user sicher nicht notwendig.

                    entweder du hast mehr informationen als unsereins oder du interpretierst die informationen einfach dahin gehend, dass DU damit zurecht kommst, ich bin geständig, ich komme mit den infos nicht ganz aus.

                    Kommentar


                    • #40
                      @sysop123: ich muss TobiaZ recht geben... du hattest bereits vorher schon nicht wirklich richtig gelegen.

                      Das Script muss auch nicht pro User durchlaufen werden, ich sprach rein von der Ladezeit pro User die das script benötigt. Ein gewöhnliche Schleife für jeden User.

                      Außerdem steht es außer Frage, dass ich diese Berechnungen jeden Tag anstoßen muss und nicht warten kann, bis der User sich einloggt. Zum einen, ja die Daten der verschiedenen User können sich beeinflussen, zum anderen benötige ich die Daten für Statisitken und Rankings die sich jeweils aus der letzten berechnung errechnen... daher muss das script für jeden user einmal am tag durchlaufen, was allerdings mit einem cronjob geschehen wird (oder mit mehreren, falls die berechnung auf mehreren servern verteilt wird...)

                      wie auch immer, die optimierung liegt nun an mir und ich werde mein bestmögliches tun... falls es bestmöglich optimiert ist (so gut ich es eben bis dahin kann), wird sich zeigen auf welche punkte ich zurückgreifen kann, die onemorenerd weiter oben genannt hat...

                      danke euch allen... sobald ich fragen habe, zu der serverseitigen optimierung werde ich mich gegenfalls hier wieder melden...
                      Zuletzt geändert von comfreak; 20.08.2007, 00:11.

                      Kommentar


                      • #41
                        ich will auch garnicht streiten, trotzdem lässt mir das keine ruhe. ich habe das ganze sogar sehr aufmerksam durchgelesen und komme einfach auf keinen grünen zweig. mag schon sein, dass TobiaZ das alles im vorbeigehen erfasst hat.
                        z.b. diese aussage:

                        Original geschrieben von comfreak
                        @sysop123: ich muss TobiaZ recht geben... du hattest bereits vorher schon nicht wirklich richtig gelegen.

                        Das Script muss auch nicht [COLOR=red]pro[/COLOR] User durchlaufen werden, ich sprach rein von der Ladezeit pro User die das script benötigt. Ein gewöhnliche Schleife für [COLOR=red]jeden[/COLOR] User
                        wo liegt bitte der unterschied zwischen berechnungs schleife pro user und schleife für jeden user ? darauf, dass ein cron je user nicht das gefragte ist, hatten wir uns schon geeinigt.
                        du musst bei einem login eines einzelnen users alle 499.999 user durchackern, das ist die kern aussage. in deinem letzten post ist von dir zum ersten mal klar gesagt worden, dass du alle 499.999 user veränderst, wenn nur ein user etwas macht.

                        sorry, aber rankings und statistiken habe ich schon so viele gemacht, dass ich meine zweifel hatte und immer noch habe, dass man immer alles durch exerzieren muss.

                        ich logge mich mal aus um böses blut zu vermeiden.

                        Kommentar


                        • #42
                          @combie: Jain, zwei Prozesse können durch diverse Effekte durchaus schneller zum selben Ergebnis kommen als einer.
                          Wenn du mit "diverse Effekte" z.B. Wartezeiten auf externe Resourcen meinst, Naja... dann wird sich das wohl bemerkbar machen....

                          Aber wenn sichs um harte Prozessor Rechenlast dreht, dann wohl weniger....

                          Sollte auch nur eine Tendenz zeigen, von daher habe ich es extra schwammig formuliert. Aber solange das wichtigste geheim bleibt, ist es sowieso nur ein Stochern im Nebel.....
                          Wir werden alle sterben

                          Kommentar


                          • #43
                            Update zu der Berechnung

                            Hallo...

                            so die Formeln sind alle eingetragen. Wir lagen bei 1000 Berechnungen bei ca 1-1,5 sec und haben nun 1700 Berechnungen in 2,1-2,3 sec.
                            Es sind 100 Kategorien mit jeweils 7 Formeln. Einige müssen eben mehrmals berechnet werden, da sie sich auf Ergebnisse anderer beziehen... ich versuche nun die Zahl der Berechnungen etwas runter zu schrauben...

                            Meine Frage ist nun: Mir wurde erzählt, dass es evtl günstiger wäre, diese intensive Berechnungen in einer anderen Sprache auszuführen... Hat der jmd eine Idee, bzw wie bekomme ich die Daten von Sprache A nach B und anschließend wieder von B nach A, wobei A = PHP ist :-)

                            Hoffe, jmd hat eine Idee...

                            Kommentar


                            • #44
                              XML, Datenbank, SOAP, etc.

                              Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                              bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                              Wie man Fragen richtig stellt

                              Kommentar


                              • #45
                                Wenns noch schneller sein soll Semaphore ...
                                Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

                                Kommentar

                                Lädt...
                                X