CLI redirekts

[Joyride]

Ir skripts, kurs veic milzum daudz HTTP GET pieprasijumus ar cURL palidzibu uz dazadam adresem (~20 000x), sanem datus un apstrada tos, tad saliek ieks DB. Izpildas vins 1,5-2stundas, kad laizu CLI rezima no savas kastes. Sakuma vins bija taisits ar domu laist no weba, bet pec neilga laika uzkaras un partaisiju, lai varetu laist caur CLI. Tatad uz manas kastes strada ok, bet, kad tiek laists uz ista servera, izmet "Allowed memory size of 8388608 bytes exhausted" erroru. Uz ista servera PHP ir uzlikts memory limits uz 8MB, mainit to nevar (hostejamies pie serveris.lv).

Vai ir kadas idejas, ka skriptu uzlabot, lai netiktu tik daudz patereta atminja? Webiskaja vide varetu to istenot ar redirektiem (izpildit paris darbibas, atcereties checkpoint, tad redirekts uz to pasu skriptu, bet ar citu checkpoint parametru ?id=0...=>id=25...?id=50 u.t.t.). Vai CLI rezima var ko tadu lidzigu panakt?

[Aleksandrs]

Ar ini_set('memory_limit', '8M'); pamēģini izmainīt vērtību varbūt.

[andrisp]

Mēģināji rekursīvi ar system('php tavsskripts.php [atribuuti, kaa nu tur vinjus vareeja padot]') imitēt redirektu ?

 

Varbūt labāk mēģini optimizēt to skriptu ?

[bubu]

Rekursīvi diez vai būs labāk. Tad jau var uztaisīt vienu citu mazu skriptiņu, kurš dara apmēram šādi:

for ($i=0; $i<100; $i+=10)
{
system("iistais_skripts.php $i");
}

 

http://php.lv/f/index.php?showtopic=7591 ?

[Joyride]

Jap, veca problema reloaded...

[andrisp]

Ja nav baigais komercnoslēpums, parādi kodu - varbūt varam ieteikt kā optimizēt.

 

bubu, kāpēc gan rekursīvi nebūtu labāk ? Tas pats jau vien būtu kā izveidojot mazu skriptu, kas n-tās reizes izsauc to atmiņas rijošo skriptu.

[bubu]

Tāpēc, ka katra child-procesa izveidošanai sistēma patērē kautkāus OS resursus (atmiņa, handļi, threadi, utt). Ja tev jāizveido tikai vienu līmeni dziļš "rekursīvs" izsaukums (mans kods), tad vajadzēs atmiņā turēt tikai divas instances no šiem resursiem (sevi + childu). Ja tev vajadzēs 100 reizes izsaukt to skriptu, tad tavā kodā OS'ei vajadzēs turēt atmiņā līdz pat 101 šīm instancēm (sevi + katru childu) - resursu patēriņš ir lielāks.

[Joyride]

Šeit ir kods.

[Delfins]

Jā, slavenā GNT xml draza. Ja būs liels XML fails un parseris to mēģinās ielādēt "sevī", tad dabūsi vienmēr mem.limitu. (nezinu vai simplexml to dara).

Cik atceros, tad viss katalogs svera ap 16Mb !? Bet ja pieprasa pa kategorijām, laikam bija ap 200kB. Un skatoties kurš katalogs.

 

Neesmu pārliecināts, vai PHP atbrīvo atmiņu pēc ciklošanās šitai rindai

$xml = simplexml_load_string($text);

, bet izskatās tā ir vājā vieta un iespējams pat šito var izsaukt kā citu procesu (kā jau te piedāvāja).

Edited August 2, 2007 by Delfins

[Joyride]

Varētu mani nedaudz apgaismot, kas butu jādara galvenajam skriptam un kas būtu jādara atsevšķajiem procesiem (jāpieprasa xml / jāpārsē / jāsaglabā db)?

 

Ar PHP sistēmas komandam (system, passthru, exec u.t.t.) esmu uz Tu... ir kaut kā jānorāda working dir, vai pietiek kā andrisp rakstīja

system("iistais_skripts.php $i");

, ja "apakšfails" atrodas tajā pašā mapē?

 

Varbūt kāds zin, vai uz serveris.lv piedāvātā hostinga vispār ies cauri šīs sistēmas komandas?

[andrisp]

Varētu gadīties, ka ne. Katrā ziņā varbūt uzvani viņiem. Ko zin - varbūt vari vienkārši sarunāt, lai mem limitu palielina.

 

un working dir, ja nemaldos, būs tā, kurā atrodas aktīvais skripts. Tātad ja abi skripti būs vienā dirā, tad ar šo vajadzētu pietikt:

system("php skripts.php [argumenti]");

[Joyride]

Atradu šo: http://bugs.php.net/bug.php?id=38604

 

Priekšpēdējie 2 komenti ir attiecīgi kļūdainais kods un iespējamais risinājums. Man liekas, ka šitā ari ir visa problēma.

[bubu]

Vai nevar vienkārši parsēt ar SAX parseri? SAX jau tieši ir domāts šādiem gadījumiem, kad negrib ielādēt visu xml faila saturu atmiņā, bet tikai pa maziem gabaliem - katru atsevišķo elementu noparsē un izsauc callbacku uz tavu funkciju. SimpleXML ir jau DOM-veida parseris, tas ielādē pilnīgi visu xml faila saturu atmiņā.

 

Atceros kautkad senāk vecajā darbā bija kautkāds vecs kods (ne php, ne manis rakstīs), kurš importēja xml failu, tur tika izmantots DOM parseris. Importētie faili bija lieli - desmitos megabaitu. Un tas imports strādāja dikti ilgi - desmitiem sekunžu, ja pat ne minūšu. Un atmiņas patēriņš arī bija nevājš. Apnika man vienmēr uz to importu gaidīt. Pārrakstīju importu izmantojot SAX parseri. Rezultāti bija iespaidīgi. Imports tagad ilga <10sekundēm arī pat uz vislielākajiem xml failiem un atmiņas patēriņš bija praktiski nekāds.

[Joyride]

Ar SAX es sākumā mēgināju (xml_parser_create, xml_set_element_handler u.t.t.), bet bija 2 problēmas: kodējuma kropļojumi un parsing errors. Ja varbūt kodējuma kropļojumi radās no tā, ka es biju nepareizi norādījis encoding, tad lai novērstu parse errorus, tas nav manos spēkos. Simplexml dīvainā kārtā nav pīkstējis par kaut vienu malformed xml. Žēl, ka tagad nav pie rokas vecais kods, būtu publicējis.

[bubu]

Vai tad tas nav normāli, ka malformed xml's netiek parsēts? (cik saprotu - invalīda xml sintakse)

Kāpēc jālabo citu bugi? Ja tiešām xmls ir nekorekts, tad raksti tam gnt, lai salabo.

Dīvaini ir tas, ka simplexml neko nesaka par kļūdām.. Es tādam parserim īsti nemaz negribetu uzticēties - kas zin, šis varbūt pilnīgi greizi kautko noparsēs un pateiks, ka viss ok.