Az Upp 8.3 lassan elkezdett működni. Automatizálási tippek. SQL Server DMO objektumok használata

A felhasználók gyakran panaszkodnak, hogy „az 1C 8.3 lassú”: a dokumentum-űrlapok lassan nyílnak meg, a dokumentumok feldolgozása hosszú ideig tart, a program elindul, a jelentések generálása sok időt vesz igénybe, és így tovább.

Ezenkívül az ilyen „hibák” különböző programokban fordulhatnak elő:

Az okok eltérőek lehetnek. Ez nem visszaállított dokumentumok, gyenge számítógép vagy szerver, az 1C szerver helytelenül van konfigurálva.

Ebben a cikkben a lassú program egyik legegyszerűbb és leggyakoribb okát szeretném megvizsgálni - . Ez az utasítás 1-2 felhasználós fájladatbázisok felhasználói számára lesz releváns, ahol nincs verseny az erőforrásokért.

Ha érdekel a rendszer működéséhez szükséges kliens-szerver opciók komolyabb optimalizálása, látogass el az oldal részébe.

Hol vannak az ütemezett feladatok az 1C 8.3-ban?

Mielőtt időm lett volna betölteni a programot, az 1C sok mindent végrehajtott háttérmunkák. Megtekintheti őket az „Adminisztráció” menüben, majd a „Támogatás és karbantartás” menüben:

Szerezzen ingyen 267 videóleckét 1C-n:

Így néz ki a befejezett feladatokat tartalmazó ablak:

És aztán teljes lista minden elindított ütemezett feladat:

Ezen feladatok között láthat például „“, különféle osztályozók betöltését, a programverzió relevanciájának ellenőrzését stb. Például ezeknek a feladatoknak szinte mindegyikére nincs hasznom. Devizanyilvántartást nem vezetek, a verziókat magam irányítom, és szükség szerint töltöm be az osztályozókat.

Ennek megfelelően az én (és a legtöbb esetben az Ön) érdeke a szükségtelen feladatok letiltása.

Ütemezett és háttérfeladatok letiltása az 1C 8.3-ban

A beteg tünetei és története:

A hálózaton keresztül ugyanazzal a fájllal (adatbázissal) végzett több felhasználó munkája hálózati blokkoló mechanizmust tartalmaz. Ez arra kényszeríti a rendszert, hogy értékes időt veszítsen a nyitott felvételi munkamenetek azonosítására és a konfliktusok ennek megfelelő megoldására.

A blokkoló működés fő jelei:

• gyors felhasználói munka az adatbázissal a hálózaton keresztül exkluzív módban, és rendkívül lassú, ha több felhasználó dolgozik egyszerre
• gyors felhasználói élmény egy helyi adatbázissal a szerveren és lassú munka a hálózaton keresztül
• apellál fájlrendszer alig 10 MB/sec

Így azt a feladatot kaptam, hogy gondoskodjak arról, hogy akár három felhasználó is dolgozhasson 1C-ben egyszerre! Vicces, nem?

Elfelejtettem az összes viccet, amikor megláttam, hogy mivel kell foglalkoznom: egy „szerverrel” egy közönséges irodai számítógép és két laptop formájában.

A boldogság hiányos lenne, ha nem a csodálatos operációs rendszerek - a számítógépen és egy Windows laptop 7, másrészt Windows 8.

Amikor egyidejűleg próbált dokumentumokat feltenni laptopokra, az egyik körülbelül egy percig elakadt, a második pedig kizuhant az 1C-ből a „nem sikerült lezárni az asztalt...” hibaszöveggel.

Az 1C laptopon való elindítása egy külön műsor, ami kb 3 perc!

Számos forrásnál találkoztam tanácsokkal, hogy váltsam át a terminálhozzáférésre. Sajnos a Windows 7 nem teszi lehetővé rendszeres eszközökkel terminálkiszolgálóvá alakul - legfeljebb egy aktív kapcsolat. Ebben az esetben a fennmaradó munkamenetek nem szűnnek meg, újra csatlakozhat egy másik felhasználóhoz - „kidobva” az előző felhasználót, de anélkül, hogy megszakítaná a munkamenetét. Ezért az 1C-t át kell vinnie egy szerver operációs rendszerre, ahol nincsenek ilyen korlátozások. Az ügyfél saját felelősségére egy harmadik féltől származó segédprogram segítségével oldotta meg a problémát Windows7_SP1_RDPhack.

De a kalandok ezzel nem értek véget. Még a terminálkapcsolatban is jelentős késések voltak. A mindenható keresőmotorok ismét segítettek. Az alábbiakban tippeket adunk az 1C fájl felgyorsításához, amelyeket követtem:

1. Letiltás hálózati protokoll használata IPv6, konfigurálja a címzést a „régi” IPv4-en.

2. Adjon hozzá 1C folyamatokat a Windows tűzfal kivételeihez, valamint a víruskereső kivételekhez, vagy tiltsa le teljesen (kockázatosabb, de egy egyszerű teszt azt mutatta sebesség növekedés dokumentumok újraküldése letiltott állapotban Avast víruskereső tényezője!)

3. Kezdje el indexelni a teljes szöveges keresést 1C-ben, vagy kapcsolja ki teljesen

4. Futtassa az adatbázis tesztelését és javítását, ellenőrzést a ChDbfl segédprogrammal

5. Futtassa a Konfiguráció ellenőrzése elemet a konfigurációban (ha a konfiguráció nem szabványos, ez hasznos lehet). A konfiguráció ellenőrzésének eredménye alapján varázslatosan csaknem harmadával csökkent a mérete. Nem igazán mélyedtem el abban, hogy a beérkező programozók pontosan mit frissítettek előttem, de a tény nyilvánvaló.

6. Tiltsa le a szükségtelen funkcionális opciókat.

7. Állítsa be a felhasználói jogosultságokat. (Ez és az előző tanács hülyeségnek tűnt, amíg meg nem néztem a rajzot ellenőrzött formák a dokumentumlista megnyitásakor. Minél kevesebb a felesleges dolog egy felügyelt felületen, annál gyorsabban működik, általában)

8. Kezdje el az összegek újraszámítását és a sorrend visszaállítását (jelentős növekedés csak akkor következhet be, ha az összegeket hosszú ideig nem állítják vissza)

9. Adja meg az adatbázis lista beállításainál a "Connection speed - low"-t (ez nem sok eredményt hozott, kivéve, hogy az alrendszerek képei kikapcsolva :))

Mindezen lépések elvégzése után az 1C fájladatbázis sokkal gyorsabban kezdett működni. Maximum 10 másodperc alatt indult el, a dokumentumátvitel sebessége pedig átlagosan 12-szeresére nőtt.

