[SFERA] Kompletacja pojedyńczej pozycji ZK

[Darek FremanOfArrakis 0]

Od kilku lat bezproblemowo korzystamy z rozwiązania własnego obsługującego dokumenty Nexo na kolektorach danych przez Sferę. Od momentu przejścia API na .net Framework 4.7.2 powstało kilka problemów z wydajnością – z większością się uporaliśmy niestety z kompletacją pojedynczej pozycji ZK już nie. Do tej pory (do wersji 41) używanie interfejsu IDokumentRezerwujący -> Zwolnij/ZwiększRezerwację na ZK działało satysfakcjonująco (pomimo potrzeby otwarcia/zmiany/zapisu całego dokumentu). Obecnie kompletacja poj. pozycji w tej formie jest nie do przyjęcia – trwa ok 4 sek. (na ZK powyżej 100 pozycji)  vs 1s. Czy ominęliśmy coś w dokumentacji i jest inny bardziej wydajny sposób (np. ew. osobny „Menadżer Rezerwacji”)?

[Mateusz Matuszewski 92]

W której wersji konkretnie pojawił się problem? Czy spowolnienie jest odczuwalne w momencie pobierania ZK z menedżera zamówień, wywołania metody Zwolnij/ZwiekszRezerwacje, podczas zapisu dokumentu czy w jeszcze innym miejscu? Czy problem dotyczy każdego zamówienia czy tylko takich z większą ilością pozycji? Czy w metodzie dzieje się coś więcej poza zmianą rezerwacji? Jaki jest status zamówienia (C/R/S/inny)? Czy w parametrach Subiekta włączona jest Kolejność realizacji zamówień? Czy w systemie działają jakieś rozwiązania sfery zdarzeniowej? Jeśli to możliwe, to poproszę o kod rozwiązania (może być w wiadomości prywatnej).

[Darek FremanOfArrakis 0]

Generalnie chodzi mi o czas ogólny procedury rezerwacji pozycji dokumentu ze statusem C, na który w tym wypadku składa się:

 

Dla ZK z 200 poz. :

Zamowienie znajdz time: 00:01.57
PozycjaEncja znajdz time: 00:00.00
ZwiekszZwolnijRezerwacje time: 00:00.06
Zapisz ZK time: 00:02.43
Elapsed method TOTAL time: 00:00:04.08

Suma czasu wykonania SQL queries wygenerowanych przez Linq to znikome kilka milisekund

 

Dla ZK z 10 poz. :

 

Zamowienie znajdz time: 00:00.30
PozycjaEncja znajdz time: 00:00.00
ZwiekszZwolnijRezerwacje time: 00:00.06
Zapisz ZK time: 00:00.11
Elapsed method TOTAL time: 00:00:00.48

Suma czasu wykonania SQL queries wygenerowanych przez Linq to znikome kilka milisekund

 

Logiczne jest to, że większe zamówienie szczególnie przy zapisie będzie wydłużało czas proporcjonalnie do ilości dodawanych pozycji, od wersji >=41 czas zapisu i wyszukiwania wzrósł 4 krotnie.  Czy nie ma możliwości skompletowania dokumentu już ze zmienionym statusem przez jakiś "Inny" Manager? Tj. bez otwierania dokumentu? Według mnie nie przewidziano scenariusza, który by umożliwił sprawną kompletację częściową pozycji – z UI nie jest to możliwe a przez SFERĘ działa to mozolnie przez znane opóźnienia obecnej procedury. Dodatkowa metoda zk.KompletujZamowienie domyślnie zawsze rezerwuje pełną dostępną ilość – jeśli mam popularny produkt na kilkudziesięciu ZK, np. spóźnioną dostawę(dla nas) i stan 50% i termin dostawy „na już” to zwykle wydajemy to co mamy skompletowane po równo dla każdego ZK i dosyłamy resztę po nowej dostawie.

 

Kolejność realizacji zamówień - brak

Sfera zdarzeniowa - brak

SQL Server 2016 Standard

64G RAM

testowane na DB o zapełnieniu 20GB i 50GB (podobne rezultaty)

 

Pozdrawiam.

Edytowane 13 Kwietnia 2023 przez Darek FremanOfArrakis

[Mateusz Matuszewski 92]

Sprawdziłem czasy takiej operacji sferycznej na zamówieniu z 300 pozycjami w wersji 41 oraz po konwersji do 45 i nie powtarzam takiego spowolnienia. W obu przypadkach czas zapisu ZK wynosił niewiele ponad sekundę. Czy operacja wykonana z poziomu UI (w roletce Rozbicia pozycji) na tym dokumencie również trwa dłużej? Czy po konwersji była wykonywana konserwacja bazy danych? Może w międzyczasie zostały zainstalowane jakieś rozwiązania własne albo dodane triggery w bazie danych? Poproszę jeszcze o wygenerowanie informacji diagnostycznych w programie serwisowym (menu Pomoc -> Eksportuj informacje diagnostyczne) i przesłanie ich w wiadomości prywatnej.
 

Cytat

Czy nie ma możliwości skompletowania dokumentu już ze zmienionym statusem przez jakiś "Inny" Manager? Tj. bez otwierania dokumentu?

Niestety obecnie nie ma takiej możliwości, ale faktycznie jest tutaj pole do optymalizacji, więc zapisałem sugestię do przeanalizowania.
 

Cytat

Dodatkowa metoda zk.KompletujZamowienie domyślnie zawsze rezerwuje pełną dostępną ilość – jeśli mam popularny produkt na kilkudziesięciu ZK, np. spóźnioną dostawę(dla nas) i stan 50% i termin dostawy „na już” to zwykle wydajemy to co mamy skompletowane po równo dla każdego ZK i dosyłamy resztę po nowej dostawie.

Takie były założenia tej metody, tzn. aby kompletowała maksymalną ilość możliwą do zarezerwowania według Kolejności realizacji zamówień. Do bardziej szczegółowej obsługi rezerwacji służą interfejsy IDokumentRezerwujacy (zk.ObslugaRezerwacji) oraz IDokumentZRozbiciem (zk.ObslugaRozbiciaPozycji) i nie planujemy zmian w tym zakresie.