Langsom drift av 1s 8.3 i terminalen. Automatiseringstips

Starter 1C om to minutter? Tar dokumentloggen 40 sekunder å åpne? Oppbevares dokumentet i nesten ett minutt?

Dette er en kjent situasjon hvis du bruker filversjonen med nettverkstilgang.
Du kan selvfølgelig installere en server og glemme bremsene, men hvis du bare har 2-3 personer som jobber i 1C, og det er ikke praktisk å bruke penger på å kjøpe serverlisenser.

Symptomer:
Arbeidet til flere brukere over nettverket med samme fil (database) inkluderer en nettverksblokkeringsmekanisme. Dette tvinger systemet til å kaste bort verdifull tid på å identifisere åpne opptaksøkter og løse konflikter deretter. De viktigste tegnene på blokkering:

raskt brukerarbeid med databasen over nettverket i eksklusiv modus og ekstremt sakte når flere brukere jobber samtidig.
raskt brukerarbeid med en lokal database på serveren og sakte arbeid over nettverket.
Prosessoren på serveren er nesten inaktiv.
Gigabit nettverkskortbelastning er mindre enn 5 %.
tilgang til filsystemet er litt mindre enn 10 MB/sek.
Når du prøver å legge ut dokumenter samtidig, stopper den ene datamaskinen i omtrent et minutt, og den andre krasjer fra 1C med feilteksten "mislyktes i å låse bordet."
Start 1C varer ca 3 minutter.

Tips som kan bidra til å øke hastigheten på fildatabasen:

Gå på jobb i terminaltilgang. Dessverre tillater ikke Windows 7 deg å gjøre om til en terminalserver ved å bruke standardverktøy - det er maksimalt én aktiv tilkobling. I dette tilfellet avsluttes ikke de gjenværende øktene, du kan koble til på nytt under en annen bruker - ved å "kaste ut" forrige bruker, men uten å avslutte økten. Derfor bør du overføre 1C til et server-OS, der det ikke er slike begrensninger, eller løse problemet med et tredjepartsverktøy.
Deaktiver bruken av IPv6-nettverksprotokollen, konfigurer adressering på den "gamle" IPv4.
Legg til 1C-prosesser til unntakene for Windows-brannmuren, så vel som til antivirus-unntakene, eller deaktiver dem helt (mer risikabelt, men en enkel test viste en økning i hastigheten på dokumentoverføring med Avast antivirus betydelig deaktivert!)
Begynn å indeksere fulltekstsøk i 1C eller slå det av helt
Kjør testing og korrigering av databasen, sjekk med ChDbfl-verktøyet (verktøyet er plassert i "bin"-mappen på den installerte teknologiplattformen).
Kjør "Sjekk konfigurasjon"-elementet i konfigurasjonen (hvis konfigurasjonen ikke er standard, kan dette være nyttig).
Deaktiver unødvendige funksjonelle alternativer (jo mindre unødvendig i det administrerte grensesnittet, jo raskere fungerer det som regel).
Sett opp brukerrettigheter (jo mindre unødvendig i det administrerte grensesnittet, jo raskere fungerer det som regel).
Begynn å beregne totalen på nytt og gjenopprette sekvensen (en betydelig økning kan bare skje hvis i lang tid resultatene ble ikke gjenopprettet).
Angi "Tilkoblingshastighet - lav" i databaselisteinnstillingene.
Defragmentering av en disk med en fildatabase.
Databasekonvolusjon (kan være nyttig hvis databasen er stor, for eksempel i flere år).
Maskinvareoppgradering - raskere harddisk (SSD), ny bryter, prosessor, minne, etc.
Installer på en webserver, få tilgang ved hjelp av en tynn klient.

Etter å ha fullført alle disse trinnene fildatabase 1C kan tjene mye raskere. I noen tilfeller startet den på 10 sekunder, og hastigheten på dokumentoverføringen økte 12 ganger.

P.S. I UT 11.1-konfigurasjonen er det urealistisk å starte fil 1C ved å bruke nettverkstilgang til en delt mappe, fordi Selv den raskeste solid-state-stasjonen, RAM og prosessor kjører inn i nettverkslåser, og arbeidet til mer enn én bruker blir praktisk talt umulig.
Selvskrevet små konfigurasjoner De kan fungere ganske raskt selv i filversjonen.

1C: Regnskap er et av de mest kjente og mest praktiske programmene regnskap. Et bevis på dette er dens utbredte distribusjon på alle aktivitetsområder: handel, produksjon, finans osv.

Dessverre, som alle andre dataprogrammer i 1C: Regnskap er det også forskjellige krasj og fryser. Et av de vanligste problemene er treg systemdrift.

For å forstå årsakene til dens forekomst og prøve å løse dem, ble dagens artikkel skrevet.

Eliminerer vanlige årsaker til langsom 1C-drift

1. Den vanligste årsaken sakte arbeid programmer - langsiktig tilgang til den grunnleggende 1C-filen, som er mulig på grunn av feil på harddisken eller på grunn av dårlig kvalitet på Internett-tilkoblingen, i tilfelle bruk av skyteknologier. Det kan også være problemer med antivirussysteminnstillingene.

Løsning: utfør en skanning for å eliminere feil og defragmentere harddisken. Test hastigheten på Internett-tilgang. Hvis avlesningene er lave (mindre enn 1 Mb/s), kontakt leverandørens TP-tjeneste. Deaktiver antivirusbeskyttelse og brannmur midlertidig i antivirussystemet.

2. Kanskje den trege driften av programmet skyldes stor størrelse databasefil.

For å løse dette problemetåpne 1C i "Konfigurator"-modus, velg "Administrasjon" i systemmenyen, deretter "Testing og korrigering". I vinduet må elementet "Komprimering av informasjonsdatabasetabeller" velges elementet "Testing og korrigering" nedenfor er aktivt. Klikk "Kjør" og vent til prosessen er fullført.

3. Neste mulig årsak- utdatert programvare eller utdatert versjon av selve programmet.

Veit ut av denne situasjonen: oppdater operativsystemets programvare eller installer den nyeste på dette øyeblikket versjon av 1C-programmet. For forebyggende formål, oppdater alltid til den nyeste versjonen, som eliminerer feil fra tidligere konfigurasjoner.

å installere siste versjon 1C-systemet, må du gå inn i programmet i "Konfigurasjon" -modus, og gå deretter fra menyen til "Tjeneste" -> "Tjeneste" -> "Konfigurasjonsoppdatering", velg deretter standardinnstillingene og klikk på "Oppdater" -knappen.

Svært ofte kommer folk til meg med spørsmål som:

Hvorfor bremser 1C-serveren?
1C-datamaskinen er veldig treg
1C-klienten er fryktelig treg

Hva du skal gjøre og hvordan du kan overvinne det, og så videre i rekkefølge:

Klienter jobber veldig sakte med serverversjonen av 1C

I tillegg til det langsomme arbeidet til 1C, er det også sakte arbeid med nettverksfiler. Problemet oppstår under normal drift og med RDP

for å løse dette starter jeg alltid etter hver installasjon av Seven eller 2008-serveren

netsh int tcp set global autotuning=deaktivert

netsh int tcp set global autotuninglevel=deaktivert

netsh int tcp set global rss=deaktivert skorstein=deaktivert

og nettverket fungerer uten problemer

noen ganger er det beste alternativet:
netsh-grensesnitt tcp set global autotuning= HighlyRestricted

slik ser installasjonen ut

Konfigurer Anti-Virus eller Windows brannmur

Hvordan konfigurere en antivirus- eller Windows-brannmur for å kjøre en 1C-server (for eksempel en kombinasjon av 1C Server: Enterprise og MS SQL 2008).

Legg til regler:

Hvis SQL-serveren godtar tilkoblinger på standard TCP-port 1433, tillater vi det.
Hvis SQL-porten er dynamisk, må du tillate tilkoblinger til %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe-applikasjonen.
Server 1C kjører på porter 1541, cluster 1540 og range 1560-1591. Av helt mystiske grunner tillater noen ganger en slik liste over åpne porter fortsatt ikke tilkoblinger til serveren. For å være sikker på at det fungerer, tillat området 1540-1591.

Innstilling av server/datamaskinytelse

