Roze

Protams ka ir (tikai nejaukt ar CGI tur ir nedaudz cits princips, proti failā tiek norādīts ka fails darbinām caur kādu executabli, bet Fastcgi ir permanenti procesi kuriem caur unix socketiem vai specifisku portu uz kuru klausās process tiek padota source un saņemta atbilde). Kompilējam php ar mums vajadzīgajiem parametriem tikai pieliekam klāt arī --enable-fastcgi. Tad tiks uzmeikots arī sapi/cgi/php executablis kuru tad teiksim iekopējam kaut kur iekš sistēmas ( es piem /usr/local/bin/php.fcgi - php.fcgi tapēc lai nekonfliktē ar php CLI executabli) Un tad jau konfigurējam webserveri. Lai gan uz apache ar mod_fatscgi varētu nebūt nekādi ļoti būtisku uzlabojumi pret apache+php kā modulis, tad uz sīkajiem threading serveriem (lighttpd, litespeed (iespējas ir škiet arī Boa un hydra)) iet zvērā. Arī lielākie monstri kā Zeus php darbina tikai šādā veidā. Priekšrocības gan ir tādas ka tākā php nav pilnībā thread-safe tad ja kompilē kā moduli lielākoties jāizmanto prefork (protams cik mēģināju iet arī ar worker un php ar zend-experimental-thread-safety taču performance pēc maniem testiem ir sudīgāka (requesti/sekundē))), tad FastCGI modē var experimentēt ar Apache2 dažādajiem threading moduļiem līdz nelabumam un tas nekādīgi neietekmē php darbību, kā arī otrādi lai darbinātu php 100 php procesiem nevajag 100 apaches procesus.

A kapēc IP range tiek likts vienā laukā? Liec sākumu un beigas divos dažādos tad varēsi meklēt arī pa vidu teiksim sakums | beigas 192.168.001.002 | 192.168.001.007 un tad where sakums >= '192.168.001.006' and beigas <= '192.168.001.006'

no-no! nenostrādās ja kāds no pārpalikušiem ir NOT NULL, VALUES() ir tas prasīgais 17924[/snapback] Tas tā ir, es vienkārši uzreiz nepamaniju ka $set tiek veidots šādi $set[]='`m'.$i."`='".mysql_escape($_GLOBALS['m'.$i])."'"; līdz ar to arī pēcāk palaboju savu komentāru :) Protams ja būtu tikai values tad apgalvojums paliek spēkā.

mysql_query() nemet nekādus erorus (funkcija pati atgriež tikai true vai false), lai redzētu ko mysql atgriež pēc kverija pēc mysql_query() uztaisi echo mysql_error(); tad redzēsi ar ko DB servers ir neapmierināts. Otrs vizuālam debugam vienmēr der ja kverijs nestrādā izvadīt viņu echo "INSERT INTO tabla_1 SET ".implode(',',$set);

Protams ka var. īsumā izvelkot no dažām mūsu funkcijām izmantojam šitādu .. function resize(ifram){ try{ var oFrame = document.all(ifram); var oBody = ifreims.document.body; if((oBody.scrollHeight + (oBody.offsetHeight - oBody.clientHeight))>0){ oFrame.style.height = oBody.scrollHeight + (oBody.offsetHeight - oBody.clientHeight); } } } Domāju ka sapratīsi un samainīsi savām vajadzībām :) Bet teorētiski varbūt vienkāršāk un no browsera neatkarīgāk ir lādēt contentu ar xmlhttp un innerHTML ieksh diva

Nu a kam tev webam tiff bildes? jpeg/png/gif viss ko vajag :) Sliktākajā gadijumā ja nu tiešām vajag to visu - tad var taisīt ka imagemagicks tiek darbināts tikai ja bildi nevar apstrādāt ar GD un būsi anyway ieguvējs.

