PHP - AJAX - MYSQL Performance

    Hey, mal ne Frage an die, die in diesem Gebiet (Performance im Web) Erfahrung hat.


    Momentan lade ich bei meiner Seite über PHP pro Aufruf eines Users 100Zeilen aus der MySQL Datenbank (mit ca. 10 Spalten) und verarbeite diese insgesamt in ca. 800Zeilen HTML-Quellcode.


    Diesen lade ich dann über Ajax in die Seite.


    Das heißt im Endeffekt werden MySQL Daten von PHP verarbeitet und über Ajax an den User in Form von HTML gesendet. So wie es meist der Fall ist.


    Jetzt zur Frage: Gibt es bessere Wege Zwecks Performance?
    Die Daten, die ich aus der MySQL DB lade, sind durch LIMIT in ein Intervall aufgeteilt. Wäre es besser, alles zu laden und dann über Javascript zu speichern? Eigentlich kann ich mir das nicht vorstellen, da das zum einen ausarten kann und zum anderen die Daten dann nicht aktuell sind. Gibt es einen besseren Weg? Oder sollte man nur Sicherheitsmaßnahmen einfügen, damit man den AjaxRequest maximal alle 5-10 Sekunden machen kann?


    Bin gespannt auf eure Antworten ^^


    Mit freundlichen Grüßen
    Alf21

    Mal aus Neugier...wieso speicherst du deine HTML Seite in einer MySQL Datenbank und wieso verbraucht das 800 Zeilen 8|


    Und handelt es sich dabei nur um statischen Content? ^^

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

    Gefällt mir 1

    Ich persöhnlich generie über AJAX nie HTML Seiten.
    Der AJAX Response gibt mir lediglich einen JSON String mit den "Rohdaten". Diese werden dann Client-Side in eine Tabelle oder so umgewandelt.
    Errechnen wieviel bytes du pro Anfrage sparrst kannst du dabei selber ;)

    seekrass approved
    4x vom Discord geflogen


    shoxinat0r 4
    dennismitzwein 2
    Trooper[Y] 2
    maddin 1
    Unbekannter Discord Kick 2
    Gefällt mir 1

    Du kannst die benötigten Daten z.B. über eine RESTful API anbieten und entsprechend mit JavaScript auslesen und in den Code zur Laufzeit einbinden. Damit würdest du die Verarbeitung aus dem Server nehmen und in den Client (Browser) stecken.


    Das nimmt ordentlich Daten aus jedem AJAX Call. Außerdem könntest du die Daten auch anderweitig verwenden, z.B. einer App.


    Ich bezweifle aber, dass die Technologie hier das Bottleneck ist. Vermutlich eher, wie du sie effektiv benutzt.


    Wo hängt es denn am längsten? Am Request in der Datenbank? Beim Erzeugen der Seite durch PHP?


    Ich halte es jedenfalls nicht für sinnvoll komplette Seiteninhalte in darstellbarer Form über einen AJAX Call einzubinden.

    Also es kommt auf die Daten an die du übermittelst. In den meisten fällen wird es jedoch so gemacht, dass du lediglich die Rohdaten an den Client übermittelst per json-string zum beispiel oder YAML, welcher dann den html content generiert und injiziert.


    Zusätzlich werden meist bestimmte pattern genutzt, so kannst du zum Beispiel bei Tabellen oder Listen , InfinitScrolling integrieren(pre loaden der ersten 50 einträge) und RecyclingViews (nur sichtfeld der liste wird gerendert).


    Wegen dem laden des gesamten Inhalts kommt es natürlich wieder drauf an was man genau machen möchte und um wie viel Einträge es sich handelt, wenn diese von einer hohen Bedeutung sind sag ich mir persönlich lass ich den user beim initalisieren etwas länger warten damit er später auf der seite schneller unterwegs ist. Um den Datenbestand jedoch aktuell zu halten muss man an dieser stelle am besten mit sockets arbeiten. Dazu gibt es auch paar nette tutorial, wie man solche echtzeit anwendungen entwickeln kann, welche die datenänderungen über die sockets direkt an den client weitergeben.

    Vielen vielen Dank für die unterschiedlichen Ideen und Anmerkungen. Wirklich qualitativ, also Ahnung habt ihr :)


    Vielleicht zum Verständnis um auf das Problem weiter einzugehen und die beste Lösung zu finden:


    Ich lade aus der Datenbank Daten wie Dateipfad, Likes, id und etwaige essentielle Daten.
    Da diese Methode die schnellste ist (ein kompletter Scan mit Sortierung und splitting des Arrays in PHP dauert viel viel länger), würde ich es auch dabei belassen.
    Im Anschluss generiere ich aus den Daten mit PHP einen kleinen Wrapper pro Bild mit ca. 3Links, dem Bild und paar Buttons mit Container, alles in allem liegen wir da bei 8 Zeilen pro Wrapper.
    Die übermittle ich nun alle als HTML-Quellcode über AJAX an den Client bzw. binde diese ins Dokument ein.
    Zuvor hatte ich einen Preloader, der nach dem Laden verschwindet. Habe ich aber rausgenommen, um den Unterschied zu sehen.
    Letztendlich war der Server schneller mit der Verarbeitung als das Javascript, wenn ich nur die Rohdaten als JSON String übermittelt habe.
    Da das aber zu Kosten des Servers geht, wollte ich das ändern. Denn bei einer größeren Nutzerzahl hat er sicher ganz schön zu kämpfen.


    Deshalb gefällt mir die Idee von @IPrototypeI momentan am besten. Statt alle 100 Einträge pro Seite zu laden, würden zB auch die ersten 20 reichen. Und dann wenn man weiter runterscrollt, könnte man die nächsten 20 laden. Denkt ihr, das macht in diesem Fall am meisten Sinn? Die Daten dann aber als Rohdaten per Ajax Request vom PHP Script über Javascript zu verarbeiten?


    Danke nochmal, besonders an @root, @fnL und @IPrototypeI :)

    also 20 Einträge sind schon wenig, aber kann man machen. Diese Taktik wird auch von facebook zum beispiel genutzt, dass ist dir bestimmt schon beim scrollen aufgefallen.


    Ob du die Daten auf dem server formatierst und dann zurück gibst ist halt immer so die Frage, hier eventuell berücksichtigen, dass nicht jeder User eine gute Internetleitung hat und dementsprechend braucht es ein bissle länger für die Seite ;). Ich bin zum Beispiel ein Fan von Fat-Clients und übergebe gern ein Teil der Anwendungslogik an den Client und der Webserver dahinter ist bei mir eher der Daten-controller , welche die Anfragen verarbeitet und überprüft und dem entsprechend auf die Datenbank schreibt.
    Meine Erfahrung bis jetzt ist diese, dass darüber die Seite am Anfang etwas länger zum laden braucht, aber danach die variante nur über den webserver zu gehen hinsichtlich Geschwindigkeit schlägt.

    Okay Danke dir :)
    Ich denke, ich werde es so wie du machen. Ergibt alles Sinn und so hab ich es speziell noch nie betrachtet.
    Was denkst du über Ember? https://www.emberjs.com/


    Bzw. Hat jemand mit soetwas Erfahrung?
    Hab überlegt, es auszuprobieren. Nur ich will nicht alles sinnlos ändern, falls die Performance erheblich drunter leiden sollte :/

    @Alf21
    Benutze persönlich lieber Angular, ist aber Geschmackssache.


    Beides setzt auf Single Page Applications. D.h. dein Browser lädt initial eine HTML Seite, das JavaScript (und Stylesheets ggf.) herunter.
    Statischer Content wird dabei oft schon voll bereitgestellt. Bei dynamischem Content handelt es sich ja in den meisten Fällen um Daten, die in ein lesbares Schema gebracht werden. Daten werden dann an einer API (z.B. RESTful API) abgerufen und Clientseitig mit dem Code verwoben.


    Vorteile:
    - Seite muss nicht bei jedem Wechsel neu aufgebaut werden
    - Es ist "modern" und hip
    - Seitenwechsel kommen dem Benutzer erstaunlich schnell vor. Schließlich müssen ja nur ganz wenige Daten noch von einer API abgefragt werden
    - Loser gekoppelt. Die Webseite muss im Prinzip nicht wissen woher die Daten, wie kommen. Wichtig ist, dass die Schnittstelle, also die API, "vertraglich" vereinbart implementiert wurde
    - Mehr Ordnung im Code, dadurch dass man UI, UI Logik und Backend Prozesse getrennt hat


    Nachteile:
    - Es kann u.U. komplexer werden das Ganze zu warten
    - Für Mobile Clients ist es manchmal besser vereinzelt große Seiten zu laden als viele kleine Request abzusetzen (Das würde heißen, dass AJAX in diesem Fall suboptimal wäre). Das liegt nicht an der Bandbreite, sondern am recht zähen Verbindungsaufbau
    - SEO ist schwieriger, wobei das mittlerweile auch antiquiert ist

    Also ember sagt mir was und ich kann es auch einordnen, jedoch hab ich leider keine Erfahrung damit ich könnte nur react noch empfehlen oder angular 4 (was jedoch vom funktionsumfang mehr bietet als du brauchst, daher würde ich eher auf was leichtgewichtigeres zurück greifen)


    Aber für den Anfang kannst du ember.js gerne mal probieren.