Talán ez a rövid cikk hasznos lesz az Ön számára, ha hirtelen fel kell gyorsítania 1C fájladatbázisát.

Ui.: De egy 1C fájl elindítása hálózati hozzáféréssel egy megosztott mappához továbbra is irreális, mert... Dasha a leggyorsabb Solid State Drive, a RAM és a processzor beszorul a hálózati zárakba, és egynél több felhasználó munkája gyakorlatilag lehetetlenné válik. Ez körülbelül konkrétan az UT 11.1 konfigurációjáról. Az önállóan írt kis konfigurációk még a fájl verzióban is elég gyorsan működhetnek.

Kiegészítések a megjegyzésekből közzétételre:

Lemez töredezettségmentesitő fájlbázissal

Konvolúció adatbázis (hasznos lehet, ha az adatbázis nagy, például több éve). Az ügyfél adatbázisa meglehetősen fiatal volt, így a csökkentés nem volt praktikus.

Hardverfrissítés – gyorsabb merevlemez, új kapcsoló, processzor stb.

Telepítés webszerverre, hozzáférés vékony kliens segítségével. Itt megoszlanak a vélemények. Egyesek szerint sokszor gyorsabb, mások szerint nincs gyorsulás.

A cikk megírásának fő célja, hogy elkerülje a nyilvánvaló árnyalatok megismétlését azon rendszergazdák (és programozók) számára, akik még nem szereztek tapasztalatot az 1C-vel kapcsolatban.

A másodlagos cél az, hogy ha hiányosságaim vannak, akkor erre a leggyorsabban az Infostart tudjon rámutatni.

V. Gilev tesztje már egyfajta „de facto” mércévé vált. A szerző a honlapján elég egyértelmű ajánlásokat adott, de csak néhány eredményt adok, és a legtöbbet kommentálom valószínű hibák. Természetesen az Ön berendezésének teszteredményei eltérhetnek, ez csak egy útmutató, hogy mit kell tenni, és mire lehet törekedni. Rögtön megjegyezném, hogy a változtatásokat lépésről lépésre kell végrehajtani, és minden lépés után ellenőrizni, hogy milyen eredményt hozott.

Az Infostarton is vannak hasonló cikkek, ezekre linkeket teszek a megfelelő rovatba (ha valamit kihagyok, kérlek jelezzétek kommentben, felteszem). Tehát tegyük fel, hogy az 1C lassú. Hogyan lehet diagnosztizálni a problémát, és hogyan lehet megérteni, hogy ki a hibás, a rendszergazda vagy a programozó?

Kiinduló adatok:

Tesztelt számítógép, fő tengerimalac: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2-vel szerelve. Összehasonlításképpen a Core i3-2100 összehasonlítható eredményeket mutat az egyszálas tesztben. A felszerelés, amit konkrétan vettem, nem a legújabb volt, hanem modern felszerelés az eredmények észrevehetően jobbak.

Külön 1C és SQL szerverek teszteléséhez SQL szerver: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

A 10 Gbit-es hálózat teszteléséhez Intel 520-DA2 adaptereket használtak.

Fájl verzió. (az adatbázis megosztott mappában van a szerveren, a kliensek hálózaton keresztül csatlakoznak, CIFS/SMB protokoll). Algoritmus lépésről lépésre:

0. Adja hozzá a Gilev tesztadatbázisát a fájlszerverhez ugyanabban a mappában, mint a fő adatbázisok. Csatlakozunk az ügyfélszámítógépről, és lefuttatjuk a tesztet. Emlékszünk az eredményre.

Magától értetődik, hogy még a 10 évvel ezelőtti régi számítógépeknél is (Pentium a 775-ös foglalaton ) az 1C:Enterprise parancsikonra való kattintástól az adatbázis-ablak megjelenéséig eltelt időnek kevesebb mint egy percnek kell eltelnie. ( Celeron = lassú).

Ha egy Pentiumnál rosszabb számítógéped van 775-ös foglalat 1 GB-tal véletlen hozzáférésű memória, akkor együttérzek veled, és nehéz lesz kényelmes munkát elérni az 1C 8.2 fájlverzióban. Gondoljon a frissítésre (legfőbb ideje), vagy a terminál (vagy vékony kliensek és felügyelt űrlapok esetén webes) szerverre váltásra.

Ha a számítógép nem rosszabb, akkor kirúghatja a rendszergazdát. Legalább ellenőrizze a hálózat, a víruskereső és a HASP védelmi illesztőprogram működését.

Ha Gilev tesztje ebben a szakaszban 30 „papagáj”-ot mutatott vagy magasabb, de az 1C munkabázis még mindig lassan működik, a kérdéseket a programozóhoz kell irányítani.

1. Útmutatóként, hogy egy kliens számítógép mennyit tud „megszorítani”, csak ennek a számítógépnek a működését ellenőrizzük, hálózat nélkül. Feltesszük a tesztalapot helyi számítógép(nagyon gyors lemez). Ha az ügyfélszámítógép nem rendelkezik normál SSD-vel, akkor létrejön egy ramdisk. Egyelőre a legegyszerűbb és ingyenes a Ramdisk Enterprise.

A 8.2-es verzió teszteléséhez elég egy 256 MB-os ramdisk, és! A legfontosabb. A számítógép újraindítása után futás közben a ramdisk mellett 100-200 MB szabadnak kell lennie rajta. Ennek megfelelően ramdisk nélkül, mert normál működés A szabad memória 300-400 MB legyen.

A 8.3-as verzió teszteléséhez elég egy 256 MB-os ramdisk, de több szabad RAM kell hozzá.

Teszteléskor meg kell nézni a processzor terhelését. Ideálishoz közeli esetben (ramdisk) az 1c helyi fájl 1 processzormagot tölt be futás közben. Ennek megfelelően, ha a tesztelés során a processzormag nincs teljesen betöltve, keresse meg a gyenge pontokat. Kicsit érzelmes, de általánosságban helyesen leírják a processzor hatását az 1C működésére. Csak referenciaként, még a modern, magas frekvenciájú Core i3-asokon is elég reálisak a 70-80-as számok.

A leggyakoribb hibák ebben a szakaszban.

a) Helytelenül konfigurált víruskereső. Sok vírusirtó létezik, mindegyikhez más a beállítások, csak annyit mondok, hogy megfelelő konfigurációval sem a web, sem a Kaspersky 1C nem zavarja. Az alapértelmezett beállításokkal körülbelül 3-5 papagáj (10-15%) vihető el.

