To je pokrenulo nekoliko pitanja o 1C načinima rada.

Načini rada sa informacijskom bazom:
Verzija fajla rada
Klijent - server verzija rada

Način rada datoteke

Fajl verzija rada je dizajnirana za lični rad jednog korisnika, ali je dostupan i rad više korisnika preko mreže. Paralelna obrada dokumenata u ovom režimu je nemoguća. U prosjeku, oko 10 korisnika može istovremeno raditi u file modu.
Nije potrebna kupovina ključa servera.
U režimu rada datoteka cjelokupna baza podataka (baza podataka, konfiguracija) se pohranjuje u datoteci 1Cv8.1CD.

1Cv8.1CD je baza podataka datoteka

Datotečnom bazom podataka (datoteka 1Cv8.1CD) upravlja File DBMS, koji je dio platforme 1C:Enterprise.
U fajl modu rada simulira se klijent-server način rada, tako da se i dalje morate pridržavati razvojnog mehanizma klijent-server.

Ako datoteka 1Cv8.1CD prelazi 4 GB. Sada je vrijeme da razmislite o prelasku na klijent-server verziju rada.

Veliki nedostatak načina rada datoteka je niska sigurnost informacija.

Šema rada u verziji datoteke

Debela klijentska aplikacija direktno pristupa bazi podataka i prima odgovor. Tanki klijent također direktno pristupa bazi podataka koristeći svoj vlastiti protokol. Web klijent pristupa bazi podataka sa koristeći Web server.

Za prebacivanje iz načina rada datoteke na klijent-server Dovoljno je preuzeti informacijsku bazu u dt formatu, a zatim je učitati u bazu podataka kreiranu na serveru.

Klijent-server verzija rada

Opcija klijent-server je pogodna za rad sa informacijskom bazom velikog broja korisnika. Pouzdanost baze podataka garantuje DBMS, koji sadrži mehanizme automatskog arhiviranja i oporavka. Brzina rada sa podacima je veća nego u fajl modu.

Verzija klijent-server radi na troslojnoj arhitekturi:
Korisnik
Server aplikacija (klaster servera)
DBMS

Klijenti kontaktiraju klaster menadžera, koji preusmjerava zahtjev korisnika na neki radni server (zahtjev se može preusmjeriti na slobodniji server). Zatim se server okreće DBMS-u kako bi dobio potrebne podatke.
DBMS obrađuje zahtjev i vraća niz podataka serveru, koji vraća obrađene podatke klijentu. U klasteru servera moguće je konfigurirati backup servere na koje se prenose procesi ako radni server ne uspije. Ovo povećava pouzdanost.

Web klijent je u interakciji (preko http protokola) sa web serverom koji pristupa grupi servera. Također je moguće upravljati tankim klijentom koristeći http protokol (prema potpuno istoj šemi)

Trenutni način rada može se pogledati u konfiguratoru iu korisničkom modu otvaranjem Pomoć -> O programu (linija “režim”)

Redovna aplikacija uvijek radi u načinu debelog klijenta. Upravljana aplikacija može raditi i u debelom i u tankom klijentu. Funkcionalnost tankog klijenta je vrlo ograničena.

Članak o redovnim i upravljanim aplikacijama, redovnim i kontrolisane forme"1C:Enterprise", koji se nalazi ovdje.

Ostavite komentar, cijenim vaše mišljenje.

P.S. Charlie Brooker - Kutija želja

Često dobijamo pitanja o tome šta usporava 1c, posebno pri prelasku na verziju 1c 8.3, zahvaljujući našim kolegama iz Interface LLC-a, detaljno vam kažemo:

U našim prethodnim publikacijama već smo se dotakli uticaja performansi diskovnog podsistema na brzinu 1C, ali ova studija se ticala lokalne upotrebe aplikacije na zasebnom računaru ili terminal serveru. Istovremeno, većina malih implementacija uključuje rad sa bazom podataka preko mreže, pri čemu se kao server koristi jedan od korisničkih računara, ili namenski server datoteka zasnovan na običnom, najčešće i jeftinom računaru.

Mala studija resursa na ruskom jeziku na 1C pokazala je da se ovaj problem marljivo izbjegava ako se pojave problemi, obično se preporučuje prelazak na način rada klijent-server ili terminal. Također je postalo gotovo općenito prihvaćeno da konfiguracije na upravljanoj aplikaciji rade mnogo sporije nego inače. Argumenti su po pravilu „gvozdeni“: „Računovodstvo 2.0 je samo proletelo, ali „trojka“ se jedva pomerila“, naravno, ima istine u ovim rečima, pa hajde da to shvatimo.

Potrošnja resursa, na prvi pogled

Prije nego što započnemo ovu studiju, postavili smo si dva cilja: da saznamo da li su konfiguracije zasnovane na upravljana aplikacija sporije nego inače i koji resursi imaju primarni uticaj na performanse.

Za testiranje smo uzeli dvije virtuelne mašine koje su pokrenute Windows Server 2012 R2 i Windows 8.1, respektivno, dajući im 2 jezgra domaćina Core i5-4670 i 2 GB RAM, što odgovara približno prosječnoj kancelarijskoj mašini. Server je postavljen na RAID 0 niz od dva WD Se, a klijent je postavljen na sličan niz diskova opšte namene.

