Roze

No klāstera tā tiešajā izpratnē nav ne smakas :) un cīnamies aizvien.. Uz gada beigām plānots ap 120+- kastes un tad vēl nez kā būs.. Mums gan ir zināmi ierobežojumi.. es gribētu piemēram likt parastās (paškomplektētās kastes) gandrīz vai desktopus, bet diemžēl pagaidām nav īsti variantu (nav kur) un smejies vai raudi lielākā problēma ir elektrība.. ja teiksim datucentrā ir 47U skapis bet uz visu skapi ir tikai 2kW a mums serveris tādā ne īpaši aktīvā darbībā ēd 400+ W.. tad uz visu skapi max var ielikt 5 serverus :( utt utprojām.. Bet atbildod uz jautājumu nav īsti tāda pareizā ceļa.. Ir jāpieņem lēmums vai arī javadās no apstākļiem, proti ir kompānijas/iestādes kurās tu nemaz nedrīksti likt kaut kādus paškomplektētos dzelžus, bet jābūt obligāti ar 24/7 supportu utt.. Man teiksim pareizāk un izdevīgāk šķiet nopirkt divus lētus dzelžus un ja viens izrubās tad pofig lietojam otru nevis pirkt vienu uberdārgu dzelzi/servisu un tad cerēt ka nekas nenoplīsīs - plīst viss jo principā visu ražo ķīnieši tas pats IBM ir Lenovo (savulaik pirkām x306M no 10 dzelžiem 2 bija jāatgriež uz servisu labošanai UZREIZ) ;) Un tam pašam ibm supportam reizēm gadās visādas ķibele.. Par lētajiem dzelžīem kaut vai piemēru varu minēt viens IBM kaut kāds x3550 piem maksā ap 3000Ls.. pa tādu naudu tu vari nopirkt 8-10 desktopus analogās jaudās / protams papildus izmaksas ir uzturēšanā (ja to dari pats tad nekādas) / izvietošanā, taču tad tā kaste kaut vai viena mēnesī nosprāgst :) Protams ir svarīgi lietojumi kā DB kurus drošāk turēt uz "enterprise" līmeņa dzelžiem - tai pat laikā stabilitāti tikuntā var panākt arī letā gala aparatūru. Bet nu tā ja doma bija par brandname tad kā jau daži rakstīja IBM vai HP (pēdējais pasūtijums mums ir no HP jo iedeva labāku cenu nepieciešamajai aparatūrai :) )... teorētiski vēl cilvēki liek Dell un SuperMicro ir redzēti arī daži Intel serveri, arī Sun daži produkti (Sunfires) bija interesanti (it īpaši pirms IBM izlaida savu jauno sēriju).

Tad tam nav īsti nekāda sakara ar sociālo tīklu vai jebkuru citu konkrētu produktu, bet gan vienkārši kā veidot relācijas starp datiem un projektēt datu struktūras/db. Par to literatūras ir gana :)

Webā ir daži gatavi produkti.. var ņemt un pētīt tos. Taču ja gribas nopietni, tad diezvai kāds tā ar pilnu know-how dalīsies. Ir protams dažas jaukas prezentācijas man piemēram patīk LJ http://www.danga.com/words/2005_oscon/oscon-2005.pdf lai saprastu ka sociālais tīkls neaprobežojas ar php un mysql :)

Jā var.. Tam jaizmanto mod_proxy modulis (jabūt ielādētam arī proxy_http ) <VirtualHost *:80> ServerName kautkas.adrese.lv ProxyPass / http://127.0.0.1:5656/ ProxyPassReverse / http://127.0.0.1:5656/ </VirtualHost> Attiecīgi visi pieprasījumu uz konkrēto virtualhostu (kautkas.adrese.lv) tiks forwardēti uz tavu webserveri kas klausās uz 5656 porta..

Ja jau hostingu pierunāji tad jau tā ir viņu problēma ne tavējā ne tā? :) Bet uz linux slēgšanās pie MSSQL tiek nodrošināta ar FreeTDS http://www.freetds.org/ otra iespēja ir likt Sybase driveri

Vispār jau diezgan nejēdzīgs jautājums, jo php koderim (protams ja tas neaprobežojas ar dziļu backendu rakstīšanu) kā web-developerim ir jālieto (sanāk lietot) VISI daudz maz populārie pārlūki un to versijas.. proti IE6 IE7 FF 1.8 FF2.x Opera8 Opera9 un opcionāli ja vēl iespējams tad Safari.. Pretēji pēc pieredzes ir sanācis ka vot baksta koderim ar pirkstu vot shitas un tas nestrādā.. a izrādās cilvēks teiksi paskatījies tikai FF vai tikai IE.. Personīgi ikdienā izmantoju IE6 (ja tāds bija jautājuma mērķis).. porno lapas skatos ar FF :)

