Multithreading, mint bizonyos eljárások gyorsítása

Platform 1C: Az Enterprise 8 rendelkezik a szükséges eszközökkel a többszálas elrendezés biztosításához, de a gyakorlatban ezek az eszközök elfelejthetetlenül elfelejtettek.

Természetesen a multithreading nem csodaszer, de jó módja ennek:

1) a hosszú eljárások időtartamának csökkentése (egyes esetekben - megrendelések esetén!);

2) a berendezések erőforrásainak nagyobb kihasználtsága.

Nem minden hosszú eljárást lehet végrehajtani többszálas módban, de csak azok, amelyek nagyszámú, nem összekapcsolt információblokkokkal működnek.

1) Számos száz üzlet működik az önírón alapuló szoftveren, és egyetlen alapot az anyavállalatnál, ahol az értékesítési tranzakciókat naponta töltik fel. A letöltést a felhasználó kezdeményezi a gombon, és hosszú időt vesz igénybe, mert tárolja a sok és tranzakciók tisztességes mennyiségű, és az adatcsomagok feldolgozása következetes.

Ebben az esetben az egyes boltok értékesítése nem függ egymástól, ezért a fájlok értelmezése és a dokumentumok létrehozása a rendszerben többszálas módban is végrehajtható. De a dokumentumok végrehajtása valószínűleg szűk keresztmetszet, és egyszálú üzemmódban kell végrehajtani.

Ebben a példában a gyorsítás nem túl nagy, mert a dokumentumok kialakulása kevesebb időt vesz igénybe, mint a vezetésük.

2) Van egy nagy adatbázist tároló értékesítési tranzakciókkal (az előző példából), és szükség van arra, hogy ezeket az adatokat rendszeresen letöltsék egy harmadik fél BI rendszerére az 1C használatával. A kirakodást a felhasználó kezdeményezi, és sok időt vesz igénybe. a rendszernek több millió sorot kell lekérnie az adatbázisból, és fel kell töltenie őket egy köztes adatbázisra a BI számára. Az adatok kirakodása során a berendezés nem töltődik be jelentősen.

Ebben a helyzetben lehetővé válik az adatok letöltésének párhuzamosítása - egyszerre töltsön adatokat különböző üzletekbe. Ez jelentősen fel fogja gyorsítani a folyamatot, és lehetővé teszi, hogy teljes mértékben megtapasztalja a hatalmas vas hatását.

Beépített nyelvi eszközök többszálú eljárás végrehajtásához.

A többszálas elrendezés leghatékonyabb módja a háttérfunkciók használata (nem szabad összetéveszteni a rutin feladatokkal).
Meg kell cikázni a háttérben végzett munkákat, és várja meg őket.

A második eset példakódja (nagyszámú adat feltöltése tételekben):

1) A többszálú kódfuttatást kezdeményező eljárás:

Eljárás gomb végrehajtása Nyomja meg a (gombot)

// megadja a szálak számát egyidejűleg
Párhuzamos áramlások száma = 10;

A feladatok sorrendje = Új sor;

Request = Új lekérdezés (
"KÜLÖNBÖZŐ KIVÁLASZTÁS
| | Sok áruNincs áruházak
FROM
| | A felhalmozási nyilvántartás, az áruk nyilvántartása a raktárakba, mint a raktárak nagy része
WHERE
| | A raktárakban lévő árucikkek közötti időszak Dátum1 ÉS Date2 ");
Kérelmet. Állítsa be a paramétert ("Date1." Start Date);
Kérelmet. Állítsa be a paramétert ("Date2" .DateDate);

Eredmény = Kérelem. Futtatás (). Unload ();

Minden eredménye az eredményciklusból

Array of Parameters = Új Array;
A paraméterek tömbje. Hozzáadás (kezdő dátum);
A paraméterek tömbje. Add (DateDiscussion);
A paraméterek tömbje. Add (Page Warehouse);

Feladat = Háttér-hozzárendelések. Végrehajtja ("Adatok letöltése a kiszolgálón, Adatok feltöltése a bekezdésekbe." Paraméterek csoportja);

A feladatok csoportja. Add (Feladat);

Ha a tömb egy feladat. Szám ()> = Párhuzamos áramlások száma
kísérlet
Háttér munkák. Várakozás a befejezésre (a hozzárendelési réteg);
A kivétel
Vége kísérletek;
A feladatok csoportja. Tiszta ();
End If;

Ha a tömb egy feladat. A szám ()> 0 majd
kísérlet
Háttér munkák. Várakozás a befejezésre (a hozzárendelési réteg);
A kivétel
Vége kísérletek;
A feladatok csoportja. Tiszta ();
End If;

Jelentés ("Az eljárás végrehajtási ideje" + (aktuális dátum () - indítási idő) + "with.");

2) Az a művelet, amelyet a háttér feladatok (alap logika) végeznek:

