Hallo,

ich habe eine PHP-Seite mit einer Tabelle (8 Spalten), wo Infos aus der
Datenbank angezeigt werden. D.h. es gibt eine MySQL-Abfrage und eine
Schleife, die <tr>...</tr> umfasst. Da Cache ausgeschaltet ist, wird die
Seite immer neu geladen. Das Problem ist, dass u.U. über 500 Einträge
auf einmal angezeigt werden sollen und bis die Seite vollständig geladen
ist, dauert es wirklich sehr lange (über 30 Sekunden). Mit einer
Blätterfunktion (also mit einer Db-Anfrage mehr) funktioniert das ganze
relativ schnell, wenn man die Anzahl der Einträge z.B. auf 20 pro Seite
einschränkt.

Da ich zu wenig Erfahrung habe mit Ladezeiten bei größerer Menge von
Daten, wollte ich mal Fragen, ob das normal ist, oder ob es vielleicht
welche Möglichkeiten gibt, es zu optimieren? Ich habe mal bei phpMyAdmin
nachgeschaut und da dauert das Laden einer Tabelle mit 500 Einträgen
auch ein Weilchen.

Gruß

Monika

Hallo Monika,

Monika Nowak wrote:
> ich habe eine PHP-Seite mit einer Tabelle (8 Spalten), wo Infos aus der
> Datenbank angezeigt werden. D.h. es gibt eine MySQL-Abfrage und eine
> Schleife, die <tr>...</tr> umfasst. Da Cache ausgeschaltet ist, wird die
> Seite immer neu geladen. Das Problem ist, dass u.U. über 500 Einträge
> auf einmal angezeigt werden sollen und bis die Seite vollständig geladen
> ist, dauert es wirklich sehr lange (über 30 Sekunden). Mit einer
> Blätterfunktion (also mit einer Db-Anfrage mehr) funktioniert das ganze
> relativ schnell, wenn man die Anzahl der Einträge z.B. auf 20 pro Seite
> einschränkt.
>
> Da ich zu wenig Erfahrung habe mit Ladezeiten bei größerer Menge von
> Daten, wollte ich mal Fragen, ob das normal ist, oder ob es vielleicht
> welche Möglichkeiten gibt, es zu optimieren? Ich habe mal bei phpMyAdmin
> nachgeschaut und da dauert das Laden einer Tabelle mit 500 Einträgen
> auch ein Weilchen.

das Problem ist normalerweise _nicht_ das Lesen der Daten aus der DB oder
das serverseitige Generieren der HTML-Seite. Der
geschwindigkeits-bestimmende Schritt ist typischerweise der Browser.
Typisch muss der erst das Laden der gesamten Seite abwarten, um mit dem
Rendern zu beginnenVorher ist nicht klar, wie groß die Tabellenzellen
angelegt werden müssen.
Abhilfe kann schaffen, wenn man die Größe der Zeilen fest vorgibt in der
HTML-Tabellenstruktur, etwa absolute Breite und Höhe der Zellen.
Andererseits verbaut man damit natürlich gerade den einzigwirklichen
Vorteil einer Webanwendung gegenüber einem Richclient: die flexible
Reaktion auf unterschiedliche Daten.

--
arkascha

Monika Nowak schrieb:
> Hallo,
>
> ich habe eine PHP-Seite mit einer Tabelle (8 Spalten), wo Infos aus der=

> Datenbank angezeigt werden. D.h. es gibt eine MySQL-Abfrage und eine
> Schleife, die <tr>...</tr> umfasst. Da Cache ausgeschaltet ist, wird di=
e
> Seite immer neu geladen. Das Problem ist, dass u.U. über 500 Einträ=
ge
> auf einmal angezeigt werden sollen und bis die Seite vollständig gela=
den
> ist, dauert es wirklich sehr lange (über 30 Sekunden). Mit einer
> Blätterfunktion (also mit einer Db-Anfrage mehr) funktioniert das gan=
ze
> relativ schnell, wenn man die Anzahl der Einträge z.B. auf 20 pro Sei=
te
> einschränkt.

Du must hier differenzieren.

1. Wie lange braucht das SQL Statement bzw. wielange braucht MySQL um
alle Datensaetze zu liefern

2. Wieviel Zeit braucht die Verarbeitung in PHP

3. Transport der Daten vom Webserver zum Client

4. Wie lange braucht der Browser zum Rendern der Daten


Meine Vermutung ist die das 1 und 2 bei dir sehr schnell gehen wird es
aber an 4. haengt. Einige Browser koennen ein Element erst dann
darstellen wenn das schliessende </tag> da ist. Im Falle einer Tabelle
koennte dies dann </table> sein. Auch sollten von beginn an feste
Spaltenbeiten vorgegeben werden.

Zu 1. und 2. kannst du einfach mit PHPs microtime()[1] die Zeiten ermitte=
ln.


