Roze

Nu kapēc nav? Ir .. SCSI jebšu tagad SAS (Serial Attached SCSI) vienkārši ir ātrāki diski. Tos parasti izmanto sistēmās kur nepieciešama liels IO operāciju skaits (tālāk jau teiksim ir arī optiskie diskie ar fiber channel slēgumu) utt.. Tas vai ir vai nav raid kontrolieris nepieciešams vairāk atkarīgs no konkrēta risinājuma/modeļa ko tu izvēlies, jo bez hardwariska raida ir iespējams arī softisks (uz Linux md raid ). Daži ražotāji vispār propagandē ka hardware controlieri nav vajadzīgi kā suga - piemēram Sun ar savu OpenSolaris un ZFS uz SunFire x4500 (Thumper)... 48 diski serverim a konroliera nekāda.. viss tiek darīts caur failsistēmu. Proti - ir gan labi hardware kontrolieri gan slikti :) Šādu statistiku neviens tev nevar iedot.. Ir protams visādi teorētiskie skaitļi un % cik no rūpnīcas atnāk brāķi utt no otras puses daudz kas atkarīgs arī no vides kur iekārta stāv... Ja mājā zem galda kur ar pirkstu var izvilkt putekļu kārtā vagu tad varbūtība ka kaut kas nosvils ir liela.. Ja normālā DC pie normāla temperatūras ar gaisa filtrēšanu (kur arī pēc 3 gadiem kastē nava nekādu sūdu) tad var stāvēt diezgan ilgi. No praktiskās puses tiek uzskatīts ka var nobrukt (un kādreiz noteikti nobrukss) VISS... sākot no cietā diska un beidzot ar Latvenergo elektrības vadu mājai.. Līdz ar to cilvēki ir izdomājuši vienkāršu risinājumu - visu vismaz vienu reizi duplicēt. 1. Divi diski - Raid 1, xxx 2. Divi procesori 3. Divi elektrības barokļi 4. Divi tīkla interfeisi 5. Divi serveri 6. Divi datucentri 7. Divi administratori (ja nu viens aizdzeras) utt utt

Nu šis ir gaužām maldīgs priekštats un ieteikums.. Sistēma ir tik caura vai droša cik par to nezin vai zin tās uzturētājs. Ja liekas ka tagad naturāli uzliks kādu no BSD un viss būs labi tad tas ir nepareizi. No kura laika tad tīri grafiskas sistēmas attālināti uzturēt ir visvieglāk? Par SSD varēs sākt domāt kad parādīsies serveru līnija (piem no ibm/intel vai hp) pagaidām tā ir tikai tāda desktopu tehnoloģija jo SSD nobrukuma procents ir diezgan augsts.. attiecīgi uz tiem var mēģināt izvietot datus kam nepieciešama ātra piekļuve bet nopietni jādomā par redundanci (piemēram variants par ko domājam ir MySQL sleivs uz SSD diskiem). Viss process ir tik dārgs cik dārgu tu to pats iedomājies un uztaisi.. Proti serveri (os/aplikācijas/produkts) var uzlikt gan uz 50 gan 500 gan 5000 LVL vērta dzelža.. Un reizēm standarta situācijās (ja visu puslīdz pareizi izdara) 50 lvl variants nearko īpaši neatšķiras no 5000... Atšķirības sāk manīt tikai paaugstinātas noslodzes un specifiskos gadijumos.

Nejauc Paypalu ar banku/kredītiestādi.. Paypals nevienam naudu neaizdod līdz ar to viņam nav nekādu teorētisku iztrūkumu/mīnusu ja pēķšni visi klienti izņemtu savus līdzekļus skaidrā naudā (faktiski noklusēti transakcija tev automātiski var iekrist uzreiz uz bankas kontu (bez speciāla withdraw)). Tā ir tikai norēķinu sistēma kura pelna uz tranzakcijām..

Paypals nu nepakam nesāks vaidēt.. par katru transakciju viņiem atlec šāre..

Tas ir slikti bet var taisīt ar http://lv.php.net/eval