Kao eksperimentalne baze odabrali smo nekoliko konfiguracija Računovodstva 2.0, izdanje 2.0.64.12 , koji je zatim ažuriran na 3.0.38.52 , sve konfiguracije su pokrenute na platformi 8.3.5.1443 .

Prva stvar koja privlači pažnju je povećana veličina baze podataka Trojke, koja je značajno porasla, kao i mnogo veći apetit za RAM-om:

Spremni smo da čujemo uobičajeno: „zašto su to dodali ovoj trojci“, ali nemojmo žuriti. Za razliku od korisnika verzija klijent-server, za koje je potreban više ili manje kvalifikovan administrator, korisnici verzija datoteka rijetko razmišljaju o održavanju baza podataka. Takođe, zaposleni u specijalizovanim kompanijama koje servisiraju (čitaj ažuriraju) ove baze podataka retko razmišljaju o tome.

U međuvremenu, baza podataka 1C je punopravni DBMS vlastitog formata, koji također zahtijeva održavanje, a za to postoji čak i alat pod nazivom Testiranje i ispravljanje baze podataka. Možda je ime odigralo okrutnu šalu, što nekako implicira da se radi o alatu za rješavanje problema, ali problem je i slaba performansa, a restrukturiranje i ponovno indeksiranje, zajedno sa kompresijom tablice, dobro su poznati alati za optimizaciju baza podataka. Hoćemo li provjeriti?

Nakon primjene odabranih radnji, baza podataka je naglo "izgubila težinu", postajući čak i manja od "dvojke", koju niko nikada nije optimizirao, a potrošnja RAM-a je također blago smanjena.

Nakon toga, nakon učitavanja novih klasifikatora i direktorija, kreiranja indeksa, itd. veličina baze će se generalno povećati, „tri“ baze su veće od „dve“ baze. Međutim, to nije važnije, ako se druga verzija zadovoljavala sa 150-200 MB RAM-a, onda je novoj ediciji potrebno pola gigabajta i tu vrijednost treba uzeti u obzir pri planiranju potrebnih resursa za rad s programom.

Net

Mrežni propusni opseg je jedan od najvažnijih parametara za mrežne aplikacije, posebno kao što je 1C u režimu datoteka, koji prenose značajne količine podataka širom mreže. Većina mreža malih preduzeća izgrađena je na bazi jeftine opreme od 100 Mbit/s, pa smo počeli testiranje upoređujući 1C indikatore performansi u mrežama od 100 Mbit/s i 1 Gbit/s.

Šta se događa kada pokrenete bazu podataka 1C datoteka preko mreže? Klijent preuzima dovoljno u privremene foldere veliki broj informacije, posebno ako je ovo prvi, "hladni" početak. Pri brzini od 100 Mbit/s, očekuje se da naletimo na širinu kanala i preuzimanje može potrajati dosta vremena, u našem slučaju oko 40 sekundi (cijena dijeljenja grafikona je 4 sekunde).

Drugo pokretanje je brže, jer se dio podataka pohranjuje u keš memoriju i ostaje tamo do ponovnog pokretanja. Prelazak na gigabitnu mrežu može značajno ubrzati učitavanje programa, kako „hladnog” tako i „vrućeg”, a odnos vrijednosti se poštuje. Stoga smo odlučili rezultat izraziti u relativnim vrijednostima, uzimajući najveću vrijednost svakog mjerenja kao 100%:

Kao što možete vidjeti iz grafikona, Accounting 2.0 se učitava pri bilo kojoj brzini mreže dvostruko brže, prijelaz sa 100 Mbit/s na 1 Gbit/s vam omogućava da ubrzate vrijeme preuzimanja za četiri puta. Razlike između optimiziranih i neoptimiziranih baza podataka "trojke". ovaj način rada nije primećeno.

Provjerili smo i utjecaj brzine mreže na rad u teškim modovima, na primjer, tokom grupnih transfera. Rezultat se također izražava u relativnim vrijednostima:

Ovdje je zanimljivije, optimizirana baza „trojke“ u mreži od 100 Mbit/s radi istom brzinom kao i „dvojka“, a neoptimizirana daje duplo lošije rezultate. Na gigabitu omjeri ostaju isti, neoptimizirana "trojka" je također upola sporija od "dvojke", a optimizirana zaostaje za trećinu. Takođe, prelazak na 1 Gbit/s vam omogućava da smanjite vreme izvršenja za tri puta za izdanje 2.0 i za polovinu za izdanje 3.0.

Za procjenu utjecaja brzine mreže na svakodnevni rad koristili smo se Merenje performansi, izvodeći niz unaprijed određenih radnji u svakoj bazi podataka.

Zapravo, za svakodnevne zadatke, propusnost mreže nije usko grlo, neoptimizirana "trojka" je samo 20% sporija od "dvojke", a nakon optimizacije se ispostavi da je otprilike isto brža - prednosti rada u načinu rada tankog klijenta su evidentne. Prelazak na 1 Gbit/s ne daje optimizovanoj bazi nikakve prednosti, a neoptimizovana i ta dva počinju da rade brže, pokazujući malu razliku između sebe.

