Příspěvky

76

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 19:37:57 »

Zatial som sa este na profiler nepozeral. okrem toho musim riesit opat nieco "s ultra vysokou prioritou"

cenim si ochotu pomoct a dakujem za nu.

77

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 18:12:29 »

Vznikají v tom kódu nové objekty?  - ANO, vela
autoboxing - ANO, vela
Spouštíte to v obou případech stejnou Javou? - ANO
... instrumentaci - NIE

Sam som zvedavy, cim to je sposobnene. Ked to zistim, napisem sem dovod.

78

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 16:22:33 »

Můžete tak předejít problémům při běhu v produkčním nasazení, protože tím můžete odhalit slabé místo implementace.

plne suhlasim. urcite na to kuknem nejakym profilerom.

@Filip: kod je uplne primitivna matekatika (+,-,*,/), ale pouzita X tisic/milion-krat spolu s  java kolekciami (mozno problem niekde okolo hashcode/equals), ziadne spominane "pokrocile technologie". Tak ako zvycajne, zrejme bude aj v tomto pripade problem medzi klavesnicou a stolickou:)  - je mozne, ze som nieco prehliadol a s profilerom budem mudrejsi.

dakujem obom za tipy.

79

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 12:32:45 »

Vyriesenie (ciastocne).

Nastastie to nebol problem Springu Ked spustim aplikaciu ako "stand-alone" fat spring-boot jar, tak to trva "spravne", t.j. rovnako ako bez Springu. Ked ale aplikaciu spustam v Eclipse, pomocou "Spring Boot App" launcher-a (jedno ci debug alebo run), tak kod je pomaly. Pouzivam Eclipse 2018-12, je mozne, ze tam je nejaky bug.

@Ondrej: Mozem sa na to pozriet, ale odradilo ma od toho to, ze ten kod pouziva vela vnorenych cyklov, v roznych kombinaciach a jednoduche logovanie do konzoly naznacovalo, ze spomalenie nie je specificke pre jedno miesto, ale ze to spomalenie je "rovnomerne roztiahnute", neviem, ci rozumiete co myslim. preto som myslel, ze to bude "nejaka zrada". Ale aj taj zaujimave, preco to ten plugin/launcher tak spomaluje. V jeho nastaveni nie je nic, co by to mohlo sposobovat. Keby to boli tisicky requestov, tam by som chapal, ze sa to nazbiera, ale ako hovorim, ja urobim jeden request a necham javu pocitat a pocitat a nasledne vrati nejaky vysledok.

80

Vývoj / Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 11:42:09 »

Ahoj, vedeli by ste mi s tymto poradit?

Mam Java kod, ktory riesi nejake heuristiky (praca s kolekciami, porovnavanie, preklapanie objektov z jednej kolekcie do druhej a pod. ziadne diskove/sietove/graficke IO operacie, minimum vypisu do konzole/log suboru) tento kod je 100% nezavisly na Spring frameworku.

Avsak: ked zoberiem tento kod a vlozim jeho volanie do Spring kontrollera (Spring Boot 2.1.2) tak zrazu je cas spracovania cca 2-3x dlhsi, t.j. 2-3sekundy namiesto 1s, ako ked kod spustam mimo Spring, t.j. napr. jUnit alebo plain simple main class.

Podozrieval som Spring, ze tam nieco obaluje pomocou aspektov, tak som  este pre istotu vlozil tu cast kodu do jUnit ale tak, aby sa nastartoval skoro cely Spring kontajner, (t.j. vidim tam vsetky hlasky ako pri starte spring boot, Hibernate, transakcie, security, ... okrem WebApplicationContext, Tomcat a pod.) a zaujimave, ze tu je ten "externy kod" opat rovnako rychly ako bez Springu.

Stretli ste sa s niecim podobnym?

81

O serveru Root.cz / Re:Zase redesign?

« kdy: 28. 04. 2020, 20:55:38 »