Imagemagicks jau pēc idejas ir lēns un ļoti resursrijīgs. To kādreiz izmantoji tikai tamdēl ka GD 1.x nespēja visai kvalitatīvi resaizot bildes/fotogrāfijas. Taču GD 2.x (kas tagad nāk līdzi arī php piekam ar atjaunoptu gif atbalstu) jau ir ļoti okej un vajag izmantot to. exec() nav visai droši un otrāmkārtām kā jau minēju ir drausmīgi lēnu.

Tā ir. Pēc laika vienībām: Inserting indexes: (1 x number of indexes) http://dev.mysql.com/doc/mysql/en/insert-speed.html Jā protams vienā db var būt dažādi tabulu tipi, taču tur atkal jāskatās jo tākā myisam un innodb kaut vai datu glabāšanas principi atšķiras tad ir zināma administratīva ķeska kā arī papildus resursi no servera - proti innodb enginei papildus jāizdala savi memory pooli utt Tas bija tikai tāds piemērs. Ja iepērk no supportēta kantora (šajā gadijumā IBM) tad summa palielinās + vēl uzturēšanas etc izmaksas. Pagaidām arī risinājums nav ne tuvu beigām..

Jā uz select nosacījumā ietvertajiem un sortējamajiem laukiem. Nu mysqlam ir iespējama replikācija starp vairākiem serveriem vai arī būvēt mysql clusteri: http://dev.mysql.com/doc/mysql/en/replication-intro.html http://dev.mysql.com/doc/mysql/en/mysql-cl...r-overview.html Bet nu var jau teorētiski datus datīt tīri fiziski. Teiksim pēc tabulu noslogotības vienu tabulu uz viena servera otru uz otra (ja nav nepieciešamas relācijas utt). Vai arī ja arī savstarpēji (lietotāju) dati nav saistīti tad teiksim teiksim dalīt tā - pāra lietotāji (identifikators) uz viena nepāra uz otra (divi serveru gadijumā).

Izmaksas. Viens rackmountabls sterveris maksā 1-2+K Ls . Lēto kastīšu risinājumus pagaidām neatbalsta.. Innodb izmanto row level lockingu bet Selecti/Inserti ir lēnāki (tākā pie pēdējiem v;el tiek kurbulēti visādi commiti/rollbacki utt). Ja kveriji nav miksēti ar Update vai Insert labāk izmantot MyISAM tas būs ātrāk, ja tomēr ir tad jaskātās varbūt var iztikt ar LOW PRIORITY vai DELAYED, pretēji nekas cits neatliek kā lietot InnoDB Teorētiski ātrāk varētu būt jo šādā gadijumā izejas (galvenā) tabula pēc kuras notiek autorizācija / vai kas cits ir mazāka un filesort gadijumā (ja mysqls netrāpa uz indexiem) strādās ātrāk taču pie normāli saindeksētas tabulas starpībai pēc teorijas nekādai nevajadzētu būt.

To pagaidaam nosaka web frontendu jauda, jebshu paraleeli izdaraamo pieprasiijumu skaitu. Proti ja webserveris (sheit ierobezhojums var paarnesties uz jebkuru citu arii db u.c.) speej panjemt 400-800 pieprasiijumus sekundee, tad ja teiksim ienaak konkurenti 801 pieprasiijumi tad peedeejam naakas nedaudz gaidiit. Un ar to ka web lapu serveeshanai php tiek darbinaats fastcgi modee kur tiek saspawnoti noteikts skaits paraleelu procesu. Nu tiikla piesleegumam ir nedaudz pastarpinaata noziime - lai arii pienjemot ka image serveris dienaa izgruuzh ap 500Gb trafika, tad teikt ka tas ir nebuutisks arii nevar. Noslodze izliidzinaas ja lietojums ir skalaars. Proti nav iisti jeegas no 8 serveriem ja tie savaa starpaa nebalanceejas, nav jeegas no 8 serveriem ja aizmuguree ir viens db serveris kas taapat vairaak nespeej pavilkt. Shis ir diezgan aplams secinaajums. Ja DB arii speej to izpildiit tad tas uzradiit tikai seciigaa kaartiiba pie kam WHERE id = '5745'"; MySQLs jau zimanto query cache kas noziimee ka resultsets jau ir atminjaa un principaa vairs selecteets netiek. Pameegjini palaist vairaakus paraleelus skriptus ar dazhaadiem id kaa arii pa starpu ar UPDATE, INSERT un sajutiisi MyISAm table lockinga melnaas puses.

http://www.flash.lv/board/ jautājumus uzdot pareizajā vietā pareizajiem cilvēkiem..

Oh.. es ar 13 pa āru kazakus un razbojņikus spēlēju un svešos dārzos ābolus ēdu nevis šitājā bezcerīgajā industrijā maisījos. Kudā mir katjitsa?!

O pareizi der arī REPLACE pie nosacījuma ka nav jaupdeito vecā ieraksta kādu lauku vērtības. Teiksim lauks=lauks+1 jo REPLACE vispirms veco ierakstu dzēš, bet ja tas nav nepieciešams tad diezgan eleganti.

Ja ir 4.1.x MySQLs tad var izmantot ON DUPLICATE KEY fiichu http://dev.mysql.com/doc/mysql/en/insert.html Proti nodefinē key1 un key2 par unikāliem kejiem un tad INSERT INTO table (key1,key2,lauks) VALUES ('1','2','blabla') ON DUPLICATE KEY UPDATE citslauks=kautkadavertiba; Bet savietojamības nolūkos var tikuntā taisīt divus kverijus, bet drusku viltīgāk nevis vispirms taisīt SELECTU kas locko tabulas un pie aktīvas lietošanas varētu būt bremzīte, bet gan shitaa: Tāpat nodefinee abus keyus par unique (vai nu paari vai katru atseviskji) un tad taisi: if(!mysql_query("INSERT INTO table SET key1='val',key2='val'... ")) { mysql_query("UPDATE table SET blabla ... "); } Proti vispirms izpildi insertu ja mysqls deelj eksisteejoshiem indeksies nevarees to uztaisiit atgrieziiis false un izpildiisies updeits.

http://www.zend.com/store/products/zend-encoder.php http://www.ioncube.com/sa_encoder.php http://turck-mmcache.sourceforge.net/index_old.html#encoder ( http://eaccelerator.net ) p.s. vai tad magumas studija piedāvā php encodēt? kaut kā nemaniju tajā ides verķī kaut ko tādu..

Protams nav, taču tu iesaki lietotājam savus php skriptus darbināt ar CLI?! Melnā commandpromta logā vērties uz izvadiem?! Es tomēr uzskatu ka vajag novērtēt arī jautātājam sniedzamās informācijas atbilstību un nepieciešamību - izvirst un "spidēt" ar zināšanām vajag brīžos kad tas ir nepieciešams un jautājumu uzdevējs tā vēlas. Pretēji apjukums un nezināšana kļūst vēl lielāka. Pārējās iespējas un opcijas tiks atklātas izpētes / mācību / lietošanas gaitā.

Webserveris ar php (moduli, ekstensiju). Visbiežāk izmantotais variants ir Apache + PHP. Strādā analogi gan uz Windows gan Linux/Unix platformām. Windows gadijumā var atrast gatavas pakotnes kur viss jau ir ietverts. Teorētiski labāk ir izlasīt dokumentāciju un veikt manuālu instalāciju. Pietiekami daudz instrukcijas arī latviešu valodā: http://siets.lv/siets.php?q=apache+%2Bphp+instal%C4%81cija Un tālāk jau tīri kāds teksta redaktors. Vienkāršākajā variantā Notepad un tālāk jau pēc katra paša gaumei un vajadzīgajām iespējām (koda hailaits, sintakses checkings utt). Personīgi lietoju UltraEdit. Nu šeit pat forumā.. http://lv.php.net Officiālā mājas lapa Latvijas Mirrors http://hotscripts.net/php/ gatavu skriptu katalogs pilnīgi visām dzīves vajadzībām. Daži ievadpunkti http://man.coders.lv/pages/ http://3a3-interactive.net/php_reference/