Jā nu mērķi jau nevar vainot, bet tad nevar uzstādīt, ka šis ir kāda konkrētu risinājumu benchmarks.. tik pat labi tad varētu ielikt: <? sleep(random(10,100)); // sheit kaut ko saakam benchot ?> un teikt ka konkrētais pļurzulis galīgi nerullē.. Proti lai kaut ko mērītu precīzi ir jāizolē pārējie ietekmējošie faktori, jo tikpat labi tev bottlenecks ir DB i/o (diski) nevis teiksim APC storage ;) ie kam benchmarks jaizpilda atkārtoti (jāveido cikls / jaiztīra keshi), jo izpildot to 1x nekādus ticamus rezultātus nevar iegūt. Nekas tāds nav piedzīvots.. sāku jūzot MMCache jau hvz kad (bija krietna labāka alternatīva kā Zend Optimizeris/Suite vai Ioncube cacheris). Varbūt vaina bija citur? :) Jo vieņīgā ķeska bija ar 64bit OS parādīšanos.. bet tur tikpat liela problēma ir/bija arī pašam php.

Ko nozīmē stabilāk? Ja produkts strādā normāli priekš kam izlaist jaunu versiju? Prieka pēc? :) APC reāli manuprāt lietojams palika tikai vai nu no 5.0.x vai pat 5.1.x versijas. Iepriekš varēja tikai problēmas rasties (īpaši brīžos kad uz webservera tika mainīti faili). Ņem vērā arī: http://pecl.php.net/bugs/bug.php?id=11988

turck mmcache šķiet jau ir kādus 3-4 gadus vecs produkts un manuprāt viņam vairs nav atbalsta 5.x (5.1/5.2 noteikti) php.. Projekts kas "forkojās" no mmcache ir eAccelerator http://eaccelerator.net/ Un tur nekas nav "jākompilē" bet bytecode cache glabājas shared memory.. ir protams iespēja arī keshot gatavu kontentu.

Domāju ka nē.. Paskaties kāds izskatās: <? $arr = array(1 => 'value', 2 => 'value'); ?> Un tad <? echo serialize($arr); ?> Tev kā jau Delfins rakstija atkrīt serializācijas vajadzība un datu apjoms būtiski nemainīsies jo serializējot krāmējas tāpat visāda (tips/garums utt) figņa klāt (ja ne vēl vairāk). Serializācijas pasākums atkritīs Memcache variantā kad tiks uztaisīts binary protokols..

MySQLs savu logu/sāpi raksta savā datadir... konkrēti tavā gadijumā varētu būt /var/lib/mysql/janhousebox.err

Šis ir nepareizi.. Tu nedrīksti testos mērīt / lietot citas lietas.. proti mysql_* te nedrīkst būt! Lai arī varbūt izpildās ātri tas NEBŪS apc_store vai memcache_set laiks bet gan laiks kur dati nāks no MySQL servera un tad setosies. Aiz kam MySQL var ieķerties (cache cleaning / citas lietas utt utt). Tāpat īsti korekti nav lietot http/webserveri šādam benchmarkam, lai arī protams reālās dzīves gadijumos http tur būs. Iesaku patestēt nevis ar -n 10 ... bet gan ar -n 10000 un lielāku concurency (nevis noklusēti ar 1) -c 10 -c 100 -c 1000 Iesākumā: ./ab -n 10000 -c 100 http://adrese Un iesaku testiem un realitātē izmantot mazākus masīvus/objektus nekā 1Mb.. MC gadijumā tas stipri iespaido ātrdarbību, proti pie katra requesta sanāk lasīt 1Mb caur tīklu. Pēc pieredzes sanāca ķēpa kad programmētājs bija tieši šādi izdomājis ka var glabāt lielāku objektu uz Memcache un sanāca utilizēt gandrīz 1 gigabitu kad sāka gļukot tīkla interfeiss :) Tas izskatijās apmēram šādi (mērvienības MBps - megabaiti sekundē) http://roze.lv/traffic.gif

Kaut kā izskatās neriktīgi tie tavi rezultāti.. Vari aprakstīt testa metodes vai iedot testa skriptu? Jo Memcache->get() principā nekad nevaidzētu pārsniegt 0.00x .. Jeb tie tev ir kādi 1000 geti? Loģiski vajadzētu būt ka lokālā APC storage ir visātrākā uz shared atmiņu.. (jāņem vērā ka ja testējot ar mazu konkurenci arī risinājums uz failiem varētu būt ātrs jo linux gadijumā faktiski konkrētie faili anyway būs ramā (pat speciāli neliekot uz ramdiska)). APC ar Memcachi īsti nevar salīdzināt, jo tie ir diezgan dažādi produkti kurus izmanto atšķirīgās situācijās. Otrs - nekad nevajag storēt 3500 ierakstus vienā variablī / vienā masīvā.. Sadali keshojamies objektus katru savā un izpildi multiget ar tiem elementiem kuri nepieciešami. Arī Memcache variantā dati tiek serializēti.. Drīzāk par pamatu var ņemt šos testus http://www.mysqlperformanceblog.com/2006/0...nce-comparison/ protams nav ļoti svaigi un pa šo laiku testējamie produktiem ir jau citas/jaunākas versijas, tad vietu sadalijums pēc ātrdarbības varētu būt identisks.. Ņemt verā arī komentārus pie katra no testējamajiem variantiem.

