hmnc

jasno jasno.

a jums tas SunFire ar 24TB atnāca vai atteicāties no tās domas? :)

nu a ja tajā pašā laikā viņam iet SELECTi?

aizdomīgi vispār.

man uz 3k ierakstiem inserti ar 3 fulltext un 1primary indexiem taisās ~6sec. dzelzis gan 2xOpteron

Roze - jūs tur noteikti visu pēc kārtas izmēģinājāt, kad developējāt, ne? :)

pietam tas izskatās pēc iveikala. tur vēlams ir palasīties kā pareizi taisīt parametru sistēmu, jo tas tiešām nav divus pirkstus .. :) ja jau ir tik ļoti liela vēlme meklēt pēc atsevišķiem parametriem.

es gan šoreiz sliecos uz konfiga kļūdām + db struktūras nepārdomātību.

pietam piemēram meklēt ar LIKE%% ir diezgan nu tāds tāds variants. vai nu jātaisa linkotā tabula (ja vienā laukā ir vairāki parametri, pēc kuriem var atlasīt) ar konkrētiem identifikatoriem, vai arī ja tiešām tur teksts jāmeklē tad taisi fulltext indeksēšanas tabulu, insertēšanas tabulu un ja nav nekas nenormāli steidzams tad šedūleris ar datu dublēšanu. vienkārši un saprotami un domājams daudz ātrāk

bet tas jau vecajiem FreeBSD. Maijā tika likta FBSD 6.1 relīze un viss ok :)

pamēģini uztaisīt aptuveni šādi: visi mp3 filename ir samesti iekš db ar id, paši faili paslēpti kkādā randomā direktorijā, un tad fails getmp3.php?id=666 izvada attiecīgo failu ar readfile visupirms protams norādot headerus un nočekojot autorizāciju. nu respektīvi playlistē būs nevis /mp3dir/artist_song1.mp3, bet gan getmp3.php?id=666/777/888/utt.

vienalga galā var izkost, no kurienes songi tiek spēlēti imho.

Roze - kāpēc domā, ka *BSD nav piemērots MySQL?

SkaKri - btw iznācis apdeits visiem tiem skriptiem, iečeko :)

vai arī vienkārši nav ko darīt :D a ja nav ko darīt tad es tev varu piedāvāt :)

andrisip manāmi audzē sev komentu skaitu. spamo visur kur vien var :)

nē nē es neko nesaku, vienkārši tāds novērojums

jopcik! jo rokas no pakaļas aug tad iztaisno viņas un pieliec tur kur viņas ir paredzētas. tas skripts iet un viss ir normāli. neba viņš tur tusējas tāds sūdains un neejošs!

šoreiz jau divi užavnieki no tevis!

Delfins: user right tool for the right job :)

protams, lapas var kodēt arī ar asembleru un servisus ar php, bet tas ir vajadzīgs? :)

tur jau tā fiška, ka php kods ir skripts nevis serviss vai vēl sazin kas - skripts izpildās no nultās līdz n-tajai rindiņai un viss. un defaultajos php settingos max runtaims ir 30sec, kas manuprāt ir jau diezgan daudz. galu galā webiskām lietām manuprāt uz servera ir jāizpildās krietni zem 1sec. ja izpildās stundu(!!!!) tad vajag domāt par lietām, ko jau es pieminēju agrāk.

un par demagoģiju - tas ir aptuveni tā, ka ja viens cilvēks brauc ar mašīnu visu laiku pirmajā pārnesumā nepārslēdzot augstāku, tad pieredzējušākie parādīs, ka ir jāpārslēdz nākamais pārnesums, bet andrisp parādīs ka pirmais pārnesums nemaz nav slikts un vēl mācīs gāzēt vairāk :) (nekas personisks andrisp :) )

vispār uztaisi print_r($_SERVER); atradīsi sev daudz noderīgas lietas :)

nu a kādus linkus tev vajag?

raksti iekšā kura lapa ir atvērta blakus hitiem un miers.

nu es pēdējā gada laikā atceros: elektrība (ja ļoti nemaldos tad 2x), nets (vismaz 4-5 reizes). vienreiz bija joks, ka negāja tikai LTC ip.. ar netu problēma parasti ilga 30min - 2h.

nēnu varbūt citur iet vēl trakāk, bet tad jau jāsāk domāt par vispārējo līmeni lv.zonas datu centros, jo manuprāt nav normāli, ka kaut kas pēkšņi nobrūk un neiet pāris stundas.

techsupportam gan visu cieņu - vienmēr atbild, vienmēr saka, kad aptuveni būs sataisīts (un arī ir), atzvana,.. galu galā sēž tajā pazemē - par to vien medaļa pienākas :)

nu es pats agrāk piestrādāju par sisadminu. apnika. nav priekš manis.

jebkuram vadītājam jābūt norūdītam, un jebkuram vadītājam jābūt radošam. stulbs stereotips - vadītājs nekad neko nedara. muļķības pēdējās! neizplūdīšu garos tekstos, pats noteikti to ļoti labi zini.

un es domāju ne jau vecāko adminu, kurš pieskata lielākos servus vai vēl nez ko lielāku dara, bet gan arī tā vecākā admina vadību. nu kkā tā.

JCE pagaidām ir tikai priekš Joomla.

bet nu pats jau labu laiku izmantoju TinyMCE.. ir oke. esmu jau pieradis daudz maz. fckeditors manuprāt lēnāks.

nu principā neviens tev palīdzēt nevarēs, kamēr nebūsi izstāstījis ko vēlies panākt ar to savu sistēmu un pēc kāda algoritma tas viss tagad strādā. man tas reāli izklausās pēc kreisas db struktūras + līkiem algoritmiem.

tev tur gadījumā nav inserts uz fulltext indexiem?! :)

paņem kādu brandname p2-p3, iemet ramu, ātru hdd un viss būs šokolādē :)

STUNDU?!

50k ierakstu tici man nav daudz. daudz ir 2`000`000 ierakstu 10 tabulās..

pārbaudi algoritmus + db struktūru (struktūru nevis indexiem) + padomā par kešošanu

viselementārākais veids, kā to pārbaudīt - visiem elementiem salikt paddingus un marginus 0px un tad pārbaudīt no kuras puses viņš sāk lažot.

visbiežāk tādi gļuki novērojami kad nav norādīts precīzs diva augstums

vispār pēc pieredzes - ja jātaisa kkādi hacki, workaroundi tad 95% gadījumos tas nozīmē, ka tehniskais risinājums līdz tam ir nepareizs.