Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: marianpro w Lipiec 25, 2019, 12:13:44
-
Czołem.
Mam problem z wydajnością pracy Subiekta GT 1.53HF1, pracującego na bazie danych MSSQL Express v12 przy połączeniu zdalnym przez VPN.
Nie jest to praca przez RDP, tylko normalna praca w sieci, tyle, że zdalnie.
Testy robiłem na OpenVPN i na IPSec'u, łącząc się klientem zainstalowanym na MS Windows 7 lub 10 do routera robiącego za serwer VPN, podłączonego do światłowodu 100/50 Mb/s z pingiem 1ms.
Otworzenie faktury generuje transfer na poziomie kilkunastu kB, a trwa to jakieś 10 sekund niezależnie od tego czy łączę się przez jakąś miedź 20/1 Mb/s z pingiem 40ms czy przez światłowód 100/10 Mb/s z pingiem 5ms.
Transfer mierzony od klienta do serwera przez tunel VPN programikiem iperf3, pokazuje max jaki daje upload łącza klienckiego, więc to nie tutaj problem.
Obciążenie procesora w routerze poniżej 7%, pamięci też jest zapas.
Czy ktoś mógłby rzucić światło co tu jest grane?
-
Temat poruszany na forum wiele razy i tłumaczyłem z czego to wynika, poszukaj i poczytaj... W skrócie - program przy wykonaniu danej operacji wysyła wiele zapytań, które przy relatywnie wolnym łączu internetowym dają sumarycznie takie opóźnienia, dlatego przestrzegamy wszystkim przed takim modelem pracy...
-
Damian, dziękuję Ci za odpowiedź.
Wnosząc po ilości Twoich postów, myślę, że po prostu możesz pamiętać, że temat taki był omawiany. ;)
Ja nie znalazłem odpowiedzi, która by wyjaśniała przyczynę takiego stanu rzeczy i możliwe rozwiązania poza oczywiście zalecanym RDP. Wiesz, chodzi mi o jakieś "case study".
Natknąłem się wręcz na posty, w których użytkownicy piszą, że działa "dobrze", np. na łączu 2/2Mb... Być może każdy ma inną definicję komfortu pracy. ;)
Niektórzy pisali, że "pchanie bazy przez neta" jest nieoptymalne, ale to chyba skróty myślowe, bo zapytania nie powodują "pchania bazy" w tę i we w tę przecież.
Na razie grzebię jeszcze w sieci na forach anglojęzycznych, choć brak mi wiedzy specjalistycznej w tym temacie, więc idzie opornie.
Chciałbym wiedzieć, gdzie leży przysłowiowy "pies pogrzebany" a nie dlatego, że chcę zaoszczędzić na licencjach CAL RDP, bo potrzebowałbym ich zaledwie kilka.
-
Damian...
Daniel ;)
...dziękuję Ci za odpowiedź.
Wnosząc po ilości Twoich postów, myślę, że po prostu możesz pamiętać, że temat taki był omawiany. ;)
Pamiętam bo jak napisałem sam to tłumaczyłem ;)
Ja nie znalazłem odpowiedzi, która by wyjaśniała przyczynę takiego stanu rzeczy...
No przecież w skrócie napisałem dlaczego tak się dzieje, gdybyś prześledził komunikację programu z serwerem SQL przy wykonywaniu danej operacji w programie to wszystko byłoby jasne.
...i możliwe rozwiązania poza oczywiście zalecanym RDP.
No ale to przecież oczywiste i żadna tajemnica - programu nie zmienisz, możesz zmienić łącze na tak szybkie, aż uznasz że pracuje Ci się komfortowo lub skorzystać z znanego Ci już rozwiązania - RDP.
Natknąłem się wręcz na posty, w których użytkownicy piszą, że działa "dobrze", np. na łączu 2/2Mb... Być może każdy ma inną definicję komfortu pracy. ;)
No diametralnie inną, dlatego ja do znudzenia wszystkim ostrzegam i proponuję testy, choć miałem takie przypadki że była testowana praca z bezpośrednim podłączeniem do serwera SQL, niby działało "dobrze", a po jednym, dwóch tygodniach przechodziliśmy na RDP.
Niektórzy pisali, że "pchanie bazy przez neta" jest nieoptymalne, ale to chyba skróty myślowe, bo zapytania nie powodują "pchania bazy" w tę i we w tę przecież.
To wypowiedzi laików, którzy nie wiedzą jak działają SQL'owe bazy danych i programy Insertu.
Na razie grzebię jeszcze w sieci na forach anglojęzycznych, choć brak mi wiedzy specjalistycznej w tym temacie, więc idzie opornie.
Ciekawe jakie znajdziesz tam informacje o programach Insertu ? :o Program można optymalizować do takiej pracy, ale w programach Insetu tego nie zaprojektowano - to efekt architektury aplikacji, a nie samego serwera SQL.
Chciałbym wiedzieć, gdzie leży przysłowiowy "pies pogrzebany" a nie dlatego, że chcę zaoszczędzić na licencjach CAL RDP, bo potrzebowałbym ich zaledwie kilka.
Zrób jak napisałem (sprawdź jak działa program) lub przyjmij do wiadomości.
-
No przecież w skrócie napisałem dlaczego tak się dzieje, gdybyś prześledził komunikację programu z serwerem SQL przy wykonywaniu danej operacji w programie to wszystko byłoby jasne.
No widzisz, tutaj właśnie brakuje mi wiedzy, więc ciekawy jestem co bym zobaczył i czy bym potrafił to zinterpretować.
Ciekawe jakie znajdziesz tam informacje o programach Insertu ? :o Program można optymalizować do takiej pracy, ale w programach Insetu tego nie zaprojektowano - to efekt architektury aplikacji, a nie samego serwera SQL.
No i ponownie, nie wiedziałem, że to wynik braku stosownej architektury ze strony Subiekta. Myślałem, że problem leży w specyfice transmisji baz MS SQL, stąd poszukiwania w kierunku. manipulacji parametrami z zakresu sieci stricte lub baz danych MS SQL.
Zrób jak napisałem (sprawdź jak działa program) lub przyjmij do wiadomości.
Ok, zatem przyjmuję do wiadomości, skoro już było to sprawdzane i nie ma lekarstwa na optymalizację.
-
Zrób jak napisałem (sprawdź jak działa program) lub przyjmij do wiadomości.
Ok, zatem przyjmuję do wiadomości, skoro już było to sprawdzane i nie ma lekarstwa na optymalizację.
No nie ma. Poza szybkością działania jest jeszcze jeden aspekt, często ważniejszy, czyli stabilność rozwiążania - programy Insertu nie są w stanie wznowić połączenia, więc chwilowa (ułamek sekundy, który nie będzie widoczny dla użytkownika) przerwa połączeniu powoduje, że nie zapiszemy wprowadzonych zmian...
-
Mam podobny problem i nie bardzo mogę zrozumieć gdzie leży problem z dużą ilością zapytań do bazy.
Mam VPN na światłowodach spięte dwie sieci. Pingi do serwera na poziomie 11ms czyli podobnie jak na wifi. Na wifi gdzie prędkość jest 802.11g = 54Mbps wszystko działa dobrze. Przy światłowodzie gdzie nie wykorzystuje max. transferów na otwarcie karty towaru czekam 2-5sekund a 50Mbps w obecnych czasach dla światłowodu nie jest niczym nadzwyczajnym.
-
Zdecydowanie serwer terminali.