Un? Tevi tas satrauc?

tas ir komerciāls projekts. vismaz autori tā uzskata :), lasīju Dienā interviju kaut kad pirms laika

apskaties, tur lapas apakšā ir linki uz citām viņu lapām, viņi teica, ka paliks ar laiku komerciālāks - tb šī lapa palīdzēšot pievērst uzmanību citiem viņu projektiem

draugus var iegut arī bez sitiem portaliem... turklat ja vel prasa SMS.. naglež... saprot ka gribās $.. bet nu.. naher!?

rokas nost no sausajaam atejaam!!!

Man liekas (ceru), ka tiešām šķietamība... Apstiprināšana nesen sāka kustēt, katru dienu kāds mīļš "pacietieties" tekstiņš :), ja vēl visi lietotu Kešojošo Pārlūku, tad arī bildes tik smagi nebremzētu... Tikai nevaru saprast, kāpēc tur kāds nejēdz un nejēdz magic quotes no tekstiem aizvākt.

par to thread listē.... džeks Exigenā sēdēdams gribēja pevērst 2 pirkstus \m/ pret visu vareno Marsu, bet.... :D

jaa, un kaadus projektus tu, ::vertigo, esi izbiidiijis, vai biidi?

kāpēc gan tu domā, ka tas projekts lēnām un pārliecinoši tiek laists caurumā? AFAIK projekta darbinātāji viņu darbina [gan usability, gan profitability virzienos] cik tik spēj...

karlis: //as far as you know// un //as far as i see//. Kurš kuru?

grūti spriest cik daudz es //know//, salīdzinot ar to cik daudz tu //see//...

Patiesībā pēc trešdienas es nekādas īpašas pārmaiņas draugos neieraudzīju, varbūt tāpēc, ka esmu paviršs vērotājs. Nevis varbūt, bet gandrīz droši tāpēc. Līdz ar to jautājums - ko tik sliktu ieraudzīji tu...

karlis: Kāpēc tieši no trešdienas? Kas notika trešdien? Es vispār runāju par to, ka tur es neko (absolūti) neko jaunu (vērā ņemamu no lietotāja viedokļa) neesmu ievērojis. It īpaši viņiem grūtības sagādā pasākuma ātrdarbība.

trešdien bija kaut kāds upgreids. Ātrdarbība tik tiešām klibo un tas var piebesīt pat pie ļoti vērtīgiem resursiem, kur nu vēl parastas socializēšanās.

Eh, atceros porno uz dialup, kā bilde lēnām, lēnām pa mazai rindiņai raisās vaļā... Labi laiki bija..

kaads sakars te ar mani - es tikai fikseeju faktu :/

to "2 watt" - idiotu klasiskā stratēģija. Novilkt līdz savam līmenim un sakaut ar pieredzi. Jebšu, OSS kliedzošie bari ka ļaunā pārējā pasaule arī nesēž mammas mājas pagrabā kodēdama nelietojamus produktus.

:)) atzistu, ka esam amatieri. tachu kuram no jums ir bijusi pieredze ar 1.500 cilvekiem onlaina..nopelniit var, tachu vajag ieguldit papravas naudas uz serveriem. pateikshu priekshaa, ka serveris ar 2 x 3GB xeon procesoriem, 3GB operativo, un citiem labumiem, 1500 cilveekus nevelk. tagad sprauzham klaat veel vienu tikpat labu serveri, lai slodzi mazinatu. un tikai nesakiet, ka php klibo, jo php tur ir loti maz palicis pie web lapu atteloshanam. un jauni pakalpojumi klaat nenaak, tapec ka cinamies ar sasodito atrumu. migrejam no viena servera uz otru utml. ir jau gatavs kaut kas lidzigs yahoo groups pasakumam, ir jau kaut kas lidzigs blogiem, tachu neesam vel palaidushi. bet nakamnedel cerams buus. tapat tagad taisam C++ risinajumu draugu tiikla veidoshanai jo php tas nav iespejams. un ar naudas pelniishanu ari nav tik vienkarshi. lai piesaistitu reklamas devejus, vajag normali funkcionejoshu saitu, kas mums, protams, nav. likt kaut kadu mobilo fun? negribas...lai gan varetu. kadas tad vel pastav iespejas pelnit naudu? jau tagad aparatos un softos ir ieguldits 8.000 Ls. mees neesam ne bagats kantoris, ne bagatu onkulu mantinieki. kaut kadi krediti, kaut kadas vienoshanas.

