Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
nginx (vyslovováno engine x) je lehkotonážní webový server/reverzní proxy vydaný pod licencí BSD. Mimo protokolů http/http(s) zvládá i POP3 a IMAP, takže se ve skutečnosti nejedná jen o webový server. Ale na e-mailové vlastnosti tohoto webového serveru se v článku zaměřovat nebudeme.
Tento webový server umí servírovat veškerý statický obsah (statické HTML, CSS, iso, ...) a určitý typ požadavků směřovat jinam. Nativně webserver neumí PHP, ani Python, Ruby, ... je to jen "hloupá proxy" a webový server pro statický obsah. Avšak důležité je to, že je to i proxy. Pokud si totiž jako pomocníka přivoláme buď FastCGI, nebo jiný webový server (který už mod_php nebo cokoli jiného, po čem toužíme, umí), můžeme nginx použít jako proxy pro servírování tohoto obsahu.
Na svém serveru ism.m4r3k.org
používám FastCGI PHP s nginxem. FastCGI PHP je zhruba stejně rychlé jako mod_php, avšak nese sebou větší paměťový overhead, což však u méně náročných webových prezentací nemusí vůbec vadit. Moje konfigurace vypadá následovně:
user nginx; worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; server { listen [::]:80; server_name ism.m4r3k.org; location / { root /srv/www/htdocs/ism.m4r3k.org/; index index.html index.htm index.php; } # redirect server error pages to the static page /50x.html error_page 500 502 503 504 50x.html; location = /50x.html { root /srv/www/htdocs/ism.m4r3k.org/; } # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /srv/www/htdocs/ism.m4r3k.org/$fastcgi_script_name; include fastcgi_params; } } }
První řádek user
říká nginxu, aby po svém startu zahodil rootovská privilegia a začal fungovat pod uživatelem nginx. Start pod uživatelem root je nutný, pokud chcete, aby nginx běžel na portech nižších než 1024
, které si může nabindovat jen root.
Řádek worker_processes
říká, kolik má běžet procesů pro obsluhu uživatelských požadavků. Každý worker proces může obsloužit takový počet příchozích spojení, jaký je definován konfiguračním řádkem worker_connections
. Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O. Pokud si chcete spočítat maximální počet spojení, které je v jednu chvíli váš server schopen obsloužit, docílíte toho tím, že vynásobíte počet worker procesů hodnotou worker spojení (worker_processes * worker_connections), v naší konfiguraci je tedy webový server schopen obsloužit maximálně 1024 klientů.
V části konfigurace http
načítáme soubor mime.types
, který obsahuje přiřazení Content-Type
k jednotlivým příponám souborů.
types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/x-javascript js; application/atom+xml atom; application/rss+xml rss; }
Parametr gzip
udává, zda se budou odchozí soubory komprimovat gzipem, nebo ne. V případě zapnuté gzip komprese můžete konfigurační soubor rozšířit o volby:
text/html
Více konfiguračních voleb pro modul gzip najdete v dokumentaci.
Sekce http
má podsekci server
, ve které už se konfigurují jednotliví virtuální hosté.
Řádek listen [::]:80;
určuje, na jakých adresách a portech má nginx nabindovat svůj socket. Uvedená konfigurace nabidnuje nginx na port 80 na všechny IPv4 a IPv6 adresy; parametr listen
může obsahovat adresu, na kterou se má server nabindovat, případně port.
127.0.0.1
- nabinduje nginx na adresu 127.0.0.1 port 80127.0.0.1:8080
- nabinduje nginx na adresu 127.0.0.1 port 8080443 default ssl
- nabinduje nginx na všech IPv4 adresách na port 443 pro https spojeníKonfigurační volba server_name se používá pro named virtual hosty. Z každého příchozího HTTP požadavku se vezme hlavička Host
a ta je pak porovnávána se server_name
. Při první shodě je požadavek obsloužen podle dané konfigurace. Volba server_name
může být klasické jméno ism.m4r3k.org
, jméno se žolíkovým znakem (wildcard) na začátku či konci (*.ism.m4r3k.org
, ism.m4r3k.*
) nebo jméno definované regulárním výrazem. server_name
může mít více záznamů, v takovém případě se jednotlivé záznamy oddělují mezerou.
První část location
obsahuje pokyny, jak obsloužit všechny HTTP požadavky, volba root
určuje cestu k adresáři, kde jsou k nalezení požadovaná data. Na rozdíl od webového serveru Apache nginx nezahazuje matchující se část v location
. Budete li tedy chtít mít pro adresář /tmp/
povoleno procházení (autoindexing), musíte vytvořit následující location
.
location /tmp/ { root /srv/www/htdocs/ism.m4r3k.org/; autoindex on; }
Tato část konfiguračního souboru zajistí, že každý požadavek http://ism.m4r3k.org/tmp/nejaky-soubor.txt bude směřovat do adresáře /srv/www/htdocs/ism.m4r3k.org/tmp/
. A pokud se někdo pokusí otevřít http://ism.m4r3k.org/tmp/, tak se mu zobrazí všechny soubory včetně podadresářů, vizte například tuto stránku.
Konfigurační volba error_page
slouží k nastavení chování chybových kódů HTTP protokolů. Uvedený řádek error_page 500 502 503 504 50x.html;
zajistí, aby byly uvedené chybové kódy 500, 502, 503, 504 přesměrovány na statickou stránku 50x.html
. Úplně stejně můžete pracovat i s dalšími kódy jako 404 Not found
nebo 403 Forbiden
. Případně můžete také zajistit změnu chybového kódu, například pokud místo kódu 404 Not found chcete vracet nějaký soubor s kódem 200 OK, můžete do konfiguračního souboru přidat následující řádek error_page 404 =200 vraceny-soubor.html;
.
Jak jsem již řekl, nginx neumí mod_php, jako to dělá Apache, ale umí FastCGI, což je na většinu použití dostatečné. A pokud FastCGI nestačí, může nám na pozadí běžet Apache a nginx dělat k tomuto webserveru jen proxy. O FastCGI PHP se nám stará poslední část uvedeného konfiguračního souboru, tedy ta začínající location ~ \.php$
. Znak ~
označuje regulární výraz, který slouží k identifikaci požadavků, jež mají být zpracovávány pomocí FastCGI. Volba fastcgi_pass
specifikuje, kam má nginx předávat své požadavky na zpracování. Může se jednat o IP adresu a port jako v mém případě nebo o Unixový socket - zadáte unix:/cesta-k/socketu.socket
. Řádek fastcgi_index index.php;
říká, jaké má být jméno zpracovávaného souboru, pokud bude uvedená cesta končit znakem lomítka (/
). V našem případě se jedná o FastCGI PHP, takže očekáváme v adresáři soubor index.php. Další řádek je fastcgi_param
. Ten slouží k nastavování parametrů pro CGI požadavek, který bude odeslán na cíl podle volby fastcgi_pass
. V našem příkladu nastavujeme volbu SCRIPT_FILENAME
na cestu k samotnémi CGI skriptu, tedy /srv/www/htdocs/prace.m4r3k.org/$fastcgi_script_name
. Jak jistě uhádnete, proměnná $fastcgi_script_name
obsahuje všechno, co následuje po /
v požadavku GET, který webserver obdržel. Pokud tedy bude požadavek GET vypadat takto: GET /scripts/rss.php HTTP/1.1
, tak v proměnné $fastcgi_script_name
bude cesta scripts/rss.php
.
Posledním řádkem načítám soubor /etc/nginx/fastcgi_params
, který obsahuje následující parametry pro FastCGI:
fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name;
Nyní, když jsme donutili nginx předávat požadavky na php soubory někam dále, slušelo by se ještě zajistit, aby tyto požadavky i očekávalo něco, co je následně zpracuje - jinak dostaneme chybovou zprávu 502 Bad gateway
. Já osobně jsem se inspiroval tím, jak to dělá lighttpd, a použil jsem program spawn-fcgi
k tomu, aby mi vytvořil požadovaný počet procesů php-cgi, nabindoval jim sockety a zahodil rootovská privilegia. spawn-fcgi spouštím s následujícími parametry:
/usr/bin/spawn-fcgi -C 10 -a 127.0.0.1 -p 9000 -u nginx -f /usr/bin/php-cgi
Parametr -C
udává počet instancí, které mají být spuštěny, -a je adresa, na kterou se má php-cgi
nabindovat, -p
udává port, na který se bude bindovat, -u
udává uživatele, pod kterým se má php-cgi
spouštět, a -f
udává cestu k binárce, která se má spouštět.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Ve chvílích, kdy Apache přestává stíhatTo mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.
je to jen "hloupá proxy"Ehm, jak vypadá chytrá proxy? Je mi jasné, že pokud něco neumí out-of-the-box nativně PHP, spousta PHP programátorů to bude považovat za nepotřebný balast a proto je třeba je poučit, ale zacházet až tak daleko
Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O.Myšleno je nejspíš diskové I/O, že... Blokující síťové I/O, to by si snad při single-process single-thread architektuře nikdo nedovolil... Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1? A rozdíl by tu byl ještě jeden
To mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.Vim o mistech kde apache nestihal a nginx se flaka
Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1?epoll/poll/select/rtsignals...
>> A rozdíl by tu byl ještě jeden
Nesmíte věřit všemu co se kde píše. Tyhle věci se dají nastavovat a zpravidla jsou nastaveny správně, aby se podobné věci neděly.
Myšleno je nejspíš diskové I/O, že...Ano, mysleli jsme samozřejmě diskové I/O.
bez .htaccess nepouzitelne
Ale je nekompatibilní s Apache. Stejně jako v lighttpd...
btw pryc jsou doby kdy na nginx byla potreba rustina :)
aktualni anglicka wikina je uz velice schopna a vseobjimajici
To budu asi ja ;)
Chybi mi aspon strucne zduvodneni, proc by jsem mel zkusit nginx a ne treba lighttpd (ktery je znamejsi). V cem je nginx lespi nez lighttpd?
Nebo teba boa ?
Ci jine valstni napsane web servery ?
Uznavam ze apache2 je na lecktere veci tezsi ...
... ale neni to spis o konfiguraci ?
A proc BOA??
23 Feb 2005 - Version 0.94.14rc21 released!
ten projekt prakticky skoncil... Jak jej muzete porovnavat s lighttpd?