b) Teljesítmény mód. Valamiért kevesen figyelnek erre, de a hatás a legjelentősebb. Ha gyorsaságra van szüksége, akkor ezt mind kliens, mind szerver számítógépeken meg kell tennie. ( Jó leírás Gilevnél. Az egyetlen figyelmeztetés az, hogy egyeseknél alaplapok Ha kikapcsolja az Intel SpeedStep funkciót, a TurboBoost nem kapcsolhatja be).

Röviden, amíg az 1C fut, rengeteget kell várni más eszközök (lemez, hálózat stb.) válaszára. Amikor a válaszra vár, ha a teljesítmény mód engedélyezve van, a processzor csökkenti a frekvenciáját. Válasz érkezik az eszköztől, az 1C-nek (a processzornak) működnie kell, de az első órajelek csökkentett frekvencián zajlanak, majd a frekvencia növekszik - és az 1C ismét az eszköz válaszára vár. És így – sok százszor másodpercenként.

A teljesítmény módot két helyen engedélyezheti (és lehetőleg):

BIOS-on keresztül. A C1, C1E, Intel C-state (C2, C3, C4) módok letiltása. Különböző biosokban másképpen hívják őket, de a jelentés ugyanaz. Sokáig tart a keresés, újraindítás szükséges, de ha egyszer megcsinálod, akkor elfelejtheted. Ha mindent helyesen csinál a BIOS-ban, a sebesség nő. Egyes alaplapokon konfigurálhatja a BIOS-beállításokat, hogy a Windows teljesítménymódja ne játsszon szerepet. (Példák BIOS beállítások Gilevben). Ezek a beállítások főként szerverprocesszorokra vagy „fejlett” BIOS-okra vonatkoznak, ha ezt nem találtad meg, és NINCS Xeonod, az rendben van.

Vezérlőpult - Tápellátás - Nagy teljesítmény. Mínusz - ha a számítógépet hosszabb ideig nem szervizelték, akkor nagyobb ventilátorzajt ad, jobban felmelegszik és több energiát fogyaszt. Ez teljesítménydíj.

Hogyan ellenőrizhető, hogy a mód engedélyezve van-e. Indítsa el a feladatkezelőt - teljesítmény - erőforrásfigyelő - CPU. Megvárjuk, amíg a processzor semmivel nem lesz elfoglalva.

Ezek az alapértelmezett beállítások. BIOS C-állapotban beleértve, kiegyensúlyozott energiafogyasztási mód
BIOS C-állapotban beleértve, nagy teljesítményű üzemmód A Pentium és a Core esetében itt megállhat, A Xeonból még ki lehet préselni egy kis "papagájokat".
BIOS C-állapotban kikapcsolt, nagy teljesítményű üzemmód. Ha nem használod a Turbo boost-ot, akkor ennek így kell kinéznie teljesítményre hangolt szerver

És most a számok. Hadd emlékeztesselek: Intel Xeon 5650, ramdisk. Az első esetben a teszt 23,26-ot mutat, az utolsóban - 49,5. A különbség majdnem kétszeres. A számok változhatnak, de az arány lényegében ugyanaz marad az Intel Core esetében.

Kedves adminisztrátorok, bármennyit kritizálhatnak az 1C-vel, de ha a végfelhasználóknak gyorsaságra van szükségük, akkor engedélyezni kell a nagy teljesítményű módot.

c) Turbo Boost. Először meg kell értenie, hogy például a processzora támogatja-e ezt a funkciót. Ha támogatja, akkor még mindig legálisan szerezhet némi teljesítményt. (Nem akarok a frekvencia túlhúzás problémáival foglalkozni, főleg a szervereknél, ezt csak a saját károdra és kockázatodra tedd. De egyetértek azzal, hogy a busz sebességének 133-ról 166-ra való növelése nagyon észrevehető növekedést eredményez mind a sebességben, mind a hőleadásban)

A turbo boost bekapcsolásának módja például meg van írva. De! Az 1C esetében van néhány árnyalat (nem a legnyilvánvalóbb). A nehézség az, hogy a turbóerősítés maximális hatása a C állapot bekapcsolásakor jelentkezik. És valami ilyesmit kapunk:

Kérjük, vegye figyelembe, hogy a szorzó a maximális, a mag sebessége gyönyörű, és a teljesítmény magas. De mi lesz ennek eredményeként az 1-esekkel?

	Tényező	Magsebesség (frekvencia), GHz	CPU-Z egyszálú	Gilev Ramdisk teszt fájl verzió	Gilev Ramdisk teszt kliens-szerver
Turbo boost nélkül
C-állapot kikapcsolva, Turbo boost				53.19	40,32
C-állapot be, Turbo boost			1080	53,13	23,04

De a végén kiderül, hogy a CPU-teljesítménytesztek szerint a 23-as szorzós verzió van előrébb, Gilev tesztjei szerint a fájlverzióban a 22-es és 23-as szorzós teljesítmény ugyanaz, de a kliens-szerverben verzió - a 23-as szorzóval rendelkező verzió rettenetesen szörnyű (még ha a C állapot 7-es szintre van állítva, akkor is lassabb, mint kikapcsolt C állapot esetén). Ezért azt javasoljuk, hogy ellenőrizze mindkét lehetőséget, és válassza ki a legjobbat. Mindenesetre a 49,5 és 53 papagájok közötti különbség meglehetősen jelentős, különösen nagy erőfeszítés nélkül.

Következtetés - a turbóerősítést be kell kapcsolni. Hadd emlékeztesselek arra, hogy nem elég engedélyezni a Turbo boost elemet a BIOS-ban, meg kell nézni a többi beállítást is (BIOS: QPI L0s, L1 - disable, scrubbering - disable, Intel SpeedStep - enable, Turbo boost - Vezérlőpult – Energiagazdálkodási lehetőségek – Nagy teljesítmény) . És továbbra is (még a fájlverziónál is) azt az opciót választanám, ahol a c-state ki van kapcsolva, pedig kisebb a szorzó. Valami ilyesmi lesz belőle...

Egy meglehetősen ellentmondásos pont a memória frekvenciája. Például kimutatták, hogy a memória frekvenciája nagyon erős befolyást gyakorol. A tesztjeim nem mutattak ki ilyen függőséget. A DDR 2/3/4-et nem fogom összehasonlítani, ugyanazon a vonalon belül mutatom meg a frekvenciaváltás eredményeit. A memória ugyanaz, de a BIOS-ban kénytelenek vagyunk alacsonyabb frekvenciákat beállítani.