[1]http://www.php.net/microtime

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Monika Nowak schrieb:
> Hallo,
>
> ich habe eine PHP-Seite mit einer Tabelle (8 Spalten), wo Infos aus der
> Datenbank angezeigt werden. D.h. es gibt eine MySQL-Abfrage und eine
> Schleife, die <tr>...</tr> umfasst. Da Cache ausgeschaltet ist, wird die
> Seite immer neu geladen. Das Problem ist, dass u.U. über 500 Einträge
> auf einmal angezeigt werden sollen und bis die Seite vollständig geladen
> ist, dauert es wirklich sehr lange (über 30 Sekunden). Mit einer
> Blätterfunktion (also mit einer Db-Anfrage mehr) funktioniert das ganze
> relativ schnell, wenn man die Anzahl der Einträge z.B. auf 20 pro Seite
> einschränkt.
>
> Da ich zu wenig Erfahrung habe mit Ladezeiten bei größerer Menge von
> Daten, wollte ich mal Fragen, ob das normal ist, oder ob es vielleicht
> welche Möglichkeiten gibt, es zu optimieren? Ich habe mal bei phpMyAdmin
> nachgeschaut und da dauert das Laden einer Tabelle mit 500 Einträgen
> auch ein Weilchen.
>
> Gruß
>
> Monika

Hallo Monika,

Das laden der Daten ist an sich kein Problem, das geht (je nach
Datenbank) rech fix. An der Rendergeschwindigkeit kannst du an sich
nicht viel schrauben. Ich denke, vieles kann man auch mit "ordentlichem"
HTML rausholen. Eher DIVS als Tabellen "zeichnen", da div Container zur
Laufzeit sichtbar werden und der User nicht all zu lange auf den Content
warten muss. Tabellen jedoch werden erst angezeigt, wenn sie komplett zu
ende gerendert wurden.

Gruß Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRD3JEFwR+I34OMsRAikaAJ4zzsqpAkqgKqrQRmLYiYaelzjQTwCg 63v9
itpTDw3zhrx6yc8r6UgAsEA=
=B/sB
-----END PGP SIGNATURE-----

Stefan Riedel schrieb:
> Das laden der Daten ist an sich kein Problem, das geht (je nach
> Datenbank) rech fix. An der Rendergeschwindigkeit kannst du an sich
> nicht viel schrauben. Ich denke, vieles kann man auch mit "ordentlichem"
> HTML rausholen. Eher DIVS als Tabellen "zeichnen", da div Container zur
> Laufzeit sichtbar werden und der User nicht all zu lange auf den Content
> warten muss. Tabellen jedoch werden erst angezeigt, wenn sie komplett zu
> ende gerendert wurden.

Tabellarische Daten gehören doch in eine Tabelle, oder nicht? :)

Die Frage ist eher, braucht/will der Anwender alle 500 Zeilen auf einmal
sehen? Es hat ja seine Gründe warum die meisten Funktionalitäten zum
Blättern anbieten. Es ist einfach übersichtlicher und schneller.

Der Rest wurde ja schon gesagt woran es liegen könnt. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Herrmann schrieb:
> Stefan Riedel schrieb:
>> Das laden der Daten ist an sich kein Problem, das geht (je nach
>> Datenbank) rech fix. An der Rendergeschwindigkeit kannst du an sich
>> nicht viel schrauben. Ich denke, vieles kann man auch mit "ordentlichem"
>> HTML rausholen. Eher DIVS als Tabellen "zeichnen", da div Container zur
>> Laufzeit sichtbar werden und der User nicht all zu lange auf den Content
>> warten muss. Tabellen jedoch werden erst angezeigt, wenn sie komplett zu
>> ende gerendert wurden.
>
> Tabellarische Daten gehören doch in eine Tabelle, oder nicht? :)
>

Wie oft hol ich aber Daten aus ner Datenbank, die nicht umbedingt
tabellarisch "aufgewertet" werden müssen. ;)

> Die Frage ist eher, braucht/will der Anwender alle 500 Zeilen auf einmal
> sehen? Es hat ja seine Gründe warum die meisten Funktionalitäten zum
> Blättern anbieten. Es ist einfach übersichtlicher und schneller.
>

Aber 500 Datensätze in eine Seite packen, find ich auch nen bissel zu
viel. ;) Ich klicke schon bei 100 weiter. :D

> Der Rest wurde ja schon gesagt woran es liegen könnt. :)
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRELKEFwR+I34OMsRAj84AKCoLHcOhluoVOiiN6ixT/CBsJ/kQQCg ji6p
VdLrg9Wd2IcXADDJ8IyCVmI=
=MtXB
-----END PGP SIGNATURE-----

Stefan Riedel schrieb:
> Wie oft hol ich aber Daten aus ner Datenbank, die nicht umbedingt
> tabellarisch "aufgewertet" werden müssen. ;)