Iz obavljenih testova postaje jasno da mreža nije usko grlo za nove konfiguracije, a upravljana aplikacija radi čak i brže nego inače. Takođe možete preporučiti prelazak na 1 Gbit/s ako su teški zadaci i brzina učitavanja baze podataka kritični za vas, u drugim slučajevima, nove konfiguracije vam omogućavaju efikasan rad čak i u sporim mrežama od 100 Mbit/s.

Pa zašto je 1C spor? Razmotrićemo to dalje.

Podsistem serverskog diska i SSD

U prethodnom članku smo postigli povećanje performansi 1C postavljanjem baza podataka na SSD. Možda performanse diskovnog podsistema servera nisu dovoljne? Izmjerili smo performanse disk servera tokom grupnog rada u dvije baze podataka odjednom i dobili prilično optimističan rezultat.

Uprkos relativno velikom broju ulazno/izlaznih operacija u sekundi (IOPS) - 913, dužina reda čekanja nije prelazila 1,84, što je veoma dobar rezultat. Na osnovu toga možemo pretpostaviti da će ogledalo napravljeno od običnih diskova biti dovoljno za normalan rad 8-10 mrežnih klijenata u teškim modovima.

Dakle, da li je potreban SSD na serveru? Najbolji način da odgovorimo na ovo pitanje biće testiranjem koje smo sproveli sličnim metodom, mrežna veza svugdje 1 Gbit/s, rezultat je također izražen u relativnim vrijednostima.

Počnimo sa brzinom učitavanja baze podataka.

Možda će nekome izgledati iznenađujuće, ali SSD na serveru ne utiče na brzinu učitavanja baze podataka. Glavni ograničavajući faktor ovdje, kao što je prethodni test pokazao, je mrežna propusnost i performanse klijenta.

Pređimo na ponavljanje:

Iznad smo već napomenuli da su performanse diska sasvim dovoljne čak i za rad u teškim modovima, tako da brzina SSD-a također nije pogođena, osim neoptimizirane baze koja je na SSD-u sustigla optimizovanu. Zapravo, ovo još jednom potvrđuje da operacije optimizacije organizuju informacije u bazi podataka, smanjujući broj nasumičnih I/O operacija i povećavajući brzinu pristupa njoj.

U svakodnevnim zadacima slika je slična:

Samo neoptimizirana baza podataka ima koristi od SSD-a. Vi, naravno, možete kupiti SSD, ali bi bilo mnogo bolje razmisliti o blagovremenom održavanju baze podataka. Također, ne zaboravite defragmentirati particiju sa informacione baze na serveru.

Podsistem klijentskog diska i SSD

Uticaj SSD-a na brzinu rada lokalno instaliranog 1C govorili smo u prethodnom materijalu. Doista, 1C prilično aktivno koristi resurse diska, uključujući pozadinske i rutinske zadatke. Na slici ispod možete vidjeti kako Accounting 3.0 prilično aktivno pristupa disku oko 40 sekundi nakon učitavanja.

Ali treba shvatiti da za radna stanica gdje se aktivan rad obavlja s jednom ili dvije informacijske baze, resursi performansi običnog HDD-a masovne proizvodnje su sasvim dovoljni. Kupovina SSD-a može ubrzati neke procese, ali nećete primijetiti radikalno ubrzanje u svakodnevnom radu, jer će, na primjer, punjenje biti ograničeno propusnost mreže.

Sporo hard disk može usporiti neke operacije, ali sam po sebi ne može uzrokovati usporavanje programa.

RAM

Unatoč činjenici da je RAM sada nepristojno jeftin, mnoge radne stanice nastavljaju raditi s količinom memorije koja je instalirana prilikom kupovine. Tu čekaju prvi problemi. Na osnovu činjenice da prosječna „trojka“ zahtijeva oko 500 MB memorije, možemo pretpostaviti da ukupna količina RAM-a od 1 GB neće biti dovoljna za rad s programom.

Smanjili smo sistemsku memoriju na 1 GB i pokrenuli dvije baze podataka.

Na prvi pogled nije sve tako loše, program je obuzdao apetite i dobro se uklopio u raspoloživu memoriju, ali ne zaboravimo da se potreba za operativnim podacima nije promijenila, pa kuda je nestala? Reset na disk, keš, swap itd., suština ove operacije je da je nepotrebno trenutno podaci se šalju iz brzog RAM-a, čija količina nije dovoljna, kako bi se usporila memorija diska.

Do čega će to dovesti? Pogledajmo kako se sistemski resursi koriste u teškim operacijama, na primjer, pokrenimo grupni ponovni prijenos u dvije baze podataka odjednom. Prvo na sistemu sa 2 GB RAM-a:

Kao što vidimo, sistem aktivno koristi mrežu za primanje podataka, a aktivnost diska je neznatna tokom obrade, ali nije ograničavajući faktor;

Sada smanjimo memoriju na 1 GB:

Situacija se radikalno mijenja, glavno opterećenje sada pada na hard disk, procesor i mreža ne rade, čekajući da sistem pročita potrebne podatke sa diska u memoriju i tamo pošalje nepotrebne podatke.