For at datamaskinen skal fungere med maksimal ytelse, må du konfigurere den for dette:

1. BIOS-innstillinger

I server-BIOS deaktiverer vi alle innstillinger for å spare prosessorkraft.
Hvis det er "C1E" og sørg for å KOPPE !!
For noen ikke veldig parallelle oppgaver anbefales det også å slå av hypertrading i BIOS
I noen tilfeller (spesielt for HP!) må du gå inn i server-BIOS og slå AV elementene der som har EIST, Intel SpeedStep og C1E i navnene sine.
I stedet må du finne elementer relatert til prosessoren der som har Turbo Boost i navnene, og AKTIVERE dem.
Hvis det i BIOS er en generell indikasjon på en strømsparingsmodus og inkludere den i maksimal ytelsesmodus (det kan også kalles "aggressiv")

2. Skjemainnstillinger i operativsystemet - Høy ytelse

Servere med Intel Sandy Bridge-arkitektur kan dynamisk endre prosessorfrekvenser.

1C-systemet har en dominerende posisjon i automatiseringsmarkedet for små og mellomstore bedrifter. Hvis selskapet velger regnskapssystem 1C, da jobber vanligvis nesten alle ansatte i den, fra vanlige spesialister til ledelse. Følgelig avhenger hastigheten på selskapets forretningsprosesser av hastigheten på 1C. Hvis 1C jobber i en utilfredsstillende hastighet, så påvirker dette direkte arbeidet til hele selskapet og resultat.

eksisterer faktisk tre 1C-akselerasjonsmetoder:

Økning i maskinvarekapasitet.
Optimalisering av operativsystem og DBMS-innstillinger.
Optimalisering av kode og algoritmer i 1C.

Den første metoden krever kjøp av utstyr og lisenser, den tredje krever mye arbeid for programmerere og som et resultat resulterer begge veier i betydelige økonomiske kostnader. Først av alt må du ta hensyn til programkoden, siden ingen økning i serverkapasitet kan kompensere for feil kode. Enhver programmerer vet at med bare noen få linjer med kode er det mulig å lage en prosess som vil laste ressursene til enhver server fullstendig.

Hvis en bedrift er sikker på at programkoden er optimal, men den fortsatt fungerer sakte, bestemmer ledelsen seg vanligvis for å øke serverkapasiteten. På dette tidspunktet oppstår et logisk spørsmål: hva mangler, hvor mye og hva som må legges til til slutt.

1C-selskapet gir et ganske vagt svar på spørsmålet om hvor mange ressurser som trengs, vi skrev om det tidligere i våre innlegg. Og derfor må du selvstendig utføre eksperimenter og finne ut hva 1C-ytelsen avhenger av. Eksperimenter med programytelse ved EFSOL er beskrevet nedenfor.

Når du arbeider med 1C 8.2, spesielt med konfigurasjoner som bruker administrerte skjemaer, ble et merkelig faktum lagt merke til: 1C fungerer raskere på en arbeidsstasjon enn på en kraftig server. Dessuten er alle egenskapene til arbeidsstasjonen dårligere enn serverens.

Tabell 1 - Konfigurasjoner som innledende testing ble utført på

Arbeidsstasjonen viser 155 % mer ytelse enn en 1C-server med overlegne egenskaper. Vi begynte å finne ut hva som foregikk og begrense søket.

Figur 1 – Ytelsesmålinger på arbeidsstasjonen ved bruk av Gilev-testen

Den første mistanken var at Gilevs test var utilstrekkelig. Målinger av åpningsskjemaer, postering av dokumenter, generering av rapporter osv. ved bruk av instrumenteringsverktøy viste at Gilevs test gir en proporsjonal poengsum ekte hastighet arbeid i 1C.

Antall og frekvens av RAM

