Opțiuni pentru rezolvarea problemei

Optimizare 1C reprezintă o serie de măsuri pentru creșterea performanței unui sistem informațional. Să luăm în considerare pașii principali pentru analiza erorilor de performanță și creșterea vitezei lui 1C 8.3 (8.2).

Este foarte dificil să măsurați performanța bazei de date pe baza experienței utilizatorului. De exemplu, un utilizator spune că 1C este „lent”, al doilea spune „bine” - îi plac pauzele de cafea. Experții în acest domeniu au început să caute o cale de ieșire din această situație - cum să evalueze obiectiv calitatea funcționării unui sistem informațional?

În acest scop, a fost inventată o tehnică de evaluare digitală a vitezei sistemului - . Folosind această tehnică, puteți evalua în mod obiectiv viteza înainte și după optimizarea 1C.

Verificarea hardware-ului

Primul pas către optimizarea funcționării 1C este identificarea blocajului din echipament. Foarte des, după ce ați găsit un loc ocupat în echipament, puteți înțelege rapid cauza principală - erori în configurația serverului, performanță hardware insuficientă sau erori în codul programului.

Cu toate acestea, dacă credeți că puteți crește performanța 1C prin simpla modernizare a echipamentului, vă înșelați profund. Există erori în configurația sistemului care vor „mânca” toate resursele echipamentului, indiferent de situație.

Monitorizarea și analiza performanței 1C folosind software special - TsUP

Folosind o dezvoltare specială 1C - Centrul de management al performanței pentru a optimiza 1C, ar trebui să instalați monitorizare pe sistemul dumneavoastră de informații.

Rezultatul testului de performanță va fi blocajele de performanță 1C, care vor servi drept instrucțiuni pentru acțiunile de optimizare a 1C.

Astăzi vreau să vă vorbesc despre optimizarea 1C, cum puteți rezolva problema așteptării încuietorilor atunci când sistemul rulează. Vă voi spune lucruri destul de simple, dar acestea pot permite cuiva să economisească timp, efort și bani.

Când am început să lucrez pentru o companie utilizator, cel mai important lucru pentru mine nu a fost cât de frumoasă și corect făcută a fost soluția mea din punct de vedere al refactorizării, ci cât de repede aș putea rezolva o problemă de business și ce efect avea să aducă. Modul în care este scris codul meu nu este adesea important pentru afaceri.

Vă voi spune despre experiența noastră, despre cum am optimizat 1C în acele zone în care a fost „prost” și „lent” și cum am făcut-o fără a optimiza interogări, algoritmi etc.

Optimizare „la carte”

Lasă-mă să-ți amintesc abordare clasică a optimizării.

Să presupunem că 1C nostru este „prost” și „încetinește”. Vedem acest lucru în sistemele de monitorizare sau utilizatorii ne spun despre asta. Ce ar trebui să facem noi, ca specialiști 1C, „la carte”?

• Noi găsim blocaje, unde „doare” cel mai mult - de exemplu, sistemul începe să „se blocheze” atunci când există un calcul în masă al costurilor, sau salarizarea sau introducerea în masă a vânzărilor, așa cum a fost cazul la noi.
• Odată ce sunt găsite blocajele, trebuie să ne uităm la ce poate fi optimizat pentru a accelera sistemul.
  • Poate ai nevoie optimizarea interogărilor astfel încât să capteze mai puține date,
  • Sau rescrie algoritmi cu tranzacții, astfel încât să trimită datele mai des, sau să le prelucreze într-o perioadă mai scurtă de timp.
  • Dacă asta nu ajută, încercăm crește echipamentul serverului.

Uneori, toate acestea duc la rezultate pozitive. Dar acum vreau să dau exemple despre cum noi a accelerat sistemul fără a utiliza abordări clasice.

În compania noastră, ne-am confruntat cu faptul că 1C la un moment dat „îngheață” și „încetinește”. Conducerea a cerut să rezolve această problemă, dar:

• În echipa noastră nu existau specialisti seriosi, care s-ar ocupa în mod profesionist de problemele de optimizare în fiecare zi.
• Pentru noi a fost este nevoie de forță de muncă pentru a rezolva problema folosind abordări clasice;
• Necesar anumite calificări pe care nu le aveam, sau a fost necesar să se implice alți specialiști;
• în care nu puteam garanta că eforturile noastre vor avea vreun efect. De exemplu, dacă optimizăm algoritmii de implementare, din cauza cărora avem o mulțime de așteptări pe încuietori, atunci poate că vom obține un fel de accelerare uneori, sau poate asta va da doar o mică creștere.

Câteva cuvinte despre companie

Câteva cuvinte despre compania noastră.

Compania Arosa - furnizăm produse alimentare către HoReCa (cafenele, baruri, restaurante), agenții guvernamentale și retail. Lucrăm la Moscova, Sankt Petersburg, Soci.

Expediem:

• Aproximativ 100 de tone de mărfuri pe zi, acum chiar mai mult.
• Procesăm aproximativ 800 sau mai multe comenzi pe zi - în total există aproximativ 4000 de linii în toate comenzile.
• Aceasta este în principal un transport de bucată.

În compania noastră, sunt responsabil pentru automatizarea depozitelor, adică direct pentru sistemul nostru WMS.