U isto vrijeme, čak i subjektivni rad s dvije otvorene baze podataka na sistemu sa 1 GB memorije pokazao se izuzetno neugodnim direktorijima i časopisima koji se otvaraju sa značajnim zakašnjenjem i aktivnim pristupom disku. Na primjer, otvaranje dnevnika Prodaja roba i usluga trajalo je oko 20 sekundi i sve to vrijeme je bilo praćeno velikom aktivnošću diska (označeno crvenom linijom).

Da bismo objektivno procenili uticaj RAM-a na performanse konfiguracija zasnovanih na upravljanoj aplikaciji, izvršili smo tri merenja: brzinu učitavanja prve baze podataka, brzinu učitavanja druge baze podataka i grupno ponovno pokretanje u jednoj od baza podataka. . Obje baze podataka su potpuno identične i nastale su kopiranjem optimizirane baze podataka. Rezultat se izražava u relativnim jedinicama.

Rezultat govori sam za sebe: ako se vrijeme učitavanja poveća za oko trećinu, što je još uvijek prilično podnošljivo, onda se vrijeme za obavljanje operacija u bazi podataka povećava tri puta, ne treba govoriti o bilo kakvom udobnom radu u takvim uvjetima. Inače, to je slučaj kada kupovina SSD-a može poboljšati situaciju, ali je mnogo lakše (i jeftinije) riješiti se uzroka, a ne posljedica, i samo kupiti pravu količinu RAM-a.

Nedostatak RAM-a je glavni razlog zašto rad s novim 1C konfiguracijama ispada neugodan. Konfiguracije sa 2 GB memorije na ploči treba smatrati minimalno prikladnim. Istovremeno, imajte na umu da su u našem slučaju stvoreni "staklenički" uslovi: čist sistem, radili su samo 1C i upravitelj zadataka. U stvarnom životu, pretraživač je obično otvoren na radnom računaru, uredski paket, antivirus je pokrenut itd. itd., pa polazite od potrebe od 500 MB po bazi podataka plus nešto margine, tako da tokom teških operacija ne naiđete na nedostatak memorije i nagli pad performansi.

CPU

Bez preterivanja, centralni procesor se može nazvati srcem računara, jer on na kraju obrađuje sve proračune. Da bismo ocijenili njegovu ulogu, sproveli smo još jedan set testova, isti kao i za RAM, smanjujući broj dostupnih virtuelna mašina jezgri od dvije do jedne, dok je test obavljen dva puta sa količinama memorije od 1 GB i 2 GB.

Rezultat se pokazao prilično zanimljivim i neočekivanim, više moćan procesor prilično efikasno preuzeo opterećenje u uslovima nedostatka resursa, ostatak vremena bez ikakvih opipljivih koristi. 1C Enterprise se teško može nazvati aplikacijom koja aktivno koristi procesorske resurse, prilično je nezahtjevna. I unutra teški uslovi Procesor je opterećen ne toliko obradom podataka same aplikacije, koliko servisiranjem režijskih troškova: dodatnim ulazno/izlaznim operacijama itd.

Zaključci

Dakle, zašto je 1C spor? Prije svega, ovo je nedostatak RAM-a, glavno opterećenje u ovom slučaju pada na tvrdi disk i procesor. A ako ne blistaju performansama, kao što je obično slučaj u uredskim konfiguracijama, onda dobijamo situaciju opisanu na početku članka - "dvojka" je dobro radila, ali "trojka" je bezbožno spora.

Na drugom mjestu su performanse mreže, spori kanal od 100 Mbit/s može postati pravo usko grlo, ali u isto vrijeme, način rada tankog klijenta je u stanju da održi prilično udoban nivo rada čak i na sporim kanalima.

Tada biste trebali obratiti pažnju na disk jedinicu kupovina SSD-a je malo vjerovatna dobra investicija novca, ali zamjena diska modernijim ne bi bila loša ideja. Razlika među generacijama tvrdi diskovi može se procijeniti korištenjem sljedećeg materijala: Pregled dva jeftina pogona u seriji Western Digital Plava 500 GB i 1 TB.

I na kraju procesor. Brži model, naravno, neće biti suvišan, ali nema smisla povećavati njegove performanse osim ako se ovaj računar ne koristi za teške operacije: grupnu obradu, teške izvještaje, zatvaranje na kraju mjeseca, itd.

Nadamo se da će vam ovaj materijal pomoći da brzo shvatite pitanje "zašto je 1C spor" i riješite ga najefikasnije i bez dodatnih troškova.

Fajl ili klijent-server?

Koji je način rada brži u programima 1C:Enterprise 8?

Koliko često vaš 1C program kvari tokom izvještajnog perioda? Da li se operacija zamrzava ili je potrebno mnogo vremena da se završi? Jeste li ikada izgubili podatke zbog neočekivanog nestanka struje? Predlažemo da smislite kako da program 1C učinite bržim i sigurnijim.

Rad u programima 1C:Enterprise 8 može se organizirati u dva načina: datoteka i klijent-server.

Način rada datoteke 1C

Verzija datoteke rada u 1C: Enterprise 8 moći će osigurati ispravan i efikasan rad sistema ako istovremeno u programu ne radi više od 3 osobe.

