Vlákno názorů ke zprávičce Jak zrychlit ssh od j - Tj, to je zase blabol ... bych chtel...

Tj, to je zase blabol ... bych chtel videt toho uzivatele, kterej pozna ze ma sshcko o 10, 20 nebo 30ms pomalejsi odezvu, protoze to je tak jediny, v cem muze bejt rozdil.

Jeste vetsi blabol je to s tema klicema ... protoze jak heslo tak klic se pouzije jen jednou - pri zahajeni session. Nehlede na to, ze v odkazovanym clanku je uplne neco jinyho nez v newsce, je tam ze se ma sshcku RICT jakej zpusob autentizace se pouzije (protoze jinak se bude dohadovat = cekat) coz opet povede tak maximalne k par ms pri loginu. Rozhodne tam NENI ze pouziti klice je rychlejsi, protoze ani byt nemuze.

Nejde o to ci to pozna interaktivny uzivatel. Skus si urobit 30 spojeni na 60 serverov cez nejaky automatizacny framework, ktory ssh vyuziva (povedzme ansible, atd) a ten rozdiel bude viac ako podstatny. V pripade CI, ked musis otestovat kvantum moznosti deploymentu na kvantum masinach, tak to dava zmysel optimalizovat. To iste plati pre dohadovanie sa o autentizacii.

Jo, a asi tak o 2 rady efektivnejsi bude drzet pripojeni na to kvantum masin otevreny ...

Resit tohle je asi tak stejny, jako kdyz budes resit, jestli by ta lopata nemela bejt o cm sirsi, nebo o cm uzsi ... a jak afektivne s ni vykopes tu diru, kdyz soused ma bagr.

ked robis paralelne ssh na 1000 masin, tak sa ti prave tento zisk rychlosti rozdeli na 1/1000 realneho zisku :) ale ano ak sa pouziva centralny jump a proxy cez neho, tak control master dokaze zrychlit toto pripajanie.

v tom případě ale nebudu číst návody na tecmint.com a naslepo něco upravovat, ale půjdu na jistotu a budu hledat bottleneck, teda já bych to tak udělal, lidé jsou ale asi různí.

ono uplne staci mit UseDNS yes a pak pri spatne (ne)nastavenych PTR trva i nekolik desitek sekund nez se otevre spojeni
a to uz je sakra znat, jestli se spojeni otevre za 0,5 s nebo za 20s