Sistemul nostru principal de contabilitate este „Managementul comerțului”. Și în depozit folosim WMS „Cortes”.În lumea 1C, cel mai utilizat sistem WMS este soluția de la compania Axelot, dar pe lângă aceasta există și alte soluții WMS pentru 1C, dintre care una folosim.

Cazul 1. Procesarea comenzii

Primul blocaj despre care voi vorbi este procesul de procesare a comenzilor în depozit.

Procesele noastre de depozitare sunt structurate după cum urmează:

• Depozitul este deschis toată ziua - se acceptă mărfuri de la furnizori;
• apoi comenzile primite în timpul zilei lucrătoare sunt introduse în sistem;
• sunt asamblate noaptea;
• Dimineața, mașinile livrează comenzile clienților.

Și în fiecare zi la orele 18:00-19:00, când numărul de comenzi pe zi a atins anumite valori, am început să întâlnim înghețari de sistem - în acele una sau două ore în care se derula principala procesare a comenzilor de către operatori, era aproape imposibil de lucrat în sistem.

Toate comenzile noastre sunt grupate în călătorii cu mașina în care vor călători la clienți. Când pregătiți un zbor, trebuie să procesați „teancul” de comenzi care sunt incluse în acesta (pot fi 30-40 dintre ele) și să rezervați bunuri pentru ele. Toate zborurile (și pot fi câteva zeci de ele) sunt procesate de operatori în paralel.

Și datorită faptului că un număr mare de comenzi necesită acces la aproximativ aceleași date, a apărut o problemă - a existat concurență pentru date.

De exemplu, un anumit produs (să spunem carnea de vită) se află în celula X ca sold liber, iar această carne de vită este necesară în fiecare a patra ordine. Și, deoarece un număr mare de comenzi au fost efectuate în paralel, mai multe sesiuni au încercat să concureze pentru aceleași date - a fost o aşteptare la blocare.

Operatorii au fost forțați să joace jocul „Voi rezerva acest zbor la a cincea încercare” deoarece nu a fost implementat perfect. Când operatorul a apăsat butonul „Rezervați mărfuri pentru zbor”, a apărut o clepsidră - sistemul a început să proceseze prima, a doua, a treia comandă și, de exemplu, la a patra comandă a existat o așteptare pe bloc - utilizatorul a fost dat o eroare că a avut loc un timeout. Încercați numărul doi, încercați din nou etc.

Ne-am uitat atent la această situație și am văzut asta dacă rezervarea nu s-a făcut în paralel, dacă nu toată lumea ar încerca să treacă pe aceeași ușă în același timp, atunci nu ar fi nicio problema. Dacă utilizatorii noștri ar procesa comenzi în mod constant, ar finaliza totul în timpul alocat. Așa cum a fost, cea mai mare parte a timpului a fost petrecut așteptând la blocaje și încercând să reproceseze.

Aceasta este o captură de ecran a unuia dintre sistemele de monitorizare pe care le folosim. Acesta arată timpul total de așteptare pentru blocări în timpul zilei. Două vârfuri strălucitoare sunt vizibile.

• Primul vârf este 17:00-19:00, când operatorii procesează primul lot de comenzi.
• Iar al doilea vârf este noaptea, când încep masiv să proceseze al doilea lot de comenzi.

Ce am făcut? Am schimbat puțin logica de business a sistemului, astfel încât comenzile să nu mai fie procesate și rezervate în paralel. Recunosc că a fost posibil să optimizăm ceva în algoritmi, dar am decis să nu o facem, doar a făcut astfel încât toate comenzile să fie procesate secvenţial de un singur job de fundal.

Cum arată asta din punct de vedere tehnic?

• Când operatorul dă clic pe butonul „Rezervare zbor”, sesiunea sa nu face nicio rezervare - pur și simplu face o înregistrare în registrul de servicii a informațiilor care trebuie făcute pentru acest zbor.
• Un job de fundal începe și începe să efectueze toate acțiunile necesare.
• Când un alt operator efectuează simultan aceleași acțiuni pe zborurile sale în același timp, zborul său se alătură și el la coadă.
• Și apoi, când lucrarea de fundal termină de lucru cu primul zbor, se trece la procesarea celui de-al doilea zbor. Când se termină al doilea, se va trece la al treilea, dacă este în registru. Dacă nu există al treilea, atunci se termină.

Astfel, comenzile nu mai sunt procesate în paralel.

Captura de ecran arată cum arată toate acestea în interfața din soluția Cortez pe care o folosim pe forme groase. Acum totul se întâmplă cam așa:

• Când utilizatorul face clic pe butonul „Rezervați element”, o pictogramă ceas apare lângă zborul specific. Aceasta înseamnă că acest zbor a fost pus în funcțiune.
• În același timp, interfața utilizatorului nu se „îngheață”; el poate continua să construiască unele rapoarte, să trimită un alt zbor la serviciu, dar sesiunea sa nu mai este angajată în această muncă.
• Când zborul este finalizat, acest ceas va dispărea.

Dacă în timpul funcționării, sarcina de fundal primește unele erori, de exemplu, nu există suficient produs pentru o anumită comandă sau detaliile sunt completate incorect în document și trebuie să fie emise un fel de diagnosticare utilizatorului, atunci într-un registru de informatii separat, unde tinem un protocol de trimitere a zborurilor, se vor face inregistrari. Orice utilizator va putea vedea dacă au existat probleme cu zborul sau nu.

