- Fotók, videók mobillal
- iPhone topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Milyen okostelefont vegyek?
- Motorola Edge 50 Neo - az egyensúly gyengesége
- One mobilszolgáltatások
- Ilyen lesz a Fairphone 6
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy A54 - türelemjáték
- Középkategóriást mutatott be újra az Oppo
-
Mobilarena
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
sztanozs
veterán
Ez a fajta asszociatív tömb nem létezik JS-ben, a legközelebbi az egy objektum, aminek string paraméterei vannak (ahogy át is jön json-ban). Ez nem tömbbe kell beleerőszakolni, hanem meg kell tartani objektumnak és stingként kell hivatkozni az elemekre:
const json = '{"0":0, "5":0}';
const obj = JSON.parse(json);
console.log(obj[0]);
console.log(obj[5]);
console.log(obj);
obj[8] = 1
console.log(JSON.stringify(obj));
> 0
> 0
> Object { 0: 0, 5: 0 }
> "{"0":0,"5":0,"8":1}"
A számból álló kulcsokat tényleg nem szereti JS, mert az objektum kulcsai csak stringek lehetnek. -
#8079
instantwater
addikt
coco2
#8078
-
-
dqdb
nagyúr
A titkosítás teljesítményre gyakorolt hatását ketté kell bontani kapcsolatfelépítésre és a már felépített kapcsolaton keresztüli kommunikációra.
Egy TLS kapcsolatnál a felépítés költsége az igazán jelentős, ez hálózati oldalon egy extra RTT körből jön össze a protokoll miatt (a TLS1.3 és a neked ajánlott HTTP/2 rendelkezik zero-RTT opcióval, szóval ez eliminálható), CPU oldalon egy privát kulcsos műveletből, ami a kriptográfiai műveletek között messze a legdrágább.
Először lefuttattam egy Core i5-4590-en a kéznél levő őskövület, 2012-es OpenSSL 1.0.1c egy szálon futó sebességtesztjét:
sign verify sign/s verify/s
rsa 2048 bits 0.004417s 0.000136s 226.4 7361.3
rsa 4096 bits 0.032730s 0.000511s 30.6 1955.3Aztán beugrott, hogy azóta bekerülhetett AES-NI támogatás az OpenSSL-be és a CNG-be is (saját céges teszt volt RSA aláírás témakörben, azon az OpenSSL-t használó C kód és a CNG-t használó C# kód ugyanazt a teljesítményszintet nyújtotta), ezért fordítottam OpenSSL 1.1.1c-t, és lemértem azzal is:
sign verify sign/s verify/s
rsa 2048 bits 0.000616s 0.000029s 1623.4 33982.7
rsa 3072 bits 0.002859s 0.000060s 349.8 16806.2
rsa 4096 bits 0.006546s 0.000104s 152.8 9661.8Az előrelépés látványos, és a fenti processzor egyetlen szálon 1623 aláírást tud végrehajtani másodpercenként a most elterjedt 2048 bites kulccsal. Mivel ennek a kulcsméretnek várhatóan már csak pár éve van, hogy átcsússzon nem ajánlottba (bár addig még rengeteg, hogy határozottan kerülendő legyen), bekerült a 3072 és 4096 bites kulcsméret is, azokat is érdemes nézegetni, hogy mire lehet majd 8-10 éven belül számítani. Az ECC opciókat kihagytam, azok CPU erőforrásban a 2048 és 3072 bites RSA között vannak valahol korábbi céges tesztjeink alapján.
Ha már felépült a kapcsolat, akkor azon titkosítva mennek át az adatok, ez ma tipikusan AES128/AES256. Lássuk a teszteket (csak frissebb OpenSSL, itt 10% javulás volt csak a korábbihoz képest):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 138254.38k 146752.33k 153316.83k 148921.83k 151887.48k 151125.24k
aes-192 cbc 107198.00k 121410.13k 124547.81k 122201.29k 128566.72k 129934.99k
aes-256 cbc 97304.25k 107784.19k 107225.75k 105430.48k 106100.13k 104593.96kAzaz a ma elterjedt AES128-cal egyetlen szál 138 MB/s sebességre képes a gépemen, ebbe az általad megadott 15 MB/s sebességigény röhögve belefér, egyetlen átlagosan erősnek nevezhető CPU egyetlen szála 11%-os terheléssel kiszolgálja a létrejött TLS csatornán a titkosítást, ezt én elhanyagolható erőforrástöbbletnek nevezném. Az AES128 várhatóan még sokáig velünk lesz ajánlott formában, itt erőforrás szempontjából a jövőre nézve a legrosszabb eset az AES256-ra áttérés jelenti.
A fentiekből látható, hogy nem kell hatalmas szerverfarm ahhoz, hogy kiszolgálj 10000 kapcsolódást, elég egy szerver megfelelően sok maggal, de az is látható, hogy a HTTP Keep-Alive funkcióra egyszerűen kötelező építeni, mert ezzel a kapcsolatfelépítést tudod megspórolni, minden kéréshez külön TLS csatornát építeni drága hobbi és ahhoz tényleg kell az erőforrás (azonban mivel böngésző a túloldal, ezért ahhoz komolyan meg kell dolgozni, hogy kiiktasd azon az oldalon a keep alive-ot).
10000 tps-hez a szervert megfelelően össze kell rakni. Felejtsd el az async idők előttről itt ragadt HttpListener-t, az ASP.NET Core-ra építs IIS vagy Kestrel alapokon (és azonnal kapsz HTTP/2 támogatást), ahogyan martonx ajánlotta, vagy ha pehelysúlyra vágysz HTTP/2 nélkül, akkor ott a uHttpSharp. A kérések kiszolgálását kizárólag async kód végezze kihasználva az aszinkron futás lehetőségét az összes IO műveletnél, mert ilyen terhelés töredékénél is luxusnak számít az 1 worker thread/kérés működés (az általad írt 1 process/kérés pedig teljes mértékben az).
További olvasnivaló a témában itt.
-
martonx
veterán
Pont ez az, hogy nincsenek ott, legalábbis az asp.net core, nodejs, python, go és még ki tudja mennyi esetben, ha nem használsz felettük proxy webszervert (mint pl. apache, amit a legelső hsz-emben is írtam, hogy nem szabad ebben az esetben használni, mégis mindig ezzel jössz...), hanem csak önmagukban bután futtatod őket, hogy mondjuk figyelnek a 443-as porton, és ennyi, akkor ezek egyik általad problémásnak tekintett dolgot se fogják figyelni (csak amit direkt felparaméterezel bennük, hogy figyeljenek, mert használni akarod)
-
sztanozs
veterán
pure http post és get ha kell visszaigazolás, különben mehet webrtc-n (UDP), de nem biztos, hogy megkapod az üzenetet. Persze vacakolhatsz sima tcp-vel is, de ki tudja meddig lesz támogatott (és az IE láz óta nem láttam olyan peremfeltételt, hogy kizárólag egy böngészőt lehet használni)
-
-
#57018880
törölt tag
Feathersjs gondolom a stack egy kicsit visszafogja a teljesítményt. Azok a számok amiket írtál point to point nálam nem jönnek ki WebSocketen sem.
Szívesen megnéznék forrást ahol van működő rendszer ezekkel a számokkal amit írtál, akár csak szerver oldalon, de a teljes routing az ideális esetben is kb +10ms per kör ( 4G ~60ms), ha jól kerestem ki, még a HTTP átlag 100+ms, tipikusan több.
Még egy linky összevetéssel.
-
-
#2312
Sk8erPeter
nagyúr
coco2
#2311
Sk8erPeter
nagyúr
"Én azt hittem, a JScript Java alapokra hajaz, de ott értéket adni "="-al szokás, nem ":"-al. Én legalábbis még sohasem csináltam másképpen."
Erre válaszul egy elég hiteles forrás:
https://developer.mozilla.org/en/JavaScript/A_re-introduction_to_JavaScript
"It's useful to start with an idea of the language's history. JavaScript was created in 1995 by Brendan Eich, an engineer at Netscape, and first released with Netscape 2 early in 1996. It was originally going to be called LiveScript, but was renamed in an ill-fated marketing decision to try to capitalize on the popularity of Sun Microsystem's Java language — despite the two having very little in common. This has been a source of confusion ever since."A JavaScript és a JScript megint csak nem ugyanaz. Te a JavaScript topicban vagy...
"Microsoft released a mostly-compatible version of the language called JScript with IE 3 several months later."
JScriptről továbbiak itt."Én legalábbis még sohasem csináltam másképpen. A JQuery-t ne keverd ebbe bele, ez JScript alapot érintő kérdés. Az igazi problémámnak nulla köze van konkrét lib szintű kód részletekhez."
1. Nem JScript, hanem JavaScript-alapot érintő kérdés, lásd a korábbiakat.
2. (A "JQuery-t ne keverd ebbe bele" részre reagálva Előbb nem volt egyértelmű, konkrétan melyik szintaktikával van a problémád..."Most hogy ezen juszt is elkezdesz rugózni.. irigylem a fene sok fölös energiádat."
Én meg csodálkozom az erősen offenzív és egyben destruktív stílusodon. Idejössz, segítséget kérsz, meg is adjuk neked, több kérdésedre is reagálok, Te meg úgy válaszolsz, mint akinek szidták az anyját. Ha valaki próbál neked segíteni, akkor cserébe lehetőleg ne rugdalózz. Felvilágosításként: a segítségként történő válaszadást meg egy programozási hibára történő figyelemfelhívást nem "rugózásnak" hívnak. Így az embernek egy kicsit elmegy a kedve a további válaszadástól. És most nagyon finoman reagáltam az általad alkalmazott, bicskakinyitó stílusra.Objektumok: [link], [link], plusz amire kérdezel, magára a szintaktikára ez jó referencia:
"An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma)."
Másik válasz:var o = {
r: 'some value',
t: 'some other value'
};
is functionally equivalent tovar o = new Object();
o.r = 'some value';
o.t = 'some other value'; -
#2310
Sk8erPeter
nagyúr
coco2
#2305
Sk8erPeter
nagyúr
"szívesebben láttam volna explicite kibontva ezt a (szerintem) mákos tésztát, de a szerzőnek más volt a véleménye."
Hogy kellett volna "explicite kibontani"? Magyarázza el a JavaScript vagy jQuery alapjait?
Vagy nem tudom, mire gondolsz.
Egyébként a kóddal nincs baj, ez így elég átlátható.Tulajdonképpen röviden paraméterként átad egy objektumot, amiben az onChange és onSelect eseményekre mutató függvénypointereket tárolja (tehát milyen függvények hívódjanak meg az események bekövetkeztekor), második paraméterként pedig egy anonim függvényt ad át.
Ezt más szintaktikával is meg lehetett volna írni akár, pl. így:
var faszaObjektum = {
onChange: updatePreview,
onSelect: updateCoords,
aspectRatio: 1
};
$('#target').Jcrop(faszaObjektum, function () {
// Use the API to get the real image size
var bounds = this.getBounds();
boundx = bounds[0];
boundy = bounds[1];
// Store the API in the jcrop_api variable
jcrop_api = this;
});De egybevonva látszik, mivel hívod meg a Jcrop-ot az adott DOM-elemre. Ez ízlés kérdése, hogy írod meg.
-
#2301
Sk8erPeter
nagyúr
coco2
#2299
Sk8erPeter
nagyúr
Minek ilyen nyakatekerten megoldani a függvényeket? Nem igazán világos itt az anonim funkció szerepe sem, hogy tulajdonképpen minek - nem sok értelme van.
Átalakítva valami normálisan értelmezhető formára:
function multiply( a, b ){
return a * b;
}
alert( multiply(3, 4) ); // 12Így még lehet is látni, mit akar csinálni a függvényed.
Egyébként ha nagyon ragaszkodsz - az okát nem látom - a saját függvényedhez, akkor az anonim funkciónál sincs sok értelme egyből megadni a bemenő paramétereket.
Példa:var proven = function (a, b) { return a * b; };
alert( proven(3, 4) ); // 12Így pontosan ugyanaz a függvény meghívásának módja.
=====
(#2300) Athlon64+ : sajnos nagyon sok tutorialban a mai napig benne maradt ez a language="JavaScript" baromság. Ez még nagyon régen használatos volt, de már elég régóta kiment a divatból - tehát "deprecated"-nek minősül (pl.). Itt is találtam egy oldalt, ahol arról vakerásznak, miért is kell(ett) ez az attribútum. Sajnos az ilyeneket nem törlik. Volt ilyen, ma már nincs.
Vagy nem tudom, mire gondolsz.
Ezt hol olvastad?Új hozzászólás Aktív témák
Hirdetés
- BestBuy topik
- gban: Ingyen kellene, de tegnapra
- Gyúrósok ide!
- Fotók, videók mobillal
- CASIO órák kedvelők topicja!
- sto1911: Pinball FX3 PH! verseny
- sziku69: Fűzzük össze a szavakat :)
- PlayStation 5
- hdanesz: Hyundai Ioniq 28kWh - Első benyomások - második felvonás
- Szünetmentes tápegységek (UPS)
- További aktív témák...
- Precision 3480 27% 14" FHD IPS i7-1370P 32GB 512GB NVMe magyar vbill IR kam gar
- Apple watch Ultra 2 megkímélt akku 100% 2025.08.25.Apple jótállás beszámítok!
- Precision 3580 27% 15.6" FHD IPS i7-1360P RTX A500 32GB 512GB NVMe magyar vbill gar
- Intel Core i5-13500 OEM
- Toshiba Surveillance Pro S300 8TB megfigyelőrendszerekre optimalizált merevlemez
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- BESZÁMÍTÁS! ASUS ROG CROSSHAIR VI EXTREME alaplap garanciával hibátlan működéssel
- Csere-Beszámítás! Olcsó RTX Gamer Laptop játékra! I5 11400H / RTX 3050Ti / 16GB DDR4 / 512GB SSD
- Csere-Beszámítás! Prémium vizhűtéses számítógép! I9 11900K / RTX 3090 / 64GB DDR4 / 1TB SSD
- LG 27GS60QC-B - 27" Ívelt - 2560x1440 - 180Hz 1ms - AMD FreeSync - Bontatlan - 2 Év Gyári Garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest