Jump to content
php.lv forumi

Lapa lielam apmeklējumam


Rich Bitch
 Share

Recommended Posts

Problēma tāda, ka visu laiku esmu taisījis tādas nelielas lapas, kur apmeklētāju daudzums dienā ir līdz 5000. Tagad atsūtīta specifikācija kaut kādai Anglijas lapai, kur prasība lapai ir nodrošināt, lai tā normāli darbotos pie apmeklētāju daudzuma, kas dienā var sasniegt 100-200tk. Tā kā pieredze šadā lietā nav, tad ir jautājums - kā taisīt lapu, lai tā spētu izturēt šādu daudzumu apmeklētāju un vai lapas darbība to ietekmē, ja serveris ir ļoti jaudīgs?

Link to comment
Share on other sites

Izmanto kešošanu, raksti saprātīgus kvērijus, lieto tabulām indeksus, raksti optimālus algoritmus.

Tās, imo, ir tās lietas par kurām jārūpējas pašam programmētājam. Tālāk jau sākas servera puses konfigurēšana, load-balancings un vēl sazin kas...

Link to comment
Share on other sites

Datus, kuri bieži nemainās... teiksim nedēļas tops rakstiem. Kāpēc būtu katru reizi tas dinamiski "jāvelk" arā no datubāzes? Saglabā to statiski un maini šo info reizi nedēļā. Tikai piemērs.

Link to comment
Share on other sites

Līdz kaut kādam apmeklējumam servera jauda utt. glābj, bet kad aiziet īstais apmeklējums, tad, ja nav arhitektūras, tad nav :)

 

Principā tas, kā uztaisīt ātrdarbīgu lapu, ir katra profesionālais noslēpums, kas patiesībā nemaz nav noslēpums. Vnk. attiecīgi jādomā. Pārējais ir detaļas.

Link to comment
Share on other sites

Nav viegli izdomāt, nezinot kas tieši būs tajā lapā, cik liela informācijas pieprasīšanas/ievadīšanas attiecība. Piemēram sociālajos tīklos diezgan stipri jāpadomā arī par to ka informācija diezgan intensīvi būs ievadīta, ne tikai nolasīta. Domāju pie tāda apmeklējuma būs jādomā pie katra sīkuma, jāskatās, lai iespējami mazāk pārlādētu visu lapu kur to var, jāmēģina dizainu taisīt tā, lai pēc iespējas mazāk baitus pārsūta pa tīklu, nu un protams koda un vaicājumu optimāla veidošana, kā te jau minēja. Pats tik stipri apmeklētos projektos neesmu piedalījies, bet dzirdēts ir gan, cik zinu tur par katru baitu cīnās šādos gadījumos, lai samazinātu noslodzi kur tik var.

Link to comment
Share on other sites

Pārāk maz info, bet ļoti vispārīgi runājot par datubāzēm (ja tur tāda apakšā vispār ir):

1) Slikti ir tad, ja lietotājs pilda da jebkādu lielu pieprasījumu, kas prasa daudz resursus (statistika, neoptimāla meklēšana utt) vai bloķē resursus - piem pievieno vai modificē ierakstus un uz to brīdi neviens cits nevar šai tabulā to darīt.

2) Slikti ir tad ja __daudzi__ lietotāji pilda mazus pieprasījumus, jo tie visi kopā summējas.

3) ĻOTI SLIKTI ir tad, ja __daudzi__ lietotāji pilda lielus pieprasījumus.

 

Tātad pēc iespējas mazāk pieprasījumu (skaitā) un pēc iespējas mazāki pieprasījumi (pēc izpildes laika un resursu nepieciešamības).

To kā reiz var minimizēt ar kešošanu, nerādot lieku info, neizvirstot ar funkcionalitāti.

Pēc iespējas minimizēt arī dzenājamo datu apjomu starp DB un webserveri un webserveri un klientu.

 

Un vēl ļoti silts ieteikums - ja tam apakšā ir kāda bāze, tad testē uz reāla (t.i. produkcijai atbilstoša) datu daudzuma. Dabū tos reālus vai saģenerē, tas jau ir sekundāri, bet īstās problēmas parādās tikai tad.

Nu un, protams, stress testi - izmanto rīkus, kas veidos ntos pieprasījumus lapai un skaties, kas tur sanāk. Lai vismaz sākotnējās problēmas risini pats, nevis visu saņem no klienta, jo no klienta pretenzijas būs anyway :)

 

Gints Plivna

http://datubazes.wordpress.com

Link to comment
Share on other sites

Sveiki!

Kā jau iepriekš minēja - šī jautājuma risināšanai vajag vairāk informācijas.

Vispārējā gadījumā tas ir atkarīgs no šādām lietām:

Infrastruktūras (tā ietekmē tīkla caurlaidību, tīkla aizturi, serverpuses koda izpildes laiku, vienlaicīgi apkalpojamo sesiju skaitu),

koda arhitektūras (tas noteiks, cik vienkārši varēs palielināt veiktspēju, izmantojot vertikālo mērogošanu (jaudīgāki dzelži, lielāka atmiņa utt) un it īpaši horizontālo mērogošanu (veiktspējas palielināšanas uz serveru skaita palielināšanas iespējamība)),

koda optimizācijas (visu vajadzīgo informāciju no db/cache ievākt pēc iespējas mazāk piegājienos, pēc iespējas samazināt pārsūtāmās informācijas apjomu utt),

līdzīgi kā serverpusē, jāpadomā arī par klientpuses koda optimizāciju (JS, CSS, DOM), jo kā rāda pieredze, "modernajās" aplikācijās izpildes laiks klienta pusē (JS/Flash/Flex/CSS selektori/DOM manipulācijas/Attēlošana) sasniedz līdz pat 70% un pat vairāk.

Lūk interesants raksts par veiktspējas problēmām klientpusē:

http://blog.dynatrace.com/2010/08/25/top-10-client-side-performance-problems-in-web-2-0/

 

Utt, utjp... Ja ir interese, varu paplašināti uzrakstīt pārdomas par par kādu no šiem jautājumiem.

Link to comment
Share on other sites

Būtu forši! Jo vairāk info... jo labāk. Vairāk gan interesētu kaut kas par "cache'u" utml.. lietām. Piemēram, "Kā izveidot vienkāršu, bet efektīvu kešošanas sistēmu?".

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...