A kiszolgálón futó általános modul "Adatok letöltése a kiszolgálón":

Eljárás: Adatok feltöltése a bárdokba (kezdő dátum, befejezés dátuma, raktár)

Request = Új lekérdezés (
„SELECT
| | *
FROM
| | A felhalmozási nyilvántartás, az áruk nyilvántartása a raktárakba, mint sok áru a raktárakba
WHERE
| | A raktárakban lévő árucikkek közötti időszak Dátum1 ÉS Date2
| | És a raktárak áruinak pártja Warehouse = Raktár ");

Kérelmet. Állítsa be a paramétert ("Date1." Start Date);
Kérelmet. Állítsa be a paramétert ("Date2" .DateDate);
Kérelmet. Állítsa be a Paramétert ("Raktár").

Eredmény = Kérelem. Futtatás (). Unload ();

Minden eredménye az eredményciklusból
// Tegyen valamit az adatokkal
A ciklus vége;

Ha ez a helyzet, hogy úgy vélik, hogy a választás a több egyidejű munkahelyet kell venni felelősen - ha futtatni őket még néhány tucat, akkor valószínű, hogy „lógni”, és az alkalmazás szerver és adatbázis szerver.

66. Dmitry Sherstobitov (DitriX) 2525 16.04.13 12:37 Most a témában

(65) Ha a szervezetek semmilyen kapcsolatban nem állnak egymással, akkor miért ne, de ha van legalább egy értékesítés vagy átruházás közöttük, komplikációk lehetnek.

(63) azonban létezhet másik, megbízhatóbb és egyszerűbb, de rugalmasabb, bár az árnyalatokkal, nevezetesen - külön nyilvántartások használatával bizonyos feladatokhoz.

Például - Megvan UT, ott jön létre dofiga CMC ellenőrzések során ellenőrizni kell a raktárból, hogy milyen típusú nagykereskedelmi (ne kérdezzétek, miért olyan már, és az összes feldolgozó / jelentéseket kiélezte azt), és mi volt, hogy kirak az eladási adatait.
Három megoldást lehetett megoldani: minden egyes raktárba kirakodni a patakokban, vagy futtatni a PM dokumentumokat, vagy külön nyilvántartást tenni a forradalmakról, ahol a teljes infra flocked.
A kényelem miatt - a harmadik lehetőséget elfogadták, ahogyan ez lehetővé tette, végül a kérdésekben a nagyon szép emberek egyesülnek más adatokkal stb.

Én, hogy mi az - az igazi feladatok, amelyek párhuzamot igényelnek - nem annyira, mert a problémák 90% -a más módon megoldható elegánsabb megközelítéssel.

Bármelyik kód, és nem vagyok meggyőződve ezzel szemben, szigorúan lineáris és egymást követő.


valamiféle homályos értelmezés, egy utasítás határain belül, és ez vitatható, mert vannak címkék.
Egyetértek - a címkék kissé torzítják a kód végrehajtásának linearitását. Következetesen - igen, de nem lineárisan.


Ha egy eljárás vagy egy függvény hívásra kerül, a kód meg fogja várni annak befejezését, mielőtt folytatná a következő lépést.


Ó igen, így az emberek csalnak :)

Íme egy példa a valós tranzakciós párhuzamról:
Én parsyu site 100 oldalat kapott, meg kell elemeznem őket, és be kell helyeznem az információs nyilvántartást, például 100 sorból álló sorozatot kapok, futnak cikluson és hívják a vbs használatával. Íme egy példa:

Például amikor egy elemre kattint.
Ezt a kliens funkciót hívják:

Az Adat finomítása funkció a feldolgozómodulban található meg
És ott is elemzi a weboldalakat, és hozzáadja őket a leírás fához. Tehát, miközben ez a függvény végrehajtásra kerül - biztonsággal dolgozhatok további feldolgozással és más olyan szálak végrehajtásával, amelyek nem kapcsolódnak a fa feldolgozásához.
Azonban, amint újból felhívom ezt a funkciót, és a fa frissítésének színpadán (az első még nem fejeződött be), az 1C maga is kritikusan repül.
Itt van - nagyon különböző áramlások, és ez az, ami az alkalmazásukhoz vezet.
Ha azonban adatokat írok a nyilvántartásba, és dinamikus listát hozok létre a fa számára, minden rendben lesz.

Ez az, amire szükségem van - az elemző funkció stb. még mindig fut, de a program már költözött egy másik vonalra, és nem várja meg az előző funkció befejezését, amelyet a modulról hívnak.


Ie tényleg igazi problémák vannak, ahol alkalmazhatja ezt a mechanizmust és felgyorsíthatja a felhasználók munkáját, csak fantázia szükséges.


Ja, és vegye figyelembe a következményeket, valamint a platform korlátait.

69. AlexBar (AlexBar) 52 17.04.13 00:31 Már a témában

ha a szervezetek egyáltalán nem kapcsolódnak egymáshoz, akkor miért ne, de ha van legalább egy értékesítés vagy mozgás közöttük, komplikációk lehetnek.


Egyáltalán nem világos, hogy milyen kapcsolatokról van szó. Ami a szervezetet illeti, egyértelműen jogi személyiség kérdése, mivel a vezetőség számára a szervezet fogalma általában nem létezik. És mivel jogi személyről beszélünk, az e jogi személy minden más szervezete csak partner. És nem számít, hogy közöttük lehetnek viszonteladók, autópályadíj / jutalék / ügynöki rendszerek. Mindez a Szövetség és az Ügyfél közötti kapcsolat. A szervezet elszámolása önálló és önálló, és semmilyen módon nem függ az adatbázisban szereplő más szervezetektől.

közöttük mozog


Sir! Ezt a kifejezést írtam arra a tényre, hogy a szlengjét használja, de próbálja meg, hogy ne beszéljen ilyen módon a könyvelők és a könyvvizsgálók jelenlétében.
A fentiek alapján, ha a szekvencia mérési szervezet, a helyreállítási szekvenciák szekcionált minden szervezet lehet végezni „párhuzamosan”, kívánatos zár vezérli impozáns sorozata a jelen mérés.

talán van egy másik módja, megbízhatóbb és egyszerűbb, de rugalmas is, bár az árnyalatokkal, nevezetesen - külön nyilvántartások használatával bizonyos feladatokhoz.


Nem teljesen világos, hogy ez mit jelent.

Egyetértek - a címkék kissé torzítják a kód végrehajtásának linearitását. Következetesen - igen, de nem lineárisan.


A linearitás a megértésemben és az összefüggésben azt jelenti, hogy szó szerint a kód nem terjed ki. A kód megérkezése után a kód ugrik rá, és máris kezdi meg a címkét. Ie A helyzet, amikor egy kontextus a címkére került, és a második kontextus tovább ment, nem létezhet a természetben.
Amit tovább írsz, megértem, hogyan használhatok további parancsfájlokat, amelyek végrehajthatók anélkül, hogy várnák a kódfuttatás befejezését. De ez nem az egyetlen alkalmazás kontextusa. És ez ugyanazoknak a háttértevékenységnek felel meg, mint amit mérlegelünk. De ellentétben a szkriptekkel, a háttértárak ugyanabban az alkalmazásban futnak.
De a példában, amit leírsz, van egy pozitív racionális gabona: ez alternatív lehet a háttértevékenységekhez fájl módban.

Ja, és vegye figyelembe a következményeket, valamint a platform korlátait.


