Pereiti prie turinio

Lygiagretūs darbuotojai

Peržiūrėti kaip Markdown Redaguoti per GitHub Dokumentacija: d105217

Greph paskirsto teksto ir AST skenavimą darbuotojų telkiniui, kai darbų apimtis pateisina papildomas sąnaudas. Telkinys sukurtas naudojant pcntl_fork(), o jei ext-pcntl nepasiekiamas (Windows, kai kuriose PaaS aplinkose ar riboto prieglobos plano sistemose), vykdymas grąžinamas į procesą.

Lygiagrečių skenavimų įjungimas

Nustatykite -j N CLI arba jobs: N atitinkamame parinkčių objekte:

Shell
./vendor/bin/greph -F -j 8 "function" src
./vendor/bin/greph -p '$obj->$method($$$ARGS)' -j 4 src
./vendor/bin/rg --threads 8 -F "function" src
./vendor/bin/sg run --threads 8 --pattern '$obj->$method($$$ARGS)' src
PHP
use Greph\Greph;
use Greph\Text\TextSearchOptions;

Greph::searchText(
    'function',
    'src',
    new TextSearchOptions(fixedString: true, jobs: 8),
);

Kada įsijungia lygiagretus vykdymas

Greph ne visada vykdo užduotis lygiagrečiai. N procesų šakojimas ir jų rezultatų perdavimas atgal kanalais kainuoja, o esant nedideliam failų sąrašui šios sąnaudos nusveria pačią paiešką. Todėl fasadas apskaičiuoja ribą pagal užduočių skaičių, paieškos režimą ir šablono formą. Į darbuotojų telkinį siunčiami tik ribą viršijantys failų sąrašai.

Dabartinės euristikos (Greph\Greph::shouldUseTextWorkers ir susijusiuose failuose):

  • Vienos užduoties vykdymai (-j 1) visada vykdomi tame pačiame procese.
  • Pagal numatytąsias nuostatas teksto skenavimui reikia maždaug jobs * 2_000 failų, kad įsijungtų telkinys.
  • Skaičiavimo, failų su atitikmenimis ir failų be atitikmenų režimuose riba sumažinama iki maždaug jobs * 750, nes kiekvieno failo apdorojimas pigesnis.
  • Trumpų, identifikatorių formos fiksuotų eilučių šablonų riba padidinama iki maždaug jobs * 4_000, nes pažodinių eilučių greitasis kelias toks spartus, kad procesų šakojimas retai apsimoka.
  • AST paieškai ir AST perrašymui taikoma jobs * 750 riba.

Tai euristinės reikšmės, o ne garantijos. Jos sureguliuotos pagal WordPress našumo testų duomenų rinkinį ir gali būti peržiūrėtos.

Kaip veikia telkinys

Greph\Parallel\WorkSplitter paskirsto failų sąrašą į N dalis. Greph\Parallel\WorkerPool išsišakoja į vieną darbuotojo procesą kiekvienai daliai; kiekvienas darbuotojas vykdo tą pačią uždarąją funkciją savo failų daliai, o Greph\Parallel\ResultCollector per kiekvienam darbuotojui skirtą Unix lizdų porą perskaito serializuotus rezultatus. Pirminis procesas laukia visų darbuotojų, tada sujungia rezultatus ir iš naujo juos surikiuoja, kad išvesties tvarka būtų stabili, nesvarbu, kaip buvo paskirstytas darbas.

Teksto režime darbuotojų telkinys naudoja pasirinktinį perdavimo kanalų kodeką (Greph\Text\TextResultCodec), kad serializuoti duomenys būtų kompaktiški. AST režime naudojamas standartinis serialize() iš PHP.

Kai pcntl nepasiekiamas

Jei pcntl_fork iškviesti negalima (Windows, sustiprinto saugumo PHP versijose), telkinys nepastebimai grįžta prie kiekvienos dalies vykdymo tame pačiame procese. Rezultatas toks pat kaip -j 1 atveju. Greph klaidos nepateikia; tiesiog veikia vienoje gijoje.

Tai galima aptikti vykdymo metu patikrinus function_exists('pcntl_fork').

Derinimo patarimai

  • Pradėkite nuo -j reikšmės, lygios pusei fizinių procesoriaus branduolių skaičiaus, ir ją didinkite, kol nebematysite pagerėjimo.
  • Ieškant tik pažodinių fiksuotų eilučių mažose saugyklose, vieno proceso paieška paprastai greitesnė už bet kurią lygiagrečią konfigūraciją.
  • Paskelbtuose našumo testuose nematuojama lygiagreti AST paieška ar perrašymas. Prieš pasirinkdami užduočių skaičių, išmatuokite savo medyje.
  • README „Lygiagretaus teksto skenavimo režimo“ eilutėse (1, 2 ir 4 darbuotojai, WordPress duomenų rinkinyje) telkinys nematuojamas: jose ieškoma trumpo pažodinio šablono function, kurio jobs * 4_000 failų riba viršija duomenų rinkinio dydį, todėl kiekviena eilutė vykdoma tame pačiame procese (#8).

Apribojimai

  • Dabartinis telkinys nepalaiko darbo vagystės. Jei viena dalis gerokai sunkesnė už kitas, telkinys laukia lėčiausio darbuotojo.
  • Darbuotojų rezultatai kaupiami atmintyje, kol baigia darbą visi darbuotojai. Ilgai trunkančio skenavimo rezultatų srautinė išvestis (kaip rg --json siunčia įvykius) lygiagrečiu režimu nepalaikoma.
  • Sujungęs rezultatus pirminis procesas juos surikiuoja iš naujo, todėl darbuotojų telkinys nesumažina didžiausio atminties naudojimo, palyginti su vieno proceso skenavimu.

Šie apribojimai priimtini darbo krūviams, kuriems skirtas Greph (interaktyviai kodo paieškai, agentų ciklams ir CI užduotims su momentinėmis kopijomis). Jie bus peržiūrėti, jei profiliavimas parodys, kad realiuose duomenų rinkiniuose šie apribojimai tampa našumo kliūtimi.