Tiedostotietokannan pullonkaulat - miten välttää (viime kokemuksen perusteella). Tiedostopohjaiset hidastukset – miten vältät (viime kokemuksen perusteella) Tiedostopohjainen versio hidastaa 1C 8.3:a verkon yli

2. Ohjelman ominaisuudet. Usein jopa optimaalisilla asetuksilla 1C toimii hyvin hitaasti. Suorituskyky heikkenee erityisen jyrkästi, kun tietokannan kanssa samanaikaisesti työskentelevien määrä ylittää 4-5 käyttäjää.

Kuka olet yrityksessä?

Ratkaisu hitaan 1C:n toiminnan ongelmaan riippuu siitä, kuka olet yrityksessä. Jos olet teknikko, lue vain. Jos olet johtaja tai kirjanpitäjä, seuraa erityistä linkkiä ↓

Verkon kaistanleveys

Yleensä yhden tietokannan (IS) kanssa ei työskentele yksi, vaan useita käyttäjiä. Samaan aikaan tapahtuu jatkuvaa tiedonvaihtoa tietokoneen, johon 1C-asiakas on asennettu, ja tietokoneen, jossa tietoturva sijaitsee, välillä. Tämän datan määrä on varsin merkittävä. Usein syntyy tilanne, kun yleisimmän nopeuden 100 Mbit/s nopeudella toimiva lähiverkko ei yksinkertaisesti kestä kuormitusta. Ja taas käyttäjä valittaa ohjelman hitaasta.

Jokainen näistä tekijöistä yksittäin vähentää jo merkittävästi ohjelman nopeutta, mutta epämiellyttävintä on, että yleensä nämä asiat laskevat yhteen.

Tarkastellaan nyt useita ratkaisuja alhaisen 1C-nopeuden ja niiden kustannusten ongelmaan käyttämällä esimerkkiä 10 keskikokoisen tietokoneen paikallisverkosta.

Ratkaisu yksi. Infrastruktuurin modernisointi

Tämä on ehkä ilmeisin ratkaisu. Lasketaan sen vähimmäiskustannukset.

Jokaiselle tietokoneelle tarvitaan vähintään 2 Gt RAM-muistitikku, joka maksaa keskimäärin 1500 ruplaa, 1 Gbit/s nopeutta tukeva verkkokortti maksaa noin 700 ruplaa. Lisäksi tarvitset vähintään yhden reitittimen, joka tukee 1 Gbit/s nopeutta, mikä maksaa noin 4000 ruplaa. Kokonaiskustannukset - 26 000 ruplaa laitteille, ilman työtä.

Periaatteessa nopeus voi nousta huomattavasti, mutta nyt ei ole enää mahdollista ostaa edullisia tietokoneita toimistoon. Lisäksi tämä ratkaisu ei sovellu niille, jotka käyttävät Wi-Fiä tai haluavat työskennellä Internetin kautta - heidän tapauksessaan verkon nopeus voi olla kymmeniä kertoja pienempi. Herää ajatus: "Eikö koko ohjelmaa ole mahdollista toteuttaa yhdellä tehokkaalla palvelimella niin, että käyttäjän tietokone ei osallistu monimutkaisiin laskelmiin, vaan toimii vain kuvan siirtämisessä?" Sitten voit työskennellä jopa erittäin heikkojen tietokoneiden kanssa, jopa alhaisen kaistanleveyden verkoissa. Luonnollisesti tällaisia ​​ratkaisuja on olemassa.

Ratkaisu kaksi. Päätepalvelin

Se saavutti suuren suosion jo 1C 7:n päivinä. Se on toteutettu Windowsin palvelinversiossa ja selviää hyvin tehtävästämme. Sillä on kuitenkin sudenkuoppansa, nimittäin lisenssien hinta.

Itse käyttöjärjestelmä maksaa noin 40 000 ruplaa. Tämän lisäksi tarvitsemme jokaiselle, joka aikoo työskennellä 1C:ssä, Windows Server CAL -lisenssin, joka maksaa noin 1 700 ruplaa, ja Windows Remote Desktop Services CAL -lisenssin, joka maksaa noin 5 900 ruplaa.

Laskettuamme 10 tietokoneen verkon kustannukset, päädymme 116 000 ruplaan. vain yhdelle lisenssille. Lisää tähän itse palvelimen kustannukset (vähintään 40 000 ruplaa) ja toteutustyön kustannukset, mutta ilman tätäkin lisenssien hinta osoittautui vaikuttavaksi.

Ratkaisu kolme. Palvelu 1C Enterprise

1C on kehittänyt tähän ongelmaan oman ratkaisunsa, joka voi merkittävästi nopeuttaa ohjelmaa. Mutta tässä on myös vivahde.

Tosiasia on, että tällaisen ratkaisun hinta vaihtelee 50 000 - 80 000 ruplaa painoksesta riippuen. Yritykselle, jolla on jopa 15 käyttäjää, se osoittautuu melko kalliiksi. Suuria toiveita asetettiin "1C-yritysminipalvelimelle", joka 1C-yrityksen mukaan on suunnattu pienille yrityksille ja maksaa noin 10 000 - 15 000 ruplaa.

Kuitenkin, kun se tuli myyntiin, tämä tuote oli suuri pettymys. Tosiasia on, että käyttäjien enimmäismäärä, joiden kanssa minipalvelinta voitiin käyttää, oli vain 5.

Kuten eräs 1C-ohjelmoija kirjoitti foorumilla: "Ei ole vieläkään selvää, miksi 1C valitsi tarkalleen 5 yhteyttä! Ongelmat alkavat vain neljällä käyttäjällä, mutta viidellä käyttäjällä kaikki päättyy. Jos haluat yhdistää kuudennen henkilön, maksa vielä 50 tuhatta. Voisimme tehdä vähintään 10 yhteyttä...”

Tietysti myös minipalvelin löysi kuluttajansa. Yrityksille, joissa 1C:n kanssa työskentelee vähintään 5 henkilöä, yksinkertaista ja edullista ratkaisua ei kuitenkaan ole ilmestynyt.

Yllä kuvattujen ohjelman kiihdytysmenetelmien lisäksi on toinen, joka sopii ihanteellisesti 5–15 käyttäjän segmentille, nimittäin verkkokäyttö 1C:lle tiedostotilassa.