foreach($_POST as $k => $v) { $_POST[$k] = strip_tags($v); } aatri un netiiri ..

Varningus parasti var ieslēgt ar ini_set('display_errors',1); un error_reporting(E_ALL); vai error_reporting(E_ALL ^ E_NOTICE);

Pamēģini ftp_chmod http://lv.php.net/manual/en/function.ftp-chmod.php Lai arī itkā dokumentācijā rakstīt ka PHP5 komentāros teikts ka strādā arī uz 4.3.10 Otrs piemēr ar ir lietojams (ja tomēr pirmais nefunkcilierē): ftp_site($conn_id, 'CHMOD 0777 /home/www/www.domain.lv/mainisana/images_m/'.$id.'/';);

Nu te jau ir datu fiziskā drošība un ne vairs no php koda atkarīga. Par ko akmens hostetāju lauciņā. Protams :) Tad teiksim arī jāsāk lietot kriptēts slēgums uz DB (teiksim SSL uz mysql) lai nevarētu nosnifot ;)

Paroles vajag glabāt tajos pašos .php failos, proti teiksim nevis taisīt config.inc (vai jebkādu citu failu kas netiek pārsēts ar php) un tad to includēt bet config.php un tad ja glabāsi šādā formātā <? $parole = 'superduper'; ?> tad no pārlūka atverot config.php nekas izvadīts netiks. Protams tas nepasargā no tā ka kāds kuram ir pieeja pie servera paroles var aplūkot - taču tas jau ir cita līmeņa drošības jautājums (proti vai vieta/hostings kur .php skripti ir atrodas ir pietiekami droša un serviss profesionāls). Taču arī šim ir risinājums - kriptēt jebšu encodēt .php failus. Līdz ar to ja arī kādam izdodas fiziski piekļut failiem, tad tie principā ir neizmantojami. Šim gan nepieciešamas papildus instalēt dažus moduļus webserverī. Populārākie encodētāji varētu būt - Zend Encoder (maksas produkts) http://www.zend.com/store/products/zend-encoder.php un uz servera lai šādus encodētus failus apstrādātu nepieciešams Zend Optimizer kas gan ir bezmaksas http://www.zend.com/store/products/zend-optimizer.php Tad ir arī IonCube http://www.ioncube.com/ Pilnīgs bezmaksas verķis kas ir reizē arī labs accelerators ir eAccelerator http://eaccelerator.net

Nu jopcik vai tad failu var nolasīt tikai ar include()?! No cita faila php kods var izpildīties tikai 3 gadījumos: include, require vai nolasīts un tad padots eval(). echo file_get_contents('tavsfails.php') un nekas nenomirs ja nepatiik pirmaa rinda pie izvadiem tad echo implode('',array_shift(file('tavsfails.php'))); Ja logfaili sanaak milzoniigi > 1Mb, tad jālas ar fread vai fgets pa chunkiem kā jau iepriekš Venom dod piemēru ar fgets (noskipojam pirmo rindu un tad lasam līdz beigām un metam uz outputu). No otras puses varbūt vienkāršāk ir palūgt webstervera adminam lai sakonfigo ka publiski log faili nav pieejami bet teiksim rakstās direktorijā ar autorizāciju. šādi diezgan muļķigi "hacki" sanāk :)

Var. Bet ar JS un CSS palīdzību, ne php (topic moved). Iframei jau by default var ielikt lai nerāda scollbarus un lai nav scrollings. Tad kā child framei izmantojam moveTo() un iesetojam ar ar style.bgColor (dokumentam, tabulai) kādu krāsu vaig.