En analyse av informasjonen tilgjengelig på Internett viste at mange skriver om avhengigheten av 1C-ytelse på minnefrekvens. Det avhenger av frekvensen, ikke av volumet. Vi bestemte oss for å teste denne hypotesen, siden vi har en RAM-frekvens på 1066 Mhz på serveren mot 1333 Mhz på arbeidsstasjonen, og mengden RAM på serveren allerede er mye høyere. Vi bestemte oss for å umiddelbart installere ikke 1066 Mhz, men 800 Mhz, slik at effekten av ytelsesavhengigheten på minnefrekvensen var tydeligere. Resultatet er at produktiviteten falt med 12 % og utgjorde 39,37 enheter. Vi installerte minne med en frekvens på 1333 Mhz i stedet for 1066 Mhz på serveren og fikk en liten økning i ytelse - omtrent 11%. Produktiviteten var 19,53 enheter. Følgelig er det ikke et spørsmål om minne, selv om frekvensen gir en liten økning.

Figur 2 – Ytelsesmålinger på en arbeidsstasjon etter senking av RAM-frekvensen

Figur 3 – Ytelsesmålinger på serveren etter økning av RAM-frekvensen

Diskundersystem

Den neste hypotesen var relatert til diskundersystemet. To antakelser oppsto umiddelbart:

SSD-er er bedre enn SAS-stasjoner, selv om de er i raid 10.
iSCSI er treg eller feil.

Derfor ble det installert en vanlig SATA-disk i arbeidsstasjonen i stedet for en SSD, og det samme ble gjort med serveren - databasen ble plassert på en lokal SATA-disk. Resultatet ble at ytelsesmålinger ikke endret seg i det hele tatt. Mest sannsynlig skjer dette fordi det er en tilstrekkelig mengde RAM og diskene er praktisk talt ikke involvert på noen måte når du kjører testen.

prosessor

Prosessorene på serveren er selvfølgelig kraftigere og det er to av dem, men frekvensen er litt lavere enn på arbeidsstasjonen. Vi bestemte oss for å sjekke effekten av prosessorfrekvens på ytelsen: det var ingen prosessorer med høyere frekvens tilgjengelig for serveren, så vi senket prosessorfrekvensen på arbeidsstasjonen. Vi senket den umiddelbart til 1,6 slik at korrelasjonen ble tydeligere. Testen viste at ytelsen falt betydelig, men selv med en 1,6 prosessor produserte arbeidsstasjonen nesten 28 enheter, som er nesten 1,5 ganger mer enn på serveren.

Figur 4 – Ytelsesmålinger på en arbeidsstasjon med en 1,6 Ghz prosessor

Skjermkort

Det er informasjon på Internett om at ytelsen til 1C kan påvirkes av skjermkortet. Vi prøvde å bruke arbeidsstasjonens integrerte video, en profesjonell Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5-adapter og et gammelt GeForce 16MbSDR-skjermkort. Under Gilev-testen ble ingen signifikant forskjell lagt merke til. Kanskje skjermkortet fortsatt har en effekt, men reelle forhold når du trenger å åpne administrerte skjemaer osv.

For øyeblikket er det to mistanker om hvorfor arbeidsstasjonen fungerer raskere selv med merkbart dårligere egenskaper:

PROSESSOR. Prosessortypen på arbeidsstasjonen er bedre egnet til 1C.
Brikkesett. Annet enn det like forhold Arbeidsstasjonen vår har et nyere brikkesett, så det er kanskje det som er problemet.

Vi planlegger å kjøpe de nødvendige komponentene og fortsette tester for å endelig finne ut hva som gjør i større grad 1C ytelse avhenger. Ha det prosessen er i gang godkjenninger og innkjøp bestemte vi oss for å utføre optimalisering, spesielt siden det ikke koster noe. Følgende stadier ble identifisert:

Trinn 1. Systemoppsett

Først, la oss gjøre følgende innstillinger i BIOS og operativsystem:

I server-BIOS deaktiverer vi alle innstillinger for å spare prosessorkraft.
Velg "Maksimal ytelse"-planen i operativsystemet.
Prosessoren er også innstilt for maksimal ytelse. Dette kan gjøres ved å bruke PowerSchemeEd-verktøyet.

Trinn 2. Sette opp SQL-server og 1C:Enterprise-server

Vi gjør følgende endringer i DBMS- og 1C:Enterprise-serverinnstillingene.