Ratkaisu neljä. Verkkokäyttö 1C:lle tiedostotilassa

Toimintaperiaate on seuraava: tietokoneelle asennetaan lisärooli web-palvelimesta, jolla tietoturva julkaistaan.

Luonnollisesti tämän tulisi olla joko verkon tehokkain tietokone tai erillinen kone, joka on omistettu tälle roolille. Sen jälkeen voit työskennellä 1C:n kanssa verkkopalvelintilassa. Kaikki raskaat toiminnot suoritetaan palvelinpuolella, ja verkon yli kulkeva liikenne minimoidaan, kuten myös asiakkaan tietokoneen kuormitus.

Näin ollen jopa erittäin heikkoja koneita voidaan käyttää 1C:ssä työskentelemiseen, eikä verkon kaistanleveydestä tule kriittinen. Testimme ovat osoittaneet, että voit työskennellä mukavasti langattoman Internetin kautta halvalla tabletilla ilman epämukavuutta.

Tämä vaihtoehto on toimintanopeuden suhteen huonompi kuin yrityksen 1C-palvelin, mutta tämä ero on käytännössä näkymätön 15-20 käyttäjälle. Muuten, web-palvelimen toteuttamiseen voit käyttää IIS:ää (Windows) ja Apachea (Linuxille) ja molemmat ratkaisut ovat ilmaisia!

Ilmeisistä eduista huolimatta tämä 1C-toiminnan optimointimenetelmä ei ole saavuttanut suurta suosiota.

En voi sanoa varmaksi, mutta todennäköisesti tämä johtuu kahdesta syystä:

• Melko heikko kuvaus teknisessä dokumentaatiossa
• Sijaitsee järjestelmänvalvojan ja 1C-ohjelmoijan vastuualueen risteyksessä

Yleensä kun järjestelmänvalvojaa lähestytään hitaan nopeuden ongelmalla, hän ehdottaa infrastruktuurin tai päätepalvelimen päivittämistä; jos 1C-asiantuntijaan otetaan yhteyttä, hänelle tarjotaan 1C-yrityspalvelinta. Joten jos yrityksessäsi infrastruktuurista vastaava asiantuntija ja 1C:stä vastaava asiantuntija työskentelevät "käsi kädessä", voit turvallisesti käyttää verkkopalvelimeen perustuvaa ratkaisua.

Nopeutetaan 1C. Etänä, nopeasti ja ilman osallistumistasi

Tiedämme kuinka nopeuttaa 1Skiä asiakasta häiritsemättä. Perehdymme ongelmaan, teemme työmme ja lähdemme. Jos haluat ohjelman toimivan normaalisti, ota yhteyttä. Selvitämme sen.

Jätä pyyntö ja vastaanota ilmainen konsultaatio ohjelman nopeuttamiseksi.

1C-optimointi ja työn nopeus riippuvat monella tapaa lukkojen, kyselyjen ja indeksien kanssa työskentelystä. Yritämme vastata kysymykseen "kuinka nopeuttaa 1C:n työtä" (pohdimme kysymystä 1C:n käynnistämisen nopeuttamisesta toisessa artikkelissa) ja välttämään käyttäjien valituksia "asiakirjojen pitkästä käsittelystä", mikä väistämättä vaikuttaa liiketoimintaprosesseihin.

Osa 3. 1C:n suorituskyky

Lukot 1C 8.3:ssa: haku ja poistaminen koodista, siirto hallittuun lukkoon

Lukot ovat osa ACID-mekanismia. Tarkastellaanpa sen konseptia, joka on esitetty yksinkertaistetun kaavion muodossa SQL SERVERin esimerkillä

Automaattitilassa lukkoja hallitsee itse DBMS. Samaan aikaan MS SQL -palvelimelle ilmaantui sivuvaikutuksia, kuten tyhjien taulukoiden ja rajatietoalueiden lukitseminen (Serialisoitava taso), mikä aiheutti lisäongelmia usean käyttäjän työssä. Näiden ongelmien ratkaisemiseksi 1C loi ohjattuja lukkoja.

1C Ohjatut lukot

Lukitusmekanismi siirrettiin 1C-palvelimelle, ja DBMS-tasolla eristys vähennettiin minimiin. MS SQL:ssä eristystaso alennettiin Read Committed -tasolle jaetulla lukitusmekanismilla 8.2-alustalla ja riviversiointimekanismilla 8.3-alustalla (ns. Read Committed Snapshot Isolation). Tarkemmin sanottuna tämä on samanniminen tietokantaominaisuus ja kaksi Read Committed -toimintatilaa, jotka riippuvat tästä parametrista.

Viimeisellä eristystasolla (RCSI) mekanismi mahdollisti sen, että luku- ja kirjoitustapahtumia ei leikattu samoissa resursseissa DBMS-palvelimella. Kaiken päätyön otti 1C-estopalvelu, joka määrittää alkuperäisten metatietojen perusteella, sallitaanko tapahtumat DBMS-palvelimelle vai ei, jotta liiketoimintalogiikkaa ei rikota. Ongelmat tyhjien pöytien ja raja-alueiden lukitsemisessa ovat menneisyyttä.

DBMS	Lukon tyyppi	Tapahtuman eristystaso	Lue kaupan ulkopuolella
Automaattiset lukot
Tiedoston tietokanta	Taulukot	Sarjasoitavissa	Likaista luettavaa
MS SQL Server	Viestit		Likaista luettavaa
IBM DB2	Viestit	Toistettava luettava tai sarjoitettava	Likaista luettavaa
PostgreSQL	Taulukot	Sarjasoitavissa	Johdonmukaista lukemista
Oracle-tietokanta	Taulukot	Sarjasoitavissa	Johdonmukaista lukemista
Hallitut lukot
Tiedoston tietokanta	Taulukot	Sarjasoitavissa	Likaista luettavaa
MS SQL Server 2000	Viestit	Lue Sitoutunut	Likaista luettavaa
MS SQL Server 2005 ja uudemmat		Lue Sitoutunut tilannekuva	Johdonmukaista lukemista
IBM DB2 ennen versiota 9.7	Viestit	Lue Sitoutunut	Likaista luettavaa
IBM DB2 versio 9.7 tai uudempi	Viestit	Lue Sitoutunut	Johdonmukaista lukemista
PostgreSQL	Viestit	Lue Sitoutunut	Johdonmukaista lukemista
Oracle-tietokanta	Viestit	Lue Sitoutunut	Johdonmukaista lukemista

