Platforma 1C: Enterprise 8 dispune de instrumentele necesare pentru a asigura multi-threading, dar în practică aceste instrumente sunt uitate nemărginit.
Desigur, multithreading nu este un panaceu, dar este o modalitate buna pentru:
1) reducerea duratei procedurilor îndelungate (în anumite situații - la comenzi!);
2) utilizarea sporită a resurselor echipamentelor.
Nu orice procedură lungă poate fi efectuată într-un mod cu mai multe fire, dar numai cele care funcționează cu un număr mare de blocuri de informații care nu sunt interconectate.
1) Există câteva sute de magazine care operează pe software-ul auto-scris și o singură bază în compania-mamă, în care tranzacțiile de vânzări sunt încărcate zilnic. Descărcarea este inițiată de utilizator pe buton și durează mult timp, deoarece stochează mult și tranzacțiile o sumă decentă, iar prelucrarea pachetelor de date este consecventă.
În această situație, vânzările fiecărui magazin nu depind una de alta, prin urmare, parsarea fișierelor și formarea de documente în sistem pot fi efectuate în modul multithreaded. Dar executarea documentelor este probabil un obstacol și trebuie efectuată într-un mod cu un singur filet.
În acest exemplu, accelerația nu poate fi foarte mare, deoarece formarea documentelor durează mai puțin decât conducerea acestora.
2) Există o bază de date vastă cu tranzacții de vânzări la magazin (din exemplul anterior) și este necesar să descărcați periodic aceste date într-un sistem BI de la terți utilizând 1C. Descărcarea este inițiată de utilizator și durează mult. sistemul trebuie să extragă milioane de rânduri din baza de date și să le încarce într-o bază de date intermediară pentru BI. În timpul descărcării datelor, echipamentul nu este încărcat semnificativ.
În această situație, puteți paraleli descărcarea de date - încărcați simultan datele către diferite magazine. Acest lucru va accelera semnificativ procesul și vă va permite să experimentați complet efectul unui fier puternic.
Instrumente de limbaj încorporate pentru efectuarea unei proceduri multithreaded.
Cea mai eficientă modalitate de organizare a mai multor fire este folosirea sarcinilor de fundal (pentru a nu fi confundată cu sarcinile de rutină).
Trebuie să parcurgeți lucrările de fundal și să așteptați finalizarea acestora.
Cod exemplu pentru cel de-al doilea caz (încărcarea unui număr mare de date în loturi):
1) Procedura care inițiază executarea codului multithread:
Butonul Procedură Executați Apăsați (Buton)
// specifică numărul de fire care se execută în același timp
Numărul fluxurilor paralele = 10;
Array of Tasks = Array nou;
Solicitare = Solicitare nouă (
"ALEGEREA VARIOANE
| | Multe bunuri
| FROM
| | Registrul de acumulare, Registrul de mărfuri la depozite, ca o mulțime de bunuri la depozite
WHERE
| | Partea de bunuri în depozite. Periodicitate ÎNTRE Data1 AND Data2 ");
Cerere. Setați parametrul ("Data1"; data de începere);
Cerere. Setați parametrul ("Data2." DateDiscount);
Rezultat = Solicitare. Rulați (). Descărcați ();
Pentru fiecare Stρ din ciclul rezultat
Array de parametri = Array nou;
Gama de parametri. Adăugați (Data de începere);
Gama de parametri. Adăugați (DateDiscussion);
Gama de parametri. Adăugați (Depozit pagină);
Sarcină = asignări de fond. Executați ("Descărcarea datelor de pe server, încărcarea datelor în paragrafe").
Gama de sarcini. Adăugați (Activitate);
Dacă matricea este o sarcină. Number ()> = Numărul de fluxuri paralele atunci
încercare
Lucrări de bază. Asteptati la sfarsit (gama de asignari);
Excepția
Încercări finale;
Gama de sarcini. Clear ();
Sfârșit Dacă;
Dacă matricea este o sarcină. Numărul ()> 0 Apoi
încercare
Lucrări de bază. Asteptati la sfarsit (gama de asignari);
Excepția
Încercări finale;
Gama de sarcini. Clear ();
Sfârșit Dacă;
Raport ("Timpul de execuție a procedurii este" + (Data curentă () - Ora de începere) + "cu.");
2) Procedura pe care sarcina de fundal (logica de bază) o realizează direct:
Modulul general "Descărcarea datelor de pe server", care rulează pe server:
Procedură: încărcați datele în Bard (Data de începere, Data de încheiere, Depozit) Exportați
Solicitare = Solicitare nouă (
„SELECT
| | *
| FROM
| | Registrul de acumulare, Registrul de mărfuri la depozite, ca o mulțime de bunuri la depozite
WHERE
| | Partea de bunuri în depozite. Periodicitate ÎNTRE Data1 AND Date2
| | Și Partidul de Bunuri pentru Depozite Depozit ");
Cerere. Setați parametrul ("Data1"; data de începere);
Cerere. Setați parametrul ("Date2" .DateDate);
Cerere. Setați parametrul ("Depozit"; Depozit);
Rezultat = Solicitare. Rulați (). Descărcați ();
Pentru fiecare Stρ din ciclul rezultat
// Faceți ceva cu datele
Sfârșitul ciclului;
În acest caz, se ia în considerare faptul că alegerea numărului de locuri de muncă paralele trebuie să fie luată în mod responsabil - dacă le executați chiar și câteva duzini, atunci probabilitatea de "atârnă" și serverul de aplicații și serverul de baze de date.
66. Dmitry Sherstobitov (DitriX) 2525 16.04.13 12:37 Acum în subiect
(65) În cazul în care organizația nu este afiliat in nici un fel, de ce nu, dar dacă a existat cel puțin o vânzare sau de mișcare între ele, pot exista complicații.
(63) poate fi, dar există un alt mod, o mai fiabile și simplu, dar, de asemenea, flexibil, cu toate acestea, cu nuanțe, - și anume, utilizarea de registre separate pentru anumite sarcini.
De exemplu, - am UT, se creează dofiga controale CMC, controalele sunt realizate din depozit la tipul de en-gros (nu întrebați de ce acest lucru deja, și toate de prelucrare / rapoarte au fost ascutita de ea), și a trebuit să descarce informațiile de vânzări.
Au existat 3 moduri de rezolvare - de a face descărcarea fiecărui depozit în fluxurile sale, de a rula pe documentele PM sau de a realiza un registru separat de revoluții, unde întregul infa a flopat.
În ceea ce privește comoditatea - a fost adoptată a treia opțiune, deoarece, în cele din urmă, a fost posibilă cercetarea, oamenii foarte frumoși se vor uni cu alte date etc.
Sunt ceea ce este - probleme din lumea reală, care necesită rasparalelivaniya - nu atât de mult, deoarece 90% din problemele pot fi rezolvate în alte moduri cu mai abordare izyaschnym.
Orice cod, și nu sunt convins de contrariul, este strict liniar și secvențial.
un fel de interpretare vagă, în limitele unei instrucțiuni, că și care este discutabilă, deoarece există etichete.
Sunt de acord - etichetele distorsionează ușor liniaritatea executării codului. În mod consecvent - da, dar nu liniar.
Dacă se solicită o procedură sau o funcție, codul va aștepta finalizarea acesteia înainte de a trece la pasul următor.
Ei bine, asa ca tu inseala :)
Iată un exemplu de paralelă reală a tranzacțiilor:
Am parsyu site-ul a primit 100 de pagini, am nevoie pentru a le parsa și a pus în registrul de informații, de exemplu, am obține o serie de 100 de linii, rulați pe un ciclu și apela folosind VBS. Iată un exemplu:
De exemplu, când faceți clic pe un element.
Funcția client este apelată de la aceasta:
Funcția de îmbunătățire a datelor este descrisă în modulul de procesare
Există, de asemenea, parsarea paginilor web și adăugarea lor în arborele de descriere. Deci, în timp ce această funcție este executată - pot lucra în siguranță în continuare cu procesarea și executarea altor fire care nu au legătură cu prelucrarea arborelui.
Cu toate acestea, de îndată ce eu numesc din nou această funcție, și va ajunge la stadiul de actualizare a arborelui (primul nu este terminat încă), atunci el zboară spre Creta în sine 1C.
Aici este - fluxuri cu adevărat diferite, și aceasta este scopul aplicării lor.
Cu toate acestea, dacă scriu date în registru, de exemplu, și fac arborele o listă dinamică a acestui registru, totul merge bine.
Asta am nevoie - funcția de parsare, etc. care rulează în continuare, însă programul sa mutat deja la o altă linie de cod și nu așteaptă finalizarea funcției anterioare, care este apelată din modul.
Ie există probleme cu adevărat reale, în care puteți aplica acest mecanism și puteți accelera munca utilizatorilor, trebuie doar să includeți fantezie.
Da, și să ia în considerare consecințele, precum și limitările platformei.
69. AlexBar (AlexBar) 52 17.04.13 00:31 Deja în subiect
dacă organizațiile nu sunt deloc conectate, atunci de ce nu, dar dacă a existat cel puțin o vânzare sau un transfer între ele, s-ar putea să existe complicații.
Nu este deloc clar care sunt legăturile despre care vorbești. În ceea ce privește organizația, este vorba în mod neechivoc de o entitate juridică, deoarece, pentru contabilitatea de gestiune, conceptul de organizație nu există în general. Și din moment ce vorbim despre o entitate juridică, toate celelalte organizații pentru această entitate juridică sunt doar contrapărți. Și nu contează ce dintre ele pot exista programe de revânzare, scheme de taxare / comision / agent. Toate acestea sunt relațiile dintre organizație și contrapartidă. Contabilitatea pentru orice organizație este separată și autosuficientă și nu depinde în niciun fel de alte organizații din baza de date.
se deplasează între ele
Domnule! Scopul acestei expresii este faptul că folosiți argoul dvs., dar încercați să nu vorbiți așa în prezența contabililor și a auditorilor.
Plecând de la ceea ce sa spus, dacă în orice ordine există o dimensiune organizațională, atunci recuperarea secvențelor în contextul fiecărei organizații poate fi efectuată "în paralel", de preferință prin impunerea blocărilor controlate pe secvența pentru această măsurare.
poate, totuși, există o altă cale, mai fiabilă și mai simplă, dar și flexibilă, deși cu nuanțele sale, și anume - utilizarea unor registre separate pentru anumite sarcini.
Nu este clar cu ce se referă acest lucru.
Sunt de acord - etichetele distorsionează ușor liniaritatea executării codului. În mod consecvent - da, dar nu liniar.
Liniaritatea în înțelegerea mea și în contextul a ceea ce spun eu înseamnă literalmente că codul nu se poate extinde. Chiar ajungând la marcaj, codul va sari la el și va începe să se descurce deja din etichetă. Ie Situația în care un context a mers la etichetă, iar cel de-al doilea context a mers mai departe, nu poate exista în natură.
Ceea ce descrieți în continuare, înțeleg cum să folosesc scripturi suplimentare care pot fi executate fără a aștepta finalizarea executării codului. Dar acesta nu este contextul unei singure aplicații. Și este echivalent cu aceleași sarcini de fond pe care le luăm în considerare. Dar spre deosebire de script-uri, lucrările de fundal sunt executate în contextul aceleiași aplicații.
Dar în exemplul pe care îl descrieți, există o boală rațională pozitivă: aceasta poate fi o alternativă la sarcinile de fundal în modul fișier.
Da, și să ia în considerare consecințele, precum și limitările platformei.
Dacă credeți că aveți un topor, puteți face greșeli într-o expresie matematică simplă, care va copleși complet orice server.
67. Yuri Osipov (yuraos) 914 Joi, 16 Aprilie 2006 16:59 În prezent în subiect
(65) KroVladS,
probabil imet în vedere,
că secvența are o dimensiune a "Organizației"
și restabilirea secvenței
pentru fiecare valoare a organizației din cadrul acesteia
puteți încerca să rulați în paralel
(pentru fiecare organizație în sarcina lor de bază).
---
dacă unele organizații sunt într-un fel interconectate
privind mișcările în registre,
atunci această abordare poate să nu fie foarte bună.
59. Sergey Bushmakin (relanium86) 13 15.04.13 14:42 În prezent în fișier
Ciudat am urmatoarele
Timpul procedurii este de 102 s. cu fundal
Timpul procedurii este de 7 secunde. fără fundal
De ce este atât de interesant?
60. Yuri Osipov (yuraos) 914 Joi, 15 Aprilie 2011 17:31 În prezent în thread
(59) relanium86,
paralelizarea nu este un panaceu,
acesta este modul în care estul este subtil.
nu toate sarcinile pot fi paralelizate în general
și optimal în paralel în special.
61. Anton Grachev (Fragster) 745 15.04.13 18:04 Currently in thread
(59) relanium86, sarcinile de fundal înșiși încep un timp vizibil, deci pentru operațiuni <десятков секунд смысла вообще нет (или нужны постоянно запущенные задания "в боевой готовности")
64. Sergey Bushmakin (relanium86) 13 16.04.13 06:55 Momentan în coș
Da, dacă specificați numărul de iterații> = 10ml, atunci sarcinile de fundal sunt accelerate.
Aparent afectează faptul că este nevoie de timp pentru a începe lucrarea de fundal.
70. Dmitry Sherstobitov (DitriX) 2525 17.04.13 11:49 În prezent în colaj
Nu este deloc clar care sunt legăturile despre care vorbești. În ceea ce privește organizația, este vorba în mod neechivoc de o entitate juridică, deoarece, pentru contabilitatea de gestiune, conceptul de organizație nu există în general.
Dacă am fost în America sau Europa - mi-ar fi râs, dar au existat cazuri în care oamenii au fost de vânzare bunuri de la o organizație la alta, și a făcut acest lucru la costuri, ci pentru că părțile nu au fost construite, au făcut-o la orice preț, atunci la sfârșitul lunii, părțile au fost aliniate, prețurile din documentul de vânzare și veniturile pentru noul preț de cost au fost modificate.
Iată un exemplu de dependență explicită, și în timp ce o organizație a atins acest document primire - până când este forțat să zhdvt doua organizație va ajunge la documentul de vânzări legate, indiferent de preț pentru a pune în jos și transportat la fluxul.
În cazul contabilizării RAUS - această situație nu ar trebui să apară, deși există opțiuni.
Domnule! Scopul acestei expresii este faptul că folosiți argoul dvs., dar încercați să nu vorbiți așa în prezența contabililor și a auditorilor.
Nu este clar cu ce se referă acest lucru.
Acest lucru se referă la faptul că este departe de a fi rezonabil de rezolvat prin paralelism.
Ie Situația în care un context a mers la etichetă, iar cel de-al doilea context a mers mai departe, nu poate exista în natură.
Ți-am dat un exemplu - când pot, și am descris consecințele :)
Și în detrimentul restricției exprimate de dvs., inițial am spus că este necesar să clarificăm - dacă într-o singură funcție - da și dacă nu, atunci nu vehda.
În general, 1C are pași importanți în această direcție - și anume, posibilitatea de a lansa tratamente de rutină externe, fără a fi nevoie de a urca în configuratorul, așa cum face în UT11, dar nu am săpat într-adevăr.
Trimiteți-le prietenilor: