Lange ladezeit - Großes Projekt
Hallo,
ich habe ein großes Problem mit meinem Projekt. Es ist eine Art Shop á la Ebay.
Nun zu meinem Problem. Es kommt oft vor das die Seite sehr lange bzw. garnicht läd.
Hardware:
AMD 3200+ (2 GHz)
2 GB RAM
200 GB Festplatte
Bei dem CMS Handelt es sich um eine eigentwicklung. Die Datenbank umfasst rund 200 MB. Wobei die Angebote knapp 100 MB ausmachen. Es sind durchschnittlich ca. 30-40 User online. Die CPU ist fast immer zu 100% ausgelastet laut meines Hosters. Das Hauptproblem liege in der DB so die aussage des Hosters.
Was ich mir jedoch schonmal gedacht habe ist folgendes.... Alle Bilder liegen in /images/ Angebots-ID / Bildname.jpg
Jetzt muss das System also knapp 240.000 Ordner durchgehen um den Richtigen Ordner zu finden, kann das etwas mit der langen Ladezeit zu tun haben?
Ich habe mir bereits die slowqueries.log zukommen lassen und diese Probleme behoben. Gibt es sonst eine Möglichkeit herrauszufinden wie es zu den langen Ladezeiten kommt? Ich muss dazu sagen das es manchmal auch bei Seiten ohne/mit nur wenigen SQL-Abfragen zu dieser langen Ladezeit kommt.
Ich weiss das ich gerade auf eure Glasskugeln setzte, aber ich kann/darf leider nicht so viele Infos hier veröffentlichen.
Danke und Gruß
ich habe ein großes Problem mit meinem Projekt. Es ist eine Art Shop á la Ebay.
Nun zu meinem Problem. Es kommt oft vor das die Seite sehr lange bzw. garnicht läd.
Hardware:
AMD 3200+ (2 GHz)
2 GB RAM
200 GB Festplatte
Bei dem CMS Handelt es sich um eine eigentwicklung. Die Datenbank umfasst rund 200 MB. Wobei die Angebote knapp 100 MB ausmachen. Es sind durchschnittlich ca. 30-40 User online. Die CPU ist fast immer zu 100% ausgelastet laut meines Hosters. Das Hauptproblem liege in der DB so die aussage des Hosters.
Was ich mir jedoch schonmal gedacht habe ist folgendes.... Alle Bilder liegen in /images/ Angebots-ID / Bildname.jpg
Jetzt muss das System also knapp 240.000 Ordner durchgehen um den Richtigen Ordner zu finden, kann das etwas mit der langen Ladezeit zu tun haben?
Ich habe mir bereits die slowqueries.log zukommen lassen und diese Probleme behoben. Gibt es sonst eine Möglichkeit herrauszufinden wie es zu den langen Ladezeiten kommt? Ich muss dazu sagen das es manchmal auch bei Seiten ohne/mit nur wenigen SQL-Abfragen zu dieser langen Ladezeit kommt.
Ich weiss das ich gerade auf eure Glasskugeln setzte, aber ich kann/darf leider nicht so viele Infos hier veröffentlichen.
Danke und Gruß
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93091
Url: https://administrator.de/forum/lange-ladezeit-grosses-projekt-93091.html
Ausgedruckt am: 14.05.2025 um 22:05 Uhr
14 Kommentare
Neuester Kommentar
Mach eine Zeitmessung rein wielange der reine PHP Code brauch zum abarbeiten, die Datenbank braucht führ ihre bearbeitung.... und dann wo die hohe Zeit ist die Scripte genauer analysieren und schon hast du dein Problem gefunden!
G' Abend,
das Problem kann von verschiedenen Faktoren abhängen:
So spontan kann man als den Fehler nicht festmachen. Vllt. kannst du erstmal was zu den oberen Punkten sagen....
Was mich interessieren würde ist dieser Gedanke. Kannst du uns erklären, warum du das so gemacht hast?
Gruss,
Dani
das Problem kann von verschiedenen Faktoren abhängen:
- Anbindung des Servers ans Internet
- Deine Internetverbindung bzw. Konten deines ISP ist bei 100% und droppt Pakete (gibt es...)
- (teils) schlechte Programmierung - Keine Klassen, unstruktiert programmiert, falsches DB-Design
- MySQL / Apache - IIS falsch konfiguriert
So spontan kann man als den Fehler nicht festmachen. Vllt. kannst du erstmal was zu den oberen Punkten sagen....
Was mich interessieren würde ist dieser Gedanke. Kannst du uns erklären, warum du das so gemacht hast?
Jetzt muss das System also knapp 240.000 Ordner durchgehen um den Richtigen Ordner zu finden, kann das etwas mit der langen Ladezeit zu tun haben?Gruss,
Dani
So danke erstmal hab es gerade mal gemacht und hat sich auch wirklich gelohnt, sehr aufschlussreich!
Also ich weiss jetzt ziemlich sicher das das alles mit der Angebotstabelle in der Datenbank zu tun hat.
"Zeige Datensätze 0 - 29 (241.412 insgesamt, die Abfrage dauerte 33.1256 sek)"
Ich poste einfach mal die Datenbank Struktur bestimmt hat jemand ne Idee wie ich es besser und somit Performanter umbauen könnte...
CREATE TABLE `offers` (
`offer_id` int(10) NOT NULL auto_increment,
`customer_id` int(10) NOT NULL default '0',
`user_id` int(10) NOT NULL default '0',
`lang_id` tinyint(2) NOT NULL default '0',
`offer_status` tinyint(1) NOT NULL default '1',
`category_id` int(10) NOT NULL default '0',
`category_id_2` int(10) NOT NULL default '0',
`offer_time` int(10) NOT NULL default '0',
`offer_endtime` int(10) default NULL,
`offer_title` varchar(120) collate latin1_general_ci NOT NULL default '',
`offer_text` text collate latin1_general_ci,
`offer_price` int(10) default NULL,
`offer_pieces` int(10) default '0',
`offer_upe` int(10) default NULL,
`offer_uvp` int(10) default NULL,
`offer_articlenumber` varchar(30) collate latin1_general_ci default NULL,
`offer_minimum_purchase` int(10) default '0',
`offer_shippingtime` varchar(10) collate latin1_general_ci default NULL,
`offer_articlequality` tinyint(2) default '10',
`offer_price_per` tinyint(2) default NULL,
`offer_packing` tinyint(2) default '0',
`offer_shippingcosts` int(10) default '0',
`offer_hits` int(10) NOT NULL default '0',
`offer_watchers` mediumint(5) NOT NULL default '0',
PRIMARY KEY (`offer_id`),
KEY `category_id_2` (`category_id_2`),
KEY `category_id` (`category_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci PACK_KEYS=0;
Also ich weiss jetzt ziemlich sicher das das alles mit der Angebotstabelle in der Datenbank zu tun hat.
"Zeige Datensätze 0 - 29 (241.412 insgesamt, die Abfrage dauerte 33.1256 sek)"
Ich poste einfach mal die Datenbank Struktur bestimmt hat jemand ne Idee wie ich es besser und somit Performanter umbauen könnte...
CREATE TABLE `offers` (
`offer_id` int(10) NOT NULL auto_increment,
`customer_id` int(10) NOT NULL default '0',
`user_id` int(10) NOT NULL default '0',
`lang_id` tinyint(2) NOT NULL default '0',
`offer_status` tinyint(1) NOT NULL default '1',
`category_id` int(10) NOT NULL default '0',
`category_id_2` int(10) NOT NULL default '0',
`offer_time` int(10) NOT NULL default '0',
`offer_endtime` int(10) default NULL,
`offer_title` varchar(120) collate latin1_general_ci NOT NULL default '',
`offer_text` text collate latin1_general_ci,
`offer_price` int(10) default NULL,
`offer_pieces` int(10) default '0',
`offer_upe` int(10) default NULL,
`offer_uvp` int(10) default NULL,
`offer_articlenumber` varchar(30) collate latin1_general_ci default NULL,
`offer_minimum_purchase` int(10) default '0',
`offer_shippingtime` varchar(10) collate latin1_general_ci default NULL,
`offer_articlequality` tinyint(2) default '10',
`offer_price_per` tinyint(2) default NULL,
`offer_packing` tinyint(2) default '0',
`offer_shippingcosts` int(10) default '0',
`offer_hits` int(10) NOT NULL default '0',
`offer_watchers` mediumint(5) NOT NULL default '0',
PRIMARY KEY (`offer_id`),
KEY `category_id_2` (`category_id_2`),
KEY `category_id` (`category_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci PACK_KEYS=0;
Ich wollte damit eigentlich genau bewirken das das ganze Schneller von statten geht! Wie währe es denn besser. Alle Bilder in einen Ordner und alle Thumbnails in einen anderen?
Danke und Gruß
Danke und Gruß
Nun jedes Angebot hat ja seine eigende ID daher ein Ordner für die Bilder mit id-bild id-bild2 ect zb speichern...
Ist das denn sicher schneller ? Hast du damit schon erfahrungen gemacht? Soll kein Angriff sein, bin nur ein wenig am verzweifeln.
Danke und Gruß
Danke und Gruß
Hi,
naja, wie wärs, wenn du zum Artikel einfach eine Tabelle anlegst, wo ALLE Bilder mit der BeitragsID verknüpft werden. Somit ist es eine REINE SQL Geschichte und somit wesentlich schneller. Das wirst du auf jeden Fall merken.
Ein weitere Punkt wäre, nur die HTML Tags in PHP oder ASP schreiben, wirklich nötig sind. D.h. alles was statisch ist nicht Parsen lassen. Das wirst du merken, wenn viele User (> 40) deine Seite besuchen.
NIE SO MACHEN:
Sondern so:
Gruss,
Dani
naja, wie wärs, wenn du zum Artikel einfach eine Tabelle anlegst, wo ALLE Bilder mit der BeitragsID verknüpft werden. Somit ist es eine REINE SQL Geschichte und somit wesentlich schneller. Das wirst du auf jeden Fall merken.
Ein weitere Punkt wäre, nur die HTML Tags in PHP oder ASP schreiben, wirklich nötig sind. D.h. alles was statisch ist nicht Parsen lassen. Das wirst du merken, wenn viele User (> 40) deine Seite besuchen.
NIE SO MACHEN:
<?
echo '<html>';
echo '<head>';
....
?><html>
<head>
<? include_once ("");?>
....Gruss,
Dani
Das ist legendlich die Strutkur einer Tabelle, nicht die Datenbankstruktur. 
33 Sekunden für 290.000 Einträge ist ganz gut. Also das sieht schon mal gut aus...
Was ich mich frage, warum hat z.B. "uvp", "price", etc... 10 Stellen? Ist das wirklich nötig? Denn bei deiner Datenbankstrutkur und Anzahl der Datensätze rechnet sich das später bei einem Dump oder Berechungen.
==> Felder immer nur so groß dimensonieren, wie nötig!
Gruss,
Dani
33 Sekunden für 290.000 Einträge ist ganz gut. Also das sieht schon mal gut aus...
Was ich mich frage, warum hat z.B. "uvp", "price", etc... 10 Stellen? Ist das wirklich nötig? Denn bei deiner Datenbankstrutkur und Anzahl der Datensätze rechnet sich das später bei einem Dump oder Berechungen.
==> Felder immer nur so groß dimensonieren, wie nötig!
Gruss,
Dani
Hi,
danke, das mit der Tabelle für die Bilder ist bereits so umgesetzt, also die Datenbank ist eigentlich komplett normaliesiert. Auch sind sinvolle Index'es gesetzt.
Ich benutzte Smarty als Templatesystem, wollte mir dannach einmal Zend anschauen!
Danke und Gruß
danke, das mit der Tabelle für die Bilder ist bereits so umgesetzt, also die Datenbank ist eigentlich komplett normaliesiert. Auch sind sinvolle Index'es gesetzt.
Ich benutzte Smarty als Templatesystem, wollte mir dannach einmal Zend anschauen!
Danke und Gruß
Ok...dann würde mich mal die Auslastung nun interessieren bzw. die Dauer der Seitenaufrufe. Denn es müsste auf jeden Fall zügiger gehen....Ansonsten vergrößere den Cache von MySQL von 16MB auf 128MB. Und erzeuge von den Abfragen, die sehr oft ausgeführt werden, temporäre Dateien. Mit fällt bloß grad das Stichwort nemme ein. 
Ist eine Neuerung von MySQLv4 zu v5.
Gruss,
Dani
Ist eine Neuerung von MySQLv4 zu v5.Gruss,
Dani
Stimmt, ist nur die Tabellenstruktur für die eine Tabelle.
Nein es braucht keine 10 stellen, stimmt werde das Umbauen, danke!
Nein es braucht keine 10 stellen, stimmt werde das Umbauen, danke!
Leider habe ich dort keinen einfluss auf die MySQL Config, das liegt alles beim Hoster. Und ich muss dazu sagen das ich mich noch nicht wirklich mit der Administration von MySQL server auseinander gesetzt habe!
Du machst mir den eindruck, als könntest du das wissen
Was sind der "Query Cache Hitrate" und der "Key buffer". Stimmt es das ein "Key buffer" umso besser ist desto höher die % Angabe? Ich muss ehrlich sagen habe ich gelesen, aber kann es mir nicht/nur schlecht vorstellen.
Danke und Gruß
Du machst mir den eindruck, als könntest du das wissen
Was sind der "Query Cache Hitrate" und der "Key buffer". Stimmt es das ein "Key buffer" umso besser ist desto höher die % Angabe? Ich muss ehrlich sagen habe ich gelesen, aber kann es mir nicht/nur schlecht vorstellen.
Danke und Gruß
Abend,
zu "Key buffer" kann ich dir nix selbst sagen, aber hierstehen ein paar Tipps dazu.
Die Hitrate ist die Anzeige im HealthMonitor (zu deutsch "status) unter MySQL. Dieser Wert ist abhängig von den Variablen "query_cache_limit" & "query_cache_size". Diese musst du anpassen. Der 1. Wert gibt an, wie viel Platz eine Abfrage benutzen darf. Die Andere den Gesamtspeicherplatz.
Um so mehr die Hitrate unter Status ausschlägt, um so mehr werden die Daten aus dem Cache gezogen und somit sieht der Besucher das Ergebnis in einm Bruchteil der normal Berechnung.
P.S. Sry, ist bei schon ein Weilchen her, dass ich mit solchen DB-Systeme gearbeitet habe.
Gruss,
Dani
zu "Key buffer" kann ich dir nix selbst sagen, aber hierstehen ein paar Tipps dazu.
Die Hitrate ist die Anzeige im HealthMonitor (zu deutsch "status) unter MySQL. Dieser Wert ist abhängig von den Variablen "query_cache_limit" & "query_cache_size". Diese musst du anpassen. Der 1. Wert gibt an, wie viel Platz eine Abfrage benutzen darf. Die Andere den Gesamtspeicherplatz.
Um so mehr die Hitrate unter Status ausschlägt, um so mehr werden die Daten aus dem Cache gezogen und somit sieht der Besucher das Ergebnis in einm Bruchteil der normal Berechnung.
P.S. Sry, ist bei schon ein Weilchen her, dass ich mit solchen DB-Systeme gearbeitet habe.
Leider habe ich dort keinen einfluss auf die MySQL Config, das liegt alles beim Hoster
Dann soll er das auf deinen Wunsch anpassen. Ansonsten einfach zu einem anderen Hoster wechseln. Ich würde da einen guten kennen. Gruss,
Dani
Bitte alle Tabellen prüfen und Indizes, ggf nochmal neu generien.