Sette opp protokollen for delt minne:
- Delt minne vil bare være aktivert på plattformen fra og med 1C 8.2.17 på tidligere utgivelser, Named Pipe vil være aktivert - litt dårligere i driftshastighet. Denne teknologien fungerer bare hvis 1C- og MSSQL-tjenester er installert på samme fysiske eller virtuelle server.
Det anbefales å bytte 1C-tjenesten til feilsøkingsmodus, da dette paradoksalt nok gir et ytelsesløft. Som standard er feilsøking deaktivert på serveren.
Sette opp SQL server:
- Vi trenger bare serveren, de andre tjenestene som er relatert til den, og kanskje noen bruker dem, bare bremse arbeidet. Vi stopper og deaktiverer tjenester som: FullText Search (1C har sin egen fulltekstsøkemekanisme), Integration Services, etc.
- Vi angir maksimal mengde minne som er tildelt serveren. Dette er nødvendig for at sql-serveren skal beregne denne mengden og tømme minnet på forhånd.
- Installere maksimalt beløp tråder (Maksimal arbeidstråder) og angi den økte serverprioriteten (Boost-prioritet).

Trinn 3: Sette opp en produksjonsdatabase

Etter at DBMS-serveren og 1C:Enterprise er optimalisert, går vi videre til databaseinnstillinger. Hvis databasen ennå ikke er utvidet fra .dt-filen, og du vet den omtrentlige størrelsen, er det bedre å umiddelbart angi initialiseringsstørrelsen til primærfilen med ">=" av databasestørrelsen, men dette er en sak av smak, vil den fortsatt vokse under utvidelse. Men størrelsen for automatisk økning må spesifiseres: ca. 200 MB per base og 50 MB per logg, fordi Standardverdiene er 1MB og 10% vekst, noe som bremser serveren kraftig når den trenger å øke filen hver tredje transaksjon. Det er også bedre å spesifisere lagringen av databasefilen og loggfilen på forskjellige fysiske disker eller RAID-grupper hvis en RAID-matrise brukes, og begrense veksten av loggen. Det anbefales å flytte Tempdb-filen til en høyhastighetsarray, siden DBMS bruker den ganske ofte.

Trinn 4. Sette opp planlagte oppgaver

Planlagte oppgaver lages ganske enkelt ved å bruke vedlikeholdsplanen i seksjonen administrasjon ved hjelp av grafiske verktøy, så vi vil ikke beskrive i detalj hvordan dette gjøres. La oss se på hvilke operasjoner som må utføres for å forbedre produktiviteten.

Defragmentering av indekser og oppdatering av statistikk må gjøres daglig, pga hvis indeksfragmentering er > 25 %, reduserer det serverytelsen dramatisk.
Defragmentering og oppdatering av statistikk gjøres raskt og krever ikke frakobling av brukere. Det anbefales også å gjøre det daglig.
Full re-indeksering - gjort med databasen blokkert, det anbefales å gjøre det minst en gang i uken. Naturligvis, etter fullstendig reindeksering, defragmenteres indeksene umiddelbart og statistikken oppdateres.

Som et resultat, ved hjelp av finjustering av systemet, SQL-serveren og arbeidsdatabasen, klarte vi å øke produktiviteten med 46 %. Målingene ble utført ved bruk av 1C KIP-verktøyet og ved bruk av Gilev-testen. Sistnevnte viste 25,6 enheter mot 17,53 som opprinnelig var.

Kort konklusjon

1C-ytelsen avhenger ikke mye av RAM-frekvensen. Når en tilstrekkelig mengde minne er nådd, gir ytterligere utvidelse av minne ikke mening, siden det ikke fører til økt ytelse.
1C-ytelsen avhenger ikke av skjermkortet.
1C ytelse er ikke avhengig av disk undersystem forutsatt at diskens lese- eller skrivekø ikke overskrides. Hvis SATA-stasjoner er installert og køen deres ikke overskrides, vil ikke installasjon av en SSD forbedre ytelsen.
Ytelsen er ganske avhengig av prosessorfrekvensen.
Med riktig konfigurasjon av operativsystemet og MSSQL-serveren er det mulig å oppnå en økning i 1C-ytelsen med 40-50 % uten materialkostnader.

