encoding
Nginx
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
encoding
- Handling high-traffic HTTP requests with JSON payloads
-
Rust vs. Go in 2023
https://github.com/BurntSushi/rebar#summary-of-search-time-b...
Further, Go refusing to have macros means that many libraries use reflection instead, which often makes those parts of the Go program perform no better than Python and in some cases worse. Rust can just generate all of that at compile time with macros, and optimize them with LLVM like any other code. Some Go libraries go to enormous lengths to reduce reflection overhead, but that's hard to justify for most things, and hard to maintain even once done. The legendary https://github.com/segmentio/encoding seems to be abandoned now and progress on Go JSON in general seems to have died with https://github.com/go-json-experiment/json .
Many people claiming their projects are IO-bound are just assuming that's the case because most of the time is spent in their input reader. If they actually measured they'd see it's not even saturating a 100Mbps link, let alone 1-100Gbps, so by definition it is not IO-bound. Even if they didn't need more throughput than that, they still could have put those cycles to better use or at worst saved energy. Isn't that what people like to say about Go vs Python, that Go saves energy? Sure, but it still burns a lot more energy than it would if it had macros.
Rust can use state-of-the-art memory allocators like mimalloc, while Go is still stuck on an old fork of tcmalloc, and not just tcmalloc in its original C, but transpiled to Go so it optimizes much less than LLVM would optimize it. (Many people benchmarking them forget to even try substitute allocators in Rust, so they're actually underestimating just how much faster Rust is)
Finally, even Go Generics have failed to improve performance, and in many cases can make it unimaginably worse through -- I kid you not -- global lock contention hidden behind innocent type assertion syntax: https://planetscale.com/blog/generics-can-make-your-go-code-...
It's not even close. There are many reasons Go is a lot slower than Rust and many of them are likely to remain forever. Most of them have not seen meaningful progress in a decade or more. The GC has improved, which is great, but that's not even a factor on the Rust side.
-
Quickly checking that a string belongs to a small set
We took a similar approach in our JSON decoder. We needed to support sets (JSON object keys) that aren't necessarily known until runtime, and strings that are up to 16 bytes in length.
We got better performance with a linear scan and SIMD matching than with a hash table or a perfect hashing scheme.
See https://github.com/segmentio/asm/pull/57 (AMD64) and https://github.com/segmentio/asm/pull/65 (ARM64). Here's how it's used in the JSON decoder: https://github.com/segmentio/encoding/pull/101
-
80x improvements in caching by moving from JSON to gob
Binary formats work well for some cases but JSON is often unavoidable since it is so widely used for APIs. However, you can make it faster in golang with this https://github.com/segmentio/encoding.
-
Speeding up Go's builtin JSON encoder up to 55% for large arrays of objects
Would love to see results from incorporating https://github.com/segmentio/encoding/tree/master/json!
-
Fastest JSON parser for large (~888kB) API response?
Try this one out https://github.com/segmentio/encoding it's always worked well for me
-
📖 Go Fiber by Examples: Delving into built-in functions
Converts any interface or string to JSON using the segmentio/encoding package. Also, the JSON method sets the content header to application/json.
-
In-memory caching solutions
If you're interested in super fast & easy JSON for that cache give this a try I've used it in prod & never had a problem.
Nginx
-
Nginx 1.26.0 Stable Released
Yeah, unless I'm looking at it wrong, there doesn't seem to be any meaningful difference between 1.25.5 and 1.26.0:
https://github.com/nginx/nginx/compare/release-1.25.5...rele...
-
How to securely reverse-proxy ASP.NET Core web apps
However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:
- Ask HN: Is nginx.org (the domain-name itself) gone?
-
Freenginx: Core Nginx Developer Announces Fork of Popular Web Server
> I actually don't understand why I am seeing arguments like this all the time.
Have a look at:
https://github.com/nginx/nginx/blob/master/src/http/modules/...
It's got the whole checklist: nginx idiosyncratic module system, inline parsing, custom utf conversion, buffer preallocation and adjustments, linked lists, comments about side effects of custom allocator, and probably other things.
It's not easy to deal with source like that and any serious improvement to that area would effectively be a rewrite anyway.
Since anything doing work in nginx is a module anyway, it wouldn't even have to be a full rewrite in one go.
-
The Internet is Maintained by 1 Software Developer
According to this article, nGinx is being used to serve 34% of all websites in the world. I checked out who's contributing to nGinx, and just like I thought, the project has 8,208 commits, and 5,366 of those commits was made by 2 software developers; igorsoev and mdounin.
- [06/52] Accessible Kubernetes with Terraform and DigitalOcean
- Freenginx.org
-
Performance benchmark of PHP runtimes
Nginx + Roadrunner (fcgi mode)
-
Web CGI programs aren't particularly slow these days
Apache’s mod_fastcgi’s last commit was 2 weeks ago:
https://svn.apache.org/viewvc/httpd/httpd/trunk/
It’s a fork of what you linked (and was more popular afaik back when fastcgi was state of the art, and apache was the undisputed champion of web servers).
These days, nginx has more market share than apache, and its fastcgi module is one of the more recently updated ones in its source tree (5 months vs multiple years):
https://github.com/nginx/nginx/tree/master/src/http/modules
If I was going to build an embedded web server, I’d start with nostd rust, probably with though axum + tokio, since thats already memory safe-ish.
If I needed fastcgi for some reason (dynamically loadable endpoints, or os-level isolation), there are at least four implementations of fastcgi for it. No idea if any are decent though.
-
Five Apache projects you probably didn't know about
APISIX is an API Gateway. It builds upon OpenResty, a Lua layer built on top of the famous nginx reverse-proxy. APISIX adds abstractions to the mix, e.g., Route, Service, Upstream, and offers a plugin-based architecture.
What are some alternatives?
sonic - A blazingly fast JSON serializing & deserializing library
Caddy - Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
groupcache - Clone of golang/groupcache with TTL and Item Removal support
envoy - Cloud-native high-performance edge/middle/service proxy
parquet-go - Go library to read/write Parquet files
Squid - Squid Web Proxy Cache
base64 - Faster base64 encoding for Go
nestjs-monorepo-microservices-proxy - Example of how to implement a Nestjs monorepo with no shared folder
buntdb - BuntDB is an embeddable, in-memory key/value database for Go with custom indexing and geospatial support
Hiawatha - Hiawatha is an open source webserver with security, easy to use and lightweight as the three key features. Hiawatha supports among others (Fast)CGI, IPv6, URL rewriting and reverse proxy. It has security features no other webserver has, like blocking SQL injections, XSS and CSRF attacks and exploit attempts. The built-in monitoring tool makes it perfect for large scale deployments.
hilbert - Go package for mapping values to and from space-filling curves, such as Hilbert and Peano curves.
YARP - A toolkit for developing high-performance HTTP reverse proxy applications.