Jotta voit selvittää, missä lukitustilassa 1C-ohjelmatietokanta on, sinun on suoritettava seuraava pyyntö SSMS:stä halutun tietokannan yhteydessä:

1C lukot. Käyttäjä ei odota lukkoja, 1C nopeutuu, jos noudatat tiettyjä sääntöjä:

• Liiketoimien kestoa tulee lyhentää mahdollisimman paljon. Pitkien laskutoimitusten suorittaminen tapahtumassa 100 %:ssa tapauksista johtaa tukkoon työskennellessäsi OLTP-järjestelmässä.
• Pitkät ulkoiset toiminnot tapahtuman sisällä jäävät pois, kuten sähköpostivahvistuksen lähettäminen ja vastaanottaminen, tiedostojärjestelmän käsittely ja muut lisätoiminnot. Kaikki toiminnot on sijoitettava lykättyihin lyhyisiin tehtäviin.
• Kyselyt on optimoitu maksimissaan.
• Indeksejä tulee luoda vain tarpeen mukaan optimaalisen kyselyn suorituskyvyn varmistamiseksi sovelluksessa.
• Usein päivitettävien sarakkeiden sisällyttäminen klusteroituun indeksiin on minimoitu. Klusteroitujen indeksiavainsarakkeiden päivitykset vaativat lukon sekä klusteroituun indeksiin että kaikkiin klusteroimattomiin indekseihin (koska niiden paikannusrivi sisältää klusteroidun indeksiavaimen).
• Mikäli mahdollista, luodaan peittävä indeksi, jota käytetään tietojen hakuajan lyhentämiseen.
• Käytä alimman tason tapahtumien eristämistä, mikä edellyttää siirtymistä hallittuun lukitustilaan.

Työkalut tukosten diagnosointiin:

• Teknologia-lehti;
• Suorituskyvyn hallintakeskus 1C-työkaluista;
• Gilevin pilvipalvelut;

Alla on esimerkki järjestelmän valvonnasta Gilev-palvelun avulla. Eston kokonaiskesto on ~15 tuntia. Yli 400 aktiivista käyttäjää. Päätösten ja optimoinnin jälkeen aikakatkaisut ovat alle minuutin ja estojen määrä on vähentynyt ~670 kertaa.

Oli:

Tuli:

Tilanteessa, jossa "kaikki roikkuu ja kestää kauan" ja valvontapalveluita ei ole konfiguroitu tai niitä ei käytetä ollenkaan, Pareto-periaate muistaa, sinun on keskityttävä koodiin.

Automaattisessa tilassa palvelimen lukkojen olemassaolo voidaan havaita järjestelmäproseduurilla halutun tietokannan yhteydessä. Tämän tallennetun menettelyn avulla voit määrittää, missä tilassa lukot toimivat, niiden tilan, tyypin jne.:

Kun 1C:n menettely on valmis, voit saada visuaalista tietoa siitä, mitä palvelimella tällä hetkellä tapahtuu, ottaen huomioon 1C-taulukoiden erityispiirteet:

Fragmentti 1

//Lukitsee 1C:n suhteen SELECT * FROM dbo.ReturnLukonNimi1C(DEFAULT,DEFAULT) as t Missä TaulukonNimi1C EI OLE NULL-JÄRJESTYKSESSÄ t.Resource

Tämän mekanismin avulla voit saada täydelliset tiedot nykyisistä lukoista. Jos raportti sisältää vain S-lukkoja, ongelma voi johtua pitkään jatkuneesta kyselystä tai kyselyistä. Selvittääksesi syyn ja paikan niiden esiintymiseen koodissa, voit käyttää eri polkuja: käyttää SQL-palvelimen DMO-objekteja (mutta muista, että niiden tiedot nollataan palvelimen uudelleenkäynnistyksen jälkeen) tai määritä Data Collector, seurantatietojen tallentaminen taulukoihin tietyksi ajaksi. Tärkeintä on saada ongelmallisten pyyntöjen tekstit.

SQL Serverin DMO-objektien käyttäminen

Näytämme palvelimen aloituspäivän ymmärtääksemme tietojen merkityksen. Jaamme paketin lukemalla luokituksen (fyysinen, looginen, prosessorin kuormitus). Tässä tapauksessa käytetään sys.dm_exec_query_stats-päätietoja. Käännämme pyyntötekstin 1C-termeiksi. Jos ymmärrät puhelun kontekstin pyyntötekstistä, ei tarvitse muuta kuin katsoa pyyntösuunnitelmaa, löytää ongelmalliset operaattorit ja ymmärtää mitä voidaan tehdä.

Fragmentti 2

//aloitusaika SELECT sqlserver_start_time FROM sys.dm_os_sys_info; //Suosituimmat fyysisen lukemisen pyynnöt SELECT TOP (50) (total_physical_reads) AS Total_physical_reading,

Ongelmallisten kyselyiden tunnistaminen Data Collectorin keräämisen seurauksena

Tämän työkalun avulla voit luokitella tiedot tarvittavien parametrien, kuten prosessorin kuormituksen, keston, loogisen I/O:n, fyysisten lukutoimintojen mukaan, mikä mahdollistaa täydellisen tilastotietojen tallentamisen jatkoanalyysiä varten SQL-palvelimen uudelleenkäynnistämisestä huolimatta.

Kun palvelin on kerännyt ongelmalliset pyynnöt ilman kolmannen osapuolen valvontaa, voit luokitella vastaanotetut tiedot tarvittavien parametrien mukaan.

Seuraavaksi ottamalla käyttöön teknologinen loki ja määrittämällä asetuksissa "haku merkkijonolla" ja pyynnön osan, jonka taataan kohtaaminen, voit selvittää, mistä ongelmallinen pyyntö on kutsuttu. Jos palvelimella on useita tietokantoja tai käyttäjätunnus on tiedossa, kannattaa suodattimeen lisätä kenttiä palvelimen kuormituksen vähentämiseksi prosessilokia kerättäessä.

Esimerkki ongelmallisesta pyynnöstä ja esimerkki teknologisen lokin asettamisesta:

Kyselyn optimointi mahdollisuutena nopeuttaa 1C 8.3

