Ankündigung

Einklappen
Keine Ankündigung bisher.

Hardware bzw. Laufzeitumgebung bei n Requests pro Zeiteinheit

Einklappen

Neue Werbung 2019

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

  • Hardware bzw. Laufzeitumgebung bei n Requests pro Zeiteinheit

    Hi,

    ich bewerbe mich gerade um einen Auftrag für eine Webapplikation und hatte zum ersten Mal überhaupt den Eindruck, dass die Frage

    "Wie viel Requests pro Stunde, Minute, Sekunde sind zu erwarten"

    relevant ist.

    So, jetzt habe ich das gefragt und die Antwort lautet: "Die Anwendung sollte 50 Requests gleichzeitig beantworten können."

    Ein Request wird, soweit ich das heute absehen kann, eine Webseite sein, die, abgesehen von pre-cached js, img Dateien etc. - wohl kaum mehr als 10KB groß sein wird.

    Ich frage mich jetzt, was das für die Auswahl der Laufzeitumgebung bzw. der Serverhardware konkret bedeutet und wollte mal fragen, wie Ihr da vorgeht?

    Es ist schon alles gesagt. Nur noch nicht von allen.


  • #2
    Das hängt ja sehr stark davon ab was im Rahmen eines Requests passiert. Wenn zum Großteil statische Dateien aus dem Cache ausgeliefert werden (können) dann halte ich 50 Req/s nicht weiter für beachtenswert.

    Kommentar


    • #3
      "50 Requests gleichzeitig beantworten" geht genaugenommen nicht.
      PHP-Klassen auf github

      Kommentar


      • #4
        Zitat von jspit Beitrag anzeigen
        "50 Requests gleichzeitig beantworten" geht genaugenommen nicht.
        Schon klar. Ich denke, die Interpretation 50 Req/s von lottikarotti kann man als Annahme erstmal her nehmen.
        Es ist schon alles gesagt. Nur noch nicht von allen.

        Kommentar


        • #5
          Dann hat jeder Request im Schnitt 0.02 Sekunden zur Verfügung. Bei Datenbankabfragen sollte der Wert der DB dann etwas kleiner sein um keine Probleme zu verursachen.

          Kommentar


          • #6
            Zitat von protestix Beitrag anzeigen
            Dann hat jeder Request im Schnitt 0.02 Sekunden zur Verfügung. Bei Datenbankabfragen sollte der Wert der DB dann etwas kleiner sein um keine Probleme zu verursachen.
            Das trifft aber nur zu, wenn alle synchron abgearbeitet wird. Dank mehrere CPU-Kerne, Multithreading, usw. können Requests auch parallel abgearbeitet werden.

            Kommentar


            • #7
              Zitat von hellbringer Beitrag anzeigen
              können Requests auch parallel abgearbeitet werden.
              Der Wert ist eh theoretischer Natur und bezog sich auf die 50 Req/s.

              Bei viel Datenbankverkehr und wenn viele Schreibzugriffe erfolgen, kann es auch mal weniger sein als wenn nur reine HTML Dateien ausgeliefert werden.

              Insofern ist die Aussage "Die Anwendung sollte 50 Requests gleichzeitig beantworten können." eigentlich zu unscharf formuliert.

              Kommentar


              • #8
                Mach dem Server doch etwas Stress

                Code:
                sudo apt-get install siege
                Code:
                siege -c255 -b -t60S http://.......................
                dann schaue Dir das Ergebnis an.

                Kommentar


                • #9
                  Nur mal so zur Info, ab welcher Besucherzahl pro Sekunde sollte man sich Gedanken machen, eingedenk der Prämisse in #2, das während des Requests nicht so grossartiges passiert ?



                  Kommentar


                  • #10
                    hellbringer hat es für meine Begriffe noch zu vorsichtig formuliert. Eine synchrone Abarbeitung ist m.E. eher die Ausnahme und eine parallele Abarbeitung der Normalfall.
                    Da die Verbindung zum Webserver immer über den Port 80/443 beginnt, können die Phasen Request-Empfang und Erstellung einer Server-Client-Instanz nur nacheinander ablaufen.
                    Dafür werden je nach Leistung des Servers oft nur Mikrosekunden benötigt. Danach ist der Port 80 bzw. 443 wieder frei für den nächsten Request.
                    Hab mal versucht das grafisch darzustellen:
                    Code:
                    |Req|Client-I|------------Verarbeitung----------------|Response-Out|
                                   |Req|Client-I|-------------Verarbeitung-----------------|Response-Out|
                                                  |Req|Client-I|---------------Verarbeitung-------------------|Response-Out|
                    PHP-Klassen auf github

                    Kommentar


                    • #11
                      Oh man...

                      Zitat von jspit Beitrag anzeigen
                      "50 Requests gleichzeitig beantworten" geht genaugenommen nicht.
                      Natürlich geht das. Die Faktoren, die du später aufzählst sind im Verhältnis zu "PHP macht HTML von Daten aus Datenbank" defacto irrelevant. Da ist SSL-Termination wahrscheinlich noch die wahrnehmbarste Größe.

                      Und die Eingangs gestellte Frage ist praktisch auch sinnfrei. Wenn man nicht künstlich dafür gesorgt hat, dass sich PHP-Prozesse gegenseitig auf die Füße treten, dann skaliert PHP innerhalb der Grenzen eines Servers abhängig von verschiedenen Faktoren ziemlich steil. Darunter diese:
                      • Wie viele CPU-Kerne hat der Server?
                      • Wie viel Arbeitsspeicher steht zur Verfügung?
                      • Wie hoch ist der Datendurchsatz auf Netzwerkebene?
                      • Wie hoch ist ggf der Datendurchsatz auf Festspeicherebene?
                      • Wie viele Ressourcen bindet ein einzelner PHP-Request?
                        • Wie viel Arbeitsspeicher?
                        • Wie viel CPU-Zeit?
                        • Welche Ausführungspfade sollten in den Verbrauch reingerechnet werden?
                      • Steht im Hintergrund noch eine Datenbank oder irgendwas anderes, die hier auch noch mal zusätzlich Ressourcen pro Request kostet?
                        • Läuft dieses andere Etwas auf dem gleichen Server, oder auf einem benachbarten, autark laufenden Gerät?
                      • usw.
                      Wenn ein Server nicht reicht, dann wird die Umgebung via LoadBalancer auf mehrere Server erweitert.

                      Die richtige Antwort ist je nach Vorliebe:
                      • Unendlich
                      • Es kommt drauf an(tm)
                      Am Besten bringt man erst mal die Umgebung in Erfahrung, wo der Bums nachher laufen soll...

                      Auf einem 80$ Digitalocean-Base-Droplet bekomme ich bei einer unkomplexen PHP(FPM)+PHPDI+TWIG-Seite ohne Datenbank gut 1100Req/s via apache-ab raus, wenn ich von Localhost aus teste.
                      Das sagt aber nichts...
                      Standards - Best Practices - AwesomePHP - Guideline für WebApps

                      Kommentar


                      • #12
                        Vielen Dank an alle für die rege Diskussion. Das Wichtigste für mich ist, dass ich - so wie ich Eure Antworten deute - da wohl mit einem überschaubaren Hardwareeinsatz klar kommen werde.

                        @rkr:
                        Am Besten bringt man erst mal die Umgebung in Erfahrung, wo der Bums nachher laufen soll...
                        Die Frage war ja anders herum: Ich wollte einen Weg finden bei gegebenen Anforderungen
                        die nötige Hardware einzuschätzen bzw. anzuschaffen.

                        Ich weiß per heute auch noch nicht ganz genau, was ein Request an Ressourcen beanspruchen wird. Das Pflichtenheft wird ja noch geschrieben...

                        Mach dem Server doch etwas Stress
                        Wird voraussichtlich ein Managed Server. Da kann ich sowas nicht machen.
                        Es ist schon alles gesagt. Nur noch nicht von allen.

                        Kommentar


                        • #13
                          Zitat von drsoong Beitrag anzeigen
                          @rkr: Die Frage war ja anders herum: Ich wollte einen Weg finden bei gegebenen Anforderungen
                          die nötige Hardware einzuschätzen bzw. anzuschaffen.
                          Das kann dir niemand klar beantworten.

                          Eine Zeile Code kann deine responses/s halbieren.
                          Eine CPU mit 50 HW-Threads kann relativ easy auf einem Nicht-Windows-System 50 Req/s verarbeiten - selbst wenn deine Scripte nahezu eine Sekunde für die Ausführung brauchen.
                          Mit NodeJS bekommst du ca. 10 mal mehr r/s durch bei ähnlicher Komplexität der Anwendung. Nur JavaScript will kein Mensch in größeren Projekten auf der Serverseite haben. Freiwillig.
                          Bzgl Swoole ist meine Einstellung derzeit noch ähnlich...
                          Standards - Best Practices - AwesomePHP - Guideline für WebApps

                          Kommentar

                          Lädt...
                          X