Rich Bitch Posted April 12, 2011 Report Share Posted April 12, 2011 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? Quote Link to comment Share on other sites More sharing options...
briedis Posted April 12, 2011 Report Share Posted April 12, 2011 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... Quote Link to comment Share on other sites More sharing options...
Rich Bitch Posted April 12, 2011 Author Report Share Posted April 12, 2011 ko tu domā ar kešošanu? Quote Link to comment Share on other sites More sharing options...
briedis Posted April 12, 2011 Report Share Posted April 12, 2011 Tieši to, ko tas vārds sevī ietver :) Teiksim, datus, kas bieži jāvēlk ārā no DB būtu labāk turēt atmiņā. Var izmantot to pašu memcache. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 12, 2011 Report Share Posted April 12, 2011 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. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted April 13, 2011 Report Share Posted April 13, 2011 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. Quote Link to comment Share on other sites More sharing options...
Maris-S Posted April 13, 2011 Report Share Posted April 13, 2011 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. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted April 13, 2011 Report Share Posted April 13, 2011 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 Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted April 18, 2011 Report Share Posted April 18, 2011 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. Quote Link to comment Share on other sites More sharing options...
daGrevis Posted April 18, 2011 Report Share Posted April 18, 2011 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?". Quote Link to comment Share on other sites More sharing options...
yeahz Posted April 18, 2011 Report Share Posted April 18, 2011 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?". +. Es arī gribētu ko tādu redzēt. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.