Tehnic am rezolvat aceasta problema destul de repede, fara a optimiza algoritmii. Ca urmare:

• Așteptările în perioadele de vârf au dispărut;
• Nervozitatea depozitului a scăzut;
• Viteza de procesare a zborului a crescut semnificativ;
• Și ceea ce este cel mai important pentru noi și afacere este că toate acestea s-au făcut simplu și rapid.

Cazul 2. Expediere cu avion

Al doilea blocaj pe care l-am optimizat a fost expedierea comenzilor care au fost colectate de către depozitari peste noapte. Ne-am ocupat deja de procesul de afaceri care are loc înainte de asamblare, dar după finalizarea asamblarii are loc o operație, când depozitarii au început să înregistreze faptul expedierii zborurilor de la terminalul de colectare a datelor. Din punctul de vedere al utilizatorului, nu s-a întâmplat nimic critic în acest moment - codurile de bare au fost scanate, s-a înregistrat în 1C că un astfel de zbor ar putea fi expediat, stivuitorii au încărcat paleții în mașină și a plecat.

Din punctul de vedere al lui 1C în acest moment Reordonarea în masă a comenzilor a fost lansată pentru fiecare zbor, deoarece este necesar să se efectueze mișcările corespunzătoare conform documentelor, anularea acestui produs conform registrului soldurilor din celulele de expediere, efectuarea unor mișcări conform rezervelor etc. Și datorită faptului că mai mulți depozitari făceau asta în același timp, era din nou în aşteptare.

Poate că totul a fost rău în interogările noastre și trebuiau optimizate, dar nu am vrut să aprofundăm prea mult în acest lucru, poate pentru că suntem leneși.

Până la urmă noi implementat implementarea amânată.

• Din punct de vedere al logicii afacerii, nu a fost important pentru noi ca la orele 7:00-8:00 dimineața, când se încarcă mașinile, marfa să fie corect radiată conform registrelor. Principalul lucru pentru noi a fost că documentele aveau statutul „Expediate”, iar utilizatorii vedeau în formularele lor că au procesat astfel de documente. Deci, când depozitarii expediază zborurile, documentele de comandă nu sunt repostate; starea lor este pur și simplu schimbată în „Expediat”.
• în care Se face o înscriere în registrul de informații „Documente de executare” că astfel de zboruri, astfel de comenzi trebuie să fie finalizate mai târziu.
• Și apoi, după câteva ore, când nu există nicio încărcare pe sistem, începe un job de fundal, care rulează prin acest registru, se uită la aceste zboruri, aceste comenzi care trebuie procesate și le finalizează.

În esență, am implementat execuția întârziată. Nu este nimic nou aici; această idee funcționează de mulți ani atât în ​​ediția a X-a UT, cât și în UPP.

Uneori, implementatorii uită că astfel de probleme pot fi rezolvate cu o tehnică atât de simplă. Dar am rezolvat încă o dată problemele cu așteptările și faptul că 1C este „prost” și „lent”, și am făcut-o destul de repede.

Cazul 3. Crearea și implementarea implementărilor

A treia problemă pe care am rezolvat-o printr-o abordare similară a fost o problemă direct în baza noastră de birouri UT.

În timp ce lucram în depozit, am făcut viața lucrătorilor din depozit minunată și uimitoare, Au fost probleme și în biroul nostru UT, iar specialiștii noștri 1C din birou, care sunt responsabili de UT, ne-au rugat să ne dăm seama ce se întâmplă cu ei.

Am văzut că din anumite motive, biroul are și propria sa sezonalitate zilnică - o anumită fereastră de timp la începutul schimbului (aproximativ două până la trei ore), când vânzătorii înregistrează cea mai mare parte a comenzilor.

Telemarketerii, oamenii de vânzări, managerii de vânzări sună clienții, comunică cu aceștia și plasează comenzi. În acest moment, sistemul începe să încetinească teribil, până în punctul în care nu se generează rapoarte.

Procesul nostru de comandă este destul de simplu, îl puteți vedea pe slide.

• În UT, vânzătorul pregătește documentul „Comandă”, selectează soldurile disponibile utilizând selecția și înregistrează documentul.
• La plasarea unei comenzi, sistemul verifică dacă există suficiente solduri libere, dacă există datorii la creanțe și dacă au fost îndeplinite toate condițiile de plată. Și, dacă totul este bine, comanda este procesată. Dacă comanda este finalizată, înseamnă că există suficient produs pentru client.
• Apoi, vânzătorul trece la starea „Pentru expediere” și intră pe baza acestuia:
  • implementare;
  • factura fiscala;
  • documentul nostru oficial „Comanda de depozit”, care, cu ajutorul schimburilor, zboară apoi la noi în WMS.

Toate aceste operațiuni, în special înregistrarea vânzărilor, nu sunt necesare de către vânzătorul însuși. El a făcut deja tot ce era necesar pentru a accepta comanda - dacă comanda a fost procesată, atunci implementarea nu poate eșua. Este posibil să nu fie efectuată numai din cauza unor probleme tehnice care nu au legătură cu această comandă.

