Roze

main.php: <a href="vote.php?id=1">Vote 1</a> <a href="vote.php?id=2">Vote 2</a> vote.php: <? /* UPDATE SQL where $_GET['id'] .. */ header("Location: /main.php"); ?> http://lv.php.net/header

Nu tad dari to ar http://lv.php.net/rename nevis ar imagejpeg() :)

Nu teorētiski jā.. proti liec bildes iekš fiksēta platuma 100px containeriem (<div> piem) un tad taisi dizainu ka pie 400px tas wrapojas jaunā rindā. No otras puses to vienkāršāk ir uztaisīt no php puses skaitot līdz 4 :)

Vienīgais kam varbūt varētu piesieties ir kāpēc tu pārseivo arī lielo bildi ja tu to nemaz neresaizo? If (false !== ($m = imagejpeg($img_old,'bildes/'.$gal.'/large/'.$file)))//save lielo { echo "normal img saved | <br>"; }

A1: Skripta maksimālais izpildes laiks (jebšu precīzāk paziņojums par tā pārsniegšanu). A2: php.ini max_execution_time = 30 jauzliek lielāks (apache pēc tam jānorestartē) A3: lapas sākumā ini_set('max_execution_time',60); vai set_time_limit(60) piemēram A4: Pavirši paskatoties likās ok..

http://api.drupal.org/api/HEAD/file/develo...topics/oop.html

Taisni otrādi.. šie punkti bija domāti pirms grūšanas atmiņā u.c. izvirtībām pārbaudīt standarta lietas - proti pārbaudīt vai paši kveriji ir normāli, vai ir korekta DB servera konfigurācija. Starp citu ja jums izmantojas sesijas standarta variantā (datu nesējs ir faili) tad nebūs starpība jo sesijas dati tiks tikuntā rakstīti un lasīti no diska (ja vienīgi kā sesijas save path nenorāda ramdisku).

Nu ņem lasi http://news.php.net/group.php?group=php.evangelism vai http://news.php.net/group.php?group=php.internals

Nereāli? Tak DVD pļekas tikai 5-6 gabalus vaig :) Pie kam tagad HDD līdz kādiem 300Gb ar lēti.. Nu ja iepriekš strādāja normāli, pamēģini diseiblot iebūvēto firewallu u.c. bija tur arī kaut kādi TCP limiti tikai nezinu vai pēdējiem updeitiem tur bija kaut kāds jēdzīgs veids kā tos limitus mainīt.

Paofftopikojot nedaudz.. a bez OOP nekādīgi (pārliecība vienkārši neļauj)? :)

1. Izlaist visus SELECT kverijus caur EXPLAIN (tb EXPLAIN SELECT ....) paskatīties vai vai nekur neparādas 'filesort' un no tā tikt vaļā par visu cenu. Vai visus gadijumos tiek izmantoti pareizie indexi uz WHERE nosacijuma laukiem (reizēm MySQL neprot izmantot indeksu pat ja tabulai konkrētajam laukam tas ir uzlikts) iebarot vinjam tos ar FORCE INDEX 2. skatīties vai nosacijumos nav OR 'id = 1 OR id = 2' izpildaas kudish ilgaak nekaa SELECT * .. WHERE id = 1 UNION SELECT * WHERE id = 2 3. ja tabulaam notiek selects ar lauks1=1 AND lauks2=2 tad taisīt apvienotu indeksu uz abiem laukiem.. 4. Paskatīties vai MySQLam ir ieslēgts query cache (vai tas ir pietiekami liels / vai ir normāls hitrate). 5. Izdomāt kuru no db enginēm izmantot: MyISAM ja ir daudz SELECti, bet samērā maz konkurenti INSERTi/UPDEiti, InnoDB ja ir daudz konkurentu gan selectu gan insertu. Pretēji ķeska ar lockošanos. 6. Izmantot eksternālu keshingu piem Memcached. Ko nozīmē "pie daudz cilvēkiem"? Linux pēc idejas praktiski vienmēr izmanto visu pieejamo atmiņu lai atvieglotu IO operācijas (proti failu keshings atmiņā), problēma reizēm rodas tajā ka kernelis vai konkrētais daemons sapinas meistarībā (balstoties uz sistēmas parametriem) un taupa vai tieši pretēji par daudz atmiņas izdala vienai vai otrai lietai. Kas attiecas konkrēti uz MySQLu tad katrai konekcijai viņš izdala sort / key un hvz vēl kādus buferus ( formula apmēram šāda: MySQL memory = key_buffer + max_connections * (join_buffer + record_buffer + sort_buffer + thread_stack + tmp_table_size) ) līdz ar to jāizvērtē kā rīkoties.. Var mēģināt izmantot persistantas konekcijas un teorētiski rejūzot iepriekšējās konekcijas (lai katreiz nav jāizdala un jāatbrīvo atmiņa), taču no otras puses ja persistantas konekcijas sarodas pa daudz tas beidzas ar to ka atmiņa vairs nepietiek nekam.. Bet vispār ja tas ir liels projekts tad vajag skatīties uz vairākiem DB serveriem (Master/Slave vai vienkārši contenta dalīšanu) vai kādu cluster risinājumu, jo vienam serverim tomēr ir zināmas robežas. Šeit arī divi vienkārši varianti.. Ja tabulas samērā mazas bet aktīvi lietotas tad der MySQL cluster. Ja datu daudz un tie nav satilpināmi atmiņā, tad jādala saturs vai jāsadala loģika: 1) Uzliekam vienu Master serveri caur kuru iet tikai INSERT/UPDATE/DELETE un piemēram divus Slave serverus kuri datus sihronizē no Master un nodarbojas tikai ar SELECTiem.. 2) Var dalīt arī pašu saturu, piemēram lietotāji ar pāra identifikatoriem glabājas uz viena servera, lietotāji ar nepāra uz otra.

Nu ja neatradi, tad pieliec.. Bet vispār tā šķiet kaut kāda windozes related problēma.. vismaz cik sapratu vaina tiek novelta uz kaut kādiem Firewalliem utt figņām.. Tākā ja ir apnicis jāties. iesaku visu (CS, webserveri, mysql) pārlikt uz kāda linexa ;)

speed, meamleaks ;)

Pēc: http://issues.apache.org/bugzilla/show_bug...?id=21425 parovē konfigā ielikt: EnableSendfile Off EnableMMAP Off Win32DisableAcceptEx

A jēga? Ja ir http://lv.php.net/manual/en/ref.pdo.php

Kā saprast tikai workstacijām? Standarta sterveri nāk 2 x hdd un neko citu kā raid0 tur parasti neliek.. standarta risinājumam raid0 arī ir pilnīgi pietiekami 2xread un 1xwrite diska performance.Raid5 ir kaut kas pa vidu (pie kam manuprāt diezgan sarežģīti restorējams) tad tālāk jau liek raid10 vai raid0+1 - t.i straipotus mirorus vai mirorētus straipus :) Šitais neiet cauri.. pretēji ja vienīgais tu arī pērc tur no tiem ne-Latvijas kantoriem, savādāk jārēķinās ka cenas USD ir tas pats kas pie mums LVL :)

Nu pag mums te figurē kaut kādas šitādas cenas (laikam gan bez pvna :( ): eServer x346 2X3.0GHzXeon , 4X512MB, 2XIBM 36.4GB 15K U320 SCSI HS, DVD ROM 8x-24x, 625W p/s,Rack - 1823.95 Ls eServer x346 2X3.0GHzXeon , 4X512MB, 3XIBM 73.4GB 15K U320 SCSI HS, DVD ROM 8x-24x, 625W p/s,Rack - 1979.51 Ls aiz kam 15k rpm diskus var aizstāt ar 10k rpmiem atmiņu iemazināt uz 1Gb un tad jau pavisam ok cena sanāk.. Var neņemt Xeonus bet parastos P4 kas cenā viens pats jau sastāda 300-400 Ls..

Nu tie kas nehostējas Kaimanu salās tiek ņemti jau lēnām priekšā.. spilgts piemērs SuprNova :)

Protams, bet risinājumi jau nebalstās tikai uz praksi bet gan teoriju, Proti piemēram pēc prakses (un principā arī pēc teorijas tur ir hvz cik darbības stundu garantija) HDD ar var iet 10 gadus.. Bet kapēc taisa mirorus/raidus? Tāpēc ka pēc teorijas hdd var nodegt arī pēc pāris minūtēm/stundām vai kaut kādā brīdī .. ;) Tas nozīmē ka nav failsafe/redundant līdz ar to "not for enterprise", bet tas nu tā..

Vispār jau var gan bet tad jāoperē ar atmiņu, ja gribās tikai php-only variantu tad http://lv.php.net/shmop Ja ir vēlme ka atmiņu menedžē kāds cits serviss (kas teorētiski ir drošāk) tad http://lv.php.net/memcache

Nu īsumā tā ideja ir tāda ka AMD arhitektūra balstās uz to ka viens cpu itkā ir priekš ielādes otrs operācijām (tā aptuveni izsakoties) kas principā labi darbinās (pretēji līdz šim Intel Netburst tehnoloģijai kas sarijas operacijas un nevar pats izpildīt), bet ja intel gadijumā ja viens cpu aiziet pa pieskari/sagurst tad serveris spēj darboties tālāk arī ar vienu cpu, bet amd gadijumā sākas gļuki.. tāda ir tā ideja par Enterprise pēc IBM cilvēka teiktā.. lai arī viņiem ir gan inteļa, gan amd gan ppc serveru līnijas "karogu pagaidām vicina ka "amd nav ready vēl"" un kaut kas normāls būs tikai ar nākošo paaudzi.. p.s. raid5 nesanāk lieks overheds no price/performance viedokļa? pie tam manuprāt sarežģiti atjaunot failures gadijumā.. vienkāršāk, ja nav baigas prasības, taisīt tak parastu miroru

Opteroni nav Enteprise ready (sīkumos neiegrimstot) tāda piemēram vismaz ir officiāla IBM nostāja.. ja tu gribi argumentus :) tas ko tex_the_dexter tur raksta varbūt kādam noder bet 99% LV variantā nē jo: 1) tā ir arzemju truba - tas nozīmē ka visus potenciālos mdsl/pdsl u.c. un principā arī daudzis citus subprovaideru klientus var pa dienu norakstīt jo ātruma nekāda 2) tā vāvuļošana par Ameriku tāda smieklīga sanāk.. nu ok ņemam tos 2 vai 6 USD/mēnesi.. tagad kaut kādus rebate 300Gb hdd maksā ap 80USD .. uzsēdinam uz viena HDD tur 10-20 vai 100 (attiecīgi ar mazāk speisu) lietotājus iedodam katram pa 10Gb .. saštopējam uz viena servera šitādus pāris diskus un mums virtuāls speiss pat līdz pāris tūkstošiem lietotāju.. un tad parēķini cik ilgā (ātrā) laikā visa HW jau ir nopirkta un sāk atmaksāties. LV variantā nav to tūkstošu lietotāju/projektu līdz ar to ķēpāties ar kaut kādiem sīkiem juzeriem kuriem paratsi ir lielas prasības neatmaksājas.. Ja pirmajai teikuma daļai var piekrist (piezīmējot masshostings) tad otrā ir pilnīgs bullshits. Mainframes un Blade centri ir pietiekami, kā arī specīalistu ir diezgan daudz.. protams ir slikta tendence viņiem ar laiku emigrēt uz citurieni..

Krimināllietu var piesiet abos gadijumos.. Starpība ir tikai tajā cik liela vēlme konkrētā gadijumā ir konkrētās vides turētājam / veidotājam.

A ko rāda? SELECT * FROM NLS_SESSION_PARAMETERS; Tb vai tiešām ir iesetojies? Es gan priekš LV lietoju Latvian_Latvia.BLT8CP921

Izmantojam dr.lv izvilkums no viena www frontenda: Uptime 71 days 3 hours 31 min 26 s Started at 2006-01-09 08:11:48 absolute (since start) Requests 1 Greq Traffic 6.34 Tbyte average (since start) Requests 245 req/s Traffic 1.08 Mbyte/s average (5s sliding average) Requests 396 req/s Traffic 2.23 Mbyte/s Supportē visu.. rewrite/conditional configu/mass hostingu/SSL utt utjprojām Ar ko ir labāks par apache: 1) Serveris ir single-process / multi-thread (ir jau protams arī apaches moduļi tādi bet uz tiem korekti īsti neiet php) un php darbināms FastCGI modē Kas nozīmē ka pie katras konekcijas nekāds jauns child netiek spawnots kā to dara Apache ar savu prefork kas nozīmē ka pie lielas noslodzes ļoti tiek taupīti servera resursi. 2) Tākā php darbojas fastcgi modē (proti vienmēr darbojas noteikts procesu skaits) tad ļoti efektīvi var izmantot persistantās konekcijas (uz db vai citiem resursiem). Apache diemžēl nestāv ne tuvu jaudas ziņā :) Apache is a general-purpose webserver, designed to provide a balance of flexibility, portability, and "only then" performance. ..