És a teszteredmények. 1C 8.2.19.83, helyi ramdisk fájlverzióhoz, 1C kliens-szerverhez és SQL-hez egy számítógépen, megosztott memória. A Turbo Boost mindkét verzióban le van tiltva. A 8.3 összehasonlítható eredményeket mutat.

A különbség a mérési hibán belül van. Konkrétan kihúztam a CPU-Z képernyőképeit, hogy megmutassam, hogy a frekvencia változásával más paraméterek is változnak, ugyanaz a CAS Latency és a RAS to CAS Delay, ami semlegesíti a frekvencia változását. A különbség a memóriamodulok fizikai cseréjekor lesz, lassabbról gyorsabbra, de még ott sem különösebben jelentősek a számok.

2. Miután rendeztük a kliens számítógép processzorát és memóriáját, áttérünk a következő nagyon fontos helyre - a hálózatra. Sok könyvet írtak a hálózati tuningról, vannak cikkek az Infostartról (és mások), de itt nem foglalkozom ezzel a témával. Mielőtt elkezdené az 1C tesztelését, győződjön meg arról, hogy a két számítógép közötti iperf a teljes sávszélességet mutatja (1 Gbit-es kártyák esetén - nos, legalább 850 Mbit, vagy még jobb 950-980), és betartották-e Gilev tanácsát. Ezután - a legegyszerűbb működési teszt furcsa módon egy nagy fájl (5-10 gigabájt) másolása lesz a hálózaton keresztül. A normál működés közvetett jele egy 1 Gbit-es hálózaton a 100 MB/sec átlagos másolási sebesség, a jó működés pedig 120 MB/sec. Szeretném felhívni a figyelmet, hogy a gyenge pont (beleértve) a processzor terhelése lehet. SMB A Linux protokollja meglehetősen gyengén párhuzamosított, és működés közben elég könnyen „felfal” egy processzormagot, és nem fogyaszt többet.

És tovább. A Windows alapértelmezett beállításaival az ügyfél Windows szerverrel működik a legjobban (vagy akár ablakok működnek station) és az SMB/CIFS protokoll, a linux kliens (debian, az ubuntu nem nézte a többit) jobban működik linuxszal és NFS-sel (SMB-vel is működik, de NFS-en magasabbak a papagájok). Az a tény, hogy lineáris másolás során egy Windows Linux szerver NFS-re gyorsabban másolódik egy adatfolyamba, nem jelent semmit. A Debian tuning 1C-re külön cikk témája, még nem állok készen rá, bár elmondhatom, hogy a fájl verzióban még valamivel jobb teljesítményt is kaptam, mint a Win verzió ugyanazon a berendezésen, de postgres-el over-el 50 felhasználó Még mindig minden nagyon rossz.

A legfontosabb , amit a „leégett” adminisztrátorok tudnak, de a kezdők nem veszik figyelembe. Számos módja van az 1c adatbázis elérési útjának beállítására. Csinálhatod a \\server\share, megteheted a \\192.168.0.1\share parancsot, netezheted a z: \\192.168.0.1\share parancsot (és bizonyos esetekben ez a módszer is működik, de nem mindig), majd adja meg a Z meghajtót. Úgy tűnik, hogy ezek az útvonalak ugyanarra a helyre mutatnak, de az 1C esetében csak egy mód van, amely elég megbízhatóan biztosítja a normál teljesítményt. Tehát a következőket kell helyesen tennie:

BAN BEN parancs sor(vagy házirendekben, vagy tetszés szerint) - használja a DriveLetter-t: \\server\share. Példa: net use m: \\server\bases. Kifejezetten hangsúlyozom NEM az IP címet, mégpedig Név szerver. Ha a kiszolgáló neve nem látható, adja hozzá a kiszolgáló DNS-éhez, vagy helyileg a hosts fájlhoz. De a címnek név szerint kell lennie. Ennek megfelelően az adatbázis felé vezető úton érje el ezt a lemezt (lásd a képet).

És most számokkal mutatom meg, hogy miért ez a tanács. Kiinduló adatok: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 kártyák OS Win 2008 R2, Win 7, Debian 8. Legújabb illesztőprogramok, frissítések alkalmazva. Tesztelés előtt megbizonyosodtam arról, hogy az Iperf a teljes sávszélességet adja (a 10 Gbit-es kártyákat leszámítva csak 7,2 Gbit-et sikerült kicsikarnia, később meglátom, miért, a tesztszerver még nincs megfelelően beállítva). A lemezek különbözőek, de mindenhol van SSD (speciálisan egy lemezt tettem bele tesztelésre, mással nincs feltöltve) vagy raid SSD-ről. A 100 Mbit sebességet az Intel 362 adapter beállításainak korlátozásával kaptuk, az 1 Gbit réz Intel 350 és az 1 Gbit optikai Intel X520-DA2 között (az adapter sebességének korlátozásával kapott) nem volt különbség. Maximális teljesítmény, a turbo boost ki van kapcsolva (csak az eredmények összehasonlíthatósága miatt, a jó eredményekhez a turbónövelés kicsivel kevesebb, mint 10%-ot tesz hozzá, rossz eredmények esetén előfordulhat, hogy egyáltalán nincs hatása). 1C verzió 8.2.19.86, 8.3.6.2076. Nem adom meg az összes számot, csak a legérdekesebbeket, hogy legyen mihez hasonlítani.

	Win 2008 - Win 2008 elérhetőség ip címen	Win 2008 - Win 2008 Név szerint szólítva	Win 2008 - Win 2008 Kapcsolatfelvétel IP-cím alapján	Win 2008 - Win 2008 Név szerint szólítva	Win 2008 - Win 7 Név szerint szólítva	Win 2008 – Debian Név szerint szólítva	Win 2008 - Win 2008 Kapcsolatfelvétel IP-cím alapján	Win 2008 - Win 2008 Név szerint szólítva
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1C 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Következtetések (a táblázatból és a személyes tapasztalat. Csak a fájlverzióra vonatkozik):

A hálózaton keresztül egészen normális számokat kaphat a munkához, ha ez a hálózat megfelelően van konfigurálva, és az elérési út helyesen van megadva az 1C-ben. Már az első Core i3 is simán tud 40+ papagájokat produkálni, ami egész jó, és ezek nem csak papagájok, valós munkában is érezhető a különbség. De! Több (10-nél több) felhasználóval való munkavégzésnél már nem a hálózat lesz a korlát, itt még elég 1 Gbit, de többfelhasználós munkavégzésnél blokkol (Gilev).

