Meta tags:
description=A Rust HTTP server for Python applications. Contribute to emmett-framework/granian development by creating an account on GitHub.;

Headings (most frequently used words):

uh, oh, granian, navigation, and, files, project, code, saved, searches, your, license, footer, access, log, search, repositories, users, issues, pull, requests, provide, feedback, emmett, framework, menu, use, to, filter, results, more, quickly, folders, latest, commit, history, repository, rationale, features, quickstart, extra, dependencies, options, free, threaded, python, customising, status, about, releases, 111, sponsor, this, contributors, languages, asgi, rsgi, wsgi, human, readable, durations, logging, format, workers, threads, backpressure, runtime, mode, metrics, static, proxies, forwarded, headers, asyncio, event, loop, initialization, hooks, embedding, in, topics, resources, of, conduct, contributing, security, policy, stars, watchers, forks, atoms, serving, specific, file, for, directory, listings,

Text of the page (most frequently used words):
the (205), #granian (83), env (71), var (70), for (66), and (66), default (56), you (54), number (48), #worker (41), your (35), will (35), threads (31), file (29), with (28), static (28), can (27), reload (25), http (25), application (25), path (25), python (24), server (22), workers (22), integer (21), that (20), this (20), code (18), blocking (18), range (18), security (17), runtime (17), http2 (17), all (16), connections (16), asyncio (15), loop (15), single (15), use (15), requests (15), amount (15), duration (15), ssl (15), time (14), github (14), serve (14), request (14), absolute (14), backpressure (14), while (13), from (13), app (13), counter (13), alive (13), log (13), text (13), rust (12), thus (12), threaded (12), files (12), metrics (12), size (12), there (11), changes (11), its (11), protocols (11), auto (11), access (11), gil (11), keep (11), ignore (11), asgi (10), wsgi (10), are (10), async (10), event (10), scope (10), headers (10), option (10), directory (10), seconds (10), maximum (10), sets (10), disabled (10), more (9), applications (9), like (9), version (9), def (9), run (9), main (9), value (9), type (9), per (9), error (8), only (8), also (8), instead (8), have (8), free (8), example (8), should (8), configure (8), options (8), format (8), mode (8), docs (7), status (7), please (7), license (7), rsgi (7), process (7), provides (7), import (7), interface (7), relevant (7), which (7), processes (7), build (7), enable (7), name (7), using (7), human (7), readable (7), window (7), max (7), respawn (7), view (7), not (6), other (6), was (6), loading (6), page (6), versions (6), features (6), target (6), still (6), specific (6), same (6), values (6), enabled (6), support (6), set (6), case (6), client (6), protocol (6), address (6), send (6), paths (6), route (6), mount (6), serving (6), response (6), work (6), timeout (6), http1 (6), interval (6), toml (6), cargo (6), enterprise (6), navigation (5), project (5), contributing (5), might (5), being (5), await (5), method (5), standard (5), but (5), accept (5), cli (5), want (5), those (5), any (5), thread (5), interpreter (5), since (5), list (5), check (5), specified (5), provide (5), forwarded (5), index (5), 200 (5), times (5), due (5), global (5), best (5), flow (5), logging (5), level (5), bind (5), 1024 (5), extra (5), commit (5), search (5), community (4), terms (4), releases (4), policy (4), readme (4), resources (4), provided (4), scheme (4), above (4), stop (4), spawn (4), embeddable (4), lifecycle (4), string (4), note (4), warning (4), implementation (4), hello (4), following (4), available (4), directly (4), running (4), asynchronous (4), configuration (4), general (4), need (4), means (4), trusted_hosts (4), based (4), host (4), proxy (4), environment (4), wrappers (4), these (4), header (4), proto (4), proxies (4), html (4), spent (4), threadpool (4), gauge (4), processed (4), lifetime (4), respawned (4), different (4), limit (4), connection (4), several (4), concurrency (4), better (4), before (4), would (4), help (4), another (4), backlog (4), avoid (4), websockets (4), port (4), buffer (4), content (4), create (4), actions (4), issues (4), manage (3), about (3), latest (3), stars (3), conduct (3), bsd (3), topics (3), under (3), projects (3), production (3), minor (3), introduce (3), new (3), numbers (3), where (3), task (3), own (3), two (3), methods (3), specifically (3), out (3), embed (3), accepts (3), argument (3), servers (3), module (3), supports (3), supported (3), limited (3), runs (3), experimental (3), interfaces (3), won (3), them (3), during (3), hooks (3), loops (3), some (3), synchronous (3), load (3), make (3), start (3), always (3), key (3), environments (3), 127 (3), my_wsgi_app (3), my_asgi_app (3), start_response (3), what (3), behind (3), itself (3), both (3), dir (3), package (3), allows (3), offers (3), cumulative (3), waiting (3), microseconds (3), idle (3), failed (3), exceeding (3), benchmarks (3), multi (3), handle (3), within (3), configured (3), than (3), probably (3), vast (3), majority (3), network (3), one (3), very (3), query (3), atoms (3), see (3), unix (3), uvloop (3), read (3), milliseconds (3), adaptive (3), control (3), stream (3), write (3), config (3), tls1 (3), verify (3), exit (3), rss (3), factory (3), working (3), requires (3), exporter (3), filter (3), patterns (3), when (3), pname (3), message (3), pip (3), install (3), world (3), plain (3), body (3), advanced (3), open (3), emmett (3), framework (3), insights (3), pull (3), signed (3), settings (3), tab (3), refresh (3), session (3), sign (3), saved (3), documentation (3), feedback (3), grade (3), copilot (3), platform (3), solutions (3), explore (3), perform (2), information (2), footer (2), 2026 (2), sponsors (2), sponsor (2), repository (2), forks (2), 165 (2), custom (2), clause (2), mind (2), bug (2), fixes (2), usually (2), patch (2), compatible (2), major (2), server_task (2), my_main (2), given (2), first (2), over (2), existing (2), management (2), strategy (2), tasks (2), my_hook (2), on_reload (2), invoked (2), phases (2), register (2), return (2), let (2), alter (2), behaviour (2), really (2), rules (2), apply (2), every (2), bound (2), cpu (2), suggestions (2), depending (2), each (2), between (2), separated (2), here (2), either (2), addresses (2), trust (2), disable (2), 192 (2), most (2), correct (2), determine (2), wrap_wsgi_with_proxy_headers (2), wrap_asgi_with_proxy_headers (2), environ (2), receive (2), utils (2), reverse (2), top (2), order (2), find (2), such (2), rewrite (2), pointing (2), behavior (2), somefolder (2), listings (2), assets (2), media (2), multiple (2), without (2), current (2), workers_respawns_for_lifetime (2), usage (2), spawned (2), description (2), prometheus (2), pick (2), small (2), scale (2), large (2), performance (2), though (2), depend (2), threading (2), trying (2), actual (2), think (2), after (2), wait (2), pushing (2), fine (2), handled (2), way (2), makes (2), acquire (2), hand (2), external (2), database (2), opened (2), setting (2), many (2), gunicorn (2), uvicorn (2), generally (2), regards (2), holding (2), interacting (2), they (2), throughput (2), needs (2), dealing (2), concurrently (2), operations (2), particular (2), dt_ms (2), addr (2), below (2), include (2), logger (2), logs (2), uses (2), good (2), suffix (2), uds (2), domain (2), socket (2), permissions (2), kept (2), rloop (2), winloop (2), 60000 (2), pipeline (2), flush (2), initial (2), 1048576 (2), ping (2), frames (2), frame (2), info (2), certificate (2), keyfile (2), password (2), crl (2), url (2), prefix (2), sample (2), resource (2), samples (2), dotenv (2), watch (2), names (2), directories (2), extends (2), watchfiles (2), tick (2), failure (2), pid (2), show (2), dependencies (2), assert (2), direct (2), looking (2), dependency (2), tools (2), pyproject (2), makefile (2), lock (2), rustfmt (2), pre (2), yaml (2), gitignore (2), tests (2), src (2), spec (2), 818 (2), commits (2), last (2), menu (2), quality (2), discussions (2), appearance (2), cancel (2), searches (2), repositories (2), business (2), developer (2), source (2), customer (2), services (2), devops (2), action, share, personal, cookies, contact, privacy, inc, languages, contributors, learn, 110, jul, 111, report, watching, watchers, properties, activity, released, used, companies, sentry, mozilla, microsoft, weblate, searxng, reflex, paperless, ngx, backward, breaking, follows, semantic, versioning, actively, maintained, my_logic, create_task, idea, later, interact, now, already, figured, object, my_app, requiring, advance, implementing, their, embedding, print, mentioned, callable, arguments, simply, passing, on_shutdown, on_startup, registration, new_event_loop, windowsselectoreventlooppolicy, set_event_loop_policy, build_loop, soon, customise, initialisation, overwriting, say, instance, selector, windows, initialization, gives, customization, customising, nothing, scaling, driven, related, limitation, theoretically, absent, enough, data, tuning, land, experiment, workload, reason, gets, refuse, interpreters, loaded, shared, installation, remains, wheels, published, separately, differences, highly, discouraged, strings, valid, cidr, ranges, special, hosts, effectively, catch, 2001, db8, abcd, fd12, 3456, 789a, altering, sensitive, coming, trusted, intercept, resides, machine, likely, replace, attributes, contexts, none, define, doesn, around, performs, served, points, respond, contents, present, defined, generated, location, contained, tree, arbitrary, condition, routes, mounts, locations, ability, calling, offload, py_wait_cumulative, busy, blocking_busy_cumulative, blocking_idle_cumulative, pending, blocking_queue, pool, blocking_threads, resulted, non, static_requests_err, static_requests_handled, requests_handled, connections_err, accepted, connections_handled, active, connections_active, worker_lifetime, workers_respawns_for_rss, workers_respawns_for_err, workers_spawns, unit, metric, exposes, prefixed, ones, marked, tagged, label, containing, granian_, rest, suggests, efficient, seems, efficiently, cpus, real, mileage, vary, specify, runtimes, paradigms, fact, opposition, happens, interacts, count, typically, long, service, prevent, once, reaches, circumstances, ensure, higher, expected, rather, pressure, halt, suspended, predict, interrupts, sense, never, does, reponse, then, beyond, serial, wouldn, difference, just, communicate, definitely, operates, practically, interrupting, too, down, line, addition, stack, kernel, apposite, parameter, secondary, aside, mechanism, actually, architecture, quite, suggested, irrelevant, interop, happen, fixed, demand, shutdown, inactivity, unless, average, millisecond, delivers, tune, suits, next, section, increase, primarily, lowering, second, few, lot, matching, cores, starting, point, containerized, docker, k8s, container, containers, orchestrator, try, automatically, proper, leaving, responsibility, choose, vastly, deployment, golden, rule, involved, role, system, total, dedicated, query_string, datetime, remote, identifier, specifying, messages, _granian, web, loggers, despite, citizen, library, produce, freely, familiar, idioms, days, hours, minutes, meaning, whenever, sole, interpreted, suffixes, durations, required, granian_host, granian_port, 8000, granian_uds, octal, granian_uds_permissions, asginl, granian_interface, granian_http, handling, granian_websockets, granian_workers, granian_blocking_threads, granian_blocking_threads_idle_timeout, 600, granian_runtime_threads, granian_runtime_blocking_threads, granian_runtime_mode, granian_loop, impl, granian_task_impl, hold, globally, granian_backlog, 128, granian_backpressure, granian_http1_buffer_size, 417792, 8192, granian_http1_header_read_timeout, 30000, enables, disables, granian_http1_keep_alive, aggregates, flushes, pipelined, responses, granian_http1_pipeline_flush, whether, granian_http2_adaptive_window, granian_http2_initial_c, onnection_window_size, settings_initial_window_size, granian_http2_initial_stream_window_size, sent, granian_http2_keep_alive_interval, receiving, acknowledgement, granian_http2_keep_alive_timeout, concurrent, streams, settings_max_concurrent_streams, granian_http2_max_concurrent_streams, granian_http2_max_frame_size, 16384, received, granian_http2_max_headers_size, 16777216, granian_http2_max_send_buffer_size, 409600, granian_log_enabled, critical, warn, debug, notset, granian_log_level, json, granian_log_config, granian_log_access_enabled, fmt, granian_log_access_fmt, granian_ssl_certificate, pkcs, granian_ssl_keyfile, granian_ssl_keyfile_password, min, minimum, granian_ssl_protocol_min, root, cerificate, verification, granian_ssl_ca, granian_ssl_crl, clients, certificates, granian_ssl_client_verify, mounted, granian_url_path_prefix, unexpected, granian_respawn_failed_workers, float, sleep, granian_respawn_interval, rate, monitor, granian_rss_sample_interval, 300, consecutive, consider, granian_rss_samples, granian_workers_lifetime, memory, mib, consume, granian_workers_max_rss, kill, killing, refused, gracefully, granian_workers_kill_timeout, 1800, treat, function, granian_factory, granian_working_dir, granian_env_files, granian_static_path_route, granian_static_path_mount, granian_static_path_dir_to_file, expires, cache, expiration, granian_static_path_expires, 86400, granian_metrics_enabled, scrape, collection, granian_metrics_scrape_interval, granian_metrics_address, granian_metrics_port, 9090, granian_reload, granian_reload_paths, dirs, granian_reload_ignore_dirs, regex, granian_reload_ignore_patterns, granian_reload_ignore_paths, frequency, reloader, granian_reload_tick, 5000, failures, granian_reload_ignore_worker_failure, granian_process_name, granian_pid_file, command, further, combine, extras, suit, adds, functionality, customize, interested, into, response_str, quickstart, extension, pathsend, https, mtls, extensions, yet, implemented, relies, gevent, trio, debugging, solution, pure, ideal, care, everything, else, great, capabilities, especially, performant, wanting, modern, adopting, choice, stable, compared, alternatives, usual, composition, systems, platforms, supporting, eventually, reasons, design, rationale, built, tokio, hyper, items, history, date, folders, tags, branches, master, additional, star, fork, must, change, notification, notifications, public, dismiss, alert, switched, accounts, resetting, focus, qualifiers, our, results, quickly, submit, email, contacted, piece, take, input, seriously, syntax, tips, clear, users, jump, pricing, premium, add, ons, powered, collections, trending, archive, program, accelerator, maintainer, lab, programs, fund, developers, partners, center, forum, skills, ebooks, reports, events, webinars, stories, software, development, topic, industries, government, manufacturing, financial, healthcare, industry, cases, devsecops, modernization, nonprofits, startups, medium, teams, enterprises, company, marketplace, changelog, blog, why, leaks, secret, protection, secure, fix, vulnerabilities, review, plan, track, instant, dev, codespaces, automate, workflow, workflows, integrate, mcp, registry, agents, issue, merge, creation, toggle, skip,

