Optymalizacja requestów w SOAP

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

Rejestracja: 2 lata temu

Ostatnio: 8 miesięcy temu

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
Moderator

Rejestracja: 16 lat temu

Ostatnio: 3 godziny temu

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

Rejestracja: 2 lata temu

Ostatnio: 8 miesięcy temu

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
Moderator

Rejestracja: 16 lat temu

Ostatnio: 3 godziny temu

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

Rejestracja: 2 lata temu

Ostatnio: 8 miesięcy temu

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

Rejestracja: 3 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: U krasnoludów - pod górą

0

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


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 1x, ostatnio: jarekr000000, 2019-08-12 17:59

Pozostało 580 znaków

2019-08-12 18:02

Rejestracja: 2 lata temu

Ostatnio: 8 miesięcy temu

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

Rejestracja: 2 lata temu

Ostatnio: 1 tydzień temu

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

Rejestracja: 2 lata temu

Ostatnio: 8 miesięcy temu

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

Rejestracja: 2 lata temu

Ostatnio: 1 tydzień temu

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

Rejestracja: 6 lat temu

Ostatnio: 1 dzień temu

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

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