Długie łączenie z systemem zewnętrznej sprzedaży

[Bartosz Rosa 1 782]

Sello przy wystawianiu dokumentów wykonuje więcej operacji niż samo wystawienie paragonu.

Z poziomu Subiekta mamy tutaj:

- wystawienie paragonu

 

Z poziomu Sello:

- uruchomienie Subiekta

- zalogowanie na odpowiedniego użytkownika

- utworzenie/aktualizacja kontrahenta

- wyszukanie dokumentu, czy nie został już utworzony

- utworzenie dokumentu

 

Siłą rzeczy będzie to trwało dłużej i trzeba by zdiagnozować, która z powyższych czynności wprowadza dodatkowe opóźnienie. Do tego najlepiej użyć profilera SQL i prześledzić czasy wykonywania poszczególnych zapytań SQL. Tego jednak na odległość nie zrobimy.

 

P.S. Czy indeks był dodany po aktualizacji wersji Subiekta do nowszej ponownie?

[HotKey . 249]

A co to są te wersje bazy 1.22 lub 1.23?

Bo mnie pyta jeden program.

[Bartosz Rosa 1 782]

Nie rozumiem pytania .

[HotKey . 249]

Jak wchodzę do jednego programu partnerskiego do Sello, to mnie prosi na początku o wybór wersji bazy danych i to mnie dziwi, bo nie wiedziałem, że jakieś resztki poprzednich baz danych są przechowywane w Sello typu 1.22; 1.21 itd, myślałem, że zawsze jest ona proponowana najnowsza, no ale OK to pewnie jakieś niuansy oprogramowań partnerskich.

[Bartosz Rosa 1 782]

Baza danych z wersji na wersję się nieco zmienia, dochodzą jakieś kolumny, tabele, inne się zmieniają, być może programy partnerskie muszą wiedzieć z jaką bazą mają do czynienia, aby np nie próbować wykonywać poleceń na polach, których w danej wersji bazy nie ma.

Sam numer bazy danych jest przechowywany w bazie w tzw. Extended Properties, które można zobaczyć za pomocą Management Studio we właściwościach bazy. Zazwyczaj numer bazy jest podobny do numeru wersji, tak jest łatwiej i np 1.23.0 ma numer bazy (parametr dbver ) 1.230. Bazy w wersji BETA mają numer docelowy -1, czyli dla 1.23.0 BETA miała numer 1.229.

 

Ostrzegam tylko przed modyfikacją ręczną tego parametru, bo zdarzyło się, że ktoś zmienił go ręcznie, bo aktualizacja nie chciała przejść. Nie wolno tego robić, bo wtedy Sello pracuje na złej strukturze bazy i może spowodować nieodwracalne uszkodzenia danych, a w najprostszym przypadku coś nie będzie działać, program będzie się zamykał itp.

[HotKey . 249]

OKA dzięki za wyjaśnienie.

[legend 5]

szukałem tu na forum czy coś już było w temacie i jak widać jest.

 

Zgłoszono mi, że "paragony długo idą" i faktycznie. Dłużej czeka się na okno "dokument końcowy" a i sam paragon idzie dość wolno, a przy np 40 pozycjach idzie w ratach  całkiem długimi przerwami czego nie było. Podobnie jest z wydrukami do paczek. Generują się dłużej.

 

Zadziwia to, że miesiąc temu wymieniłem serwer i mam pełne i legalne oprogramowanie ze względu na wielkość bazy danej...więc powinno być szybciej, nie jest

[Bartosz Rosa 1 782]

Czy problem wystąpił po aktualizacji Sello bądź Subiekta i jeśli tak to z jakiej wersji wcześniejszej?

[legend 5]

PODNOsIŁEM SELLO Z 1.21 do bieżącej

[Bartosz Rosa 1 782]

Pomiędzy tymi wersjami nie było w sumie spektakularnych zmian w Sello w okolicach dokumentów. Czy wersja Subiekta była również zmieniana?

 

Można sprawdzić jeszcze to rozwiązanie: https://forum.sello.pl/index.php?topic=9254.msg62775#msg62775

 

[legend 5]

dzięki za sugestię.

 

tak, subiekt jest również w najnowszej wersji.

 

Zwróciłem na to uwagę w dyskusji, że jest wolniej, ale nie na tyle aby to w jakiś sposób wpływało na pracę u mnie

[amazinggirl 4]

Wątek już trochę nieaktywny ale mamy ten sam problem - długi czas ładowania okna podczas wystawiania dokumentu końcowego z poziomu Sello, mniej więcej 5s. Sello w wersji 1.24, Subiekt 1.47 SP1, baza SQL 2012 Standard.

 

Sprawdzałem jakie zapytania lecą do bazy z SQL Profiler i dodałem kilka indeksów ale nie zmieniło to sytuacji drastycznie.

U nas problem wydaje się być w jednym SQL który jest wykonywane 4 razy przy każdym uruchomieniu okna:

 

exec sp_executesql N'DECLARE @uid		AS INT			
DECLARE @hid		AS TNazwa		
DECLARE @apid		AS INT			
DECLARE @dataRew 	AS datetime		
DECLARE @dataSub 	AS datetime		