Epäoptimaalisen kyselyn seuraukset voivat ilmetä asiakirjojen pitkittyneenä käsittelynä, tuskallisen pitkiä raporttien generointia, järjestelmän jäätymistä ja muita epämiellyttäviä tapahtumia.

Kun työskentelet pyyntöjen kanssa, et VOI:

• Yhdistä taulukot alikyselyillä;
• Yhdistä tavalliset pöydät virtuaalisiin;
• Käytä loogista "TAI" olosuhteissa;
• Käytä alikyselyitä liittymisehdoissa;
• Vastaanota tiedot pisteen kautta yhdistelmätyyppisistä kentistä ilman "Express"-avainsanaa.

Kun työskentelet pyyntöjen kanssa, VOI:

• Luo indeksejä kyselyn ehdoista, liittämisestä, yhdistämisestä ja lajittelukentistä;
• Virtuaalitaulukoiden suodatus on tehtävä valintaparametreilla.

Indeksien käyttö ja niiden vaikutus järjestelmän suorituskyvyn laatuun

Indekseistä, niiden käytön tarpeesta ja vaikutuksista järjestelmän toiminnan laatuun on kirjoitettu paljon. Yritetään ymmärtää indeksien "suunnittelun", sovellusvaihtoehdot ja edut tavallisiin taulukoihin verrattuna.

Indeksointi on tärkeä osa DBMS-ydintä. Puuttuvat indeksit tai päinvastoin, liian suuri määrä niitä, vaikuttaa tietojen haun, muokkaamisen, lisäämisen ja poistamisen nopeuteen. Tarkastellaan indeksointia yleisimmän Microsoft DBMS:n esimerkin avulla.

Ymmärtääksemme, miten tämä toimii, katsotaanpa tietoja tietojen tallennusmekanismista, jota yleensä edustamme taulukon muodossa (esimerkiksi Excel).

Fyysisen tiedon tallennuksen yksikkö on sivu - 8 kt:n moduuli, joka kuuluu vain yhteen objektiin (esimerkiksi taulukkoon tai hakemistoon). Sivu on pienin luku- ja kirjoitusyksikkö. Sivut kootaan laajuuksiin. Laajuus koostuu 8 peräkkäisestä sivusta. Sivujen laajuus voi kuulua yhdelle tai useammalle objektille. Kun sivut kuuluvat useisiin objekteihin, laajuutta kutsutaan "sekoitetuksi".

Sen sisältö on nähtävissä alta:

Nyt kun meillä on käsitys levytallennusyksikön toiminnasta, puhutaan lisää taulukoista ja hakemistoista.

Oletusarvoisesti, jos et käytä erityisiä T-SQL-käskyjä, tyhjä taulukko luodaan "kekoksi" - yksinkertainen joukko sivuja ja laajuuksia. Keon tiedoilla ei ole loogista järjestystä. SQL Server -moottori seuraa tietyn objektin sivua ja omistajuutta käyttämällä erityisiä järjestelmän sivuja, joita kutsutaan hakemistojen allokaatiokartoiksi. Jokaisessa taulukossa tai hakemistossa on vähintään yksi IAM-sivu, jota kutsutaan "ensimmäiseksi IAM-sivuksi".

Näin ollen tavallisen taulukon luomisen jälkeen tuloksena on oletusarvoisesti kaoottinen tietojen järjestely. Voit tarkastella taulukon tilaa seuraavasti:

1C-alustan käyttämät tärkeimmät indeksit

Fragmentti 3

Myytit ja todellisuus:

Myytti yksi: klusteroidut indeksit ja tietotaulukko ovat kaksi eri kokonaisuutta, jotka on tallennettu erillään toisistaan.

Myytti kaksi: yhdessä taulukossa voi olla useita klusteroituja indeksejä.

Latasin ohjelman DBMS:n optimoimiseksi. Suositellut indeksit luotu. Näytteenottonopeus kasvoi 50 %. Tietojen muuttaminen ja lisääminen hidastui 7 kertaa.

Klusteroitu (klusteroitu) indeksi

Klusteroidut hakemistot ovat joukko sivuja, jotka lajittelevat ja tallentavat tietorivejä taulukoihin tai näkymiin avainarvojensa perusteella – hakemistomääritykseen sisältyvien sarakkeiden perusteella. Tämän tyyppisen indeksin rajoitus on 16 saraketta ja 900 tavua. Jokaiselle pöydälle on vain yksi klusteroitu indeksi, koska tietorivit voidaan lajitella vain yhteen järjestykseen. Klusteroidun indeksin luominen tapahtuu järjestämällä taulukko uudelleen tietojen kopioimisen sijaan, mikä mahdollistaa taulukon tallentamisen tasapainotettuna puuna.

Fragmentti 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE objektin_id = OBJECT_ID("jäljitystiedot")

Klusteroimaton indeksi

Klusteroimattomilla indekseillä on tietoriveistä erillinen rakenne. Klusteroimaton indeksi sisältää klusteroidun indeksiavaimen arvot, ja jokainen tietue sisältää klusteroidun indeksiavaimen (ei RID:tä, koska 1C-taulukot eivät käytä kasoja harvoja poikkeuksia lukuun ottamatta).

Voit lisätä ei-avainsarakkeita klusteroimattoman indeksin lehtitasolle ja ohittaa nykyisen indeksiavaimen rajan (900 tavua ja 16 avainsaraketta) suorittamalla täysin indeksoituja kyselyitä.

Klusteroimattoman indeksin lisäämisen jälkeen tiedot kopioitiin ja toinen objekti ilmestyi:

Fragmentti 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE objektin_id = OBJECT_ID("jäljitystiedot")

Kaavio klusteroidusta indeksistä sen jälkeen, kun se on haettu kasasta tasapainoisen puun muodossa:

Klusteritaulukosta johdetun klusteroimattoman indeksin kaavio (huomaa, että rivinpaikannussarakkeessa on klusteroitu indeksiavain):

Indeksien vaikutus kyselyn suorituskykyyn

Hakemiston avulla kyselyn optimoija etsii hakemiston avainsarakkeita, etsii kyselyrivien tallennuspaikan ja hakee sieltä vastaavat rivit. Hakeminen hakemistosta on paljon nopeampaa kuin taulukosta hakeminen, koska toisin kuin taulukosta, hakemistossa on usein vähemmän sarakkeita riviä kohden, ja rivit on lajiteltu järjestykseen.

Useiden indeksien luominen johtaa siihen, että näytteenottonopeus kasvaa ja kirjoitusnopeus muokkauksen aikana pienenee merkittävästi. Tämän ongelman ratkaisemiseksi sinun on ensin poistettava tarpeettomat indeksit tai lukittava ne ensin poistamatta niitä, jolloin voit ottaa ne käyttöön tarvittaessa.

Huomaa, että klusteroitua indeksiä ei voi estää missään olosuhteissa, koska tämä estää pääsyn taulukkotietoihin. Tämä koskee vain indeksejä, jotka olet luonut itse T-SQL:n avulla. Syy indeksien luomiseen T-SQL:llä, ohittamalla 1C:Enterprise, liittyy ensinnäkin 1C-alustan rajoitettuihin ominaisuuksiin indeksien manipuloinnin ja lisäkenttien sisällyttämisen luotuun hakemistoon.

T-SQL-käsky, joka suorittaa indeksin lukituksen:

//Lukitse erillinen indeksi taulukkoon -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Sisällytä haluttu indeksi -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

Yllä olevien vaiheiden lisäksi on tärkeää luoda fyysiselle levylle tiedostoryhmä, joka ei sisällä nykyisiä tietokantatiedostoja, ja siirtää klusteroimattomat indeksit sinne. Tämä nopeuttaa tietojen muokkaamista rinnakkaisemalla niiden tallennus.

Selvitetään, mitkä indeksit ovat tarpeen tai tarpeettomia kyselyjen nopeuttamiseksi

Oletusarvoisesti 1C luo tietyn perusjoukon indeksejä. Usein niitä ei yksinkertaisesti ole tarpeeksi. SQL Serverissä on mekanismeja, joiden avulla voit työkuormasi perusteella ymmärtää, kuinka tarpeellisia nykyiset indeksisi ovat.

Database Engine Tuning Advisor analysoi tietokantoja ja antaa suosituksia kyselyn suorituskyvyn optimoimiseksi. Sitä voidaan käyttää optimaalisten indeksijoukkojen valitsemiseen ja luomiseen ilman asiantuntijatason ymmärrystä tietokannan suunnittelusta tai SQL Serverin sisäisistä prosesseista. Database Engine Configuration Assistantin avulla voit suorittaa seuraavat tehtävät:

• Tietyn ongelmallisen kyselyn suorituskyvyn vianmääritys;
• Määritä suuri joukko kyselyjä yhdessä tai useammassa tietokannassa.

DMO:t (dynaamiset hallintaobjektit), jotka sisältävät dynaamisia hallintanäkymiä ja dynaamisia hallintatoimintoja. Esimerkiksi T-SQL-käsky voi noutaa kaikki indeksit, joita ei ole käytetty palvelimen viimeisen käynnistyksen jälkeen.

Fragmentti 6

