PHP - AJAX - MYSQL Performance

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

Und handelt es sich dabei nur um statischen Content?

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

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.

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.

@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.