Ha gondolkodás nélkül ingerelsz egy fejszét, egyszerűen matematikai kifejezésekkel hibáztathatsz, ami teljesen elárasztja a szervereket.

67. Yuri Osipov (yuraos) 914 2006. április 16., csütörtök 16:59 Jelenleg a témában

(65) KroVladS,
Valószínűleg,
hogy a szekvenciának a "Szervezet" dimenziója van
és állítsa vissza a szekvenciát
a szervezet minden értékére
megpróbálhat párhuzamosan futni
(minden egyes szervezetnél a háttér feladataiknál).
---
ha egyes szervezetek valahogy összekapcsolódnak
a nyilvántartásokban történt mozgásokról,
akkor ez a megközelítés nem feltétlenül jó.

59. Sergey Bushmakin (relanium86) 13 15.04.13 14:42 Jelenleg a téma

Furcsa, a következőket kaptam
Az eljárás ideje 102 s. háttérrel
Az eljárás ideje 7 másodperc. háttér nélkül


Miért olyan érdekes?

60. Yuri Osipov (yuraos) 914 2011. április 15., csütörtök 17:31 Jelenleg a téma

(59) relanium86,
a párhuzamosság nem csodaszer,
így a Kelet finom.
Nem minden feladat általában párhuzamosan hajtható végre
és optimálisan párhuzamosan.

61. Anton Grachev (Fragster) 745 15.04.13 18:04 Jelenleg a téma

(59) relanium86, a háttér feladatok maguk is észrevehető időt kezdhetnek, így a műveletekhez <десятков секунд смысла вообще нет (или нужны постоянно запущенные задания "в боевой готовности")

64. Sergey Bushmakin (relanium86) 13 16.04.13 06:55 Jelenleg a téma

Igen, ha megadja az> 10ml-es iterációk számát, akkor a háttérben lévő feladatok felgyorsulnak.
Úgy tűnik, hogy befolyásolja azt a tényt, hogy időbe telik a háttértevékenység elindítása.

70. Dmitry Sherstobitov (DitriX) 2525 17.04.13 11:49 Jelenleg a téma


Egyáltalán nem világos, hogy milyen kapcsolatokról van szó. Ami a szervezetet illeti, egyértelműen jogi személyiség kérdése, mivel a vezetőség számára a szervezet fogalma általában nem létezik.


Ha Amerikában vagy Európában lennénk, akkor is nevetni fogtam volna, de voltak olyan esetek, amikor az emberek eladtak árut egy szervezetből a másikba, és megfizetették, de mivel a felek nem épültek, minden áron, akkor a hónap végén a felek összehangolódtak, az értékesítési dokumentumban szereplő árak és az új költség árból származó bevételek megváltoztak.
Íme egy példa a nyilvánvaló függőségre, és amíg egy szervezet eljutott az átvételi elismervényhez - kénytelen várni, amíg a második szervezet megérkezik a kapcsolódó értékesítési dokumentumba, milyen árakat állítanak fel és átutalják az átvételre.
A RAUS elszámolása esetében ez a helyzet nem merülhet fel, bár vannak lehetőségek.

Sir! Ezt a kifejezést írtam arra a tényre, hogy a szlengjét használja, de próbálja meg, hogy ne beszéljen ilyen módon a könyvelők és a könyvvizsgálók jelenlétében.

Nem teljesen világos, hogy ez mit jelent.


Ez arra a tényre utal, hogy messzemenően messze van minden ésszerű megoldással párhuzamosan.

Ie A helyzet, amikor egy kontextus a címkére került, és a második kontextus tovább ment, nem létezhet a természetben.


Adtam egy példát - amikor tudok, és leírtam a következményeket :)
És az Ön által kifejezett korlátozás rovására eredetileg azt mondtam, hogy itt tisztázni kell - ha egy funkcióon belül - igen, és ha nem, akkor nem vehda.

Általában az 1C már jó lépéseket tesz ezen a téren, nevezetesen - a külső feldolgozás tervezett indításának lehetőségét, anélkül, hogy be kellett volna mászni a konfigurátorba, így az UT11-ben történik, de nem igazán ástam.