Cilem bude zabit forum, kdyz se ted bude zobrazovat jen 5 top vlaken Nebylo by lepsi volbu sablony nechat na uzivatelech, nekteri jsme radi zasekly na par let starem, ale za to omnoho uzitecnejsim/funkcejsim designu, nez tech modernich telefonnich rozhranich.

uplny suhlas.

1) top 5 vlaken fora -  to koho napadlo to takto hlupo orezat?!?
2) sablona/redesign - este som nezazil redesign na roote aby si ho uzivatelia pochvalovali. preco mate potrebu to stale menit k horsiemu? nerozumiem tomu. ten redesign vam prinesie vyssie trzby, alebo co si od toho slubujete? pozadovali to uzivatelia? bola nejaka anketa? ja som v podstate pasivny uzivatel, takze o mna prakticky nejde. Ak to je vyhodnejsie pre redakciu, nech sa paci.

82

Bazar / Re:Darování serveru

« kdy: 26. 04. 2020, 18:56:06 »

Kde je háček? ... - fakt tam musí být háček

to by zaujimalo aj mna. mam tam 3x VPS asi 1,5 roka a stale som na ten hacik nenarazil Teraz vazne: naozaj je to v pohode, netusim, preco je cena taka aka je, ale za cely cas som nemal problem s dostupnostou. Uptime mam cca 290 dni.

jo a mam doma 100% funkcny
HP ProLiant DL360 G5, Procesor CPU - 2x XEON E5450 (8x 3.00GHz), Pamäť RAM - 32GB DDR2, Kapacita úložiska - 1000GB (2x500GB SATA3 7.2k)
ked si prides pon do Ziliny/Sk, za flasku vina je tvoj:)

83

Server / Re:Double SSH tunelling

« kdy: 21. 04. 2020, 15:26:35 »

skvele, nieco presne taketo som hladal - netusil som, ze ten "server only" tunel nie je nutny.

velmi pekne dakujem.

84

Server / Double SSH tunelling

« kdy: 21. 04. 2020, 14:02:15 »

Ahoj,

poradili by ste mi prosim s tymto?

mam desktop D a server S, na serveri bezi databaza nabindovana na localhost only a ja sa chcem s desktopu D pripojit na databazu na serveri S.

Robievam som to tak, ze som na serveri vytvoril lokalny tunel z localhost:3306 (mysql) na public_ip:5678 (whatever)  a potom som si vytvoril 2. tunel z desktopu (localhost:1234) na server (public_ip:5678) koli tomu aby connection do DB bolo sifrovane a nasledne sa pripojil do databazy (na 1234) z desktopu. po praci som tunel zrusil.

Je mozne takyto "dvojity SSH tunel" urobit jednorazovo (jednym prikazom/scriptom), t.j podporuje to SSH? Ak  nie, tak by mi aspon pomohlo to, ako nakonfigurovat SSH aby sa na ten serverovy port 5678 mohol pripojit iba konkretny jeden klient, teda moj desktop.

85

Server / Re:Doporučte zahraniční hosting

« kdy: 06. 04. 2020, 10:50:33 »

https://contabo.com/

86

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 01. 04. 2020, 17:45:04 »

Na devel stanici bych udělal něco hodně podobného.
1. Firewall output => reject (kvůli timeoutům je to vhodnější než drop)
2. Firewall output user=[můj pracovní účet] => accept (osobně bych preferoval i pro svého usera proxy)
3. Aplikaci povolit přístup ven jen přes (dopřednou) proxy (a toto bych měl i na produkci)

ano, to by asi bolo idealne ale priznam sa, ze takto dokladne to nakonfigurovane nemam. Ja sa vo vacsine pripadov spolieham na to, ze cely "standardny" Ubuntu desktop stack je "jakz-tak" bezpecny.