Lauris, moš pastāsti vairāk kā jums tur viss sarakstīts? 1500 cilvji onlainā ir normāli, ir strādāts arī ar sistēmām kur vienlaikus ir 50'000 cilvji. Jautrības pēc var pakodēt vai paskatīties ;D (lupus@burti)

Tas ar domu ka pie 1500 lietotājiem onlainā (~10-15 pieprasijumi sekundē, max) nu pie sistēmas specifikas problēmām nevajadzētu būt.

draugiem.lv gan atgādina kautko, kas sākotnēji taisīts kā kursa darbs un nav paredzēts, lai skeilotos.

orkut.com man saka "You are connected to 2'311'273 people through 62 friends.". domāju, ka tur ir daudz vairāk cilvēku onlainā. protams, dzelži ir viņiem arī var būt niknāki, bet vai 1'500 cilvēku onlainā būtu tik liela slodze?

ja vien, taisot saitu, ir domāts par to, kā tas mērogosies (nez, vai tā varētu tulkot "how it will scale"?).

Šeit jau neiet runa pat par mērogošanos. 1500 lietotāji uz nopietna dzelža - pietiktu ar normālu darbu ar datubāzi un rupjāko ciklu izravēšanu.

Captsolo: man jamais saka, ka //You are connected to 2308383 people through 1 friends.// :)

pamata problēma - dinamiskais draugu tīkls.. tā dinamika un 'update' ātrums ir galvenā ierindas lietotaja (kā es) interese.. ko cenšas arī nodrošināt! Statiskas lapas online lietotaju skaitu drosi pavilktu arī lielāku..

vakar lighthtppd pie 700 pieprasijumiem 1 sekundē atslēdzās. †āpēc vakar pa dienu pārgājām uz zeos. pieļauju, ka konfigurācijā bija problēmās, taču labākā testa vide diemžēl ir useri :) salīdzinājāt orkut ar draugiem.lv! viņu resursi un mūsu resursi...smiekli nāk :) draugiem.lv netika taisīts kā kursa darbs.

lauris - orkut, starp citu, tika taisīts kā diplomdarbs. vai, precīzāk, orkut autors uztaisīja kā diplomdarbu un tad vēlāk jau uztaisīja orkut.

ok, piekrītu, ka Latvijas līmenī draugiem.lv ir jauks. ir lietas, kas orkut ir labākas, bet jāpiedomā - bija dažas prātā, bet uz sitienu neatceros.

tā kā - lai veicas.

laacz - zināmo cilvēku daudzumā uz 1 draugu iekš orkut.com es laikam ar Tevi nevaru konkurēt ;)

Ja problēma tik vien kā dinamiskā draugu tīkla atainošanā, problēma ir elementāri risināma. Datubāze, tabula kurā tiek glabātas draugu attiecības, M>-<M tbsh, timestamp uz updeitiem (šo, vispār, vajadzētu ar trigeri saglabāt atsevišķā, vienas rindas tabulā, lai vieglāk dzīvot). Izmaiņas šajā tabulā ir krietni retākas kā atainojumi, veidojam atsevišķu kešu kur glabājam jau izveikto SQL kveriju rezultātus (es ceru ka tiek izmantoti divi kveriji - pirmais, atainojot, ar tiešo draugu sarakstu, netiešo: count(*), otrais jau netiešo pārlūkošana ar limit.) Katru reizi kad noskaidrojam ka kešs ir outdated (jebšu kešotie dati < timestamp) nosviežam kešu, sākam no nulles. Tas vien noņemtu apm 70% noslodzes (pieņemot ka šobrīd tiek vienmēr laisti pilni kveriji uz DB). (tāds 5min risinājums, var izdomāt arī ko krietni labāku)

Vēl - kas ir zeos ņeimeju predstavļeņija, bet lighthttpd nosaukt par piemērotu noslogotām sistēmām ir dikti grūti. :D

Lupus - šķiet, tev ir pieredze un/vai know-how kā taisīt sistēmas, kas prasa lielu noslodzi. Is that so? :)

pašlaik draugu tīkla attēlošana ir statiska..katru nakti dēmons izgriežas un katram cilvēkam uzģenērē tīklu. lai to izbeigtu, mēs taisam C risinājumu, kurš visu draugu tīklu ielasīs atmiņā un pēc tam veidos dinamiski.

Lupus...kādu web serveri tu iesaki?

lauris - par draugu tīkla ģenerēšanu ielasot visu tīklu atmiņā - un kas notiks,kad šāda procesa rezultātā izbeigsies brīvā atmiņa?

Pieredze - Neteiksim ka liela, bet kaut kas ir darīts. Konkrētākus variantus un sarunas gan labāk risināt pie alus glāzes vai priv. Par serveri - apačam nav ne vainas, atliek tikai nokonfigurēt. Paskatieties uz kā citi saiti griežas - un tur noslodzi, nav ne vainas. Protams, ne jau defaultajā konfigurācijā un ne uz windows ;D.

pašlaik draugu id ielasīšana atmiņā aizņem 300mb. operatīvā atmiņa var būt līdz 10gb. ta kā ir kur augt :)

to lupus: pieredze nav liela, bet viedoklis ir :)) nav slikti. tad es tev pateikšu, ka mūsu konsultantiem pieredze ir ļoti liela un arī priekš viņiem draugiem.lv ir izaicinājums...darboties ar maziem datu apjomiem ir viens, bet tad kad lietotāji un apmeklētāju skaits sniedzas tūkstošos, tad risinājumi ir vajadzīgi pavisam citi..

Lauris, kā zini. Tad kad lietotāju skaits sniedzas jau desmitos tūkstošu, risinājumi arī ir vajadzīgi jau pavisam citi. Nevēlies, nevajag, man ta kas.

Lauris - nevari iesviest reālus ciparus cik pieprasijumi sekundē iet uz serveri (max noslodzē un vidējā). Kas jums īsti aizdirš resursus? Atbilde ka cilvēku daudz neder.

Nezinu, vai pie manis pieklīdušais sources fragments ir reāls un vēl tiek izmantots, bet teiksim koda gabals [un tādi 3 fragmenti rindiņā, attiecīgi nosūtīto, saņemto un jauno ziņu skaita iegūšanai]

skaits

$in_dir = opendir($dir.substr($_SESSION['id'],0,2)."/".$_SESSION['id']."/mss_in/"); while ($fn = readdir($in_dir)) { if (strlen($fn)>3) { $inb_sk++; } }

Liekas graujoši :)

Izejas teksta fragmentu paņēmu no http://draugiem.lv/inc/main.php.save

Pat bail iedomāties, kas citur varētu būt.

Bezmaksas konsultācija. Vai komerciāls piedāvājums draugiem.lv potenciāliem konkurentiem ;D http://journal.bad.lv/users/einherjar/25946.html

Lupus, damn, paliek smieklīgi. 22. komentārā peak pieprasījumi bija minēti. Iedziļinies problēmā, pirms \m/. Ir tāda ļoti viltīga doma - ja man risinājums ienāk prātā 5 minūtēs - vai tiešām citi par to nebūs iedomājušies?...

Ulža, par nepieciešamajiem parametriem pieņemu uzskaitītos 700 pieprasijumus sekundē, kas minēti augstāk, un ciparus kurus var ievērtēt podā. Pārējais jau ir elementāri izsecināms, ja ir zināma pieredze ar šāda tipa jautājumiem. Un arī 5 minūšu risinājumiem ir nepieciešamas zināšanas par to kā lācītis alā lien.

kas tur par db tiek izmantota? un kas tad isti bremzee - vai ir kaadi konkreeti db pieprasiijumi? indeksi nooptimizeeti? tas uzreiz 1ais kas naak praataa - darbs taads.

Ar db darbs runtaimā viņiem sanāk saprāta robežās, ja jau tikai katru nakti draugu tīklu pārģenerē. Mans necilais un nepieredzējušais viedoklis ir ka pamatā pārslodze rodas dēļ visām lietotāju bildēm kuru servēšana arī aizņem resursus. TCP SYN ir žutkaja svolač. Reizēm krietni lielāka kā viss pārējais kopā ņemts.

tak sadaliet db uz viena pc, image storage uz otra, web server uz treshaa... tieshaam neredzu vajadziibu peev 10GB servera, ja jau reaalaa bankaa ar 2500 online users un 10Gb DB darbs notiek normaali. bez tam veel ir iespeeja sho to optimizeet (par atsevishkju samaksu :))

pēc vakardienas sarunas ar Lauri varu izlikt aptuveni šādu situācijas ainu: MySQL atņirdzās jau krietnu laiku atpakaļ, kad tabulas updeiti un selecti to sāka vienkārši kaut nost. Šaurā vieta izrādījās tabula, kur tiek glabāti draugi. Tabulas struktūra, tipa id frend_id. Loģiski uz abiem indeksi. Attiecīgi atrast visus manus draugus varētu ar "SELECT * FROM tabula WHERE id=1" un draugu draugus ar "SELECT * FROM tabula AS tab_1 LEFT OUTER JOIN tabula AS tab_2 ON tab_1.frend_id=tab_2.id WHERE tab_1.id=1". Tā kā nekad neesmu strādājis ar tādu pieprasījumu daudzumu, tad nevaru spriest kāpēc tieši MySQLs sāka kārties un vai tur kaut ko varēja optimizēt. Varbūt pāreja uz PostreSQL būti pilnīgi pietiekams risinājums? Anyway, šībrīža risinājums ir tāds, ka šī relationsipu tabula tiek visu laiku glabāta atmiņā, un to "apsaimnieko" C skripts, kurš tad arī atgriež augstākminēto selectu ekvivalentu.

Manuprāt atteikties no sql db ir nepareizi, jo tās tieši tam (lielam, kārtojamam datu apjomam) arī ir domātas un tāpēc bija risinājums jāmeklē sql ietvaros. Varbūt slodzi sadalot pa vairākiem serveriem, varbūt kā savādāk...

Ņemot vērā, ka šeit apgrozās manuprāt ļoti gudri ļautiņi, varbūt jums ir kādas reālas un labas idejas hipotētiskam dotās problēmas risinājumam.

kam tas viss vajadziigs?

ps. "Error 400 Bad Request" //qouting draugiem.lv

karlis: ja šitie selekti ir tas kas karās... tad vaina varētu būt arī mysql. left join principā ir slikti un lēni (iespējams pat ka mysql neizmanto indeksus left joinam, bet nu par to neko negalvoju). ok tas pirmais selekts ir neko... neko labāk tur nevar, bet vot otram gan labāk izmantot inner.

un katrā ziņā varbūt labāk pamēģināt izmantot postgres. tas ļaus vaicājumus veikt daudz vairāk veidos, kas automātiski nozīmē labāku pielāgošanos konkrētai situācijai (tas tā - no pieredzes)

Citēju djuke: "left join principā ir slikti un lēni"

Ļoti interesants apgalvojums. Es to varu nedaudz papildināt - jebkādi join'i ir slikti un lēni, jebkādi pieprasījumi ir slikti un lēni, datu bāzes vispār ir sliktas un lēnas. Neko vairs neteikšu, jo tāpat jau visiem skaidrs, ka viss ir slikti un lēni :)) Sorry, bet manāskatījumā šāds apgalvojums līdzinās apgalvojumam, ka "saskaitīt ir lēni" vai "reizināt ir lēni" ...

Bet, kas attiecas uz MySQL problēmām draugiem.lv projekta ietvarā - pārāk daudz nezināmā, lai vispār kāds te izvirzītu risinājumus. Varbūt tur pieprasījumi viens otru nepārtraukti bloķē un tādēļ nekas nenotiek un vēl vesela kaudze ar iespējamām problēmām ...

shodien jau viss straadaa pavisam raiti, es pat aiz priekiem apraudaajos.. aatrums pavisam cic, kaut kas nerelaals - taadas izmainjas :)

gy

http://www.draugiem.lv/register/??

Bet pings tachu ir normaals. Attieciigi softs. nevis tiikls, bet grafs. manupraat dalju resurs norij taa funkcija kas paraada relationsips tipa:

Anna<=>Peeteriits<=>Anna2<=>Peeteriits2

Grafu teorija. Parmekleešanas algoritmi??? Rekursija? atteikšanās no DB.. nepareiza pieeja. Subjektiivi. Veelu veiksmi!

to draugi.lv klau virini runajot par dzelziem manam katorim krievijas biroja b2b systema online sez lidz pat 2000 videji 1200 biki pari vina laida pie tam tas viss uz windows .aps un ms sql kas replicejas ar rigas centralo ERP pa izdalitu liinujuun ziniet nekaras nekas un serveri ir divi ar sadu suda configu configu 5 Gb/2x1000XEON/ nu un diski SCSI nju nezinu liekas ka jums jamekle keks kas labak prot kodet dzelzi te nepricom. Es tas nesu varu tikai dzelzu jautajumos palidzet