Оптимизация систем для экстремального масштабирования

Уровень 0 · материалов: 4

В кластер входят документы о методах достижения экстремальной масштабируемости и высокой пропускной способности систем, но не входят общие описания механизмов работы планировщиков языков программирования.

Общие признаки: высокая производительность, обработка миллионов запросов и соединений, устранение узких мест в инфраструктуре, низкоуровневая оптимизация ресурсов

Группа выше: Проектирование высоконагруженных систем

Материалы

• #33431 — Optimizing WebSocket Servers for Million Connections in Go — Представитель этого кластера

  Миллион WebSocket и Go — gobwas

  Смысл: The main idea is that while Go's idiomatic concurrency is powerful, achieving extreme scale (millions of connections) requires bypassing high-level abstractions in favor of low-level system calls (epoll), manual memory management of buffers, and strict resource pooling to avoid memory exhaustion.

  The author explains how to scale a Go WebSocket server to 3 million connections by replacing idiomatic goroutines with netpoll, implementing goroutine pools, and using zero-copy upgrades to drastically reduce memory consumption.

• #25124 — Scaling Ozon Tech's Product-Facade to 1 Million RPS

  Как департамент утилизации CPU превратился в департамент экономии железа, выдерживающий нагрузку в 1 млн RPS — Aconitum_napellus

  Смысл: The main idea is that achieving extreme scalability (1M+ RPS) requires a multi-layered, hybrid caching strategy and deep optimization of data serialization to prevent system collapse and minimize resource expenditure.

  Ozon Tech scaled its product-facade service to 1 million RPS by implementing a hybrid local/distributed caching system and optimizing protobuf serialization to reduce CPU overhead.

• #29796 — Handling One Million Concurrent Connections on Node.js

  Миллион одновременных соединений на Node.js — ashtuchkin

  Смысл: The text demonstrates that Node.js can support 1 million concurrent connections on modest hardware, provided that specific V8 engine flags are used to optimize garbage collection and prevent Event Loop blockage.

  Node.js v0.8 can handle 1 million concurrent connections on an i7 server with 16GB RAM, but requires disabling idle notifications to maintain server responsiveness.

• #7898 — Building Lusca: Ozon's Custom S3 Storage Server

  Свой S3-server: что делать, если ваши десятки петабайт уже не лезут в коробочные объектные хранилища — Maelstorm

  Смысл: The main idea is that at extreme scales (tens of petabytes), standard 'out-of-the-box' object storage gateways like Ceph RGW can become bottlenecks due to metadata handling; therefore, building a custom S3 server that separates the metadata index (using a distributed DB like ScyllaDB) from the physical storage (Rados) is a viable path to achieve linear scalability and improved performance.

  Ozon replaced Ceph RGW with their own S3 server, 'Lusca', using ScyllaDB for metadata to solve scaling issues with billions of objects and 60 PiB of data.