Noslodze

[GS_]

Velviens jautajums, man ir datubaze ar 18 tabulam kuras kopa ir 75.000 ierakstu un viss tas pasakumus kopa sver 4.5mb. Vel uz servera glabajas 2gb dazadu failu kopuma ~30.000 bildes un citi faili.

Planots (es ta ceru) ka ar visiem ierakstiem vienlaicigi stradas loti liels daudzums cilveku.

 

Pieprasijumi DB ir maksimali samazinati ar where, sadaliti lapas utt. un tomer gribetos but drosam ka tas viss ar tadu apjomu nenobruks.

 

Ka var notestet atrdarbibu un kadas butu normas prieks tada apjoma ?

 

Taka si ir pirma lappa un vispar pirma saskarsme ar PHP,Mysql tad nezinu cik liels tas apmers skaitas un cik daudz vinu vajag optimizet lai tas normali funkcionetu.

Un vai nav vajadzigs kads uber servers lai ari pie maximalas optimizacijas tas stradatu, jeb moska vispar jau jasak nauda zimet prieks atseviska servera.

[Delfins]

75.000 ieraksti nav nekas...

30.000 bildes arī nav nekas..

 

Max.performance risinājums i Load Balancing + dedicated serveri... (bildēm savs, db savs klasteris, un web atseviski (tas kas tiek balancēts))

Principā pietiek ar 3 serveriem (HTTP, DB, images)

[litt]

1. Normāla datubāzes struktūra

2. Optimāli salikti indeksi

3. Piefīčoti selekti (nekādi SELECT * FROM, pēc iespējas mazāk tabulu FULL skani)

4. Ja iespējams, tad datus atlasīt 1 reizi un pēc tam ņemt no kešatmiņas

5. Pēc iespējas nedarbināt selektus iekš cikla

[GS_]

Izskatas ka ir ok, vel jautajums cik ir normals pieprasijumu skaits datubazei. Piemeram pirmaja lappa man aiziet 4 pieslegumi uz 4 dazadam tabulam no kuram tiek randoma vilkti ara 20 ieraksti no katras. Cik normali ir kautko tamlidzigu pielietot pie sada apjoma ? Jeb lieka resursu izskerdiba ?

[Delfins]

random nerulē bydefault. aizstāj ar kešotu variantu

nafig 4 pieslēgumi? jeb tu domāji vienkārši 4-selekti?

[GS_]

Bija domati 4 selekti.

[Delfins]

Uztaisi kešu/trigeri

 

function on_story_update()
{
  do_update_cache_storylist();
}

function do_update_cache_storylist()
{
  sql = ... // kaut vai Random
  while (row)
 {
  $txt .= $row->data;
 }
  file_put_contents('cache/lateststories.txt',$txt);
}

[GS_]

Paldies par skriptu, moska ari kesot piemeram kategoriju pirmas lapas lai garam ejot nerastos lieku pieprasijumi ?

[tutins]

Uztaisi kešu/trigeri

 

function on_story_update()
{
  do_update_cache_storylist();
}

function do_update_cache_storylist()
{
  sql = ... // kaut vai Random
  while (row)
 {
  $txt .= $row->data;
 }
  file_put_contents('cache/lateststories.txt',$txt);
}

 

a ka pec tam izvilkt laukaa tos datus no ta kesha?

[andrisp]

http://lv.php.net/manual/en/function.file.php

http://lv.php.net/manual/en/function.file-get-contents.php

Edited November 7, 2006 by andrisp

[Delfins]

jāskatas cik kategorijas, pat ja tās ir kādas 50, tad labāk ielikt masīvā (ar visu koku un referencēm)

[Blitz]

Bet kas tadaa gadijuma bus atrak? Ar kesosanu samazinasies DB noslodze bet webserverim tad visu laiku jalasa tas fails =/

Vai tad atrak nav izvilkt datus no DB?

[andrisp]

Nu bieži kešo tos sql pieprasījumus, kas veic sarežģītākas darbības, kas aizņem vairāk laika. Iekešojot failā, vairs nekādi aprēķini, joinošanas etc nenotiek, bet tikai pure text ielasīšana.

[Blitz]

aa skaidrs, tad kesosanu izvelas nevis pec biezhuma, bet pec biezhuma + sarezgitibas.

[litt]

Kaut kādus operatīvos datus (piemēram, online lietotājus) var glabāt arī MySQL memory tabulā, tb datus varēs iegūt ar parasto selektu, bet tas notiks ātrāk, jo dati glabājās atmiņā, nevis failā. Nevaru komentēt par šī varianta efektivitāti, jo ir jāizvērtē vairāki kritēriji: piekonektēties pie bāzes vajadzēs, ja ir daudz dati, tad aizistīs daudz atmiņu.. Plusi tādi, ka ar selektu ir daudz vieglāk atlasīt datus, nekā no faila kaut ko lasīt un pēc tam filtrēt