Ar ko tad 12 pieprasījumi sanāk optimālāki? Bez tam selectējot pēc lauka uz kura drošvien nav indeksa - kas nozīmē ka tabulai jābrauc cauri 12 reizes anyway ... :)

Nu uztaisi teiksim failinju bans.txt kur katraa rindinjaa ir ierakstiits kas tiek banots: ban.txt: ADS nKeen gumijotais Un tad lbans.php sākumā pieliec: <? $banoti = file('ban.txt'); Tālāk kodā jau viss tas pats kas tev jau ir.. Tas arī viss.. Ja tev failā tie rakstās kaut kā savādāk (atdalot ar komatu vai piemēram | ) var izmantot explode() http://lv.php.net/explode funkciju lai sadalītu pa masīva elementiem.

Šis gan sanāks neoptimizēts kverijs (un ja es saprotu tabulas struktūru) un uz lielu tabulu būtu jātaisa savādāk bet nu principā: SELECT DATE_FORMAT(datums,'%Y-%m') AS dat, COUNT(*), SUM(apmekletaji), SUM(pirkumi) FROM info GROUP BY dat;

Nē tā nav injekcija.. Ar injekciju pēc būtības nevar (nevajadzētu) varēt koruptēt tabulas kā tādas, jo injekcija ir vienkārši nesnakcionēta SQL izpilde - vai nu tas ir DELETE, DROP vai SELECT visi dati utt.. Marked as crashed var rasties (it īpaši uz windozēm ja vēl tā ir mājas kaste) tad ja nekorekti serveris tiek restartēts MySqlam korekti nenoflushojot/neaizverot tabulu u.c. tīri fiziskas figņas..

Tāpēc ka uzdotie jautājumi ir līki - reti kurš atbildēs uz "iedodiet!" (visdrīzāk pasūtīs uz googli vai piem hotscripts), šis forums ir vairāk domāts lai atbildētu uz jautājumiem "Kā un Kāpēc?" Bez tam, kapēc tad nepanāc cilvēkam pretī?

"In use" - ir tikai phpma definīcija.. faktiski tabula ir "marked as crashed" Teorētiski tam nekad nevajadzētu notikt (no MySQL skatu viedokļa), bet praktiski (visbiežāk ar MyISAMi) tabulām ik pa laikam (it sevišķi ja seko mysql changelogam) ir dažādi crash scenāriji .. Logs kas tev būtu jāskatās ir MySQL error logs un nevis apaches (parasti hostname.err mysql direktorijā). p.s. "jūzeri man ir daudz" <- teorētiski šo to vajadzētu zināt par servisiem kurus tu darbini :)

Nekorekts salīdzinājums - ja tu tik ļoti gribi par automašīnām tad piemērs varētu būt tāds vai braukt ar traktoru, mazu bulku vāģi vai piena cisternu.. Mehāniķi ("kvalitatīvo resursu iznomātāji") visus auto var labot vienādi ar kuvaldu taču tev kā aplikācijas izstrādātājam tomer ir svarīgi kas tur apakšā ir.. Bet ja nav svarīgi (der standarts) tad arī PS3 noteikti nevajag.. Jo es no sākotnējā posta sapratu ka cilvēks vēlas eksperimentu - izspiest vairāk izmantojot nestandarta (jaunas) tehnoloģijas aka GPU / Grid Computing utt (aka ir cilvēki kas taisa clusterus uz xboxiem, apple tv utt).. Ja viss aprobežojas ar pliku weblapas izvietošanu tad tā vairs galīgi nav interesanta diskusija jo atkarībā no maka biezuma visu mierīgi var palaist arī uz desktopa pa 50LVL.. ()*#&$(*# 10k dienā ir kas? Hiti, pageviewi, useri paralēli onlainā? Parasts desktops uz parastu aplikāciju velk krietni vairāk.. tur kaut kāds standarta apache benchormakojot piem phpma ganjauka var 300 req/sec izspiest... kas ir dienaa skaitlis ar 7-8 cipariem (ja loads ir permanents)..