Az 1C 8.3 platform többszörösen megköveteli a megfelelő hálózati konfigurációt. Alapbeállítások – lásd Gilev, de ne feledje, hogy minden befolyásolható. Felgyorsult a vírusirtó eltávolítása (és nem csak kikapcsolása), az olyan protokollok eltávolítása, mint az FCoE, az illesztőprogramok régebbi, de Microsoft által hitelesített verzióra való cseréje (különösen az olyan olcsó kártyák esetében, mint az ASUS és a DLC), és a második hálózati kártya eltávolítása. a szerverről. Nagyon sok lehetőség van, gondosan állítsa be a hálózatot. Előfordulhat olyan helyzet, hogy a 8.2-es platform elfogadható számokat ad, a 8.3-as pedig kétszer vagy akár többször is kevesebbet. Próbáljon meg játszani a 8.3-as platformverzióval, néha nagyon nagy hatást ér el.

Az 1C 8.3.6.2076 (talán később, még nem kerestem a pontos verziót) még mindig könnyebben konfigurálható a hálózaton, mint a 2008.7.8. 2008.07.08-tól (hasonló papagájoknál) csak néhányszor tudtam normális működést elérni a hálózaton keresztül, általánosabb esetre nem tudnám megismételni. Nem sokat értettem, de a Process Explorer lábpakolásaiból ítélve ott nem olyan jó a felvétel, mint a 8.3.6-ban.

Annak ellenére, hogy 100 Mbit-es hálózaton dolgozva kicsi a terhelési ütemezése (mondhatjuk, hogy a hálózat ingyenes), a működési sebesség még mindig jóval kisebb, mint az 1 Gbit-en. Ennek oka a hálózati késleltetés.

Ha minden más tényező megegyezik (jól működő hálózat), az 1C 8.2 esetében az Intel-Realtek kapcsolat 10%-kal lassabb, mint az Intel-Intel. De a realtek-realtek általában hirtelen tud éles süllyedést okozni. Ezért, ha van pénzed, jobb, ha mindenhol tartasz Intel hálózati kártyákat; ha nincs pénzed, akkor csak a szerverre (a CO-ra) telepítsd az Intelt. Az Intel hálózati kártyák hangolására pedig sokszor több instrukció van.

Az alapértelmezett víruskereső beállítások (példaként a 10-es drweb verzió használatával) a papagájok körülbelül 8-10%-át foglalják el. Ha úgy konfigurálod, ahogy kell (engeded, hogy az 1cv8 folyamat csináljon mindent, bár ez nem biztonságos), akkor a sebesség ugyanaz, mint vírusirtó nélkül.

NE olvass Linux gurukat. A sambával rendelkező szerver nagyszerű és ingyenes, de ha Win XP-t vagy Win7-et (vagy még jobb - szerver operációs rendszert) telepít a szerverre, akkor az 1c fájlverzió gyorsabban fog működni. Igen, debian/ubuntuban jól hangolható a samba és a protokollverem és a hálózati beállítások és még sok minden más, de ez a szakembereknek ajánlott. Nincs értelme alapértelmezett beállításokkal telepíteni a Linuxot, és azt mondani, hogy lassú.

Egészen jó ötlet a nethasználaton keresztül csatlakoztatott lemezek működését fio segítségével ellenőrizni. Legalább kiderül, hogy ezek a problémák az 1C platformmal, vagy a hálózattal/lemezzel vannak-e.

Az egyfelhasználós verziónál nem jut eszembe olyan teszt (vagy olyan helyzet), ahol látható lenne az 1 Gbit és a 10 Gbit közötti különbség. Az egyetlen dolog, ahol a 10 Gbit a fájlverzióhoz jobb eredményeket hozott, az a lemezek iSCSI-n keresztüli csatlakoztatása, de ez egy külön cikk témája. Ennek ellenére úgy gondolom, hogy a fájlverzióhoz elég az 1 Gbit-es kártya.

Nem értem, hogy 100 Mbit-es hálózatnál a 8.3 miért működik érezhetően gyorsabban, mint a 8.2, de tény volt. Az összes többi berendezés, az összes többi beállítás teljesen azonos, csak az egyik esetben a 8.2-t, a másikban a 8.3-at tesztelik.

A nem tuningolt NFS win-win vagy win-lin 6 papagájt ad, ezeket nem vettem fel a táblázatba. Tuning után 25-öt kaptam, de instabil volt (a mérések különbsége több mint 2 egység volt). még nem tudok ajánlani windows segítségévelés NFS protokoll.

Minden beállítás és ellenőrzés után újra lefuttatjuk a tesztet a kliens számítógépről, és örülünk a javuló eredménynek (ha működik). Ha az eredmény javult, több mint 30 papagáj (és különösen több mint 40), kevesebb mint 10 felhasználó dolgozik egyszerre, és a működő adatbázis továbbra is lassú - szinte biztos, hogy a programozóval van a probléma (vagy már elérte a fájlverzió csúcsképességét).

Terminál szerver. (az adatbázis a szerveren van, a kliensek hálózaton keresztül kapcsolódnak, RDP protokoll). Algoritmus lépésről lépésre:

0. Adja hozzá a Gilev tesztadatbázisát a kiszolgálóhoz ugyanabban a mappában, mint a fő adatbázisok. Ugyanarról a szerverről csatlakozunk, és futtatjuk a tesztet. Emlékszünk az eredményre.

1. Ugyanúgy, mint a fájl verzióban, beállítjuk a munkát. A terminálszerverek esetében általában a processzoré a főszerep (feltételezzük, hogy nincsenek nyilvánvaló gyenge pontok, például memóriahiány vagy hatalmas mennyiségű felesleges szoftver).

2. A hálózati kártyák beállítása terminálszerver esetén gyakorlatilag nincs hatással az 1c működésére. A „különleges” kényelem érdekében, ha a szervere több mint 50 papagájt termel, az RDP protokoll új verzióival játszhat, csak a felhasználók kényelme, a gyorsabb válaszadás és görgetés érdekében.

3. Ha nagyszámú felhasználó dolgozik aktívan (és itt már meg lehet próbálni 30 ember csatlakoztatását egy adatbázishoz, ha megpróbálja), nagyon célszerű SSD meghajtót telepíteni. Valamilyen oknál fogva úgy gondolják, hogy a lemez nem befolyásolja különösebben az 1C működését, de minden tesztet úgy hajtanak végre, hogy a vezérlő gyorsítótárában engedélyezve van az írás, ami hibás. A tesztbázis kicsi, elég jól elfér a gyorsítótárban, innen a magas számok. Valódi (nagy) adatbázisokon minden teljesen más lesz, így a gyorsítótár le van tiltva a tesztekhez.

Például a Gilev-teszt működését különböző lemezopciókkal ellenőriztem. Felraktam a lemezeket abból, ami kéznél volt, csak hogy megmutassam a tendenciát. 2076.06.8. és 2008.07.08. között kicsi a különbség (a Ramdisk Turbo boost 8.3.6-os verziója 56.18-at, a 2008.07.08. pedig 55.56-ot produkál, más teszteknél még kisebb a különbség). Energiafogyasztás - maximális teljesítmény, turbónövelés letiltva (hacsak nincs másképp jelezve).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Egyetlen SSD	Ramdisk		Gyorsítótár engedélyezve RAID vezérlő
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1C 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Az engedélyezett RAID-vezérlő gyorsítótár kiküszöböli a lemezek közötti különbségeket; a számok ugyanazok a sat és a cas esetében is. A vele végzett tesztelés kis mennyiségű adaton haszontalan, és nem utal semmire.

A 8.2-es platformon több mint kétszeres a különbség a SATA és az SSD opciók között. Ez nem elírás. Ha megnézi a teljesítményfigyelőt a SATA meghajtókon végzett teszt során. akkor jól látható az „Aktív lemez működési ideje (%)” 80-95. Igen, ha engedélyezi a lemezek gyorsítótárát a rögzítéshez, a sebesség 35-re nő, ha engedélyezi a raid vezérlő gyorsítótárát - 49-ig (függetlenül attól, hogy melyik lemezt tesztelik Ebben a pillanatban). De ezek szintetikus gyorsítótár papagájok; valós munkában, nagy adatbázisokkal soha nem lesz 100%-os írási gyorsítótár találati aránya.

Még az olcsó SSD-k sebessége is (Agility 3-on teszteltem) bőven elegendő a fájlverzió futtatásához. A rögzítési erőforrás az egy másik kérdés, ezt minden konkrét esetben meg kell nézni, egyértelmű, hogy az Intel 3700-ban egy nagyságrenddel magasabb lesz, de az ár megfelelő. És igen, ezt megértem a tesztelés során SSD meghajtó Ennek a lemeznek a gyorsítótárát is nagyobb mértékben tesztelem, a valós eredmény kevesebb lesz.

A leghelyesebb (szempontom szerint) megoldás az lenne, ha egy tükrözött raidben 2 SSD lemezt foglalnánk le egy fájl adatbázishoz (vagy több fájl adatbázishoz), és nem helyeznénk oda semmi mást. Igen, tükörrel az SSD-k egyformán kopnak, és ez egy mínusz, de legalább a vezérlő elektronikája valahogy védett a hibáktól.

Az SSD-meghajtók fő előnyei a fájlverzióhoz akkor fognak megjelenni, ha sok adatbázis van, mindegyik több felhasználóval. Ha van 1-2 adatbázis, és kb 10 felhasználó, akkor elég lesz a SAS lemez. (de mindenesetre nézd meg ezeket a lemezeket, legalábbis perfmon-on keresztül).

A terminálszerver fő előnye, hogy nagyon gyenge kliensekkel rendelkezhet, és a hálózati beállítások sokkal kevésbé hatnak a terminálkiszolgálóra (ismét a K.O.).

Következtetések: ha terminál szerver futtassa a Gilev-tesztet (ugyanarról a lemezről, ahol a működő adatbázisok találhatók), és azokban a pillanatokban, amikor a működő adatbázis lelassul, és a Gilev-teszt jó eredményt mutat (30 felett) - akkor valószínűleg a programozó hibáztatja a a fő működő adatbázis lassú működése.

Ha Gilev tesztje kis számokat mutat, és magas órajelű processzorral és gyors lemezekkel rendelkezik, akkor az adminisztrátornak legalább perfmonot kell vennie, valahova rögzítenie kell az összes eredményt, és figyelnie kell, megfigyelnie kell, és következtetéseket kell levonnia. Nem lesz végleges tanács.

Kliens-szerver opció.

A teszteket csak a 8.2-n végezték el, mert 8.3-on minden elég komolyan a verziótól függ.

A teszteléshez különböző szerverlehetőségeket és a köztük lévő hálózatokat választottam, hogy megmutassam a főbb trendeket.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiber csatorna - SSD	SQL: Xeon E5-2630 Fiber csatorna - SAS	SQL: Xeon E5-2630 Helyi SSD	SQL: Xeon E5-2630 Fiber csatorna - SSD	SQL: Xeon E5-2630 Helyi SSD	1C: Xeon 5650 =	1C: Xeon 5650 = Megosztott memória	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1C 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Úgy tűnik, minden érdekes lehetőséget átgondoltam, ha van még valami, ami érdekel, írd meg kommentben, megpróbálom megtenni.

A tárolórendszereken lévő SAS lassabb, mint a helyi SSD-k, annak ellenére, hogy a tárolórendszerek gyorsítótár mérete nagyobb. Az SSD-k, mind a helyi, mind a tárolórendszereken, összehasonlítható sebességgel működnek Gilev tesztje során. Nem ismerek semmilyen szabványos többszálas tesztet (nem csak rögzítést, hanem minden berendezést), kivéve az MCC 1C terhelési tesztjét.

Az 1C szerver 5520-ról 5650-re cseréje csaknem megkétszerezte a teljesítményt. Igen, a szerver konfigurációk nem teljesen egyeznek, de ez egy tendenciát mutat (nem meglepő).

A frekvencia növelése az SQL szerveren biztosan meghozza a hatását, de nem ugyanazt, mint az 1C szerveren; az MS SQL szerver kiválóan alkalmas (ha kérdezed) többmagos és szabad memória használatára.

Ha a hálózatot 1C és SQL között 1 Gbitről 10 Gbit-re változtatjuk, a papagájok körülbelül 10%-át eredményezi. többet vártam.

Az Osztott memória engedélyezése továbbra is ad hatást, bár nem 15%-os, ahogyan azt leírtuk. Mindenképpen tedd meg, szerencsére gyors és egyszerű. Ha a telepítés során valaki adott egy elnevezett példányt az SQL szervernek, akkor ahhoz, hogy az 1C működjön, a kiszolgálónevet nem FQDN-nel kell megadni (a tcp/ip fog működni), nem a localhost-on vagy csak a Kiszolgálónéven keresztül, hanem például a Kiszolgálónév\Példánynéven keresztül zz-teszt\zzteszt. (Egyébként DBMS hiba lesz: Microsoft SQL szerver Native Client 10.0: Shared Memory Provider: Az SQL Server 2000-hez való kapcsolat létrehozásához használt megosztott memória könyvtár nem található. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, állapot=1, Súlyosság=10, natív=126, sor=0).

