CategoryNezařazené

Clock cycles consumed by typical system tasks

L1-cache 3 cycles
L2-cache 14 cycles
RAM 250 cycles
Disk 41,000,000 cycles
Network 240,000,000 cycles

Autor: Ryan Dahls

NodeJS: parsování příkazové řádky

Až do teď jsem pro přístup k parametrům příkazové řádky používal npm balíček optimist, nicméně teď v novém projektu jsem se ze zvědavosti poohlédl po jiných balíčcích, abych se ujistil že používám ten nej (ať už je to v jakémkoliv úhlu pohledu), nebo našel nějaký nový, modernější, lepší, zase nějaký ten nej balíček.

Našel jsem pěkný, stručný článek s přehlednou tabulkou shrnující základní vlastnosti asi nejpoužívanějších npm balíčků.

Pokud chcete jen parsovat nějaký argument, pak asi nejlepší volbou budem minimist, pokud chcete zkusit něco nového, koukněte na yargs, ale pokud potřebujte opravdu robustní řešení kde čeho na příkazové řádce, včetně povinných parametrů a já nevím čeho všeho, bude tou správnou volbou commander.

Optimist nedopadl asi nejlépe, a tak jej najradím za jiný balíček…
Vítězem krátkého porovnání se stal minimist. Srovnával jsem i rychlost zpracování parametrů na příkazové řádce (nic složitého) a minimist byl nejrychlejší. Dalším jeho kladem je minimální závislost, respektive absolutní nezávislost, ni jiných balíčcích.

Vnímání latence uživatelem

Zpoždění Reakce uživatele
0–100 ms Okamžik
100–300 ms Malé postřehnutelné zpoždění
300–1000 ms Počítač pracuje
1 s a více Přepnutí mentálního kontextu
10 s a více Vrátím se později…

WEBSITE DOWNLOADER

WEBSITE DOWNLOADER: Download all the source code and assets of any website.
Stačí zadat URL a emailovou adresu kam bude poslán komplentní, zabalený web.

Hackers

hackers620

Hackers

Nginx loadbalancer, remote address v NodeJS

Nginx jako loadbalancer

Spouštím na 3 ruzných serverech tu stejnou NodeJS aplikaci, takže mi Nginx rozkláda zátěž rovnoměrně na všechny 3 servery. To je výchozí nastavení: 1. request obslouží 1. server, 2. request 2. server, 3. reques 3. server, 4. request 1. server a furt dokola… Nádhera. Dá se samozřejmě nastavit jiné chování load balanceru, ale tohle je pro rovnoměrné rozložení zátěže ideál. Já si Round Robin můžu dovolit, protože o mé sessions se stará redis a všechny instance aplikace ví, jak si o proměnné session říct. Pokud budete mít session třeba v cookies, pak bacha, protože jednotlivé requesty neví nic co bylo včera a nepředávájí si žádné informace, pokud se o to teda sami nějak nepostaráte…

nodejs, load balancer, nginx

NodeJS apka jako multithread aplikace

Aby to byla ještě větsí legrace, samotná aplikace se spouští pomocí knihovny cluster. To proto, že normální NodeJS je singlethread aplikace… Takže pokud máte vícejádrový procesor na serveru, tak pak pokud nepoužijete cluster, beží vaše aplikace jen v jednom vlákně. Super, ale né dokonalé… Nedokonalé třeba i proto, že když vám aplikace spadne, což se může stát, tak pokud nemáte pořešené jinak, např přes PM2, nebo nodemon, tak webová aplikace zemře a neběží.
Tenhle kus kódu mi zajistí, že aplikace poběží ve všech jádrech procesoru, v případě pádu některého vlákna znovu nastartuje. Každé vlákno má svou konektivitu do MongoDB…

Pěkné je, že všechny vlákna aplikace jsou schovaná za jediným portem a master v clusteru se stará o rozdělování trafiku. To mi umožňuje maimální jednoduchost v Nginx konfiguraci, kde jen specifikuju jednotlivé fyzické servery a port onoho masteru aplikace… Super.

NodeJS a remote address

No a pokud si nenastavíte v Nginx konfiguráku proxy_set_header (jak je výše uvedeno), budete mít problém zjistit IP adresu vašeho živého návštěvníka webových stránek, protože Nginx, jako reverzní proxy a loadbalancer uvdete jako IP adresu IP adresu stroje, na kterém běží…

Proto jsou důležitá ty proxy hlavičky, protože až s nimi pak funguje:

CoffeeScript Application Development Cookbook

9691OS

CoffeeScript Application Development Cookbook

Default gateway v OSX

pro Fedoru mírná změna:

Průtokový ohřívač vody

ohrivac-vody

Objednávky přijímáme v našem eshopu: ESHOP-PLUS.CZ

Auth v MongoDB Replica Setu

Pro jednu ze svých aplikací používám jak storage engine MongoDB. Abych o data nepřišel, jsou ukládána současně na 3 serverech v ReplicaSetu. V případě pádu jednoho ze serverů jsou data dostupná na některém dalším serveru. Redudance, vedle samotné dostupnosti dat, je dobrá i k tomu, když například potřebujete zhodit některý server, například kvůli instalaci nového jádra.

Ale aby bylo vše jak má, je krom samotné dostupnosti dat, potřeba zajistit i bezpečnost přístupu k nim, respektive samotnou autentifikaci v MongoDB na ůrovni Replica Setu.

Jak na to

1. start

Nastartovat mongod proces na jednom ze serverů na kterém poběží jedotlivé servery replica setu. Proces je potřeba spustit bez paramettu –auth. Měla by být specifikovaná cesta k datům skrze parametr –dbpah a samozřejmě –port 29002 na kterém server poběží.

2. vytvoření administrátorských účtů

Přihlásit se k nastatovanému MongoDB serveru:

Vytvořit 2 účty:

Hotovo. Vyskočit z mongo shellu.

3. zastavit běžící mongo server

4. vytvořit klíč společný pro všechny servery v replica setu

5. distribuce klíče na servery

Je potřeba bezpečně rozdistribuovat klíč na všechny servery v ReplicaSetu. Taky nastavit práva na 0600.

6. nastartování serverů replica setu

Na všech serverech v replica setu nastatovat mongod proces s parametry –keyFile a –replSet

7. připojit se k mongo serveru

Ale pouze k tomu, kde se vytvářeli uživatelské účty admin a root.

A potom v mongo shellu

8. inicializace ReplicaSetu

9. ověření konigurace ReplicaSetu

V tom stejném mongo shellu bez nutnosti vyskakovat:

Měli byste dostat objekt s jednim členem v members.

10. přidání ostatních členů ReplicaSetu

Opět v mongo shellu:

11. kontrola stavu ReplicaSetu

Stále v mongo shellu:

Výsledkem by měl být objekt, který už obsahuje info o všech serverech v ReplicaSetu.

12. vytvoření samotného účtu pro replikovanou databázi

Stále v mongo shellu:

Hotovo!

Pak už se lze na ostatních serverech v ReplicaSetu přihlásit k dané databázi:

v mongo shellu pak

Zdroj

© 2017 pepa.holla.cz

Theme by Anders NorénUp ↑