SELECT * FROM tabula GROUP BY parent_id vs SELECT DISTINCT parent_id FROM tabula

Šis ieteikums ir galīgi ārpus konteksta.. runa iet par platformu - attiecīgi tu jau protams vari rakstīt zoftu kas iet visur no otras puses gala implementācija būs galīgi šķērma (lai piedod man Javas evangēlisti).

Redz atbildot uz šo un arī sākotnēja posta autora ideju - faktiski ieguvumu nebūs nekādu. Jo visās DB sistēmās šaurais gals (bottleneck) ir disku sistēma un nevis CPU.. CPU lielākoties dzīvojas tikai gaidot uz datiem (IOwait), līdz ar to praktiski šādu clusteri var darbīnāt tikai tad ja tam pieslēdz jaudīgu storagu (aka fiber/optical hdd) vai arī pavairāk ramu kur visus datus sabakāt apstrādei.. Ja tiešām gribās CPU jaudu ir nedaudz vienkāršāks risinājums imho ir no nVidias ( http://www.nvidia.com/object/tesla_computing_solutions.html ) izmantot viņu GPU (var sākot pat uz parastajām 88xx geforcēm ) un Cudu ( http://www.nvidia.com/object/cuda_home.html ) , problema gan ir salīdzinoši mazais ram apjoms (1+Gb parastajām pci kartētm tikai) kas zināmā mērā liedz fiksi piegādāt paliela apjoma datus.. sistēmas atmiņas izmantošana akal ir zināma ķeska. Bet es pieņemu ka nvidia domā par to.

Kapēc tu domā ka visi izmanto dns.parks.lv? Šaubos vai kādam ISPam tas vispār ir kā viens no opcionālajiem neimserveriem.. Šaubos vai kāds šī portāla lietotājs to izmanto :)

Danke.

Redz nav jau jāveic 100% servera investīcija, proti tev uzreiz tas dzelzis nav jānopērk - ir dāžādi līzingošanas veidi, ko pat paši datucenti piedāvā.. Un ja tev bagāžā ir pāris klienti tad to mēnešmaksājumu nosegt nav nekas traģisks.Ir arī tā saucāmā lētā gala pieeja - nevis pirkt vienu jaudīgu brand-name dzelzi (kur tu maksā par nosaukumu un kurš tāpat var noplīst), bet teiksim 2vas parastas saķīlētas kastes (kautvai desktopus) bet turēt tos mirorā (gan db gan content utt) vai nu aktīvā vai pasīvā (te protams atkal priekšnosacījums ir zināt kā softiski to panāk).. VS pakalpojums parasti ietver sevī fīču ka jaudu iespējams palielināt tik daudz cik tas tev nepieciešams t.i. parasti šādi risinājumi balstās uz klāsterī saslēgtiem dzelžiem (t.i. vairāki atsevišķi serveri kopā) un pa vidu ir papildus slānis (Xen, VMWare u.c.) kas nodrošina virtuālu serveru izveidi un virtuālajam serverim tiek piešķirtas kaut kādas jaudas (kas var būt salīmētas kopā no vairākiem fiziskiem dzelžiem). Bet faktiski šādu vadlīniju nav.. Universālākais parametrs varētu būt vienīgi "lietotāji onlainā" jebšu cilvēki/konekcijas kas konkrētā brīdī apskata tavu lapu.. Ja runa iet par parastām kontantinformācijas mājaslapelēm tad šādus saitus var sakarināt diezgan daudz (100+...). Tai pašā laikā var būt viens saits kurā teiksim glabājas liela izmēra faili (pdf/video) un tas viens pats aizsit minētos 25Gb.. Līdz ar to parasti dara tā - uzliek / palaiž un tad skatās vai pietiek jaudas vai nē.. Tas ir tīri individuāli .. var būt gan tā gan tā. Proti noklusēti hostinga administratori atbild par zemāko līmeni - t.i. dzelžiem / pieslēgumu un OS kas darbina virtualizāciju.. Tas vai viņi maisās pa tavu virtuālo OS jau ir līguma jautājums :)