WITH vl as (SELECT OBJECT_NAME(I.object_id) AS objektinnimi, I.nimi AS indeksinimi, I.index_id AS indeksitunnus FROM sys.indexes AS I SISÄLIITTYMÄ sys.objects AS O ON O.object_id = I.objektin_id WHERE I.objektin_id > 100 AND I.type_desc = "EI KOSKETTU" JA I.index_id EI SISÄLLÄ (SELECT S.index_id FROM sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id AND I.index_id=S.index_id =S.index_id tietokanta_tunnus '))) SELECT objektinnimi,T1.NimiTaulukko1C, indeksitunnus, indeksin nimi FROM vl ULKOINEN KÄYTTÖ dbo.ReturnTableName1C(objektinnimi) muodossa T1 ORDER BY objektinnimi, hakemistonimi;

Ohjeet, joita voidaan käyttää tarvittavien DBMS-ytimen suosittelemien indeksien luomiseen:

Fragmentti 7

SELECT T1.NameTable1C taulukoksi taulukon_nimi_1C, "LUO INDEKSI " + " PÄÄLLÄ "
Kyselyn optimoija tunnistaa kyselyn suoritussuunnitelmaa luodessaan tarpeen luoda puuttuva indeksi. Se tallentaa nämä tiedot XML ShowPlaniin. Koska kyselysuunnitelmat tiivistetään ja ohjeet tallennetaan (seuraavaan palvelimen uudelleenkäynnistykseen asti), jonka jälkeen ne voidaan noutaa, käsitellä ja tehdä valmiita ohjeita tarvittavien indeksien luomiseksi mihin tahansa välimuistissa olevaan suoritussuunnitelmaan. On syytä kiinnittää huomiota kyselyn suoritustiheyteen: mitä korkeampi se on, sitä merkityksellisempiä ovat kyselyn tulokset ja vastaavasti kerätyt indikaattorit. Jos kysely suoritettiin kerran, sen tulokset eivät ole niin suuntaa antavia.

Fragmentti 8

RISTIN KÄYTTÖ query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) SELECT TOP 30 DatabaseName as Database_Name, TCName, TC-nimi1, TC-nimi. , tasa-arvo_sarake ns: Comparison_columns, include_columns kuten Columns_to_include,

Fragmentti 9

KÄYTÄ [Database_name]: LUO KLUSTEREETTON INDEKSI [_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) SISÄLTÄ ([_Date_Time],[_Fld12771_RRFRRl]7,2_2RRrelf]4 MENE Joitakin koostekenttien ja lajittelukenttien indeksoinnin ominaisuuksia.

Indeksin luominen ORDER BY -lauseessa määritettyihin sarakkeisiin auttaa kyselyn optimoijaa järjestämään tulosjoukon nopeasti, koska sarakkeiden arvot lajitellaan indeksissä etukäteen. GROUP BY -mekanismin sisäinen toteutus myös lajittelee ensin sarakearvot, jotta tarvittavat tiedot voidaan ryhmitellä nopeasti.

Vakiosuosituksia käytettäessä tulos kannattaa tarkistaa ennen optimointia ja sen jälkeen. Otetaan esimerkki loogisen liiton "OR" ja sen vaihtoehdon käytöstä (ongelman ratkaisemiseksi vakiosuositusten avulla) - tekniikka muuttaa kyselyä käyttämällä "UNITE ALL" -syntaksia.

Itse 1C-pyyntö "OR":

"VALITSE Koodi, nimi, linkki FROM Directory.Counterparties AS Vastapuolina WHERE Vastapuolet.Koodi = "000000004" TAI Vastapuolet.Koodi = "0074853" TAI Vastapuolet.Koodi = "000000024" TAI = Counterpar4.Code.90Code.90Code.90Code.90Code. 0074742" TAI Vastapuolet.Koodi = "000000104";

Kyselyn muokkaaminen "UNITE ALL":lla:

SELECT Koodi, Nimi, Linkki FROM Hakemistosta Vastapuolet AS Vastapuolet WHERE Vastapuolet Koodi = "000000004" COMBINE ALL SELECT Koodi, nimi, linkki hakemistosta. Vastapuolet vastapuolina WHERE Vastapuolet. Koodi = "0074853" SELECT Koodi, nimi, linkki ALL COMBINE FROM Directory.Counterpartities AS Vastapuolina WHERE Vastapuolet.Koodi = "000000024" YHDISTÄ KAIKKI VALITSE Koodi, nimi, linkki hakemistosta. Vastapuolet vastapuolina WHERE

Todellinen kyselysuunnitelma (näytön ja suorituskyvyn vertailun helpottamiseksi, kyselyt siepataan ja suoritetaan SSMS:ssä):

Tässä tapauksessa optimoinnin jälkeen suorituskyky putosi puoleen Key Lookup -operaattorin toistuvan käytön vuoksi, johon liittyy aina Nested Loops -operaattori. Siksi, kun käytät kyselyn optimointimallia, sinun tulee mitata tavoiteaika ennen parannusten käyttöä ja sen jälkeen. Tämä esimerkki on esitetty "Luota, mutta varmista", koska tyypillisten suositusten ja käytännön ongelmien välillä voi olla ristiriitaa.

Kuinka nopeuttaa työtä 1C:ssä: Kirjanpito 8.3 (versio 3.0) tai poistaa rutiini- ja taustatehtävät käytöstä

2019-01-15T13:28:19+00:00

Ne teistä, jotka ovat jo vaihtaneet uuteen versioon 1C: Accounting 8.3 (versio 3.0), ovat huomanneet, että se on hitaampi kuin 2. Joitakin outoja hidastuksia, loputtomia taustatehtäviä useita kertoja päivässä, joita kukaan ei pyytänyt häntä suorittamaan tietämättämme.

Kirjanpitäjäni kertoivat minulle heti siirtymän jälkeen, että 1C: Accounting 3.0:n uusi versio on suorastaan ​​hidas aiempiin verrattuna! Ja työskentely on yksinkertaisesti mahdotonta.

Aloin perehtyä asiaan ja huomasin hyvin pian, että suurin syy jäätymiseen ja sitä seuranneeseen käyttäjien tyytymättömyyteen ovat rutiini- ja taustatehtävät, joista monet ovat oletusarvoisesti käytössä, vaikka valtaosalla kirjanpitäjistä niitä ei tarvita.

No, esimerkiksi miksi meidän täytyy suorittaa "Tekstinpoisto" -tehtävä sata kertaa päivässä, jos emme tee kokotekstihakua (kirjanpitäjät, älkää olko huolissamme) kaikista tietokannan kohteista.

Tai miksi ladata jatkuvasti valuuttakursseja, jos meillä ei ole valuuttatapahtumia tai teemme niitä satunnaisesti (ja ennen sitä voimme itse napsauttaa latauskurssipainiketta).

Sama koskee 1C:n jatkuvaa yritystä muodostaa yhteys sivustoon ja tarkistaa ja päivittää pankkien luokituksia. Minkä vuoksi? Painan itse painiketta päivittääkseni luokittelijat, jos en löydä oikeaa pankkia sen BIC-koodin perusteella.

Kuinka tehdä tämä vaihe vaiheelta alla.

1. Siirry "Hallinta"-osioon ja valitse toimintopaneelista "Ylläpito" ():

2. Etsi ja valitse avautuvasta ikkunasta "Rutiini- ja taustatehtävät":

3. Avaa jokainen tehtävä, jonka "Päällä"-sarakkeessa on "Päällä". on aivo.

4. Poista valinta "Käytössä" ja napsauta "Tallenna ja sulje" -painiketta.

5. Tee tämä jokaisen mukana tulleen tehtävän kanssa ja nauti uudesta painoksesta. Kaiken kaikkiaan mielestäni se on paljon parempi kuin kaksi.

Samaan aikaan alusta ottaa edelleen käyttöön jotkin käytöstä poistamistasi ajoitetuista tehtävistä.

1C-järjestelmä on nykyään yksi tärkeimmistä työkaluista pienten ja keskisuurten yritysten pyörittämiseen. Pääsääntöisesti kaikilla organisaation työntekijöillä on pääsy ohjelmaan. Siten, jos 1C alkaa hidastua tai toimia hitaasti, tämä vaikuttaa merkittävästi liiketoiminnan harjoittamiseen. Katsotaanpa, kuinka voit itse nopeuttaa ja optimoida työtä 1C:ssä.

Optimointi 1C-päivityksellä

1C:n uudet versiot toimivat aina tehokkaammin ja nopeammin, joten päivityksiä on ehdottomasti seurattava. On suositeltavaa päivittää kirjanpitosi mahdollisimman usein. Varsinkin kun säännellystä raportoinnista julkaistaan ​​versioita.

Monet ihmiset ovat käyttäneet ohjelman automaattista päivittämistä jo pitkään. Vaikka tämä ongelma voidaan helposti ratkaista manuaalisesti 1C Enterprise 8.3:lle, päivittäminen ei aiheuta ongelmia.

Ensimmäinen vaihe on ladata uusin versio tällä hetkellä käyttämästäsi alustasta. Tämä tehdään joko ITS-levyllä tai verkkokäyttöliittymän kautta, jossa ne tarjoavat jatkuvaa tukea ohjelman, kuten 1c Enterprise 8.3:n, käyttäjille, joiden kokoonpanopäivitys toimitetaan myös virallisesti.

Jälkimmäisessä tapauksessa päivitystiedot sisältävä arkisto ladataan erikseen. Se puretaan mihin tahansa kansioon, jota pidetään käyttäjälle sopivimpana. Sitten sinun on suoritettava .exe-tiedosto. Napsauta seuraavassa ikkunassa "Seuraava" -painiketta.

Toinen sivu tulee näkyviin. Siinä käyttäjä valitsee polun, jolla asennus on valmis. Mutta tätä vaihetta suositellaan vain edistyneille henkilökohtaisten tietokoneiden omistajille. Oletustoiminnot ovat yleensä riittäviä useimpien ongelmien ratkaisemiseen. Oletusarvoisesti tässä tapauksessa on määritetty yksi kansio, johon kaikki päivitykset asennetaan kerralla. Tämä on paljon kätevämpää kuin silloin, kun lopulliset polut ovat erilaisia. Napsautamme yksinkertaisesti "Seuraava" -painikkeita useita kertoja 1c Enterprise 8.3 -ohjelmassa, jonka kokoonpano tulisi päivittää nopeasti.

Jäljelle jää vain viimeinen painike, joka tarjoaa "Asenna".

Kuinka nopeuttaa 1C, jos alusta on hidas

Ongelmat johtuvat useimmiten siitä, että jossakin vaiheessa esiintyjän huomion keskittyminen heikkenee. Tässä on tärkeää valita oikea päivitysmalli, vain tässä tapauksessa emme kohtaa ongelmaa, kun 1c jäätyy päivityksen aikana.

Päivitys versio 7.7

Konfiguraatiotyyppejä on useita. Tästä riippuen valitaan jatkotoimenpiteiden kulku.

• Standardi – tässä tapauksessa oletetaan, että päivitys tehdään myös säänneltyä raportointia varten.
• Tyypilliset teollisuuden kokoonpanot muistuttavat suurelta osin aiempia vaihtoehtoja. On tärkeää lukea kehittäjän antamat ohjeet etukäteen. Muuten et voi selvittää, miksi 1C 8.3 kaatuu päivityksen aikana.
• Muokattu standardi - käyttäjällä on aina mahdollisuus muokata sovellusta itse niin, että se vastaa tämänhetkisiä tarpeita. Toinen vaihtoehto toiminnallisuuden laajentamiseen on siirtyminen uusille alustoille. Esimerkiksi versio 8.

Tietoja versioista 8.0 ja 8.1

Tällä hetkellä alusta 8.0 on jo poistettu tuesta. Uudet standardikehitykset toimivat vain uusimpia versioita käytettäessä. Sinun tarvitsee vain muistaa, että kaikki välijulkaisut valmistuvat ilman epäonnistumisia. Muussa tapauksessa on suuri todennäköisyys yksinkertaisesti menettää tietoja. Tai kohtaat tilanteen, jossa 1c jumiutuu kokoonpanoa päivitettäessä.

Vaihtoehto on mahdollista, kun uusi vakiokonfiguraatio otetaan käyttöön ja siihen siirretään vanhojen tietokantojen jäännökset.

Mitä tulee versioon 8.1, voit päivittää siihen useilla tavoilla:

1. käsin;
2. automaattitilassa;
3. ottaa yhteyttä tämän alan palveluita tarjoavien yritysten asiantuntijoihin.

Työskentely ei-standardien tai muunneltujen versioiden kanssa

Aluksi kaikki kokoonpanot viittaavat standardikehitykseen. Se lakkaa olemasta sellainen, jos yrityksessä tehdään tiettyjä muutoksia. Esimerkiksi asennuksen aikana. Epätyypillisistä kokoonpanoista erottuu kaksi luokkaa:

1. muuttunut;
2. luotu tyhjästä ottaen huomioon tietyn yrityksen tarpeet.

Joskus toisen luokan kokoonpano jaetaan aktiivisesti käyttäjien kesken. Sitten sitä pidetään tyypillisenä. Valmistajaa ei vain pidetä itse 1C:nä, vaan yrityksenä, joka loi uuden version.

Määritykset voidaan pitää ajan tasalla seuraavilla toimilla:

• Virheen korjaus.
• Toiminnan laajentaminen.
• Parantaminen.
• Muutos 1C 8.3:ssa, kokoonpanoa ei päivitetä huoltovirheiden sattuessa.

Asennusprosessi voi kestää eri aikoja riippuen Internetin nopeudesta, jolla käytät sitä tällä hetkellä. Käyttäjä valitsee erillisessä ikkunassa päivittääkö se työn valmistuttua vai välittömästi. Jälkimmäisessä vaihtoehdossa sinun on varmistettava, että kukaan muu ei työskentele sovelluksen kanssa. Itse prosessi sisältää eksklusiivisen tilan käytön 1c Enterprise 8.3 -sovelluksessa, viimeisin päivitys ei ole poikkeus.

• Meidän on muistettava, että kaikki julkaisuversiot eivät välttämättä sovellu nykyiseen kokoonpanoon.
• Jos päivityksiä ei ole tehty pitkään aikaan, saatat joutua lataamaan useita tiedostoja tai arkistoja kerralla.
• Luettelossa on helppo ymmärtää, mikä 1C Enterprise 8.3 -versio tarvitaan, päivityksen valitsee käyttäjä.

Kun prosessi on valmis, itse Configurator voidaan sulkea. Tätä tilaa käytetään useimmiten, jos päivitys on tarpeen. Se on kätevä ja automatisoi lähes koko prosessin. Kun käynnistät sen ensimmäisen kerran, näyttöön saattaa tulla viesti, joka ilmaisee, että alusta on vanhentunut. Ja että sen käyttöä ei suositella tällä hetkellä.

Muita syitä jarrutukseen

Jos ohjelma päivitetään oikein ja ilman virheitä, 1C kuitenkin hidastuu, syy voi olla seuraava:

• Virustorjunta - jos se on määritetty oikein, mikään virustorjunta ei häiritse järjestelmää, mutta jos käytät tehdasasetuksia, 1C:n suorituskyky voi laskea 5–10%. Voit optimoida virustorjuntasi käyttämällä lisäasetuksia poistamalla taustatilan (jos se on ehdottoman välttämätöntä).
• Tietokoneen parametrit - usein riittämättömät tietokoneet heikentävät merkittävästi 1C:n suorituskykyä. Erityistä huomiota on kiinnitettävä näytönohjaimeen, käyttöjärjestelmään ja prosessoriin.

Tällaiset menetelmät optimoivat ja nopeuttavat merkittävästi työtä 1C:ssä mille tahansa yritykselle tai yritykselle, minkä jälkeen ohjelman suorituskyky paranee merkittävästi.

Kuinka lisätä nopeutta ja helppokäyttöisyyttä 1C:ssä

Potilaan oireet ja historia:

Useiden käyttäjien työ verkossa samalla tiedostolla (tietokannassa) sisältää verkon estomekanismin. Tämä pakottaa järjestelmän tuhlaamaan arvokasta aikaa avoimien tallennusistuntojen tunnistamiseen ja ristiriitojen ratkaisemiseen sen mukaisesti.

Tärkeimmät merkit estotoiminnasta:

• nopea käyttäjä työskentelee tietokannan kanssa verkon yli eksklusiivisessa tilassa ja erittäin hidas, kun useita käyttäjiä työskentelee samanaikaisesti
• nopea käyttökokemus paikallisen tietokannan kanssa palvelimella ja hidas työskentely verkossa
• tiedostojärjestelmän käyttönopeudet ovat hieman alle 10 Mt/s

Joten sain tehtäväksi varmistaa, että jopa kolme käyttäjää voi työskennellä 1C:ssä samanaikaisesti! Hassua, eikö?

Unohdin kaikki vitsit, kun näin, mitä minun oli tehtävä: "palvelin" tavallisen toimistotietokoneen ja kahden kannettavan tietokoneen muodossa.

Onnellisuus olisi epätäydellinen, ellei upeita käyttöjärjestelmiä - Windows 7 tietokoneessa ja toisessa kannettavassa, Windows 8 toisessa.

Kun yritettiin lähettää asiakirjoja samanaikaisesti kannettaville tietokoneille, yksi jumissa noin minuutiksi ja toinen kaatui ulos 1C:stä virhetekstillä "ei voinut lukita pöytää...".

1C:n käynnistäminen kannettavalla tietokoneella on erillinen esitys, joka kesti noin 3 minuuttia!

Monissa resursseissa sain neuvoja siirtyä työskentelyyn terminaalikäyttöön. Valitettavasti Windows 7 ei salli sinun muuttua päätepalvelimeksi tavallisilla työkaluilla - aktiivisia yhteyksiä on enintään yksi. Tässä tapauksessa loput istunnot eivät pääty; voit muodostaa yhteyden uudelleen toisen käyttäjän alaisuudessa - "heittämällä" edellisen käyttäjän pois, mutta lopettamatta hänen istuntoaan. Siksi sinun tulee siirtää 1C palvelinkäyttöjärjestelmään, jossa ei ole tällaisia ​​rajoituksia. Asiakas ratkaisi ongelman omalla vastuullaan käyttämällä kolmannen osapuolen apuohjelmaa Windows7_SP1_RDPhack.

Mutta seikkailut eivät päättyneet tähän. Myös terminaaliyhteydessä oli merkittäviä viiveitä. Jälleen kerran kaikkivaltiaat hakukoneet auttoivat minua. Alla on vinkkejä tiedoston 1C nopeuttamiseen, joita noudatin:

1. Poista käytöstä verkkoprotokollan käyttöä IPv6, määritä osoitteet "vanhassa" IPv4:ssä.

2. Lisää 1C-prosessit Windowsin palomuuripoikkeuksiin sekä virustorjuntapoikkeuksiin tai poista ne kokonaan käytöstä (riskillisempi, mutta yksinkertainen testi osoitti nopeuden lisäys asiakirjojen uudelleensiirto, kun Avast antivirus on poistettu käytöstä tekijä!)

3. Aloita kokotekstihaun indeksointi 1C:ssä tai sammuta se kokonaan

4. Suorita tietokannan testaus ja korjaaminen, tarkistaminen ChDbfl-apuohjelmalla

5. Suorita kokoonpanon Tarkista kokoonpano -kohde (jos kokoonpano ei ole vakio, tästä voi olla hyötyä). Kokoonpanon tarkistuksen tulosten perusteella sen koko pieneni maagisesti lähes kolmanneksella. En todellakaan perehtynyt siihen, mitä saapuvat ohjelmoijat päivittivät ennen minua, mutta tosiasia on ilmeinen.

6. Poista käytöstä tarpeettomat toiminnalliset asetukset.

7. Määritä käyttäjäoikeudet. (Tämä ja edellinen neuvo tuntuivat tyhmiltä, ​​kunnes huomasin hallittujen lomakkeiden hahmonnusta dokumenttilistaa avattaessa. Mitä vähemmän tarpeetonta hallitussa käyttöliittymässä, sitä nopeammin se yleensä toimii)

8. Aloita kokonaissummien uudelleenlaskenta ja järjestyksen palauttaminen (merkittävä lisäys voi tapahtua vain, jos summia ei ole palautettu pitkään aikaan)

9. Määritä tietokantaluettelon asetuksiin "Connection speed - low" (tämä ei tuottanut paljoa tulosta, paitsi että alijärjestelmien kuvat sammutettiin :))