Prin urmare, toate aceste acțiuni pentru vânzător erau, pe de o parte, inutile; cineva pur și simplu trebuia să le facă. Dar, pe de altă parte, toate problemele au apărut în timpul implementării. Mai exact, problemele s-au datorat faptului că Mai mulți oameni de vânzări au efectuat implementări în paralel în același timp și din această cauză au apărut blocaje.

Ne-am uitat la această problemă și a decis să facă implementări create și realizate într-un fir separat de un job de fundal.

Munca vânzătorului arată acum astfel:

• El plasează o comandă și, dacă este efectuată, o transferă în starea „Pentru expediere”. Aici se termină munca vânzătorului. El trece la următorul client. Nu mai înregistrează niciun document.
• În același timp, în sistem este scris în registrul de informații corespunzător că a apărut o comandă pentru care trebuie creată o implementare.
• Și o dată la câteva minute, sarcina de rutină verifică dacă există ceva în acest registru și, dacă există, atunci începe să creeze implementări bazate pe aceste comenzi și face acest lucru „într-un fir”.

Nu există nicio dispută pentru resurse între mai multe sesiuni. Implementarea este creată puțin târziu, dar acest lucru nu este critic. Utilizatorii au plasat o comandă și au început să lucreze cu următorul client. Implementarea va fi creată în continuare în câteva minute și toate celelalte sarcini vor fi finalizate.

Rezultatul în acest caz a fost, de asemenea, similar:

• Am rezolvat problema așteptării la lacăte.
• Debitul UT a crescut în această perioadă.
• Utilizatorii și-au schimbat „mânia în milă”.

Principalul lucru este că din momentul în care totul „a fiert” pentru ei și au ajuns în vârful structurii manageriale, ne-au spus: „Faceți ceva, sunteți oameni 1C, sunteți programatori”, destul de timpul a trecut înainte, cum am înțeles care este problema și am rezolvat-o - verificată, testată.

Rezultate

Permiteți-mi să rezum pe scurt.

Dacă aveți probleme similare, dar nu există nicio modalitate de a face optimizare și doriți să obțineți rezultatul mai rapid și cu mai puține cheltuieli, aruncați o privire:

• Poate că poți reprogramați aceste operațiuni pentru altă dată astfel încât acestea să fie executate atunci când sistemul nu este încărcat puternic;
• Poate poți aranja aceste operațiuni un fir pentru a elimina cauza blocării.
• Desigur, cumpărarea de hardware pentru 1000 USD este mai corectă, dar trebuie să obținem rezultate mai rapid și cu efect maxim. Dacă logica nu suferă, atunci de ce nu.

*******************

Acest articol a fost scris pe baza rezultatelor unui raport () prezentat la conferința INFOSTART EVENT 2017 COMMUNITY.

Vă invităm la o nouă conferință.

Utilizarea System Monitor pentru a diagnostica problemele de performanță 1C: Enterprise 8

Monitor de sistem este un instrument standard pentru diagnosticarea problemelor de performanță ale sistemului de operare, ale diverselor componente ale aplicației și ale hardware-ului utilizat. Poate fi folosit pentru a măsura performanța atât a computerului local, cât și a altor computere din rețea.

Monitor de sistemeste principalul instrument de identificare a blocajelor din sistem.Componentele sistemului analizat sunt interpretate ca obiecte ai căror parametri sunt reprezentați ca un set de contoare, fiecare obiect având propriul set de contoare.În timpul procesului de instalare, unele aplicații extind setul de sistem cu propriile obiecte și contoare specifice care caracterizează performanța acestei aplicații.De exemplu, la instalarea Microsoft SQL Server, anumite obiecte și contoare de server de baze de date sunt adăugate la setul standard de obiecte și contoare ale sistemului de operare.

Potențiale blocaje care ar putea avea cel mai mare impact asupra performanței:

Memorie

• Lipsa RAM instalată pe computer are un impact negativ asupra performanței tuturor componentelor 1C:Enterprise 8 și Microsoft SQL Server.
• Pe măsură ce numărul de utilizatori și volumul bazei de informații cresc, cerințele pentru această resursă de pe serverul 1C:Enterprise 8 și Microsoft SQL Server cresc.
• Memoria insuficientă duce la creșterea paginilor între fișierul de pagină și memoria fizică, ceea ce reduce semnificativ performanța sistemului.

Procesoare

• Performanța insuficientă sau numărul de procesoare poate deveni un blocaj atunci când sarcina sistemului crește din cauza creșterii numărului de utilizatori.
• Efectul creșterii numărului de procesoare într-un sistem multi-utilizator este, de regulă, semnificativ mai mare decât creșterea vitezei acestora.

Operații pe disc

• Performanța subsistemului de disc este unul dintre factorii critici care determină performanța Microsoft SQL Server.
• De regulă, nu are niciun efect asupra performanței serverului 1C:Enterprise 8.

Conflicte de blocare Microsoft SQL Server

• Unul dintre principalii factori care reduc performanța în modul multi-utilizator
• Probabilitatea conflictelor de blocare poate fi redusă prin rafinarea soluției aplicației

Identificarea blocajelor

Tabelul oferă o listă a principalelor obiecte și contoare utilizate la analiza problemelor de performanță.