Das stimmt schon, aber ich gehe davon aus, dass der OP eine Tabelle
richtig verwendet. Und wenn er dies tut wäre es unsinnig dies in Div
Container umzustellen.

> Aber 500 Datensätze in eine Seite packen, find ich auch nen bissel zu
> viel. ;) Ich klicke schon bei 100 weiter. :D

deswegen sag ich ja eine Funktionalität zum Blättern wäre wohl
sinnvoller an der Stelle.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Stefan Riedel schrieb:

> Tabellen jedoch werden erst angezeigt, wenn sie komplett zu
> ende gerendert wurden.

Ich weiß ja nicht, welchen antiquarischen Browser Du benutzt. Die
heutigen Browser fangen schon bei den ersten Daten mit dem Rendern an.

Gruß. Claus

Hallo,

danke für die Antworten. Alle Zellen der ersten Zeile in der Tabelle (wo
die Überschriften stehen; also außerhalb der Schleife) habe ich mit
festen Breiten bereits versehen. Und die Ladezeit ist wie gesagt, schon
recht lange. Soll ich die festen Breiten auch für die dynamischen Zellen
zusätzlich einbauen? Würde das was bringen? Eigentlich ging ich immer
davon aus, wenn die Breite einmal oben definiert ist, bezieht sie sich
auf die Zellen der gesamten Tabelle. Oder?

Gruß
Monika

Monika Nowak schrieb:
> Hallo,
>
> danke für die Antworten. Alle Zellen der ersten Zeile in der Tabelle =
(wo
> die =DCberschriften stehen; also außerhalb der Schleife) habe ich mit=

> festen Breiten bereits versehen.

<table>
<colgroup>
<col width=3D"80">
<col width=3D"100">
<col width=3D"320">
</colgroup>
<tr>
<td>.....<td> =09

> Und die Ladezeit ist wie gesagt, schon
> recht lange.

Was sagen denn deine Messungen?

> Soll ich die festen Breiten auch für die dynamischen Zellen
> zusätzlich einbauen? Würde das was bringen? Eigentlich ging ich imm=
er
> davon aus, wenn die Breite einmal oben definiert ist, bezieht sie sich =

> auf die Zellen der gesamten Tabelle. Oder?

Normal schon.

Als Alternative gib mal deine Daten unformatiert aus und gucke dann ob
evtl. PHPs flush() etwas bringt.

Frage: Buffert dein PHP oder dein Webserver weil er was mit transsid,
gzip oder dergleichen macht?

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Erzeugt dein Code zufällig viele Javascript-Handler?

Möglicherweise sogar in jedem <td>?

Peter Schleif

Peter Schleif schrieb:
> Erzeugt dein Code zufällig viele Javascript-Handler?
>
> Möglicherweise sogar in jedem <td>?
>
> Peter Schleif

nein, das ist nicht der Fall

Monika

Hallo,

> <table>
> <colgroup>
> <col width="80">
> <col width="100">
> <col width="320">
> </colgroup>
> <tr>
> <td>.....<td>

könnte es einen Unterschied ausmachen, wenn man colgroup / col verwendet
oder nicht? Ich habe die Spalten-Breiten in den <td> im ersten <tr>.


> Was sagen denn deine Messungen?

Die Uhr zeigte 35 Sekunden, bis die Seite da war.:)
Mit microtime getestet (Anfang/Ende des Skriptes): ca. 0,59...

> Frage: Buffert dein PHP oder dein Webserver weil er was mit transsid,
> gzip oder dergleichen macht?

Nein.

Gruß
Monika

Monika Nowak:
> Die Uhr zeigte 35 Sekunden, bis die Seite da war.:)
> Mit microtime getestet (Anfang/Ende des Skriptes): ca. 0,59...

Bei 500 Zeilen kommt ja durchau eine größere Menge Traffic zusammen.
Vielleicht hast du ja eine langsame Internetanbindung (oder der
Server)?


Gruß,
Habbo


--

I'm using an evaluation license of nemo since 55 days.
You should really try it!
http://www.malcom-mac.com/nemo

Monika Nowak wrote:
> könnte es einen Unterschied ausmachen, wenn man colgroup / col verwendet
> oder nicht? Ich habe die Spalten-Breiten in den <td> im ersten <tr>.

Im Prinzip sollte das den selben Effekt haben.

Die Schreibweise mit colgroup sieht für mich zwar etwas sauberer aus und
ist beim Programmieren auch schöner einzubauen, allerdings habe ich damit
leider schlechte Erfahrungen gemacht: Der Firefox hat mal bei einer
Tabelle die Spaltenbreiten und die Breite der gesamten Tabelle recht
unsinnig angezeigt. Im Opera hat's dagegen funktioniert und der Validator
hatte auch nichts auszusetzen. Mit den width-Angaben in der ersten Zeile
ging es dagegen auch im Firefox.

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641