Baza podataka u režimu datoteka sastoji se od samo jedne datoteke. Program 1C:Enterprise 8, koji korisnik pokreće na svom računaru, pristupa ovoj datoteci pomoću lokalna mreža. Sve operacije ili upiti (obrada dokumenata, generisanje izveštaja, traženje dokumenata, zatvaranje perioda i sl.) se izvode direktno na računaru korisnika, što zahteva da svi koji rade u programu imaju moćnu mašinu.

Šema rada u fajl modu

Za brz i bezgrešan rad sistema potrebno je da se sve radnje (upiti) koje izvrši korisnik programa 1C:Enterprise 8 izvršava na računaru koji pohranjuje bazu podataka. Međutim, u načinu rada datoteke 1C: Enterprise 8, mehanizam za implementaciju zahtjeva je drugačiji:

1. Dio datoteke baze podataka je blokiran za druge korisnike sistema.
2. Blokirani podaci se preko lokalne mreže preusmjeravaju do klijenta.
3. Operacija promjene se vrši na računaru korisnika.
4. Promijenjeni dio datoteke se vraća na lokaciju za pohranu.
5. Datoteka baze podataka postaje dostupna drugim korisnicima sistema 1C:Enterprise 8.

Konstantna razmjena velikih količina informacija značajno usporava rad svih korisnika. Da biste ubrzali rad i učinili ga stabilnim, potrebna vam je određena „veza“ koja će koordinirati i izvršavati korisničke zadatke. Ova „veza“ je implementirana u radnom režimu klijent-server.

Klijent-server način rada 1C (sa SQL bazom podataka)

Server je računar. Ima instaliran program 1C:Server koji vam omogućava da pokrenete 1C:Enterprise 8 u klijent-server modu. To znači da program 1C, koji korisnik pokreće na svom računaru, radi sa programom 1C:Server, a on zauzvrat radi sa bazom podataka. Kao alat za upravljanje bazom podataka koristi se DBMS - PostgreSQL, MS SQL ili slično.

Šema rada u klijent-server modu

Za razliku od režima datoteka, u režimu klijent-server baza podataka se ne sastoji od jedne datoteke, već od više različite datoteke. Mehanizam implementacije korisničkih zahtjeva u ovom načinu rada je sljedeći:

1. 1C: Server distribuira zahtjeve potreban fajl baze podataka.
2. Određuje redoslijed izvođenja operacija.
3. Unosi promjene u bazu podataka.

U ovom režimu, resursno intenzivne operacije se izvode na serveru, gde se pohranjuju datoteke baze podataka, a ne na računarima korisnika. Tako će za udoban rad u programu 1C: Enterprise 8 biti dovoljna samo jedna moćna mašina. Zadatak korisničkih računara je da odražavaju vizuelnu ljusku programa. Gotovo svaki računar može ovo da podnese.

Opcija klijent-server vam omogućava da:

1. Povećajte toleranciju sistema na greške u slučaju hitnog nestanka struje i velikog opterećenja lokalne mreže. na primjer, klijent-server mod work vam omogućava da konfigurirate kreiranje sigurnosne kopije baze podataka svakih 30 minuta dok radite. To znači da čak i ako dođe do nesreće na serveru, samo pola sata podataka će biti izgubljeno, a u roku od sat vremena vaša kompanija će ponovo raditi kao i obično.
2. Ubrzajte sistem zbog odsustva potrebe za stalnim transportom podataka između računara u mreži.
3. Spriječite krađu podataka korisnici sistema 1C: Enterprise 8 Baza podataka se sastoji od mnogo datoteka koje se pohranjuju na serveru i kojima upravlja poseban DBMS. Kopiranje datoteka je moguće samo u zasebnim dijelovima, koji ne daju nikakav informativni sadržaj. Da biste preuzeli bazu podataka u funkcionalnom formatu, potreban vam je pristup s administratorskim pravima za 1C: Server i DBMS.
4. Smanjite rizike od oštećenja baze podataka. Baza podataka je statična - pohranjena i modificirana na jednom računaru, što znači da je isključeno oštećenje tokom transporta od korisnika do korisnika.

Koji način rada 1C da izaberem – fajl ili klijent-server?

Datotečni način rada u 1C programima je pogodan za male kompanije u kojima istovremeno u programu rade maksimalno 3 korisnika sa bazom podataka do 2GB.

• baza podataka veća od 2GB;
• broj korisnika 3 ili više.

Šta treba učiniti da se pređe na klijent-server način rada?

1. Kupi softver- licenca za 1C:Enterprise Server
2. Odaberite DBMS:
   • PostgreSQL je besplatan DBMS (ima veliki broj ograničenja);
3. Konfigurirajte DBMS za rad s 1C, uključujući optimizaciju i planove rezervnih kopija.
4. Instalirajte 1C: Server i konfigurirajte administraciju.

Sa rastom organizacije i povećanjem broja korisnika informacione baze 1C Enterprise na lokalnom nivou računarsku mrežu povećava se opterećenje glavnog skladišta baze podataka - servera. Stoga, prije ili kasnije, menadžer i IT stručnjak kompanije mogu imati pitanje: Kako osigurati brz, siguran i efikasan sistem uz najniže finansijske troškove?