Text of the page (random words):
ar granian_reload_ignore_worker_failure default disabled process name text set a custom name for processes requires granian pname extra env var granian_process_name pid file file a path to write the pid file to env var granian_pid_file version show the version and exit help show this message and exit human readable durations whenever granian accepts a duration it can be specified either as sole number in which case it is interpreted as a number of seconds or using one of the following suffixes suffix meaning s seconds same as no suffix m minutes h hours d days logging despite being a rust project granian is a good python citizen and uses the standard library s logging module to produce logs this means you can freely configure your logging level and format using the standard idioms you probably familiar with as many other web servers granian uses two different loggers specifically the _granian logger for runtime messages the granian access logger for access logs access log format the access log format can be configured by specifying the atoms see below to include in a specific format by default granian will use time s addr s method s path s protocol s status d dt_ms 3f as the format access log atoms the following atoms are available for use identifier description addr client remote address time datetime of the request dt_ms request duration in ms status http response status path request path without query string query_string request query string method request http method scheme request scheme protocol http protocol version workers and threads granian offers different options to configure the number of workers and threads to be run in particular workers the total number of processes holding a dedicated python interpreter that will run the application blocking threads the number of threads per worker interacting with the python interpreter runtime threads the number of rust threads per worker that will perform network i o runtime blocking threads the number of rust threads per worker involved in blocking operations the main role of these threads is dealing with blocking i o like file system operations in general granian will try its best to automatically pick proper values for the threading configuration leaving to you the responsibility to choose the number of workers you need there is no golden rule here as these numbers will vastly depend both on your application behavior and the deployment target but we can list some suggestions matching the amount of cpu cores for the workers is generally the best starting point on containerized environments like docker or k8s is best to have 1 worker per container though and scale your containers using the relevant orchestrator the default number of runtime threads and runtime blocking threads is fine for the vast majority of applications out there you might want to increase the first for applications dealing with several concurrently opened websockets or if you primarily use http 2 and lowering the second only if you serve the same few files to a lot of connections in regards of blocking threads the option is irrelevant on asynchronous protocols as all the interop will happen with the asyncio event loop which will also be the one holding the gil for the vast majority of the time and thus the value is fixed to a single thread on synchronous protocols like wsgi instead it will be the maximum amount of threads interacting and thus trying to acquire the gil with your application code all those threads will be spawned on demand depending on the amount of concurrency and they ll be shutdown after the amount of inactivity time specified with the relevant setting in general and unless you have a very specific use case to do so for example if your application have an average millisecond response a very limited amount of blocking threads usually delivers better throughput you should avoid to tune this threadpool size and configure a backpressure value that suits your needs instead in that regards please check the next section also you should generally avoid to configure workers and threads based on numbers suggested for other servers as granian architecture is quite different from projects like gunicorn or uvicorn backpressure since granian runs a separated rust runtime aside of your application that will handle i o and send work to the python interpreter a mechanism to avoid pushing more work that what the python interpreter can actually do is provided backpressure backpressure in granian operates at the single worker s connections accept loop practically interrupting the loop in case too many requests are waiting to be processed down the line you can think of it as a secondary backlog handled by granian itself in addition to the network stack one provided by the os kernel and configured with apposite parameter while on asynchronous protocols the default value for the backpressure should work fine for the vast majority of applications as work will be handled and suspended by the asyncio event loop on synchronous protocols there s no way to predict the amount of interrupts and thus gil releases your application would do on a single request and thus you should configure a value that makes sense in your environment for example if your wsgi application never does i o within a request reponse flow then you can t really go beyond serial and thus any backpressure value above 2 wouldn t probably make any difference as all the requests will just be waiting to acquire the gil in order to be processed on the other hand if your application makes external network requests within the standard request response flow a large backpressure can help as during the time spent on those code paths you can still process other requests another example would be if your application communicate with a database and you have a limited amount of connections that can be opened to that database in this case setting the backpressure to that value would definitely be the best option in general think of backpressure as the maximum amount of concurrency you want to handle per worker in your application after which granian will halt and wait before pushing more work warning since backpressure interacts with the accept loop it will limit connections not the single requests keep alive connections will handle multiple requests within a single connection but granian won t count those requests in the actual pressure this also means if you typically have several long running keep alive connections to your service for example if you run behind a reverse proxy a backpressure value can prevent granian to accept new connections once the amount of keep alive connections reaches that limit under this circumstances you want to ensure the configured backpressure is higher than the expected amount of keep alive connections and if you re trying to limit the concurrency it s probably better to configure the blocking threads number rather than the backpressure itself runtime mode granian offers two different runtime threading paradigms due to the fact the runtime can be multi threaded in opposition to what happens in python event loop which can only run as a single thread given you specify n threads with the relevant option in st mode granian will spawn n single threaded rust runtimes while in mt mode granian will spawn a single multi threaded runtime with n threads benchmarks suggests st mode to be more efficient with a small amount of processes while mt mode seems to scale more efficiently where you have a large number of cpus real performance will though depend on specific application code and thus your mileage might vary by default auto mode granian will pick the best option based on the rest of its configuration metrics granian exposes the following runtime metrics in prometheus format all the metrics are prefixed with granian_ and the ones marked with worker scope are tagged with a worker label containing the worker id metric name type unit scope description workers_spawns counter absolute number global number of times granian spawned a worker workers_respawns_for_err counter absolute number global number of times granian respawned a worker due to an error workers_respawns_for_lifetime counter absolute number global number of times granian respawned a worker due to exceeding lifetime workers_respawns_for_rss counter absolute number global number of times granian respawned a worker due to exceeding resources usage workers_respawns_for_lifetime counter absolute number global number of times granian respawned a worker due to exceeding lifetime worker_lifetime counter seconds worker current lifetime of the worker connections_active gauge absolute number worker number of active connections connections_handled counter absolute number worker number of accepted connections connections_err gauge absolute number worker number of failed connections requests_handled counter absolute number worker number of processed requests static_requests_handled counter absolute number worker number of processed requests for static files static_requests_err counter absolute number worker number of requests for static files resulted in a non 200 response code blocking_threads gauge absolute number worker current number of blocking threads in the pool on async protocols this is always 1 blocking_queue gauge absolute number worker number of pending tasks for the blocking threadpool blocking_idle_cumulative counter microseconds worker cumulative idle time spent in the blocking threadpool blocking_busy_cumulative counter microseconds worker cumulative busy time spent in the blocking threadpool py_wait_cumulative counter microseconds worker cumulative time spent waiting on gil on the free threaded build this is always 0 static files granian offers the ability to offload static files serving directly to the server without calling your python application in the process the static path route and static path mount options accept multiple values thus you can serve an arbitrary number of static locations in your application the only condition being the number of routes and mounts specified should be the same granian static path route static static path mount assets static static path route media static path mount assets media package app serving a specific file for directory listings granian also provides the option to rewrite a static location pointing to a directory to a file contained in such directory this allows you to serve for example an index html file in the static path tree granian static path route docs static path mount generated docs static path dir to file index html package app note while granian performs a rewrite on the target directory the file will still be served if the request path points to it directly in the example above requests pointing to docs somefolder and docs somefolder index html will both respond with the contents of index html if present also the option will enable this behavior on all the static paths defined proxies and forwarded headers since none of the supported applications protocols define a strategy for proxies forwarded headers granian doesn t provide any option to configure its behaviour around them what granian provides instead for contexts in which is being run behind a reverse proxy are wrappers you can use on top of your application in order to alter the request scope based on the headers forwarded by the proxy itself you can find such wrappers in the granian utils proxies module from granian utils proxies import wrap_asgi_with_proxy_headers wrap_wsgi_with_proxy_headers async def my_asgi_app scope receive send def my_wsgi_app environ start_response my_asgi_app wrap_asgi_with_proxy_headers my_asgi_app trusted_hosts 1 2 3 4 my_wsgi_app wrap_wsgi_with_proxy_headers my_wsgi_app trusted_hosts 1 2 3 4 with these wrappers granian will use the x forwarded for header to determine the client s ip address the x forwarded proto header to determine the client s protocol and replace the relevant request scope attributes with these values since altering the request scope based on values from headers is security sensitive granian will check the request is coming from a trusted host as specified by the trusted_hosts argument by default this value is set to 127 0 0 1 which means granian will only intercept those headers if the proxy resides on the same machine but most likely that s not the case in a production environment you should thus provide the correct set of addresses to the wrappers the trusted_hosts argument accepts either a string or a list of strings where valid values are ip addresses for example 192 0 2 1 or fd12 3456 789a 1 and cidr ranges for example 192 0 2 0 24 or 2001 db8 abcd 48 the special catch all value or will make granian trust all hosts and effectively disable the security check free threaded python warning free threaded python support is still experimental and highly discouraged in production environments since version 2 0 granian supports free threaded python while the installation process remains the same as wheels for the free threaded version are published separately here we list some key differences from the gil version workers are threads instead of separated processes so there will always be a single python interpreter running the application is thus loaded a single time and shared between workers in asynchronous protocols like asgi and rsgi each worker runs its own asyncio event loop like the gil version but the loop will run in the worker thread instead of the python main thread note if for any reason the gil gets enabled on the free threaded build granian will refuse to start this means you can t use the free threaded build on gil enabled interpreters while for asynchronous protocols nothing really changes in terms of workers and threads configuration as the scaling will be still driven by the number of asyncio event loops running so the same rules for gil workers apply on synchronous protocols like wsgi every gil related limitation is theoretically absent while the general rules in terms of i o bound vs cpu bound load still apply at the time being there s not enough data to make suggestions in terms of workers and threads tuning in the free threaded python land and thus you will need to experiment with those values depending on your specific workload customising granian running granian directly from python instead of its cli gives you access to some customization interfaces that let you alter its standard behaviour asyncio event loop initialization as soon as you run granian directly from python instead of its cli you can customise the default event loop initialisation policy by overwriting the auto policy let s say for instance you want to use the selector event loop on windows import asyncio from granian import granian loops loops register auto def build_loop asyncio set_event_loop_policy asyncio windowsselectoreventlooppolicy return asyncio new_event_loop granian serve hooks granian provides hooks re...