100-nál kevesebb felhasználó esetén a két különálló szerverre való felosztás egyetlen pontja a Win 2008 Std (és régebbi) licenc, amely csak 32 GB RAM-ot támogat. Minden más esetben az 1C-t és az SQL-t feltétlenül egy szerverre kell telepíteni, és több (legalább 64 GB) memóriát kell adni. Indokolatlan kapzsiság az MS SQL-nek 24-28 GB-nál kevesebb RAM-ot adni (ha úgy gondolod, hogy van hozzá elég memória, és minden jól működik, talán az 1C fájlverziója is elég lenne neked?)

Mennyivel rosszabbul működik az 1C és az SQL kombinációja Virtuális gép- egy külön cikk témája (tipp - észrevehetően rosszabb). Még a Hyper-V-ben sem minden olyan egyértelmű...

A kiegyensúlyozott teljesítmény mód rossz. Az eredmények teljesen összhangban vannak a fájl verziójával.

Sok forrás szerint a hibakeresési mód (ragent.exe -debug) jelentős teljesítménycsökkenést okoz. Nos, csökkenti, igen, de a 2-3%-ot nem nevezném jelentős hatásnak.

Nagyon gyakran fordulnak hozzánk olyan kérdésekkel, mint:

• Miért lassul le az 1C szerver?
• Az 1C számítógép nagyon lassú
• Az 1C kliens rettenetesen lassú

Néha a probléma megoldásaként kínálunk ügyfeleinknek egy fék nélküli bérelhető 1C szervert, választható szerverkonfigurációval és operációs rendszerrel, a szervert online konfigurálhatja partnerünk weboldalán, a link segítségével. https://1cloud.ru fejezet Szolgáltatások, fejezet Virtuális szerver.

Mit kell tenni és hogyan lehet leküzdeni, és így tovább sorrendben:

Az ügyfelek nagyon lassan dolgoznak az 1C szerververziójával

Az 1C lassú működése mellett lassú a munka a hálózati fájlokkal is. A probléma normál működés közben és az RDP-nél jelentkezik

ennek megoldására a Seven vagy a 2008-as szerver minden telepítése után mindig elindítom

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=letiltva chimney=letiltva

és a hálózat problémamentesen működik

néha a legjobb megoldás:

netsh interface tcp set global autotuning= HighlyRestricted

így néz ki a telepítés

Állítsa be a víruskeresőt vagy a Windows tűzfalat

Víruskereső vagy Windows tűzfal konfigurálása 1C kiszolgáló futtatásához (például az 1C Server: Enterprise és az MS SQL 2008 kombinációja).

Szabályok hozzáadása:

• Ha az SQL-kiszolgáló fogad kapcsolatokat a szabványos 1433-as TCP-porton, akkor engedélyezzük.
• Ha az SQL-port dinamikus, akkor engedélyezni kell a kapcsolatot a %ProgramFiles%\ alkalmazással Microsoft SQL Szerver\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
• Az 1C szerver az 1541-es portokon, az 1540-es fürtön és az 1560-1591-es tartományon fut. Teljesen misztikus okokból néha a nyitott portok ilyen listája mégsem teszi lehetővé a kapcsolatot a szerverrel. Annak érdekében, hogy biztosan működjön, engedélyezze az 1540-1591 tartományt.

Szerver/számítógép teljesítményhangolás

Annak érdekében, hogy számítógépe maximális teljesítménnyel működjön, ehhez be kell állítania:

1. BIOS beállítások

• A szerver BIOS-ában letiltunk minden beállítást a processzor energiájának megtakarítása érdekében.
• Ha van „C1E”, és feltétlenül SZABADÍTSA LE!!
• Egyes, nem túl párhuzamos feladatoknál javasolt a hypertrading kikapcsolása is a BIOS-ban
• Bizonyos esetekben (főleg a HP-nál!) be kell lépni a szerver BIOS-ba, és ott ki kell kapcsolni azokat az elemeket, amelyek nevében az EIST, Intel SpeedStep és C1E szerepel.
• Ehelyett meg kell találni a processzorral kapcsolatos elemeket, amelyek nevében szerepel a Turbo Boost, és ENGEDÉLYEZNI kell őket.
• Ha a BIOS-ban általános jelzés látható az energiatakarékos módról, és kapcsolja be maximális teljesítmény(agresszívnek is nevezhetjük)

2. Sémabeállítások az operációs rendszerben - Nagy teljesítmény

Az Intel Sandy Bridge architektúrájú szerverek dinamikusan módosíthatják a processzorok frekvenciáját.

Néha az 1C szerver lassú működésének problémájára a megoldás az elavult vagy tönkrement berendezés, ebben az esetben az ügyfeleknek 1C-hez bérelhető szervert kínálunk fék nélkül, választható szerverkonfigurációval és operációs rendszerrel, ezt megteheti a mi oldalunkon. partner weboldalán, a linken https://1cloud.ru Szolgáltatások szakasz, Virtuális szerver rész.

Ha kérdése van, forduljon:

• hívja a +7-812-385-55-66-ot Szentpéterváron
• írj a címre
• hagyjon jelentkezést weboldalunkon az "Online jelentkezés" oldalon

2. A program jellemzői. Az 1C gyakran még optimális beállítások mellett is nagyon lassan működik. A teljesítmény különösen akkor csökken, ha az adatbázissal egyidejűleg dolgozók száma meghaladja a 4-5 felhasználót.

Ki vagy a társaságban?

A lassú 1C működés problémájának megoldása attól függ, hogy Ön ki a cég tagja. Ha technikus vagy, csak olvass tovább. Ha Ön igazgató vagy könyvelő, kövesse a ↓ speciális hivatkozást

Hálózati sávszélesség

Általában eggyel információs bázis(IB) nem egy, hanem több felhasználó dolgozik. Ugyanakkor folyamatos adatcsere folyik a számítógép között, amelyre az 1C kliens telepítve van, és a számítógép között, amelyen az információbiztonság található. Ezen adatok mennyisége meglehetősen jelentős. Gyakran előfordul olyan helyzet, amikor a 100 Mbit/s sebességgel működő helyi hálózat, ami a leggyakoribb sebesség, egyszerűen nem tud megbirkózni a terheléssel. És ismét a felhasználó panaszkodik a program lassúságára.

Ezen tényezők mindegyike külön-külön már jelentősen csökkenti a program sebességét, de a legkellemetlenebb az, hogy általában ezek a dolgok összeadódnak.

Most nézzünk meg néhány megoldást az alacsony 1C működési sebesség problémájára és ezek költségeire a példa segítségével helyi hálózat 10 átlagos számítógépből.