Un obiect	Contoare de bază	Descriere	Principalele semne ale unei probleme	Opțiuni pentru rezolvarea problemei
Memorie	Memorie\Pagini/sec	Caracterizează intensitatea schimbului dintre subsistemul disc și RAM. Sistemul de discuri este accesat deoarece paginile solicitate nu sunt în RAM.	Valoarea normală a acestui contor ar trebui să fie aproape de zero. O creștere a citirii acestui contor peste 20 de pagini pe secundă indică necesitatea creșterii cantității de memorie RAM.	Creșterea cantității de RAM instalată pe computer. Transferați aplicații care necesită multă memorie pe un computer separat. De exemplu, instalarea serverului 1C:Enterprise 8 și Microsoft SQL Server pe computere diferite.
CPU	Procesor\%Processor Time	Timpul pe care procesorul îl petrece efectuând lucrări utile, ca procent din timpul total al sistemului.	Dacă valoarea medie de utilizare a procesorului depășește 85%, atunci procesorul este blocajul în sistem.	Înlocuirea procesoarelor cu altele mai rapide. Creșterea numărului de procesoare. Mutați aplicațiile care necesită mult procesor pe un computer separat. De exemplu, instalarea serverului 1C:Enterprise 8 și Microsoft SQL Server pe computere diferite.
	System\Processor Queue Lungime	Lungimea cozii procesorului.	Dacă lungimea medie a cozii depășește 2 pentru o lungă perioadă de timp, atunci aceasta indică faptul că procesorul este blocajul.
Sistem de discuri	Disc fizic\%Timp disc	Procentul de timp în care discul a fost ocupat cu servicii de citire sau scriere.	Utilizare redusă a procesorului serverului	Instalarea unităților mai rapide. Folosind unități SCSI. Folosind un controler RAID hardware. Creșterea numărului de discuri dintr-o matrice RAID.
	Disc fizic\Avg. Lungimea cozii de disc	Afișează eficiența subsistemului de disc. Reprezintă lungimea medie a cozii de așteptare a cererilor de disc.	Creșterea cozii de solicitări către subsistemul disc
Interfata retea	Interfață de rețea\Bytes Total/sec	Viteza cu care octeții sunt primiți sau trimiși printr-o interfață de rețea	Valoarea acestui contor nu trebuie să depășească 65% din lățimea de bandă a adaptorului de rețea.	Instalarea unui adaptor de rețea cu lățime de bandă mai mare (dacă setările de rețea permit). Instalarea unui adaptor de rețea suplimentar.
Încuietori	SQL Server: Locks\Lock Wait Time (ms)	Afișează timpul total de așteptare (în milisecunde) pentru finalizarea cererilor de blocare în ultima secundă	Valoarea medie a timpului total de așteptare nu trebuie să depășească timpul de răspuns al sistemului specificat înmulțit cu numărul de utilizatori activi	Timp redus de executare a tranzacției. Asigurarea unei proceduri uniforme de acces la toate resursele. Optimizarea interogărilor într-o soluție de aplicație. Setarea corectă a atributelor de indexare pentru detaliile obiectului de configurare poate reduce semnificativ intervalul de blocări. Menținerea la zi a indicilor și statisticilor Microsoft SQL Server. Utilizarea operatorului „PENTRU SCHIMBARE” în ​​interogări.
	SQL Server: Blocări\Timp mediu de așteptare (ms)	Afișează timpul mediu de așteptare (în milisecunde) pentru finalizarea fiecărei cereri de blocare.	Nu trebuie să depășească timpul de răspuns al sistemului specificat
Blocaje	SQL Server: Blocări\Număr de blocaje/sec	Afișează numărul de solicitări de blocare pe secundă care s-au încheiat într-un blocaj	Valoare de contor diferită de zero

Indicatori cheie ai performanței slabe

1. Performanța sistemului nu îndeplinește cerințele logicii de afaceri a întreprinderii automatizate pentru o parte semnificativă a operațiunilor;

2. Majoritatea utilizatorilor de sistem se plâng de:

2.2 Performanță generală inacceptabilă a sistemului;

2.3 Performanță inacceptabilă în operațiuni individuale;

2.4 Deteriorarea bruscă a performanței;

2.5 Erori frecvente:

2.6.1 " Perioada de expirare a cererii de blocare a fost depășită»;

2.6.2 „Timpul maxim de așteptare pentru acordarea blocării a fost depășit”;

2.6.3 " Tranzacția a fost blocată pe resurse de blocare cu un alt proces și a fost aleasă ca victimă a blocajului»;

2.6.4 „Conflict de blocare în timpul tranzacției”

Dacă performanța sistemului este considerată nesatisfăcătoare, atunci este necesar să se analizeze sarcina echipamentului în conformitate cu aceste recomandări:

Efectuați o serie de măsurători cu următoarele contoare de performanță:

Memorie – schimb de pagini\sec

Procesor - % încărcare CPU

Sistem - Lungimea cozii CPU

Disc fizic - lungimea medie a cozii de disc

Rețea – schimb octet/sec (exclus, deoarece totul este pe un singur server și activitatea în rețea este minimă)

Analiza datelor de măsurare

Analiza datelor trebuie efectuată pe baza valorii medii și maxime pentru fiecare contor în intervalul de timp selectat.

Aceste valori apar în partea de jos a ferestrei principale System Monitor.

Tabelul de mai jos oferă descrieri ale contoarelor System Monitor și ale valorilor limită pentru fiecare dintre ele.