Ale k otazke zo zaciatku tohoto vlakna: tak trochu som predpokladal, ze to dopadne presne ako to dopadlo. Ani jeden clovek tu nenapisal, ze si preveril aspon jednu OSS aplikaciu a s kludnym svedomim moze spavat:) - jasne, ked je spravne nakonfigurovany firewall, riziko je blizke nule ale minimalne podla tohoto vlakna zistujem, ze pocit bezpecia z OSS (typu "musi to byt bezpecne, ved je to OSS a urcite sa niekto nasiel, kto ten kod overil") je len fatamorgana - aj ked pocet citatelov vlakna asi nebude dostatocna reprezentativna vzorka.

BTW: a co ked je bezpecnostna diera v spominanom firewalle? sme tam, kde sme boli - ale to nie je otazka do plena, len take odlahcenie od temy na zaver.

87

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 01. 04. 2020, 12:40:32 »

Mám pocit, že si nerozumíme. Navrhované řešení řeší NOVÁ spojení ze serveru do světa. Nevyřeší se tím to, aby se zablokovaly přístupy zvenčí (to se zase řeší jinak, ale to jsme tu nediskutovali). Možná si pletete pojem "odeslat data" (nějaký script aktivně něco odešle) a "odpovědět na požadavek" (což je nejběžnější činnost, co dělá http server).

Každopádně, pokud jde o Tomcata, toho bych nikdy nespouštěl na přímo, ale vždy zřetězený až za reverzní proxy. Jako reverzní proxy může sloužit nginx, haproxy, apache. Na proxy pak můžete nejlépe ovládat kdo smí přistupovat k službě.

(Zbytek naší diskuse výše se týká situace "odeslat data").

urcite si rozumieme. Ja tu neriesim pripad komunikcie "odpovode na pozadavek z venku". stale sa bavime o desktope a nie serveri, ktory je na internete. tam by samozrejme tomcat nebezal napriamo ale za apachom, kdezto na devel stanici na to nevidim dovod (ak odhliadnem od testovania) z pohladu bezpecnosti. ta "nebezpecna aplikacia" je bindovana iba na localhost, takze z vonku nedostupna.

88

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:54:13 »

Kvas se zeptal poměrně jednoduše na oblast, která je řešitelná velmi namáhavě a liší se situace od situace. Proto na to nejsou žádná howtos.

aby sme sa nepohybovali v celom spektre moznosti uvadzam teda konkretny vymysleny priklad, ktory "akoze" potrebujem vyriesit:

1) povedzme ze neverim, ze je Tomcat (ktory bezi u mna na lokale/devel stanici) bezpecny.
2) vytvorim uzivatela ferko a nastavim iptables tak ako popisujem hore
3) ked spustim tomcat resp. catalina.sh (tusim tak sa ten script vola, nechce sa mi to hladat/overovat) pod userom ferko, tak mozem s tomcatom komunikovat z localhostu ale Tomcat ziadnu moju java classu neposle do sveta.

suhlas? za tomcat si mozno dosadit mysqld/svnserve/keepassx/python whatever......

89

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:46:06 »

Ale na destkopu je to to samé. Běží vám PHP pod uživatelem www-data a tím pádem to pravidlo se nevyhodnotí a projde to.

suhlasim, ved to ani nerozporujem v mojej odpovedi:)

90

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:23:08 »

Ano, takto by to mohlo fungovat, ale z hlediska bezpečnosti je to tzv. "na vodě". Bezpečný postup je DROP ALL (pro všechny uživatele) a poté jedno po druhém povolovat. Nikdy nevíte, které spojení se skryje pod jiného uživatele. Např. odchozí pošta se skryje pod uživatele MTA (např. postfix).

Ze stejného důvodu musíte spustit i nginx/apache a php-fpm pod userem ferko, protože jinak se to skryje (nejčastěji) pod uživatele www-data.

Rozumiem. Ale teraz mi ide o zabezpecenie len jednej aplikacie na desktope takze totoby asi mohlo stacit. samozrejme, keby to bolo  nejake php CMStak by bolo potrebne mat pod ferkom spusteny  apache/nginx + php.