viele querys = langer seitenaufbau?!

[eyz]

ho!i

also ich hätt da mal eine frage, was die ausführungszeit eines querys angeht

ich hab vor ein CMS aufzubauen.. das db-layout hab ich mir schon mehr oder weniger überlegt
auch hab ich schon zum coden eines forums angefangen

jetzt läuft alles so halbwegs.. nur will ich nicht wissen wie das aussieht wenn 1000 user am tag das forum stürmen (träum )

beim durchstöbern im netz bin ich hin und wieder über brauchbare infos gestolpert.. die zusammengefasst nur aussagen, dass es nicht nur auf die anzahl der querys ankommt, sondern auf die "komplexität".. sprich fetter join, oder kleine anfrage

könnt ihr mir vielleicht weiterhelfen? thx für eure zeit

 

[Arclite]

Is doch eigentlich klar, um so mehr Anfragen, umso länger die Rechenzeit...
Aber ich denke das n Server von halbwegs vernünftigen Hostern das ohne Probleme Meistern... Wenn ich mir mal den Code vom WBB2 anschau. Das läuft bei uns auf vielen Seiten Problemlos. Ich hab mir zwar angewöhnt (während dem Coden von meinem CMS ;P) allen code so kompakt wie möglich zu machen (was sicherlich nicht verkehrt ist), aber es sollte schon keine Probleme machen.

best greetz und frohes Coden,
arc

 

[Darkstar]

ich machs meist so

Hi,

ich habe für mein cms eine klasse für die datenbank geschrieben, damit ich jederzeit mehrere datenbanksysteme damit ansprechen kann, ohne den restl. quelltext zu durchforsten. (bis jetzt mal mysql & msAccess)

Wenn Du nicht soviel Zugriffe auf einmal auf Deinem System hast, ist es denk ich nicht so wichtig, wie Du z.B. die Datenbank durch die queries ansprichst, sollten aber einmal etwas mehr Benutzer zur gleichen Zeit queries starten, kann es je nachdem, wie Du programmiert hast, die Performance einschränken, damit hatte ich jedoch noch nicht so wirklich probleme, da ich immer die unteren dinge so weit wie möglich versuche einzuhalten und auch noch keine sooo großen traffic auf einmal im system hatte.

Vielleicht mal so ein paar tips, die ich immer so verwende.

- Lasse die Daten nur so lange im Speicher, wie Du sie auch wirklich brauchst, mysql_free_result() oder odbc_free_result() ist dabei ein großer Freund

- achte auf die Art, wie du die datenbank ansprichst (Beispiel: du hast eine Tabelle mit 20 Zeilen, brauchst aber in einer Abfrage z.b. nur die id und ein weiteres feld. Dann solltest du nicht sowas verwenden SELECT * FROM.... sondern eher SELECT tabellenname.zelle1, tabellennamen.zelle2 FROM....)

- ich versuche immer, so wenig wie möglich mehrere queries in schleifen zu verschachteln, das könnte, wenns blöd läuft vielleicht auch ein wenig lahmen
Bsp:

while (x<y) {
  query = "SELECT * FROM ....";
  while (i < x) {
    query = "SELECT * FROM user AS t1 INNER JOIN plz AS t2 (t1.plz_id ON t2.id) WHERE blupp AND bla SORT BY username ASC...";
      for (s=0,s<$wert_aus_einem_query;$s++) {
        mach vieles
      }
  }
  mach hier vielleicht auch noch einiges
}

so in der Art

Damit solltest eigentlich schon recht gut fahren, ansonsten gibts dazu auch ein ausführlich beschriebenen punkt im mysql handbuch, wie du noch mehr tunen kannst, indem du div. datensätze z.b. sperrst, sobald eine anfrage auf sie zugreift etc...

Aber vielleicht laber ich auch schon lauter Zeug, dass Du schon längst weißt, dann vergiss es einfach wieder

Hoffe, ich konnte ein wenig helfen.

Viele Grüße aus dem Süden.

 

[wegus]

Bei SQL-Abfragen lohnt es sich in der Tat ein paar mehr GEdanken zu investieren. Bei vielen kleinen Abfragen ist der Verbindungsaufbau teuer. Hier sollte man zu persistenten Verbindungen greifen. Bei vielen USern braucht man dann aber auch mehr Speicher im Rechner. Generell stellt sich die Frage, wird in die DB mehr geschrieben oder mehr gelesen. Meist ist es letzteres. Hier helfen dann gut gewählte Indizes auf die entsprechenden Spalten. Inserts dauern dann etwas länger, aber SELECTS und auch JOINS sind dadurch um Größenordnungen steigerbar. Gleiches gilt auch für VIEWS. Auch die können das Leben vereinfachen. Große DBMS erlauben auch precompiled-Versionen von häufigen Abfragen. Die liegen dann vorbereited in einem Cache.

 

[eyz]

danke für die super antworten!

genau beim setzen von querys in schleifen hab ich zum denken angefangen
..und ich werde meinen Aufbau der DB noch mal überdenken und mitberücksichtigen, dass INSERT´s länger dauern können und SELECTS/JOINS dafür einen speed-pump bekommen

eine klasse fürs CMS für die DB, damit das CMS auch auf mehrere/andere DB´s zugreifen kann hört sich interresant an.. könntest du das vielleicht genauer erläutern?

auch würde mich interresieren (wo wir schon dabei sind ), wie ich die anzahl der ausgeführten query´s auslesen kann.. und vielleicht die einzelnen timings _sry hab jetzt noch nicht *search/g00gle* benutzt, würde mich aber trotzdem über jeden anhaltspunkt freuen

////////edit
abfrage funktionen ..schon gefunden (also das manual hats echt in sich!)

thx & greets eyz

 

[wegus]

eine klasse fürs CMS für die DB, damit das CMS auch auf mehrere/andere DB´s zugreifen kann hört sich interresant an.. könntest du das vielleicht genauer erläutern?

Das ist ne Standardübung für alle PHP-Programmierer. Schreib ne Klasse Datenbank. Die folgende Methoden kapselt:

$db->setServer($server);
$db->GetServer();
$db->SetDB($database);
$db->GetDB();
$db->connect();
$db->pconnect();
$db->query($sql);
$db->fetch_row();
$db->fetch_obj();
.
.
.

und Du kannst ganz leicht den Server, die DB oder sogar den Datenbankserver wechseln (oracle, mssql,mysql). Letzteres ist problematisch weil dann nur noch Standard-SQL geht und das auch nicht immer (Sub-Queries bei alten MySQL).

Das ist ne schöne Übung und man hat die DB-Schnittstelle hinterher verstanden und kann in Webseiten viieel flexibler mit DB's umgehen. Sowas gibt's auch fertig ( in PEAR z.B.), aber das ist nur was für Balkonraucher und Schattenparker ;-)