Optymalizacja requestów w SOAP

Odpowiedz Nowy wątek
2019-08-12 17:43
0

Cześć, otóż mam pewien problem w pracy: obecnie request w timeoucie (60s) zapisuje do bazy jedynie 1k rekordów, mam osiągnąć 2x/3x to przynajmniej. Zapis jest oczywiście kaskadowy (jeszcze kilka encji obok się zapisuje przy tym requeście). Pytanie: jakie klasyczne próby optymalizacji mogę tutaj podjąć? Chodzi mi głównie o Javowe rozwiązania - pobierać jakoś wcześniej encje, które będą się zapisywały przy tym requeście - tak żeby potem operować na danych już tylko Javowo? Jak to najlepiej rozwiązać? DOdam, że to wszystko stoi na Oraclu + Springu z Apache CXF.

Z góry dzięki za porady.

Pozostało 580 znaków

2019-08-12 17:47
0
  1. Ale jakie encje? JPA? Wywal.
  2. Zrób batch insert do bazy, najlepiej jakiś duży, więc zamiast insertować po jednym zrób sobie kolejkę która zbiera dane i np. co 60 sekund robi jeden wielki insert. Zamiast 2/3x szybciej będzie pewnie kilkaset/kilka tysięcy razy.

Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2019-08-12 17:47

Pozostało 580 znaków

2019-08-12 17:49
0
  1. Gdybym miał taką moc i mógł wyrzucić JPA to zrobiłbym to - mam niecały miesiąc dośw., więc pozostaje mi jakoś to załatwić jak jest,
  2. Czyli mówisz żeby operacje na danych zrobić sobie wcześniej i zrobić jeden, wielki insert?

Pozostało 580 znaków

2019-08-12 17:53
0

Generalnie taki bulk insert jest wielokrotnie szybszy niż insertowanie/updatowanie jeden po drugim.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-08-12 17:54
0

W sumie przeszło mi to przez myśl dziś chwilę, bo obecnie jak widziałem to SAVE jest robiony chyba forEach'em po liście, więc dość słabo. Muszę jeszcze sprawdzić czy dane wcześniej wyciągane są jakimś fetch'em czy może też pobierane pojedynczo.

Pozostało 580 znaków

2019-08-12 17:58
0

DROP DATABASE - klasyczne rozwiązanie.
Wywal bazę danych, a będzie i szybciej i czyściej.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-08-12 17:59

Pozostało 580 znaków

2019-08-12 18:02
0

:D,
Obawiam się, że takie rozwiązanie mogłoby się skończyć TRUNCATE {moje_imie_nazwisko} w pracy.

Pozostało 580 znaków

2019-08-12 19:35
0

Zadałbym pytanie skąd się biorą pomysły ładowania dużej liczby danych przez ORMy, ale sam miałem niedawno w robocie przykład jak pewien łoś postanowił tak potraktować pierdyliardy rekordów z danymi pogodowymi (czyli dodatkowo czas miał duże znaczenie), później uparcie twierdził, że baza danych jest do d**y, bo suwak w chmurze się skończył. Po przejściu na load nagle zaczęło działać.

Pozostało 580 znaków

2019-08-12 20:54
0

No też wolałbym to ładować jakimś SQL'owym bardziej podejściem, ale niestety nie mam za bardzo nic do gadania w tej sprawie, dlatego próbuję zrobić to tak jak mogę przy obecnym stanie.

Pozostało 580 znaków

2019-08-13 06:44
0

Skoro nie masz nic do gadania, to nic nie zoptymalizujesz.
Jeśli musisz używać JPA, to pozostaje ci trochę podrążyć:
https://www.google.com/search[...];sourceid=chrome&ie=UTF-8

Pozostało 580 znaków

2019-08-13 08:18
0

Kurcze to nie jest czarna magia: JProfiler prawde CI powie

Co mu niby powie? Że I/O do bazy robiące insert jeden po drugim, każdy w nowej tranzakcji, zjada cały czas? Tu nie trzeba być jasnowidzem ;] - Shalom 2019-08-13 09:22

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0