MERK FØLGENDE! Veldig viktig poeng! Alle målinger ble utført på en testbase ved bruk av Gilev-testen og 1C-instrumenteringsverktøy. Oppførsel av en ekte base med ekte brukere kan avvike fra de oppnådde resultatene. For eksempel, i testdatabasen fant vi ingen avhengighet av ytelse på skjermkortet og mengden RAM. Disse konklusjonene er ganske tvilsomme og under reelle forhold kan disse faktorene ha innvirkning betydelig innflytelse for ytelse. Når du arbeider med konfigurasjoner som bruker administrerte skjemaer, er et skjermkort viktig og kraftig GPU fremskynder arbeidet når det gjelder å tegne programgrensesnittet, visuelt manifesteres dette i raskere arbeid med 1C.

Kjører din 1C sakte? Bestill IT-vedlikehold for datamaskiner og servere av EFSOL-spesialister med mange års erfaring eller overfør din 1C til en kraftig og feiltolerant 1C virtuell server.

System integrasjon. Rådgivning

2. Funksjoner i programmet. Ofte, selv med optimale innstillinger, fungerer 1C veldig sakte. Ytelsen synker spesielt kraftig når antallet samtidige arbeider med databasen overstiger 4-5 brukere.

Hvem er du i selskapet?

Løsningen på problemet med langsom 1C-drift avhenger av hvem du er i selskapet. Hvis du er en tekniker, bare les videre. Hvis du er direktør eller regnskapsfører, følg den spesielle lenken ↓

Nettverksbåndbredde

Som regel arbeider ikke én, men flere brukere med én informasjonsbase (IS). Samtidig foregår det en konstant utveksling av data mellom datamaskinen som 1C-klienten er installert på og datamaskinen som informasjonssikkerheten er plassert på. Volumet av disse dataene er ganske betydelig. En situasjon oppstår ofte når et lokalt nettverk som opererer med en hastighet på 100 Mbit/s, som er den vanligste hastigheten, rett og slett ikke kan takle belastningen. Og igjen klager brukeren over at programmet er tregt.

Hver av disse faktorene individuelt reduserer allerede hastigheten på programmet betydelig, men det mest ubehagelige er at disse tingene vanligvis går opp.

La oss nå se på flere løsninger på problemet med lav 1C-driftshastighet og kostnadene deres, ved å bruke eksemplet lokalt nettverk av 10 gjennomsnittlige datamaskiner.

Løsning én. Modernisering av infrastruktur

Dette er kanskje den mest åpenbare løsningen. La oss beregne minimumskostnaden.

Som et minimum trenger vi en brakett for hver datamaskin tilfeldig tilgang minne for 2 GB koster i gjennomsnitt 1500 rubler, LAN-kort med støtte for hastighet 1 Gbit/s, koster omtrent 700 rubler. I tillegg trenger du minst 1 ruter som støtter en hastighet på 1 Gbit/s, som vil koste omtrent 4000 rubler. Totale kostnader - 26 000 rubler for utstyr, unntatt arbeid.

I prinsippet kan hastigheten øke betydelig, men nå er det ikke lenger mulig å kjøpe rimelige datamaskiner til kontoret. I tillegg, denne avgjørelsen ikke aktuelt for de som bruker Wi-Fi eller ønsker å jobbe via Internett - i deres tilfelle kan nettverkshastigheten være titalls ganger lavere. Tanken oppstår: "Er det ikke mulig å implementere hele programmet på en kraftig server, slik at brukerens datamaskin ikke deltar i komplekse beregninger, men bare tjener til å overføre bildet?" Da kan du jobbe selv på svært svake datamaskiner, selv på nettverk med lav båndbredde. Naturligvis finnes slike løsninger.

Løsning to. Terminal Server

Fikk stor popularitet tilbake i 1C 7-dagene. Implementert på serveren Windows-versjoner og takler oppgaven vår perfekt. Det har imidlertid sine fallgruver, nemlig kostnadene for lisenser.

Hun selv operativsystem vil koste rundt 40 000 rubler. I tillegg til dette trenger vi for alle som planlegger å jobbe i 1C en Windows Server CAL-lisens, som koster rundt 1700 rubler, og en Windows Remote Desktop Services CAL-lisens, som koster omtrent 5900 rubler.