Šis ir visai stiepjams jēdziens, proti, nekad nevaig par zemu vērtēt "prasmīgu" programmētāju "prasmīgi" uzrakstītus SQL pieprasījumus un loģiku... t.i. nav nācies redzēt nevienu serveri/tehnoloģiju kas būtu no tā pasargāti :) Bet ja nopietni, tad, ja pietiek saprašana un zināšanas (vai arī ir resursi, lai kādu piesaistītu) un ja nav pārliecības par publisko (mas)hostingu virtuālajiem administratoriem, iespējams vajag padomāt vai nu par sava dedicated servera izvietošanu datucentrā vai vienkārši virtuālo serveru jaudu īri (cik zinu deac, dig un varbūt vēl kāds piedavā). Attiecīgi visus noteikumi un fīčas (kādas webserver/php/db utt versijas) paliek tavā ziņā.. Jo vairāk klientus dabū un uzliec uz savas kastes jo lielāka atdeve..

Nu kā to ņem .. "šortkati" parasti atsaucas uz kaut ko kas ir "strikts" .. un ja šis striktais vairs neeksistē tad jau ir BC problēmas.. Protams, kā katrs raksta un kādu stilu piekopj ir katra paša ziņā, taču, manuprāt, short tagu un echo valodas "konstrukcijai" šāda šortkata izmantošana ir diezgan parocīga.. It īpaši dažādās template sistēmās un MVC aiztājot dinamisko datu izvadu vietas ar <html><?=$var?></html> .. bet baidīt cilvēkus ar to ka kaut kas pēkšņi neies vai tas ir nepareizi no valodas/sintakses viedokļa imho ir nepareizi, jo ne php developeri ne hostingotāji negrib problēmas ar lietotāju masām kam tas šķiet ok.

Tas ko es jautāju faktiski ir nevis vai ir vai nav pieminēts, bet pāris (neņemot vērā <?xml figņu) iemeslus 'KĀPĒC' (un nopietnā literatūrā parasti tiek paskaidrots kamdēļ tā un ne šitā .. pie kam tiek apskatītas vairākas iespējas (par un pret)), un vēlos dzirdēt no tiem kas tik kvēli aizstāv vienu vai otru viedokli balstoties tikai uz faktu "viena tante teica (eg kaut kur bija rakstīts)" :) Tikpat labi es, piemēram, varu teikt ka kaudzē "dokumentāciju" ir teikts ka <? echo 'blabla'; ?> ir "labāk" nekā <? echo "blabla"; ?> lai gan praktiski tas ir sens mīts un vairs nav taisnība..

.. tad jautājums ko nozīmē "vislabāk"? Hostings: 1. Tāds kur ir vislētāk? 2. Tāds kur ir visresnākā truba? 3. Tāds kur visiem ir pofig ja savāda sūdus ar anonīmiem prokšiem tā lai gailis pakaļ nedzied? Īsti nesaprotu kamdēļ ko tādu vaig..

Var kādu atsauci/referenci dabūt uz tām "nopietnajām dokumentācijām un rekomendācijām" ? A to, piedodiet man, tāda tukša tiršana izskatās..

Kas lūdzu ir "php web proxy"? Proxy sarakstīts iekš php vai kas?

Programmai/meklētājam ir pilnīgi vienalga kādi objekti (vai tie būtu ekskluzīvas preces, kuras nevar nopirkt veikalos, vai lietotas zobu birstes/auto) ir datubāzē - jasaprot ka ir tikai saikne starp kaut kādu keywordu un piesietiem datiem (url, bilde, txt utt). Ja meklē cilvēku, kas palīdzēs tehniski, šeit ir pieņemts runāt arī par projekta budžetu (arī, ja tāda nav - un pasākums tīri uz entuziasmu balstīts), jo visiem "tehniskajiem" cilvēkiem vairāk vai mazāk ikdienā ir ko darīt pašiem, taču atkarībā no projekta un tam izdalītajiem resursiem kāds var pieteikties :)