Prvo, morate odabrati metodu za organizaciju korporativnog automatiziranog računarskog kompleksa na platformi 1C Enterprise 8. Platforma 1C podržava dvije operativne opcije: datoteku i klijent-server. U oba slučaja, sva aplikativna rješenja rade potpuno isto.

Verzija datoteke 1C rada dizajniran za jednog ili više korisnika za rad na lokalnoj mreži. U ovom slučaju, svi podaci baze podataka (konfiguracija, baza podataka, administrativne informacije) nalaze se u jednoj datoteci - bazi podataka razvijenoj posebno za 1C Enterprise 8 aplikativna rješenja.

Prednosti file moda rada

• Optimalno za mali broj korisnika (do 5)
• Jednostavan za instalaciju i rukovanje sistemom
• Za rad sa informacijskom bazom, nema dodatnih softver osim operativni sistem i 1C Enterprise 8
• Rizik od narušavanja integriteta podataka zbog kvarova računara i lokalne mreže je smanjen.
• Jednostavno kreirajte sigurnosne kopije jednostavnim kopiranjem datoteke baze podataka.

Rad u verziji datoteke moguć je kako direktno, direktno sa datotekom baze podataka, tako i preko web servera ako se klijentske veze koriste preko HTTP ili HTTPS protokola.

Klijent-server verzija 1C rada Dizajniran za upotrebu u odeljenjima, radnim grupama ili širom preduzeća. Implementiran je na osnovu troslojne klijent-server arhitekture:

Klijentska aplikacija - 1C Enterprise server klaster - Server baze podataka

U verziji klijent-server, baza podataka je pohranjena u jednom od podržanih DBMS-ova: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. Pristupa mu se prema potrebi od strane klijentske aplikacije preko klastera 1C Enterprise servera.

U sistemu 1C Enterprise 8 postoje tri klijentske aplikacije ili klijent(program koji se pokreće za korisnika) sa različitim mogućnostima: debeli klijent, tanki klijent, web klijent.

Debeli klijent omogućava vam da ostvarite pune mogućnosti 1C Enterprise 8 u smislu razvoja, administracije i izvršavanja koda aplikacije. Međutim, ne podržava rad s bazama podataka putem Interneta, zahtijeva prethodnu instalaciju na korisnikovom računalu i ima prilično impresivnu veličinu distribucije.

Problem

Na forumima se stalno postavlja isto pitanje: zašto je 1C+MSSQL sporiji u obradi upita od verzije datoteke?

Tada obično dolazi do “poplave” od nekoliko desetina stranica.

Postoje dva popularna "trenda" na takvim forumima - neki kažu da je to normalno za opciju klijent-server, verzija datoteke uvijek treba raditi brže, drugi kažu da 1C ne radi dobro s bazom podataka.

Kao rezultat „bitki i obračuna“ na forumima, ljudi se razlikuju u mišljenjima.

Predlažemo da pitanje podijelite na nekoliko:

1. Da li opcija datoteke radi brže u “isključivim” operacijama, kada njene aktivnosti ne zavise od drugih korisnika u bazi podataka?

Pod „ekskluzivnom prirodom“ podrazumijevamo jednog aktivnog (radnog) korisnika u bazi podataka.

2. Da li verzija datoteke radi brže u višekorisničkom načinu rada, kada se korisnici aktivno nadmeću za resurse (na primjer, kada prodaju robu, masovno pristupaju stanju u skladištu)?

3. Koliko je značajna razlika u brzini između verzije datoteke i klijent-server verzije sa poslovne tačke gledišta?

Šta zaista

Tabela br. 1. Poređenje verzija datoteke i klijent-server 1C

	Fajl 1C	Klijent-Server 1C
Maksimalna veličina jednog stola	4 gb	~stotine terabajta
Veličina u praksi kada se "kočnice" javljaju u 1C kada se dostigne veličina baze podataka	~16 Gb	~500-1500 Gb
Broj korisnika sa udobnim 1C radom	3-10 (tada ometaju brave stola)	300-700 ljudi (onda obično morate kupiti moćniji hardver i ponovo optimizirati kod)
Funkcije koje troše resurse koji se mogu potrošiti na bolje performanse	br	integritet transakcijskih podataka, evidentiranje operacija za dalju analizu, funkcije za povećanje konkurentnosti korisnika
Dodatne pogodnosti	jednostavnost (pošto postoji malo funkcija)	održavanje podataka (npr backup) bez ometanja rada korisnika
Minimalno područje blokiranja	Nivo tabele (potrebno manje resursa)	Na rekordnom nivou (zahtijeva više resursa)
Trošak vlasništva (uslovno)	Mala	Znatno više od fajla
Prisutnost međusloja između 1C klijenta i baze podataka	br	Server 1C

Odgovor na prvo pitanje: Da li opcija datoteka radi brže u operacijama „ekskluzivne prirode“, kada njene aktivnosti ne zavise od drugih korisnika u bazi podataka – sa vjerovatnoćom od 99% verzija datoteke je brža(pod uvjetom da njegove mogućnosti nisu ograničene neuspjelim hardverom i nisu postignute maksimalne mogućnosti verzije datoteke)!.