Etter å ha beregnet kostnadene for et nettverk på 10 datamaskiner, ender vi opp med 116 000 rubler. kun for én lisens. Legg til dette kostnadene for selve serveren (minst 40 000 rubler) og kostnadene for implementeringsarbeid, men selv uten dette viste prisen for lisenser seg å være imponerende.

Løsning tre. Service 1C Enterprise

1C har utviklet sin egen løsning på dette problemet, som kan øke hastigheten på programmet betydelig. Men det er en nyanse her også.

Faktum er at kostnadene for en slik løsning varierer fra 50 000 til 80 000 rubler, avhengig av utgaven. For et selskap med opptil 15 brukere viser det seg å være ganske dyrt. Store forhåpninger ble satt til "1C enterprise mini-server", som ifølge 1C-selskapet er rettet mot små bedrifter og koster rundt 10 000 - 15 000 rubler.

Men da det ble solgt, var dette produktet en stor skuffelse. Faktum er at det maksimale antallet brukere som miniserveren kunne brukes med var bare 5.

Som en 1C-programmerer skrev på forumet: "Det er fortsatt ikke klart hvorfor 1C valgte nøyaktig 5 tilkoblinger! Problemene begynner bare med 4 brukere, men med fem slutter det hele. Hvis du vil koble til en sjette person, betal ytterligere 50 tusen. Vi kan gjøre minst 10 tilkoblinger..."

Selvsagt fant miniserveren også sin forbruker. For bedrifter der 5 eller flere personer jobber med 1C har det imidlertid ikke dukket opp en enkel og rimelig løsning.

I tillegg til programakselerasjonsmetodene beskrevet ovenfor, er det en annen som er ideell for segmentet 5 - 15 brukere, nemlig nettilgang for 1C i filmodus.

Løsning fire. Nettilgang for 1C i filmodus

Driftsprinsippet er som følger: en ekstra rolle til en webserver er installert på datamaskinen, som informasjonssikkerhet publiseres på.

Naturligvis må dette være enten det meste kraftig datamaskin på nettverket, eller en egen maskin dedikert til denne rollen. Etter det kan du jobbe med 1C i webservermodus. Alle tunge operasjoner vil bli utført på serversiden, og trafikk som overføres over nettverket vil bli minimert, det samme vil belastningen på klientens datamaskin.

Dermed kan selv svært svake maskiner brukes til å jobbe i 1C, og gjennomstrømning nettverket blir ikke lenger kritisk. Våre tester har vist at du kan jobbe komfortabelt gjennom Mobilt Internett på et billig nettbrett uten å oppleve noe ubehag.

Dette alternativet er dårligere enn enterprise 1C-serveren når det gjelder driftshastighet, men denne forskjellen er praktisk talt usynlig for opptil 15-20 brukere. For å implementere en webserver kan du forresten bruke IIS (for Windows) og Apache (for Linux), og begge disse løsningene er gratis!

Til tross for de åpenbare fordelene, denne metoden optimering av 1C-drift har ikke fått mye popularitet.

Jeg kan ikke si det sikkert, men mest sannsynlig skyldes dette to grunner:

En ganske svak beskrivelse teknisk dokumentasjon
Ligger i skjæringspunktet mellom ansvar mellom systemadministrator og 1C-programmerer

Vanligvis, når en systemadministrator blir kontaktet med et problem med lav hastighet, foreslår han å oppgradere infrastrukturen eller en terminalserver hvis en 1C-spesialist blir kontaktet, blir han tilbudt en 1C-bedriftsserver. Så hvis en spesialist med ansvar for infrastruktur og en spesialist ansvarlig for 1C jobber "hånd i hånd" i din bedrift, kan du trygt bruke en løsning basert på en webserver.

La oss øke hastigheten på 1C. Fjernt, raskt og uten din deltakelse

Vi vet hvordan vi skal få fart på 1Ski uten å forstyrre kunden. Vi fordyper oss i problemet, gjør jobben vår og drar. Hvis du vil at programmet bare skal fungere normalt, kontakt oss. Vi finner ut av det.

Legg igjen en forespørsel og motta en gratis konsultasjon om å akselerere programmet.