Nezini ko nozīmē '<g>' ? :)

Ir tak jau http://latviansonline.com/ http://www.latvians.com un superprojekts <g> http://www.latvija.lv ... nez nez ar ko tava iecere būs labāka?

A kur problēma viņiem aizrakstīt/uzzvanīt un pajautāt? :)

Nekā.. Pamēģini ierakstīt nepareizu hostu un/vai jūzeri un slēgties pie servera - paziņojums(i) būs pilnīgi cits(i) un tam nav nekāda sakara ar izstrādātāja 'bla bla' (ja šeit ir domāts MySQL developeri). 'Gone away' visbiežāk ir fatals errors uz MySQL kur kverija brīdī mysqls sakaras un nodropo klientu, taču tākā MySQLs parasti automātiski māk rekoverēties (restartēties) tad bieži vien uzreiz nav saprotams, kur ir problēma. Parasti paliidz paskatiities Error failu (hostname.err mysql direktorijaa) vai ieslēgt query logingu. Otra lieta ir MySQLs apzināti ir pārtraucis konekciju. Proti bieži vien produkcijas serverim ir krietni mazāks (vismaz es lieku) wait_time settings - laiks cik ilgi MySQL atstāj vaļā idlējošu konekciju. Piemēram wait_time = 10 (10 sekundes) var sanāk šādi: <? // Sleedzamies klaat mysql_connect(); // Daram kaut ko citu / gjenereejam 10+ sec mysql_query(); <- sheit buus Gone away ?> Šeit ir pilnīgāka visu gadijumu dokumentācija http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

A man patīk rules: http://webstudio.wen9.com/rulles_lv.html Īpaši otrais punkts - "2. saita veidotajam ir tiesibas pieprasit papildus maksu,ja vinsh ir jusu majaslapu uzlabojis un jums ta patik!" ... A ja nepatīk? :D Tad nemaksājam! Fair enough.. Un 4.-.5. punkti nemaz nav vajadzīgi.. ķeramies uzreiz pie 6. :)

Diezgan līks risinājums, jo tev pašam jāsaraksta tajā JS arrayā, kas ar kuru pilsētu cik tālu atrodas.. Un jo vairāk pilsētas jo lielāks pizdjec iestājas :) "The array of distances (the third level of the array structure) contains one entry for each location entry that precedes it in the top level array. These entries are the distances in kilometres between this location and each of the preceding locations (starting from the top of the array)." Pasties jau tagad: var dist = [ ['Paris',[]], ['Madrid',[1268]], ['Lisbon',[1786,638]], ['Milan',[850,1730,2368]], ['Rome',[1531,2099,2737,681]], ['Vienna',[1285,2617,3255,887,1168]], ['Munich',[827,1877,2515,551,969,458]], ['Amsterdam', [514,1782,2300,1154,1835,1196,876]] ]; Un padomā kas sanāks ja pieliksi vēl 10-20 pilsētas ;)

getcwd(); http://lv.php.net/manual/en/function.getcwd.php Turpat koimentāros ir arī alternatīva str_replace($_SERVER['SCRIPT_NAME'],'', $_SERVER['SCRIPT_FILENAME']); p.s. Val readdir() dara pavisam ko citu..

Kapēc nelogo atsevišķos failos?

Nu ja DB nav stiprā puse, manuprāt, tad vajadzēja tomēr sākt ar MySQLu vai PostgreSQL.. noklusēti webprojektiem u.c. figņām minētās DB būs krietni vienkāršākas / ātrākas utt.. (faktiski kaut lietas ar instant-clientu ir gājušas uz labo pusi man līdz šim nepatīk Oracle priekš web/php projektiem). Jo Oracle kā tāds ir baiss veidojums.. tur ir 100 un viena figņa kas jāzin.. tad Oraclim vēl nāk visādi savi keshoshanas mehānismi (ar domu biežāk accesojamie dati tiek bīdīti vienā vietā citi citur). Ja faktiski nav kāds zinoš DBA pie rokas tad ar Oracli var ilgi un dikti nomocīties un nekādā jēgā netikt.

Nav gluži viennozīmīgi.. uz MySQL atšķiras ātrums atkarībā no tabulas tipiem (MyISAM vs Inno) gan arī no countojamajiem laukiem: http://www.mysqlperformanceblog.com/2007/0...nt-vs-countcol/ Oracli (nevienu db) "uz aci" nemēra.. Oraclim ir kveriju izpildes profilings (execution plan) u.c. performances monitoringa iespējas.. Iesaku googlee pameklēt oracle+autotrace piem http://www.oracle-base.com/articles/8i/ExplainPlanUsage.php Šādi biku nenopietni izskatās..

Bija forcēti izslēgts..

GROUP BY vietā lieto ORDER BY eg .. SELECT * FROM `rekordi` ORDER BY punkti ASC Limit 100