Ne vjerujte nam na riječ - uvjerite se sami. uzmi ( detaljan opis ovdje) i uvjerite se sami (provjerite prvo verziju datoteke, a zatim verziju klijent-server).

Ako ne vjerujete testu, testirajte operaciju za koju mislite da je prikladna za verifikaciju, također u verzijama datoteka i klijent-server. Preporučujemo da kao osnovu uzmete, na primjer, "zatvaranje mjeseca" na bazama podataka veličine do 4 gigabajta (u suprotnom verzija datoteke može dostići ograničenje veličine).

Jasno je da ako zatvaranje mjeseca korištenjem opcije datoteke nije moguće za vas, onda nema smisla da raspravljate o prednostima opcije datoteke, slažete li se?

Postavlja se još jedno srednje pitanje:

Koliko je brža verzija datoteke od verzije klijent-server u brojevima?

Odgovor na ovo pitanje je mnogo zanimljiviji i praktičniji. Naš test i praksa pokazuju:

1. u prosjeku operacije na uporedivim količinama podataka skoro 2 puta brže
2. u prosječnim operacijama kada količine podataka počinju da premašuju količinu dostupne RAM-a i povećavaju intenzitet zamjene - do 3-4 puta brže - ovo je samo primjer zatvaranja mjeseca

Međutim, važno je razumjeti šta je "prosječna" operacija. Ispostavilo se da operacije koje rade na podacima u RAM-u u verziji klijent-server ne gube, a ponekad čak i nadmašuju verziju datoteke!

Međutim, takve operacije su rijetke i daleko između njih. Glavno opterećenje čine operacije koje zapravo pristupaju podsistemu diska za čitanje, i, što je posebno važno, za upisivanje podataka.

Štaviše, čak i bezopasan izveštaj, kada je napravljen, takođe može da upiše podatke, na primer, u bazu podataka usluge tempdb kada se koristi MS SQL Server.

Prilikom izvršavanja zahtjeva u verziji datoteke ne postoji posrednik podataka u obliku 1C servera, tj. jedan segment zahtjeva manje za prolazak. Logično je da ako, na primjer, obavljate "rad bez posrednika", to je uvijek brže od "rad sa posrednicima", osim toga, značajan dio funkcionalnosti na strani DBMS-a su zapravo i "posrednici". neophodan, na primjer, ne samo za izvršavanje upita, već i za bolji paralelizam za rad drugih zahtjeva - na primjer, za zaključavanje podataka koji se koriste što je moguće pažljivije, kako ne bi blokirali "nepotrebne", kao što je fajl opcija radi. Lakše je zaključati cijelu tabelu, jer je to jedan zapis sa informacijama o zaključavanju, ali zaključavanje hiljada redova je za red veličine veće dodatni unosi, ali ono što je još važnije je da troši znatno više resursa (procesor, memorija, a ponekad i prostor na disku).

drugim riječima, opcija klijent-server zahtijeva više resursa od verzije datoteke za istu količinu posla.

Otuda posljedica - na istom računaru možete više raditi u verziji datoteke U EKSKLUZIVNOM REŽIMU nego u klijent-server modu (u istom ekskluzivnom načinu).

Kao rezultat toga, čini se da opcija klijent-server može da uradi manje posla, da zahteva više resursa, ali gde je „profit“, zašto se koristi skoro svuda?

Drugo pitanje našeg članka pomoći će nam da odgovorimo: radi li verzija datoteke brže u višekorisničkom načinu, kada se korisnici aktivno nadmeću za resurse (na primjer, kada prodaju robu, masovno pristupaju stanju u skladištu)?

U tabeli broj 1 vidimo tako značajne nedostatke opcije datoteke kao što je mala veličina baza podataka - u većini preduzeća 1C baze podataka zauzimaju desetine ili stotine gigabajta. Ali što je još važnije, opcija datoteke nameće suvišna zaključavanja (nepotrebna), što značajno smanjuje mogućnost paralelnog rada korisnika.

Tako, na primjer, preduzeće ima 100 1C korisnika. Za dobru mjeru, pretpostavimo da svaki korisnik unese 10 dokumenata ravnomjerno tokom dana, i svaki tabelarni dio sadrži 10 redova.

Dobijamo jednostavnu aritmetiku - 100 x 10 x 10 = 10.000 unesenih redova informacioni sistem tokom dana.

Radi lakšeg razumijevanja, slažemo se da svaki korisnik radi s jedinstvenim podacima, a ostali korisnici se ne preklapaju jedni s drugima ni u tabelarnom dijelu dokumenta ni u sastavu detalja.

U verziji klijent-server ovo će raditi. Dokumenti će se obraditi paralelno.

Znajući redundanciju blokiranja u verziji fajla, izračunajmo šta će se dogoditi ako 100 korisnika u verziji fajla istovremeno unese prvi dokument u sistem tog dana, ali istovremeno pritisne dugme.