Kaikkien näiden vaiheiden suorittamisen jälkeen 1C-tiedostotietokanta alkoi toimia paljon nopeammin. Se alkoi käynnistyä maksimissaan 10 sekunnissa ja asiakirjojen siirtonopeus nousi keskimäärin 12 kertaa.

Ehkä tämä lyhyt artikkeli on hyödyllinen sinulle, jos joudut yhtäkkiä nopeuttamaan 1C-tiedostotietokantaasi.

P.S: Mutta tiedoston 1C käynnistäminen verkkoyhteydellä jaettuun kansioon on edelleen epärealistista, koska... Jopa nopein solid-state-asema, RAM ja prosessori joutuvat verkkotukoksiin, ja useamman kuin yhden käyttäjän työ on käytännössä mahdotonta. Puhumme erityisesti UT 11.1:n kokoonpanosta. Itse kirjoitetut pienet kokoonpanot voivat toimia melko nopeasti jopa tiedostoversiossa.

Lisäyksiä kommenteista julkaistavaksi:

Levyn eheytys tiedostopohjalla

Convolution tietokanta (voi olla hyödyllistä, jos tietokanta on suuri, esimerkiksi useiden vuosien ajan). Asiakkaan tietokanta oli melko nuori, joten vähentäminen ei ollut käytännöllistä.

Laitteistopäivitys - nopeampi kiintolevy, uusi kytkin, prosessori jne.

Asenna web-palvelimelle, pääsy ohuen asiakkaan avulla. Tässä mielipiteet jakautuvat. Jotkut sanovat, että se on monta kertaa nopeampi, toiset sanovat, että kiihtyvyyttä ei ole havaittu.