Dacă aceste valori sunt depășite, ar trebui să luați în considerare creșterea performanței componentei hardware asociate.

grup	Tejghea	Descriere	Criteriu	Gâtul de sticlă
	schimb pagini\sec	Intensitatea schimbului dintre subsistemul disc și RAM	Medie: aproximativ 0 Maxim: nu mai mult de 20	RAM insuficientă
Procesoare	% încărcare CPU	Sarcina procesorului	Nu mai mult de 70% pentru o lungă perioadă de timp
	Lungimea cozii CPU	Coada la procesoare	Nu mai mult de 2 * număr de nuclee de procesor pentru o lungă perioadă de timp	Performanță insuficientă a procesorului
Disc fizic	lungimea medie a cozii de disc	Coada la discuri	Nu mai mult de 2 * număr de discuri care rulează în paralel	Performanță insuficientă a subsistemului de disc
Interfata retea	schimb octet/sec	Viteza de transfer în rețea	Nu mai mult de 65% din lățimea de bandă a adaptorului de rețea	Lățimea de bandă a interfeței de rețea insuficientă

Începând cu versiunea 14, Bitrix a adăugat setări SEO care ajută Optimizare SEO 1C Bitrix pentru sarcinile tale. Unul dintre punctele cheie ale acestei optimizări este capacitatea de a realiza șabloane automate în care putem seta meta tag-uri: H1, titlu, descriere, cuvinte cheie și cuvinte cheie pentru imagini precum titlu și numele imaginii în sine alt.

După cum ați ghicit, în această lecție vom vorbi despre setările SEO ale 1C Bitrix și vom lua în considerare principiile de funcționare ale acestei funcționalități.

Câmpurile SEO au proprietăți de moștenire; ele pot fi setate începând de la blocuri de informații, apoi secțiuni, și terminând cu fiecare element care poate fi format pentru cererea finală.

Puteți împărți formarea câmpurilor SEO în trei etape:

1. Configurarea câmpurilor de bloc de informații SEO;
2. Configurarea câmpurilor SEO de secțiuni și elemente;
3. Configurarea unei componente complexe.

Definiție:

Setări SEO– un set de reguli care definesc șabloanele de ieșire a metadatelor pentru optimizarea unui site pe baza parametrilor SEO ai motoarelor de căutare.

Optimizarea SEO a câmpurilor bloc de informații

Să folosim catalogul nostru de produse ca exemplu pentru a realiza optimizarea SEO a blocurilor de informații în Bitrix. Să mergem la partea administrativă a site-ului, Infoblocks, să selectăm catalogul de produse, să deschidem fila SEO și să configurem câmpurile în ordine.

Prima secțiune de setări este destinată șabloanelor de titlu, descriere, metaetichete de cuvinte cheie, precum și titluri de pagină H1. Folosind acest buton […], care se află lângă fiecare câmp, putem crea șabloanele de care avem nevoie pentru optimizarea SEO a site-ului pe Bitrix.

Să creăm un șablon META TITLE și să scriem în câmp:

Catalog (=this.Name) din magazinul online dws.mcdir.ru.

Adăugând numele sau domeniul magazinului nostru până la sfârșit, unicizăm astfel TITLUL. Titlul nostru complet TITLUL este afișat chiar mai jos și rețineți că câmpul înlocuit „Numele secțiunii” este afișat cu majuscule. Puteți să o lăsați așa cum este, dar este de dorit ca propoziția să fie formată corect. Să folosim un alt operator (=lower arg1 ... argN) care va converti numele secțiunii în minuscule.

Ne înregistrăm și numele s-a schimbat imediat, acest handler de filtru este disponibil și când faceți clic pe butonul următor […], unde selectam apoi Câmpuri de secțiune, Numele secțiunii curente cu litere mici.

Lista operatorilor din Bitrix:

• (=lower arg1 ... argN) - conversie în minuscule;
• (=upper arg1 ... argN) - conversie în majuscule;
• (=concat arg1 ... argN ", ") - concatenarea șirurilor printr-un separator;
• (=limită arg1 ... argN " „NN)- limitarea NN elemente prin separator;
• (=translit arg1 ... argN) - transliterarea argumentelor selectate;
• (=min arg1 ... argN) - eșantionarea valorii numerice minime;
• (=max arg1 ... argN) - eșantionarea valorii numerice maxime;
• (=distinct arg1 ... argN) - valori unice (fără duplicate).

Pentru a optimiza șablonul META CUVINTE CHEIE, să scriem pur și simplu o listă de cuvinte cheie cu titlul secțiunii noastre cu litere mici. Prima prioritate este să afișam numele secțiunii cu litere mici, apoi ne diluăm titlurile cu cuvinte (comanda, cumpără, cumpără în orașul tău etc.)

Exemplu de META CUVINTE CHEIE de optimizare SEO:
(=scădeți acest.Nume), comandă (=coborâți acest.Nume), cumpărați (=coborâți acest.Nume), achiziționați în Krasnodar (=coborâți acest.Nume), (=coborâți acest.Nume) de la distribuitor

Mai jos vedem cum s-au format cuvintele cheie date. În continuare, vom crea o scurtă descriere pentru metadatele DESCRIPTION ale secțiunilor de catalog.

Scriem un text tematic care va combina numele site-ului, numele secțiunii și dezvăluie esența paginilor curente ale catalogului.

Exemplu de optimizare SEO DESCRIERE:
Magazinul online dws.mcdir.ru, în secțiunea (=în jos. Nume) există o selecție uriașă de haine pentru toate gusturile. Magazinul nostru este situat în Krasnodar și suntem distribuitor oficial în Rusia.

Rezultatul final al șablonului DESCRIERE este afișat mai jos, acum să creăm titlul de secțiune, care va fi afișat și în H1.

Să trecem la următoarea secțiune „Setări pentru elemente”. Optimizăm prin analogie cu modul în care am lucrat cu secțiuni, cu excepția șablonului DESCRIERE, unde vom afișa producătorul produsului din proprietatea atribuită elementului.

Prin analogie, completăm metadatele pentru proprietățile imaginilor în sine, cum ar fi ALT și TITLE. Dacă imaginile anterioare au fost încărcate pe site, atunci datele nu le vor fi aplicate, vor rămâne ca până acum, iar această funcție va fi declanșată la actualizarea imaginii sau la crearea unui nou element când încărcați fișierul.

Chiar mai jos în Bitrix se află secțiunea „Management”, folosind fila marcată „Ștergeți cache-ul valorilor calculate”, puteți vedea imediat afișarea tuturor modificărilor efectuate, memoria cache va fi actualizată și rezultatul va fi afișat imediat.

După setările pe care le-am făcut, cu siguranță vom salva blocul de informații.

Setări SEO pentru secțiuni și elemente

Am rezolvat optimizarea blocului de informații în Bitrix, acum să mergem la catalogul de îmbrăcăminte și, dacă este necesar, să setăm secțiuni care nu corespund descrierii noastre. De exemplu, în descrierea DESCRIPTION am scris pe care o avem în magazinul nostru online „…. o selecție imensă de haine pentru toate gusturile...", această descriere nu corespunde unor secțiuni precum „Pantofi”, „Accesorii” și vom ajusta secțiunile curente pentru a se potrivi descrierii noastre.

Selectați, schimbați secțiunea „Pantofi”, deschideți fila „SEO” și verificați descrierile secțiunii curente. Dacă această filă nu este afișată, faceți setări pentru formularul curent, așa cum am explicat cum să faceți acest lucru în lecția „Editarea formularelor”. Descrierea DESCRIPTION arată o discrepanță clară cu secțiunea „... o secțiune de încălțăminte cu o selecție uriașă de ÎMBHĂCĂMINE pentru toate gusturile...”. În acest caz, să scriem nu Pantofi, ci Produse.

Pentru a face acest lucru, puteți bifa „Editați pentru această secțiune și subsecțiunile sale”, câmpul va deveni activ pentru editare. Acum să facem modificările noastre și, în viitor, dacă salvăm acum, atunci toate subsecțiunile secțiunii curente vor moșteni această proprietate.

Începeți întotdeauna editarea câmpurilor SEO din secțiunea principală.

Să coborâm și să verificăm descrierea elementelor. Să verificăm formarea descrierii subsecțiunilor și apoi să facem modificările corespunzătoare în secțiunea Accesorii.

Adăugarea unui nou element la Bitrix

Să adăugăm un nou element în această secțiune ca exemplu. Faceți clic pe butonul Creare produs și completați câmpurile principale. Să mergem la fila SEO și aici vedem că anteturile noastre nu sunt afișate în versiunea finită, deși implicit proprietățile sunt incluse peste tot. Chiar dacă setăm o nouă proprietate în mod implicit, sistemul nu ne va arăta rezultatul.

Pentru ca Bitrix să afișeze metadatele complete, elementul trebuie să fie salvat și este recomandabil să faceți acest lucru în așa fel încât alți utilizatori să nu vadă afișarea acestui element și, în același timp, să îl putem vedea de sub Cont de administrator.

Trebuie să setăm drepturi de acces la elementul curent; pentru a face acest lucru, accesați fila de acces și setați drepturile pentru grupurile „Toți utilizatorii” și „Toți utilizatorii autorizați” la Fără acces. Am arătat cum să afișez fila „Acces” și să-i configurez câmpurile în lecția Configurarea drepturilor de acces.

După ce ați terminat cu setările formularului în Bitrix, accesați fila SEO și faceți clic pe butonul Aplicați. Am creat anteturi complete și elementul Active în sine, dar toți utilizatorii, cu excepția grupului de administratori, nu îl văd pe site. Credeți-mă, acest lucru este foarte convenabil; permite administratorului să verifice complet elementul înainte de publicarea sa finală.

Activați SEO în componentă

După optimizare, blocul de informații, secțiunile și elementele din Bitrix, să mergem la catalog la partea vizuală a site-ului și să vedem cum sunt afișate formularele noastre completate cu șabloane de metadate. Dacă titlul unui element sau al unei secțiuni nu este afișat în componentă și nu este modificabil pe toate paginile, acest lucru indică faptul că parametrul „Set page title” nu este setat în componentă în Setări suplimentare.

Să mergem la setările componente și să activăm această opțiune.

Activați modul de editare rapidă, faceți clic pe roată, selectați Setări suplimentare, bifați caseta corespunzătoare și salvați.

Titlul paginii noastre s-a schimbat imediat. Prin deschiderea paginii în modul cod, vedem afișarea corectă a datelor Bitrix SEO.

După cum puteți vedea, prin optimizarea parametrilor SEO în 1C Bitrix, vă puteți personaliza în mod flexibil site-ul pentru interogări de căutare, iar ușurința de a configura mecanismul este clară chiar și pentru un copil.

Utilizați acești parametri de setări SEO în Bitrix pentru a vă optimiza și dezvolta site-ul web.

Trimite acest articol pe e-mailul meu

De-a lungul timpului, mulți utilizatori 1C observă că sistemul începe să funcționeze mai lent și din ce în ce mai des „eșecuri” chiar și atunci când folosesc configurații standard „de la fabricație”.

Principalele reclamații semnalate de utilizatori:

Documentele au început să fie procesate încet

Generarea rapoartelor durează prea mult

Programul se blochează mai des

Plângeri familiare, nu?

Să încercăm să înțelegem principalii factori care reduc performanța și să găsim soluții.

Echipament învechit

În primul rând, vom elimina posibilitatea problemelor hardware.

Pentru a face acest lucru, trebuie să verificați cerințele hardware ale 1C 8.3

Acest lucru se poate face pe site-ul oficial http://1c.ru/rus/products/1c/predpr/compat/hard/demand.htm

Platformă învechită

Unii utilizatori nu le place să actualizeze configurația din nou, considerând că versiunile anterioare funcționează mai stabil. Din păcate, un astfel de conservatorism poate fi dăunător: dezvoltatorii actualizează în mod regulat platforma, reparând erorile din cod și optimizând mecanismele, astfel încât utilizarea unei versiuni învechite (cu o întârziere semnificativă în lansări) poate afecta negativ performanța.

Performanță slabă a serverului

Este posibil să creșteți performanța prin editarea setărilor serverelor SQL și 1C:Enterprise.

Pentru a face acest lucru, în BIOS dezactivăm toate opțiunile pentru economisirea puterii procesorului și setăm performanța la maximum. Este convenabil să faceți acest lucru, de exemplu, prin utilitarul PowerSchemeEd.

Este recomandabil să dezactivați serviciile care sunt rar utilizate. Astfel de servicii includ FullText Search and Integration Services

Nu uitați să setați la maximum cantitatea de memorie alocată serverului. Acest lucru este necesar pentru ca serverul SQL să aibă timp să ștergă memoria în avans, controlând umplerea acesteia.

Alternativ, este posibil să comutați serviciul 1C în modul de depanare. Datorită acestui fapt, optimizarea 1C este crescută și mai mult.

Baza de date mare

Pe măsură ce lucrați, orice bază crește în volum în timp. Prin urmare, nu uitați de întreținerea preventivă regulată a sistemului. Este convenabil să faceți acest lucru folosind instrumentul standard „Testarea și corectarea bazei de informații”.

Acest instrument va ajuta la optimizarea bazei de date prin restructurare și reindexare. Pentru a utiliza procesarea trebuie să fiți în modul configurator. Procesarea arată astfel:

Configurare incorectă a sarcinilor de fundal și de rutină

Este recomandabil să defragmentați indici și să actualizați statisticile zilnic, deoarece prin reducerea fragmentării indicilor, optimizarea 1C este redusă semnificativ.

Este recomandabil să defragmentezi și să actualizezi statisticile la aceeași frecvență. Operația se face rapid, pentru a o efectua nu este nevoie să deconectați utilizatorii activi, iar accelerarea efectivă a 1C de la utilizare a fost dovedită.

Reindexarea completă este efectuată atunci când baza de date este blocată. Acesta este un proces mai lung, dar trebuie făcut cel puțin o dată pe săptămână în combinație cu defragmentarea și actualizarea statisticilor.

Interacțiune incorectă cu alt software

În plus, problema de performanță 1C:Enterprise poate fi legată de alt software preinstalat.

Cel mai adesea acestea sunt antivirusuri cu setări incorecte. În consecință, pentru a asigura funcționarea corectă a 1C, trebuie să verificați setările antivirusului utilizat. De exemplu, pentru Kaspersky, setările sunt indicate pe site-ul oficial https://support.kaspersky.ru/general/compatibility/11683

Canal de comunicare instabil

Cel mai adesea, această problemă este relevantă atunci când lucrați în 1C prin interfața WEB sau desktopul de la distanță. Dacă compania utilizează acces la distanță, atunci este imperativ să verificați funcționalitatea canalului de comunicare.

Accelerație 1C în modul utilizator

Din fericire, în livrările moderne, optimizarea și accelerarea 1C se realizează și în modul utilizator.

În fila „Suport și întreținere” (secțiunea „Administrare”) este disponibilă o listă largă de funcții care măresc accelerația 1C:

Dezactivarea lansării automate a sarcinilor programate neutilizate;

Dezactivați căutarea text integral;

Reducerea bazei de date pentru perioada anterioară;

Îndepărtarea obiectelor marcate;

Optimizare 1C

Desigur, optimizarea și accelerarea 1C sunt realizate nu numai prin aceste metode, așa că lista de sfaturi nu este un panaceu, ci poate oferi doar o idee generală a posibilității de îmbunătățire a muncii.

Adesea, problemele cu bazele de date necesită implicarea unor specialiști calificați, așa că ne puteți contacta oricând pentru sfaturi.