SET @uid =		@P1
SET @hid =		@P2
SET @apid =		@P3
SET @dataRew =	@P4
SET @dataSub =	@P5

DELETE FROM pd_Sesja WHERE ss_spid = @@SPID 
IF NOT EXISTS(SELECT rsc_objid FROM [master].[dbo].[syslockinfo] WHERE rsc_type=5 AND object_name(rsc_objid)=''dok_MagDysp'')
DELETE FROM dok_MagDysp WHERE md_spid = @@SPID 

UPDATE pd_Sesja SET 
ss_uid = @uid
,	ss_hid = @hid
,	ss_apid = @apid
,	ss_data = getdate()
,	ss_ignore = 0 
,	ss_data_zamkniecia = @dataSub
,	ss_data_blokady_rach = @dataRew
WHERE ss_spid = @@spid

IF @@ROWCOUNT<=0
BEGIN
INSERT INTO pd_Sesja
		(ss_spid,	ss_uid,	ss_hid,	ss_apid,ss_data_zamkniecia,	ss_data_blokady_rach)
VALUES	(@@spid,	@uid,	@hid,	@apid,	@dataSub,			@dataRew)
END
',N'@P1 int,@P2 varchar(50),@P3 bigint,@P4 datetime,@P5 datetime',12,'XXX',8,NULL,NULL

 

Każde takie zapytanie zajmuje ~250ms, więc jak jest wykonane 4x daje nam to już sekundę. Indeksy na pd_Sesja są i nie ma tam tak wielu danych więc to nie tu jest problem, ale zauważyłem że samo odpytanie widoku syslockinfo (dokumentacja mówi że ten widok będzie usunięty kiedyś..) zajmuje te ~250ms. Domyślam się że ten system służy sprawdzeniu czy ktoś inny nie wywołał tworzenia dokumentu dla transakcji - i pewnie dlatego też to nie jest wykonywane jak nowy dokument jest tworzony bezpośrednio w subiekcie (SQL Profiler nie wskazuje na to), bo niczego nie trzeba blokować.

 

Jakiś pomysł jak można by to przyśpieszyć? Przy kilkuset fakturach dziennie robi się to mało wydajne..

[itbrat ☺ 12]

Hmm to by było to..

U nas zmieniliśmy strategie, zaznaczasz kilka transakcji i grupowo.

Potem tylko edytować taki dokument.

 

Nieco działa szybciej po całkowitym odbudowaniu indeksów + przeniesienia na mocniejszy

sprzęt zarówno klienta jak i serwer z sello.

 

Obczaj tutaj zapytania, bo może całkowita odbudowa od podstaw Ci pomoże: https://forum.sello.pl/index.php?topic=10497.0

 

 

Na jakim sprzęcie macie odpalony SQL?

U mnie to:

Intel i5-6500, 16GB DDR4 2400, SSD HyperX Furry 240GB

 

[amazinggirl 4]

U nas to faktury zagraniczne i musimy każdą praktycznie edytować.

 

Spróbuję z przebudowaniem indeksów. Tylko nie wiem czy to zmieni czas odpytania tego widoku systemowego - próbuję znaleźć w google'u cokolwiek co by pomogło to zoptymalizować ale bez rezultatu.

 

Mamy serwer 2xE5-2620v2, 64GB DDR3, 4x600GB SAS w RAID10, więc konfiguracja trochę wolniejsze od Twojej. Na tym dwa serwery wirtualne, jeden na pulpity zdalne i klienty, drugi na SQL; ustawione tak żeby nie było współdzielenia RAMu albo procesorów. Generalnie wszystko raczej śmiga, tylko nie te dokumenty wystawiane z Sello.

[Bartosz Rosa 1 782]

To zapytanie do pd_Sesja widzisz dla bazy Sello czy Subiekta?

[Ł S 1]

To jest najświeższa odpowiedź insert na bolączki użytkowników sello z innego forum "AUTOMATYCZNE ODPOWIEDZI NA PYTANIA DO SPRZEDAJĄCEGO I DYSKUSJE" : Obecnie, z racji prac nad nowym Sello NX, rozwój Sello 1 jest ograniczony tylko do zmian koniecznych, wymuszonych przez Allegro. Akurat cały nasz zespół jest mocno zaangażowany w prace nad NX, które wymagają zaangażowania wszystkich programistów. Póki co obserwujemy zgłoszenia aby zakwalifikować w razie potrzeby rzeczy do realizacji w Sello 1. Regularnych prac natomiast nad Sello 1 nie prowadzimy obecnie. Zostawiam to innym do skomentowania.

 

[Bartosz Rosa 1 782]

Ale taka informacja pojawiła się już we wrześniu i jest publicznie dostępna dla wszystkich https://www.sello.pl/2021/09/28/wazne-plany-rozwoju-sello-na-najblizszy-czas/

Idziemy naprzód i aby tam dotrzeć musimy podejmować takie decyzje i ciąć ostrym nożem zaplanowane wcześniej funkcje.

 

Co do wspomnianych wiadomości automatycznych to czekają one przypisane obecnie do wersji 1.41. Gdy będzie taka możliwość, prace nad tą wersją będą kontynuowane. Natomiast w najbliższym czasie nie oderwiemy nikogo z zespołu, bo wpłynęło by to dość mocno na pracę pozostałych osób.