- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- bambano: Bambanő háza tája
- MasterDeeJay: Noname 1TB-os SATA SSD teszt
- Mr Dini: Mindent a StreamSharkról!
- Hieronymus: A németországi vasúthálózat
- ldave: New Game Blitz - 2025
-
LOGOUT
Új hozzászólás Aktív témák
-
Silεncε
őstag
válasz
pmonitor
#16896
üzenetére
Na mesélj, hogyan. Okíts, mester
Edit: a CGI jogos, bár nem hiszem, hogy meg tudsz benne írni egy React szintű webalkalmazást (de ha még meg is, mi a francnak ennyit szevedni vele, ha egyébként van rá más megoldás?)
A másiknak a kódjába belenéztem, nekem az úgy tűnik, hogy ott magát az appot összerakod C++-ból, de az a kliensen attól még ugyanúgy JSt fog futtatni.
-
pmonitor
aktív tag
-
Silεncε
őstag
válasz
pmonitor
#16886
üzenetére
Ha most lennék fiatal, és programozó szeretnék lenni, akkor én 2, esetleg 3 programnyelvet sajátítanék el nagyon. Az asm-ot, a C-t, esetleg a "mezei" C++-t(nem a VC++-t). Ezekkel mindent meg lehet csinálni, és eszközt adnak a kezembe az optimalizálásra is.
Sok sikert kívánok hozzá, hogy ezekben megírj egy webappot vagy egy mobilappot (utóbbit mondjuk még talán meg lehet...). BE fejlesztéshez is kitűnő választás mind. Oh, wait..
Egyébként meg továbbra is ott a lehetőség, hogy elkezdjed beküldözgetni a sokkal gyorsabb kódjaidat és megmutasd a nagy programozóknak, hogy milyen hülyék mindannyian.
-
-
dabadab
titán
válasz
pmonitor
#16886
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem.
Mert mindenki hülye és csak te vagy helikopter.
Egyébként sikerült már olyan atoi()-t írni, ami megcsinálja azt, amit a szabvány elvár tőle? Nem? Hát akkor meg mire ez a nagy arc? -
#16888
pmonitor
aktív tag
Netszemete
#16887
pmonitor
aktív tag
válasz
Netszemete
#16887
üzenetére
>a legtöbb feladatnál a sebesség másodlagos, sokadlagos tényező.
Akkor miért is kell erősebb HW-t venni, ha sokadlagos tényező? Akkor miért nem jó a legolcsóbb, lassabb HW, ha sokadlagos tényező?
Sztem. nem sokadlagos. Csak én az alkalmazások optimalizálását emelem ki, a többiek meg a szuper HW-t emlegetik.
-
pmonitor
aktív tag
válasz
martonx
#16885
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem. Mert az alap típusok konvertálásai alapvetőek(legalábbis sztem.). Mondjuk itt valszeg. a sok függvényhívás is közrejátszik pl. a C "relative" lassúságában.
A másik meg az, hogy ez biztos, hogy egy user programozgatónak a dolga lenne? Ha van egy autóm, amiben nekem nem tetszik valami, akkor tervezzem át, küldjem be a gyártónak, és várjak, hogy elfogadják-e, mi?
-------------------------
Ettől függetlenül nem árt, ha valaki megpróbálja megérteni az általa használt függvények/metódusok működését/algoritmusát. Főleg, ha ugyanazt a funkciót gyorsabban is meg tudja valósítani.
-------------------------
Ha most lennék fiatal, és programozó szeretnék lenni, akkor én 2, esetleg 3 programnyelvet sajátítanék el nagyon. Az asm-ot, a C-t, esetleg a "mezei" C++-t(nem a VC++-t). Ezekkel mindent meg lehet csinálni, és eszközt adnak a kezembe az optimalizálásra is. -
#16881
emvy
félisten
Netszemete
#16877
válasz
Netszemete
#16877
üzenetére
Nem, webes API-t sokminden használhat, de ha pl. óriási ateresztokepessegre van szükség, akkor nem feltétlenül a JSON a legjobb megoldás. Vagy ha gyors JSON de/szerializaciora van szükség, akkor nem a toString-et használunk. Jelenleg a C#-ban elérhető Utf8Json implementáció például egy 3-4 property-vel rendelkező osztályt kb. 100 nanosec (!) alatt szerializal JSON formátumra, ami kb. 100 bajtot eredményez egyébként. Azaz másodpercenként 1 CPU mag kb. 1e7*1e2 =>1e9 bajtnyi adatot tud kitolni JSON-ban, azaz 1 GB/sec sebességgel tudna kiküldeni a JSON streamet, ami gyakorlatilag szaturálna egy 10 Gbe linket.
-
#16880
pmonitor
aktív tag
Netszemete
#16877
pmonitor
aktív tag
válasz
Netszemete
#16877
üzenetére
>de én úgy érzem, hogy ez pont az extrém esetekről szóló téma.
Igen, az. Bár ha belegondolunk mennyi szám konvertálás történik csak ebben a kis országban is, akkor lehet, hogy kiderülne, hogy még a nem szélsőséges helyzetben is lenne létjogosultsága az optimalizálásnak. Amennyivel kevesebbet kellene használni a vasakat, az elég nagy energiamegtakarítást is jelentene sztem.
>Épeszű(!) programozó nem kezdi újraírni a glibc-t,
Ha rám gondoltál, én nem vagyok programozó. de ez a könyv is tele van az STL megvalósítás kezdeményekkel. Mondjuk az egész elég sok rizsát tartalmaz. Én mondjuk megbántam, hogy megvettem annak idején. Nem regényt szerettem volna olvasni. De most már mind1.
-
#16879
dabadab
titán
Netszemete
#16877
dabadab
titán
válasz
Netszemete
#16877
üzenetére
Épeszű(!) programozó nem kezdi újraírni a glibc-t, ha nincs rá nagyon jó oka. ;) De előfordulhat, hogy van rá ok.
És azért előfordul, hogy van rá ok. Épp a múltkor csodálkoztam rá arra, hogy hányféle hashmap implementáció van C++-hoz, pedig ott van az std::unordered_map: [link]
-
#16878
Ispy
nagyúr
Netszemete
#16877
Ispy
nagyúr
válasz
Netszemete
#16877
üzenetére
Szerintem meg a lényeg, hogy nem a gombhoz veszünk kabátot. Van egy feladat, van egy igény lista, mit kell tudnia, egy specifikáció és utána ahhoz ki kell választani a megfelelő eszközöket, ha JSON, akkor JSON, ha XML, akkor XML, ha binárisan kell áttolni, akkor meg úgy. Mi az API-khoz JSON használunk, mert olvasható, natívan támogatja a JS, az SQL szerver, és mert univerzálisan elterjedt formátum. De nálunk nem a sebesség a mérvadó és hát inkább JSON, mint XML. Rengeted féle feladat van, mindhez megvannak a bevett gyakorlatok, hogyan és mivel kell csinálni, ennyi.
-
#16876
emvy
félisten
Netszemete
#16872
válasz
Netszemete
#16872
üzenetére
Böngészők felé történő kommunikáció során a szerializacio nem szuk keresztmetszet. (Drizzt is ezt mondja, csak igényesebben
)L
-
#16875
Drizzt
nagyúr
Netszemete
#16872
Drizzt
nagyúr
válasz
Netszemete
#16872
üzenetére
De, és a JSON nem kimondottan kis erőforrásigénnyel parse-olható formátum. Ellenben remekül olvasható. Valamint WEB API-knál megintcsak fontosabban az egyéb előnyök, mint az azokhoz elhanyagolható mértékű sebességnövelés. Könnyű olvashatóság, mindenféle architektúra könnyen tudja értelmezni.
Ha pl. MQ-n küldesz adatot és nem akarsz parsingot alkalmazni, akkor mindkét végén a queuenak pontosan ismernie kell az adott adatstruktúrát.
Webes APIknál általában nincsen olyan latency requirement, amiben egy +/- JSON serdes ne férne bele.
#16873: JSON parsingnál a fő problémát az okozza, hogy nem lehet tudni az üzenet végigolvasása nélkül, hogy melyik mező hol kezdődik, így nem elég csinálni egy pár offsetről való közvetlen betöltést, ha egy mező értékét meg akarod tudni, hanem kénytelen vagy végigolvasni az eredeti JSONt(legalább addig, ahol a keresett mező(k) és annak értéke(i) van(nak)). Illetve az, hogy van szöveg, szám, meg boolean önmagában még nem segít semmit, mert a számot mindegyik oldal önkényesen értelmezheti különböző számtípusonként. Szóval általános JSON parsingnál valamiféle objektumba nem lehet megúszni a konverziót a számok esetén. Eleve a JSON sorrendfüggetlen, ugyanaz az objektum lehet a {"a": 1, "b": 2}, mint a {"b": 2, "a": 1}. Tehát nem tudsz olyat monda, hogy az Integer b mindig a 4. offseten keresendő. De még csak azt sem tudod megmondani, hogy a b Integer, Float, Double, BigInteger, BigDecimal. Szabadon értelmezhető.
De ahol a konverzió sebessége szűk keresztmetszet, ott nem is JSONt használnak. -
#16873
cattus
addikt
Netszemete
#16872
cattus
addikt
válasz
Netszemete
#16872
üzenetére
Mondjuk JSON esetén pont van külön string és number típus, szóval abban az esetben pont nem kell konvertálni egyikből a másikba. De általánosságban szerializálás / deszerializálás során nincs konvertálás típusok között.
-
#16871
emvy
félisten
Netszemete
#16869
válasz
Netszemete
#16869
üzenetére
Nagysebessegu de/szerializasal nem perszolunk, pont. Jo eséllyel annyit történik, hogy a hálózaton bejövő adatot egy-az-egyben írjuk a memóriába (es fordítva: a memóriában levő adatot egy-az-egyben toljuk ki a hálózatra).
-
-
válasz
pmonitor
#16865
üzenetére
Hányszor kell sztringet szamma konvertálni a tőzsdén?
Deszerializacional (pl. áttolsz a hálózaton egy rakás adatot, es utána a memóriába akarod rakni, mint szám) nyilván nem atoi-t használnak meg parseInt-et.
Amikor meg megjelenitesz egy csomó számot, pl. egy C# GUI-nal, arra pl. az Int32.toString() tökéletes (nagyon gyors). Ha mondjuk egy képernyőn van 2000 szám, amik másodpercenként 2* változnak, az 4000 konverzió / másodperc, az nagyon alacsony szám.
-
pmonitor
aktív tag
Akkor sorry...
De mennyien használnak olyan programot, ami IP címeket jelenít meg? Vagy pl. a tőzsdéken hányszor és mennyi számot kell konvertálni a valuta árfolyamoknál? Vagy akár az áru tőzsdéken? Vagy amikor a banki számlakivonatokat küldik ki? Meg amilyen felhasználásra az ember még csak nem is gondol.. -
pmonitor
aktív tag
Ezt elsősorban azért írtam, hogy pl. a C#-ban vannak olyan metódusok, amik hiába lassúak, nincs mód rá optimalizálni. Eszed/nem eszed, nem kapsz mást. Tehát itt most nem a konkrét metódus volt a lényeg. De a "sima/mezei"
ToString()metódus is ilyen lassú.
De ha jól tévedek, akkor pl. az IP címeket is konvertálják oda-vissza a feldolgozás során(a router-ek és egyebek). Na most ha jól tudtam ezt, akkor elég csak abba bele gondolni, hogy akár csak 1 óra alatt is mennyi IP cím kering a hálózatokon. Ha rosszul tudtam, akkor sorry. -
-
sztanozs
veterán
Zerotrust csak ott működik, ahol nincsenek legacy rendszerek. Nem hiszem , hogy ezt rúl sok nagy cég elmondhatná magáról. Ráadásul a teljes nyitottság jelentős logolási probléma is. Bár a hálózat szegregációja okozhat plusz problémákat, nyomozati szempontból (ha beüt a sz@r) sokkal kellemesebb, hogy nem a telhes internet a gyanúsított.
-
pmonitor
aktív tag
válasz
martonx
#16854
üzenetére
>mert nem atoi-t optimalizálok hehehe).
Azért próbáld optimalizálni a C# Convert.Tostring(int value, int tobase) metódusát. Ha megszakadsz sem tudod jelentősen optimalizálni, mert a C#(és mögötte a robosztus .Net) nem ad megfelelő eszközt a kezedbe.
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt. -
martonx
veterán
válasz
Vision
#16855
üzenetére
Előző, nem banki munkahelyemen, meg rendszeresek voltak a több milliárd soros DB táblák. Ott is észnél kellett lenni, minden egyes SQL lekérdezésnél, és nyilván egy 2 TB-os DB táblát cachelni se lehet
vagy legalábbis észnél kell lenni, hogy mit, mikor, milyen aggregáltsági szinten cachel az ember.
Azaz amikor cachelésről beszélünk, ne arra gondolj, hogy oké lerántom a táblát memóriába, és probléma megoldva. Ennél a valóság az esetek többségében nyilván bonyolultabb (bár kis rendszereknél, ez nyilván egy könnyű járható út). -
válasz
martonx
#16854
üzenetére
Hja, nehogy személyesre vedd, nem az volt a célom.
Csak megmutatni azt, hogy tényleg mekkora jelentősége van a tervezésnek. És itt rohadtul nem kódminőségről van szó, hanem architektúráról. És tényleg sokan vannak, akik nem láttak ekkora rendszereket, és könnyen mondanak triviálisnak tűnő, de használhatatlan megoldásokat. -
martonx
veterán
válasz
Vision
#16837
üzenetére
dolgoztam bankoknak, OTP-nél egy időben még külsős IT tanácsadó is voltam pont ilyen esetekre (mert én is csak egy nick vagyok aki ugatja a szakmát, mert nem atoi-t optimalizálok hehehe).
De mindegy is, semmi értelme egy ilyen fórum keretein belül mélyebbre mennünk. Írtál egy problémát, páran írtunk lehetséges megoldási javaslatokat, aztán ebből mindenki azt hoz ki, amit a lehetőségei, képességei (bankokat ismerve és pár kivételt mélyen tisztelve de a többség inkompetens, kezdve a menedzsmenttől, a programozókig) és a projekt scope-ja engednek.
Számomra az egészből egyedül az volt a lényeg, és amiért nagyon hálás is vagyok neked, hogy @pmonitorral ellentétben hoztál egy valós életbeli programozói problémát, szemléltetve, hogy nem az atoi-val kell szórakozni, hanem olyan robosztus rendszereket írni, tervezni, amik valós ügyfél problémákra reagálnak. -
40 éves mainframe-en szerintem ezt nem tudják megcsinálni, szóval ettől én megmenekülök. Az ügyfeleknél már most is ez van, sírnak is miatta.
#16851emvy
Hja, ezt már linkelted korábban, én is magyaráztam a kollégáknak, hogy a VPN egy faszság, csak kényelmetlenséget szül. Persze ezt nem mi fogjuk eldönteni itt a gyarmatokon. -
válasz
Vision
#16849
üzenetére
> Tehát a havonta változtatást vezették be, az összes többi volt eddig is.
Ezt mondom, uber faszsag.
> és körbe van vastagon tűzfalazva meg VPN-ezve
Ja, es ez is so kétezres évek. Merthogy a tűzfal majd megvéd. Ja. Ezert van az, hogy a világ legjobban vedett rendszereinek egyike (Google belso szolgáltatásai) kint van az interneten, tűzfal nélkül.
https://en.wikipedia.org/wiki/Zero_trust_security_model
"The once traditional approach of trusting devices within a notional corporate perimeter, or devices connected to it via a VPN, makes less sense in such highly diverse and distributed environments. Instead, the zero trust approach advocates mutual authentication, including checking the identity and integrity of devices without respect to location, and providing access to applications and services based on the confidence of device identity and device health in combination with user authentication.[1]"
-
-
Bocs, félreérthető. Tehát a havonta változtatást vezették be, az összes többi volt eddig is. A legszebb az, hogy a belső core rendszernél is kitalálták ezt, ami egy mainframe, és körbe van vastagon tűzfalazva meg VPN-ezve. Szóval én is cserélgethetem havonta a jelszavamat. Mondanom sem kell, hogy ugyanaz a jelszó, csak az utolsó szám különbözik.
Hja, ez egy amerikai giga multi, ami szerintem százmilliós nagyságrendben költ IT secre. Dollárban.
-
válasz
Vision
#16847
üzenetére
> Most bevezették nálunk azt, hogy havonta kell az ügyfeleknek jelszót változtatniuk, nem egyezhet meg az előző 12-vel, kis-nagybetű-szám legyen benne, minimum 8 karakter.
B+.
MOST vezetik be, 2021-ben, amikor mar jópár eve konkrétan ellenjavallt ez az idiótaság? Konkrétan _csokkenti_ a biztonságot, nem növeli.
Nahat ez az, ami nem penz, hanem kompetencia kérdése.
https://pages.nist.gov/800-63-3/sp800-63b.html
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). "
NIST guideline.
-
Más téma. Régen ismert már ez a dolog, de most megint szembe jött velem: [kép]
Most bevezették nálunk azt, hogy havonta kell az ügyfeleknek jelszót változtatniuk, nem egyezhet meg az előző 12-vel, kis-nagybetű-szám legyen benne, minimum 8 karakter. Na de könyörgöm, milyen webapp nem rendelkezik manapság bruteforce preventionnel? Az ügyfelek háborognak, nyilván felírkálják a jelszavukat, kérik állandóan a jelszó emlékeztetőket. Rengeteg panasz jön emiatt a CC-be. Mi értelme ennek a szigornak manapság? Hja, persze van 2-faktoros authentikáció is.
-
Ispy
nagyúr
válasz
martonx
#16836
üzenetére
a való életben SOHA nem ez az igazi probléma
Szerintem ezt már vagy 100x elmondtuk, egy mai modern pc-nél kliens oldalon tök mindegy, hogy 0.1 mp vagy 1 mp, ezért is felesleges agyonoptimalizáni bármit. Ha az ügyfél pattogósabb programot akar vegyen a gépbe több ramot/erősebb procit/ssd-t (ha nincs).
-
válasz
martonx
#16834
üzenetére
Egy végtelenül bonyolult banki ökoszisztémában sajnos ez nem ilyen egyszerű. Mert könnyen rá lehet mondani, hogy 90% mehet kessből, de egyrészt azonosítani kell ezen adatok körét, másrészt azzal is számolni, hogy ez a 90% 10 rendszerből jön össze, amiket fel kell térképezni, töltést kitalálni, embert keríteni hozzá. A végén pedig kijön, hogy mindez 3 évbe, és 1500 embernapba kerül (nyilván nem konkrétan ennyi, de elő szoktak jönni ilyen szituk). Szóval ez azért nem olyan, mint egy zöldmezős webapp, amivel a fejlesztők 90%-a szembesül életében.
Ugye ennek a szolgáltatásnak multifunkciósnak kell lennie, és illeszkednie a bank SL-ébe, hiszen más appok is akarják használni. Szóval nem lehet csak a mi appunkra kihegyezni, hiszen lehet, hogy másnak más adat "változatlan".
Most abba az irányba indulunk el alkalmazás oldalról, hogy szét fogjuk bontani a hívásokat (alapból paraméterezhető, de nekünk teljes adattartalom kell egyébként), kvázi megpróbáljuk többszálasítani a lekérdezést. Cachelés lesz alkalmazás backend oldalon, mert magát a szolgáltatást is többször hívjuk egy cikluson belül, az első hívás tartalmát bekesseljük, és csak akkor kérdezzük le újra, amikor tudjuk, hogy változhatott az adat.
Mint látszik, ez csupán tüneti kezelés, a forrás service ettől nem lesz gyorsabb, csak az ügyfél kevésbé szembesül a hátrányaival.
#16836martonx
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Nézd, az üzlet az ügyfél valid igényeire próbál referálni. Szerintem az teljesen jogos elvárás, hogy egy webes alkalmazásra ne kelljen perceket várni, és az ügyfél a valós szolgáltatásképét lássa. -
martonx
veterán
válasz
sztanozs
#16835
üzenetére
Nyilván, de Tapsi ezzel kezdte a probléma felvetést:
"A leggyorsabb futásidő 30 másodperc, ezt kéne levinni <1-re."
Persze, ez annyira tipikus üzlet, mindenből friss adat kell, és ráadásul lassú se lehet
Amúgy meg teljesen jó a probléma felvetés, mert pmonitor nagyon kezdett félre menni a string - int konverziók sebességével, miközben a való életben SOHA nem ez az igazi probléma -
sztanozs
veterán
válasz
martonx
#16834
üzenetére
Lehet, hogy nem fog - jellemzően - gyakran változni, de pl kockázatkezelési szempontból nem előnyös, ha egy üzleti döntést nem aktuális adatok alapján számol a rendszer.
Peraze egy ilyen folyamat tipikusan nem kell kis válaszidővel rendelkezzen, szóval nem triviális megtervezni egy ilyen köztes réteget. -
martonx
veterán
válasz
Vision
#16826
üzenetére
Ez alapján amit leírtál, akkor is igaz, hogy ezeknek az adatoknak a jelentős része nem fog percenként változni. Márpedig ami nem fog percenként változni, azt teljesen felesleges realtime lekéregetni. Nyilván a konkrétumok ismerete nélkül én úgy csinálnám, hogy a 90% mehet cache-ből, és elég lenne csak a 10%-ot realtime lekérni.
-
A kess logikailag nem jó itt, mert nem tudod elkülöníteni az ügyfelek olyan csoportját, amelyet nagy valószínűséggel fogsz lekérdezni. Innentől pedig az van, hogy az egész DB-t memóriában kéne tartanod. Persze ez sem lehetetlen, de nyilván te is tudod, hogy nem tipikus.
#16832nevemfel
Majd leírom, hogy mire jutottak az architekt urak, én csak a partvonalról szemlélem a dolgokat. -
nevemfel
senior tag
válasz
Vision
#16830
üzenetére
Meg hát ugye itt már minden le van fejlesztve, szóval valami olyan megoldás kéne, amihez nem kell elölről kezdeni az egészet, kifordítva a teljes architektúrát, mert nagyjából tegnapra kéne minden.Tényleg tegnapra.
Akkor tényleg nincs más megoldás rá, csak a nagyobb vas. Illetve nagyobb vasak.
-
válasz
nevemfel
#16827
üzenetére
Az adattárház nem forrásrendszer, a benne lévő adatok nem frissek, jellemzően T-1, T-2-ben vannak, vagy még régebbiek. A forrásrendszerek DB-jéből töltődnek oda az adatok számos okból. Friss dolgokra az sajnos nem használható.
A kesselés tök jó dolog, de itt nem ez lesz az út szerintem. Pont a percre készség, a nagy ügyfélállomány, és az ügyfél prioritás hiánya miatt itt komplett DB-ket kéne kessben tartani, és változás esetén azonnal frissíteni. Persze ki lehetne alakítani azt, hogy az ügyféltörzset berakod kessbe, illetve a ritkán változó adatokat, de a lassulást jellemzően amúgy sem ezek okozzák. Meg hát ugye itt már minden le van fejlesztve, szóval valami olyan megoldás kéne, amihez nem kell elölről kezdeni az egészet, kifordítva a teljes architektúrát, mert nagyjából tegnapra kéne minden.Tényleg tegnapra.
#16829Drizzt
Persze, userID, de ezt ne úgy képzeld el, hogy van egy nagy DB, és onnan queryzgetünk dolgokat. Van egy kompozit szolgáltatás, ami hívogat szintén kompozit szolgáltatásokat, amik a mi szemszögünkből blackboxok. Meg Pl/SQL jobokat, meg kis kutya faszát is. Aztán így 20 szekvenciális kérésből összerak neked egy response-t. Szóval ez a köztes absztrakt réteg egyrészt nem létezik architekturálisan (ki kéne alakítani), feltérképezni a hívott szolgáltatások logikáját, aztán vagy bekötni MQ-ba, vagy közvetlenül DB-queryzni. Csak hát így pont adtunk egy pofont annak a törekvésnek, hogy próbáljuk a bank szolgáltatásait egy standard service layerbe szervezni az egyedi kókányolásokkal szemben. -
Drizzt
nagyúr
válasz
Vision
#16826
üzenetére
"És ja, az is lehetne, hogy egy köztes absztrakt rétegbe kiforgatjuk az adatokat egyfajta view-ként, csakhogy az is üzleti igény, hogy az adatok nem napra, hanem percre pontosak legyenek."
A ketto nem zarja ki egymast. Ha a forrasrendszerek a valtozasrol valami MQ-ba is kuldenek uzeneteket, akkor azzal igen low latency-vel fel lehet frissiteni a view-t. Persze ha a tobbfele MQ-t tobb alkalmazas resz dolgozza fel, akkor ilyenkor elengedhetetlen a view update melle az optimistic locking. Meg arra fel kell keszulni, hogy az adott user view-jat teljesen nullarol is megbizhatoan fel lehessen epiteni, de erre a most meglevo query-tek tokeletesen alkalmas kell legyen az alapjan, amit irtal(feltetelezve belole, hogy valamilyen user ID a request input parametere). -
-
Maga a service ilyen szempontból paraméterezhető, de sajnos nekünk minden kell egyben. Mármint tényleg minden, mert megy ki egy dashboardra az ügyfélnek azonnal. És persze lehet mondani, hogy nem így kellett volna tervezni a UI-t, de így akkor a gombhoz varrnánk a kabátot. És ja, az is lehetne, hogy egy köztes absztrakt rétegbe kiforgatjuk az adatokat egyfajta view-ként, csakhogy az is üzleti igény, hogy az adatok nem napra, hanem percre pontosak legyenek. Tehát ha az ügyfél igényel egy biztosítást, akkor onnantól fel se dobjuk neki azt ajánlatként. Ezt pedig valós idejű forrásrendszeri kapcsolattal lehet. És itt most több banki core (számlavezető, kártya, hitel, biztosítási, adattárház) rendszerről, számos szatelitről beszélünk vegyes relációban. Nem mondom, hogy nem lehet ezen javítani, a mókusok már dolgoznak rajta, de gyors megoldás biztosan nem lesz. Ők is kapásból úgy közelítették meg, ahogy te, de folyamatosan falakba ütköznek. Itt amúgy nem a vas a probléma szerintem, egyszerűen túl sok az IO, jobban szét kellett volna darabolni, de most már késő.
-
válasz
Vision
#16824
üzenetére
Ok, nyilván nem ismerem a részleteket, szóval csak a példa kedvéért mondom, de:
Tegyük fel, hogy a lentieket megjelented a képernyőn, es ha valamelyikre rákattint a user, akkor kapsz róla több információt. Tehát legyen a képernyőn mondjuk 1-2 aktuális folyószámla (a megjelenített információ mondjuk 500 bajt) , 2 bankkartyainformacio(mondjuk 500 bajt), választhato bankkártyak (mondjuk 1 kbyte nyersen), es egy rakás biztosítási termek, amit az ügyfel választhat (mondjuk 2 kbyte, annal tuti nem lehet több az, amit a képernyőn meg tudsz jeleniteni).
Nyilván ezek mögött az adatok mögött rengeteg apróság es részlet van, amit meg akarsz majd mutatni, de _egyszerre_ nem kell több. Tehát mondjuk egy 'overview' képernyőn van 4 kB információ. Ha van 1 millió user, az 4 GB nyers adat. Tehát csinálhatsz egy olyan cache-t (view-t), ami simán memóriában tart ennyi adatot (oke, legyen mondjuk 40 GB, mert a struktúra nem optimális), es igy csak akkor kell majd a valódi 'nagy' backendhez menni, ha valaki részletekre kíváncsi.
Nyilvan a valóság ennél bonyolultabb, de nagyon ritka olyan, hogy 'nem lehet cache-elni'.
-
Ügyfél által választható biztosítási termékek, és azok, amelyekkel rendelkezik. Ügyfél által választható bankkártyák, folyószámlák, és azok, amelyekkel már rendelkezik. Megtakarítási termékei, és ajánlatok. Hitelei, és hitel ajánlatai.
Minden ügyfél típus és szegmens szerint paraméterezve.
-
Attól, hogy nem nézem, még kellenek az adatok. Csak olyan kerül lekérdezésre, amire szükség van, illetve csak 1x, szóval a kesselésnek tényleg semmi értelme, mert akkor bekesselhetnéd az egész táblát a DB-ből. Ügyfél adatokról van szó, szóval még azt sem lehet mondani, hogy a leggyakrabban használtakat betolod kessbe, mert nincsenek leggyakrabban használtak a felhasznlás jellegéből adódóan.
-
válasz
Vision
#16818
üzenetére
> Hát, bekesseled az egész banki adattárházat?
Nyilván nem, de elég ritka az, amikor az aggregált metrikak számítása közben nincs semmi olyasmi, ahol a részeredményeket el lehetne rakni.
Egyekbent mi is ilyen gondokkal küzdünk most, es egyelőre a megoldás az, hogy pénzt locsolunk ra, nem pedig humanerőforrást. Azaz: inkabb fizetünk +10k USD-t a felhoben azért egy honapban, hogy on-demand odadob a szolgáltató +1000 CPU core-t az analitika mögé, ha szükség van ra, minthogy raallitsunk X embert, hogy optimalizaklja. Persze ez hosszútávon nem fenntartható, mert a +10k-bol könnyen lesz +50k, ott meg mar (nekünk) elkezdi megérni, hogy fejlesztot tegyünk ra.
-
válasz
Drizzt
#16816
üzenetére
Ilyesmire már nincs idő. Banki core rendszerekről van szó, nagyon sok hívásról. Az architectek már törik a fejüket a dolgon, bár az első fos megoldást is ők találták ki.
Szerencsére nem nekem kell ezt megoldanom, én csak szenvedő alanya vagyok a dolognak.#16815mobal
Hát, bekesseled az egész banki adattárházat? Az a gond, hogy számtalan szolgáltatásra hivatkozik a kompozit service, és elágazások is vannak benne. Hja, PL/SQL jobokat is hív. -
Drizzt
nagyúr
válasz
Vision
#16811
üzenetére
Nem lehetne elore leszedni az osszes adatot az osszes helyrol es aggregaltan, denormalizalva eltarolni valami key-value store-ban? Nyilvan az a tradeoff, hogy nem biztos, hogy teljesen aktualis adat jon, de legalabb jo gyorsan. De lehetne adni a usernek kapcsolot, hogy gyors adat kell-e, vagy pontos. Nekunk peldaul ilyenekre elegge gyakran van olyan megoldasunk, hogy <1 sec a query, a megengedett lemaradasa a kompozit adatnak meg mondjuk 15 perc a "valosagtol".
-
dqdb
nagyúr
válasz
nevemfel
#16813
üzenetére
Vagy amikor az ügyfél hálózatában akkora packet loss van, hogy csak pislogsz. Vagy kötelező direktben használni a naplózó szerverüket helyben futó log collector nélkül, és annak a csapnivaló teljesítménye teszi tönkre a sebességedet.
Ha biztonsági okokból zónákat kell használni, akkor egy-egy ilyen kérés ellenőrzés-belső zónába hívás-válaszra várás-válasz visszaadása kör 100-200 ms-t hozzá tud adni a kiszolgálási időhöz.
-
#16811
Vision
veterán
Netszemete
#16797
válasz
Netszemete
#16797
üzenetére
Azt tapasztalom a business alkalmazásoknál, hogy nem a kód a szűk keresztmetszet, hanem az architektúra, illetve a sok DB kapcsolat. Most szenvedünk egy olyan kompozit szolgáltatással, ami 20+ egyéb szolgáltatásból szedi össze az adatokat. A leggyorsabb futásidő 30 másodperc, ezt kéne levinni <1-re.
Amikor megnézték a futási statot, akkor kiderült, hogy az idő felét DB-műveletek viszik el. Kódhibával alig-alig találkozok. -
Gyuri16
senior tag
válasz
dabadab
#16798
üzenetére
Mint a regi szep idokben:
"We cut megabyte after megabyte, and after a few days of frantic activity, we reached a point where we felt there was nothing else we could do. Unless we cut some major content, there was no way we could free up any more memory. Exhausted, we evaluated our current memory usage. We were still 1.5 MB over the memory limit!
At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory.
Instead, he brought up a source file and pointed to this line:
static char buffer[1024*1024*2];
"See this?" he said. And then deleted it with a single keystroke. Done! "
[link]
The Programming Antihero resz a cikk aljan -
#16804
axioma
veterán
Netszemete
#16794
axioma
veterán
válasz
Netszemete
#16794
üzenetére
Hat nem az a szep ami rutinbol megy, ha erre gondolsz... Tekintve hogy a hobbim a versenyprogramozas ahol jellemzoen a bigO minimumra lonek, nem fejlesztettem ki egy munka-e'nemet aki nem torodik ezzel.
-
#16803
Ispy
nagyúr
Netszemete
#16802
Ispy
nagyúr
válasz
Netszemete
#16802
üzenetére
Igen, a sas-módszerrel.
![;]](//cdn.rios.hu/dl/s/v1.gif)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De már megint ugyanazokat a köröket futjuk....
legalábbis ezt hallottam.
)
Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Latitude 5430 27% 14" FHD IPS i7-1265U 16GB 512GB NVMe magyar vbill ujjlolv IR kam gar
- Bomba áron dobozos új GIGABYTE /I7-13620H 16GB 1 TB SSD Nvidia RTX 4050 6GB 144 Hz FHD IPS/
- T14s Gen2i 14" FHD IPS i5-1135G7 16GB 256GB NVMe magyar vbill ujjlolv IR kam gar
- Új Poco F7 Ultra 512/16GB Black 3év garancia!
- Samsung Galaxy Watch Ultra 2év garancia!
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
- Bomba ár! Dell Latitude 3550 - i5-5GEN I 4GB I 500GB I 15,6" HD I HDMI I Cam I W10 I Garancia!
- Xiaomi Redmi A1 32 GB Kártyafüggetlen 1Év Garanciával
- Telefon felvásárlás!! Honor 400 Lite, Honor 400, Honor 400 Pro
- DELL PowerEdge R730xd 12LFF rack szerver - 2xE5-2680v3,64GB RAM,4x1GbE,H330 RAID v ZFS
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest