Closed fzoli15 closed 4 years ago
És amíg megírtam az issue-t rosszabbodott a helyzet:
Az említett problémát múlt héten csütörtökön, pénteken és ma reggel is tapasztaltuk. Láthatóan ismét valami nincs rendben:
Viszont hivatalos tájékoztatást most sem tett közzé a NAV. Ez így szintén nem oké, mert nekünk (szoftver fejlesztőknek) kell bizonygatnunk az ügyfelek felé, hogy nem a mi rendszerünkben van a hiba. Légy szíves ezen a gyakorlaton változtassatok!
Szia @fzoli15 !
Köszi a jelzést! A jelzett lassulás reggel óta megoldódott. A lassulás okát igyekszünk izolálni és megoldani. A kommunikáció iránti igényt jelezzük az illetékesek felé, fejlszetői oldalról keveset tudunk hozzátenni, de értjük a hiányérzeted.
Köszi!
Köszönöm!
Az issue-t eredetileg az interfész specifikáció hibája, pontatlansága miatt nyitottam. Felül tudnátok vizsgálni ezt a mondatot: "A szinkronhívások blokkoló timeout értéke 5000 ms."? A gyakorlatban úgy látszik, hogy ez nem teljesül, mert a maihoz hasonló lassulások alatt tömegesen előfordul olyan, hogy 10000 ms alatt sem jön válasz a szervertől, miközben az adatszolgáltatás befogadásra kerül.
Attól tartunk, hogy a jövőben (07.01. után) sokkal több ilyen eset lehet majd. Ezért fontos lenne számunkra, hogy be tudjuk állítani kliens oldalon a megfelelő timeout értéket, és így kiküszöböljük a fentebb leírt hibákat.
A problémát ma is tapasztaltuk/tapasztaljuk. Kérjük, hogy minél hamarabb találjatok erre valami megoldást, vagy legalább adjatok egy pontos, helytálló leírást arra vonatkozóan, hogy hogyan kezeljük a timeout-okat kliens oldalon. Köszönöm!
Szia @fzoli15 ! Köszi a jelzést, látjuk és dolgozunk az elhárításán. Amit fő problémaként jelzel, az 5000ms-es válaszidőt, azt nem az üzemzavaros esetekre kell érteni, hanem amikor üzemszerűen működünk. A dokumentációban szereplő adat nem vonatkozhat üzemzavaros esetekre, hiszen arra nem tudunk egzakt időt mondani. A tapasztalt belassulásokat folyamatosan vizsgáljuk, performancia tesztekkel hajtjuk a rendszert, metrikákkal fogunk mérni minden releváns adatot, így készülünk mi is a júliusi terhelés növekedésre, és persze az általános válaszidő növekedés elkerülésére. Ezek az optimalizálások folyamatban vannak, kérlek vedd ezt figyelembe. A mai hiba egyébként elhárult, most rendben vannak a válaszidők. Üdv
Szia @fzoli15
Több hónapnyi performancia tesztelés eredménye és a hangolások tapasztalatai alapján azt mondom, hogy a doksiban írt 5.000 ms válaszidő az új konfiguráció szerint valid maximum. A rendszert külső cloudból teszteltük ahol még magasabb is a latency mint a BIX-en keresztül, és ugyan volt eldobott/eltimeoutolt kérésünk, de a számosság sosem haladta meg a 0,01 %-ot, a többinek a válaszideje pedig a legrosszabb pillanatokban volt 2.500 ms, jellemzően inkább 1.500. Ha megnézed 07.01 óta a vanenav.hu-t, ezt ott is láthatod, pedig a forgalom növekmény szignifikáns.
Engedelmeddel lezárom a ticketet, ha szeretnél még beszélni róla akkor kérlek nyiss egy újat!
A hibás dokumentum neve / Document name containing the error Fájlnév vagy hostolt URL / File name or hosted URL. Online Szamla_interfesz specifikáció_HU_v2.0.pdf
Oldalszám / Page number A hibát tartalmazó oldal száma / Page number containing the error.
A dokumentációs hiba leírása / Description of the documentation error Rövid és tömör összefoglalása a hibának. / A clear and concise description of the summary of the error.
A dokumentáció 5000 ms-ot meghaladó timeout érték beállítását javasolja kliens oldalon. Nálunk 10000 ms van beállítva a kezdetek óta. Mégis időnként tömegesen előfordulnak olyan esetek, amikor 10000 ms-on belül nem nem kapunk választ, ezért automatikusan újraküldjük az adatszolgáltatást, de az erre adott error hibaüzenetből kiderül, hogy a szerver valójában befogadta az első beküldést.
A http://www.vanenav.hu/ oldal adatai szerint például a mai napon is volt olyan, amikor 7000 ms feletti válaszidőt produkált a NAV szerver.
Kérjük, hogy a dokumentációban határozzatok meg egy valós értéket, aminek a kliens oldali beállításával elkerülhetőek a fent említett hibák.