Znamo da je podrazumevano vremensko ograničenje zaključavanja 20 sekundi. Teoretski se može pretpostaviti da će, osim prvog korisnika, svi sljedeći korisnici čekati jedni na druge 20 sekundi i potom predati svoje dokumente. Ukupno čekanje će biti 100 korisnika x 1 dokument x 20 sekundi = 2000 sekundi čekanja. Osjetite – ovo je pola sata zastoja korisnika.

U praksi je još tužnije, ljudi nisu roboti, ne vide kada je sistem blokiran ili je velika vjerovatnoća obrade dokumenata, pa jednostavno navode da nije moguće unijeti podatke u sistem zbog stalnog blokiranja . Ili, jednostavnije, u praksi, preduzeće će se „zaustaviti“ u fajl modu.

Ali čak i ako zamislite da je neverovatan programer došao u preduzeće i napisao program tako da se pokušaji izvode konstantno automatski, ovih pola sata zastoja neće nestati.

Štaviše, ako probate 2.3, dokumenti će pogoršati sliku i za jedan dan, čak i sa idealnim kodom, verzija fajla će “akumulirati” 100 korisnika x 10 dokumenata x 20 sekundi = 20.000 sekundi ~ 5 i po sati zastoja.

5 sati je početak za opciju klijent-server. Nije ni važno kojom brzinom će biti uneti u svaku nit u verziji klijent-server. Važnije je da su uneseni, au verziji fajla u ovom trenutku postoje čekanja na suvišna zaključavanja.

Pošto pored redundantnih brava postoje i neophodne brave, hajde da ponovo formulišemo koncept performansi.

Sa poslovnog stanovišta, produktivnost je količina posla dnevno koju obavi svih 100 korisnika, a ne jedan ekskluzivni korisnik. Stoga je za posao važnije koliko će podataka u sistem unijeti ukupno svi korisnici. Procjenjujući učinak kolektivnog rada, verzija datoteke je desetine do stotine puta inferiorna u odnosu na verziju klijent-server.

I ponovo vas pozivamo da nam ne vjerujete na riječ. Uzmite 1C:Standard Test opterećenja http://v8.1c.ru/expert/etp.htm ili razvijte vlastiti kolektivni test i uvjerite se u pouzdanost naših izjava.

Ako imate bilo kakvih pitanja o testu ili njegovim rezultatima, možete o njima razgovarati na forumu.

Možda želite da kupite i 1C:KIP, obratite pažnju na karakteristike.

Sada odgovorimo na treće pitanje: Koliko je značajna razlika u brzini između opcije datoteke i opcije klijent-server sa poslovne tačke gledišta?

Verzija fajla je malo ispred verzije klijent-server u ekskluzivnom režimu i veoma značajno gubi u višekorisničkom režimu.

Ali moramo shvatiti da preduzeće ima i druge zadatke koji su gotovo uvijek prioritetniji, a to su tolerancija grešaka, neprekidan rad, pouzdanost i stabilnost. Pokretanje servera u klasteru za prevazilaženje greške zahtijeva dodatne troškove za zrcaljenje podataka. Stoga uvijek mora postojati ravnoteža između različitih ciljeva: performansi, pouzdanosti, sigurnosti itd.

Verzija datoteke nema mehanizme kontrole integriteta podataka. Na primjer, ako dođe do kvara na mreži tokom prijenosa podataka, ili nestane struje, tada će u verziji datoteke neke stvari biti snimljene, a neke neće. Integritet podataka će biti uništen. U verziji klijent-server, u takvim slučajevima, nepotpuna transakcija će se jednostavno vratiti, a nepotpuni podaci neće ući u sistem, integritet podataka će biti očuvan.

One. Ne samo da što je veći broj korisnika u sistemu, to će opcija datoteka više izgubiti u odnosu na opciju klijent-server, već i procedure oporavka podataka u slučaju neuspjeha pretvaraju opciju datoteke u opciju apsolutnog gubitka.

Sada treba da postavimo "pravo pitanje":

4. Zašto se postavilo pitanje da se proceni razlika u brzini između opcija datoteke i klijent-server?

Ista prepiska i poplava na forumima počinje činjenicom da osoba koja postavlja pitanje ima problema sa performansama u verziji klijent-server.

Ali umjesto da proučava razloge koji su uzrokovali problem u verziji klijent-server, on otkriva da u verziji datoteke nema takvog problema. On se ne brine da bi problem mogao biti u "posredniku", koji nedostaje u verziji fajla.

Tačan odgovor je da nije važno koliko je brža opcija datoteka ili klijent-server, već je važno šta tačno uzrokuje usporavanje u svakom SPECIFIČNOM slučaju. Riječ PRODUKTIVNOST je opasna, jer je zapravo treba opisati kao listu operacija na sistemima, koji zajedno čine ovu produktivnost. Potrebno je razmotriti svaku operaciju, počevši od one koja daje najveći doprinos usporavanju.

Generalno, to je ono čime se profesionalno i uspješno bavimo dugi niz godina.

Spremni smo besplatno pogledati konkretnu operaciju koja sporo radi i procijeniti troškove njenog rješavanja. Ukoliko Vam uslovi i cena odgovaraju, onda ubrzavamo rad, a ako dostigne uslove koje ste naveli, samo u tom slučaju plaćate naš rad.

Bluetooth