Megoldás egy. Infrastruktúra korszerűsítése

Ez talán a legkézenfekvőbb megoldás. Számítsuk ki a minimális költségét.

Minden számítógéphez legalább 2 GB RAM-ra van szükségünk, ami átlagosan 1500 rubelbe kerül, LAN kártya 1 Gbit/s sebesség támogatásával körülbelül 700 rubel. Ezenkívül legalább 1 routerre lesz szüksége, amely támogatja az 1 Gbit/s sebességet, ami körülbelül 4000 rubelbe fog kerülni. Teljes költség - 26 000 rubel felszerelésre, a munka nélkül.

Elvileg a sebesség jelentősen megnőhet, azonban most már nem lehet olcsón irodai számítógépeket vásárolni. Kívül, ezt a döntést nem vonatkozik azokra, akik Wi-Fi-t használnak, vagy interneten keresztül szeretnének dolgozni – esetükben a hálózati sebesség akár tízszeres is lehet. Ez felveti a kérdést: „Megvalósítható-e a teljes program egyetlen nagy teljesítményű szerveren úgy, hogy a felhasználó számítógépe ne vegyen részt a összetett számítások, hanem egyszerűen kép továbbítására szolgál?” Ekkor még nagyon gyenge számítógépeken is dolgozhat, még alacsony sávszélességű hálózatokon is. Természetesen léteznek ilyen megoldások.

Második megoldás. Terminál szerver

Nagy népszerűségre tett szert az 1C 7 idejében. A szerveren implementálva Windows verziókés tökéletesen megbirkózik a feladatunkkal. Ennek azonban megvannak a buktatói, nevezetesen a licencek költsége.

Önmaga operációs rendszer körülbelül 40 000 rubelbe kerül. Ezen kívül mindenkire szükségünk lesz, aki 1C-ben tervez dolgozni Windows licenc Szerver CAL, amelynek költsége körülbelül 1700 rubel, és egy Windows Remote Desktop Services CAL licence, amely körülbelül 5900 rubelbe kerül.

A 10 számítógépből álló hálózat költségének kiszámítása után 116 000 rubelt kapunk. csak egy licencre. Ehhez hozzá kell adni magának a szervernek a költségét (legalább 40 000 rubelt) és a megvalósítási munkák költségeit, azonban e nélkül is lenyűgözőnek bizonyult a licencek ára.

Harmadik megoldás. Service 1C Enterprise

Az 1C erre a problémára saját megoldást fejlesztett ki, ami jelentősen megnövelheti a program sebességét. De itt is van egy árnyalat.

A helyzet az, hogy egy ilyen megoldás költsége a kiadástól függően 50 000 és 80 000 rubel között mozog. Egy legfeljebb 15 felhasználóval rendelkező cég számára ez meglehetősen drága. Nagy reményeket fűztek az „1C vállalati miniszerverhez”, amely az 1C cég szerint kisvállalkozásoknak szól, és körülbelül 10 000 - 15 000 rubelbe kerül.

Amikor azonban eladásra került, ez a termék nagy csalódás volt. Az a tény, hogy a miniszerver maximálisan használható felhasználói száma mindössze 5 volt.

Ahogy egy 1C programozó írta a fórumon: „Még mindig nem világos, hogy az 1C miért választott pontosan 5 kapcsolatot! A problémák csak 4 felhasználóval kezdődnek, de öttel minden véget ér. Ha hatodik embert akarsz bekötni, fizess még 50 ezret. Legalább 10 bekötést meg tudnánk csinálni...”

Természetesen a miniszerver is megtalálta a fogyasztóját. Azoknál a cégeknél azonban, ahol 5 vagy több ember dolgozik 1C-vel, nem jelent meg egyszerű és olcsó megoldás.

A fent leírt programgyorsítási módszereken kívül van egy másik, amely ideális az 5-15 felhasználós szegmens számára, nevezetesen az 1C webelérése fájl módban.

Negyedik megoldás. Internetes hozzáférés az 1C-hez fájl módban

A működés elve a következő: a számítógépen egy további webszerver szerepkör van telepítve, amelyen az információbiztonság közzétételre kerül.

Természetesen ennek vagy a hálózat legerősebb számítógépének kell lennie, vagy egy külön gépnek kell lennie, amelyet erre a szerepre szenteltek. Ezt követően webszerver módban dolgozhat az 1C-vel. Minden súlyos műveletet a szerver oldalon hajtanak végre, és a hálózaton keresztül továbbított forgalom minimalizálódik, csakúgy, mint a kliens számítógépének terhelése.

Így még nagyon gyenge gépekkel is lehet dolgozni 1C-ben, ill áteresztőképesség a hálózat már nem válik kritikussá. Tesztjeink azt mutatták, hogy kényelmesen tud dolgozni Mobilinternet olcsó táblagépen anélkül, hogy bármilyen kellemetlenséget tapasztalna.

Ez az opció a működési sebesség szempontjából rosszabb, mint a vállalati 1C szerver, de ez a különbség gyakorlatilag láthatatlan 15-20 felhasználó számára. A webszerver megvalósításához egyébként használhat IIS-t (Windows-hoz) és Apache-ot (Linux-hoz), és mindkét megoldás ingyenes!

A nyilvánvaló előnyök ellenére ez a módszer az 1C működésének optimalizálása nem tett szert nagy népszerűségre.

Nem tudom biztosan megmondani, de valószínűleg ennek két oka lehet:

• Elég gyenge leírás a műszaki dokumentációban
• A felelősség csomópontjában található rendszergazdaés 1C programozó

Általában, amikor egy rendszergazdához fordulnak alacsony sebességgel kapcsolatos problémával, az infrastruktúra vagy egy terminálszerver frissítését javasolja; ha egy 1C szakembert keresnek fel, felajánlanak neki egy 1C vállalati szervert. Tehát, ha az Ön cégében az infrastruktúráért és az 1C-ért felelős szakember „kéz a kézben” dolgozik, akkor nyugodtan használhat egy webszerveren alapuló megoldást.

Gyorsítsunk 1C-ot. Távolról, gyorsan és az Ön részvétele nélkül

Tudjuk, hogyan gyorsítsuk fel az 1Ski-t anélkül, hogy megzavarnánk az ügyfeleket. Belemerülünk a problémába, elvégezzük a dolgunkat és távozunk. Ha azt szeretné, hogy a program normálisan működjön, lépjen kapcsolatba velünk. Majd kitaláljuk.

Hagyjon igényt és kérjen ingyenes konzultációt a program felgyorsításával kapcsolatban.