Tìm kiếm
40 kết quả cho “P99”. Tìm không phân biệt dấu.
- Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications Bài tóm tắt · LinkedIn · 2014
…ung GC 40–60 ms mỗi khoảng ba giây, một chu kỳ CMS mỗi giờ; p99.9 còn 60 ms ở mức hàng nghìn request đọc/giây. Vì sao - Với dịch vụ Java latency thấp, GC pause là thành phần chính…
- Fixing Linux filesystem performance regressions Bài tóm tắt · LinkedIn · 2020
…mới (từ 3.10). Thay đổi chính - Sự cố: gần xong thì dừng vì p99 của một ứng dụng phục vụ tăng mạnh mỗi khi một ứng dụng khác deploy trên cùng máy; chỉ xảy ra trên image mới. Rollba…
- Deploying Large-scale Fraud Detection Machine Learning Models at PayPal Bài tóm tắt · PayPal · 2021
…ham gia ra quyết định : điểm chỉ được ghi lại. Từ đó đọc ra P99 thời gian chạy model, thời gian nạp dữ liệu, phân phối điểm. - Hai chế độ: Test (đóng gói, deploy, audit lặp lại) và…
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Benchmarking databases for Global App Bài tóm tắt · Mercari · 2025
…, 50/50). - Kết quả (2025, theo Mercari): AlloyDB có p50 và p99 thấp nhất và throughput cao nhất ở mọi workload (ví dụ 80/20: đọc khoảng 82.800 ops, p99 5,2 ms; Spanner khoảng 13.1…
- Our not-so-magic journey scaling low latency, multi-region services on AWS Bài tóm tắt · Atlassian · 2019
…scale), ELB hết bộ nhớ. Chuyển sang một ALB cố định, nhưng p99 tăng từ ~7–10ms lên 20ms vì ALB dùng round robin thay vì "ít kết nối nhất". 3. "Cache không phải phép màu": Guava ca…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- Migration from HBase to MyRocks at Quora Bài tóm tắt · Quora · 2021
…au. - HBase được truy cập từ Python và C++ (qua Thrift) với p99 rất "giật". - Lý do chuyển sang MyRocks (MySQL + RocksDB): ngắn hạn là p99 đọc tốt hơn, ít timeout hơn; dài hạn là g…
- The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds Bài tóm tắt · Twitter · 2013
…iệu lần chèn; giao hàng p50 tới 1 triệu người mất 3,5 giây, p99 tới 5 phút . Hệ quả: reply tới trước tweet gốc, người follow sau thấy tweet trước người follow lâu, race condition k…
- How Uber Scaled Data Replication to Move Petabytes Every Day Bài tóm tắt · Uber · 2026
…374.000, tồn đọng lớn, khó giữ SLA độ trễ P100 4 giờ và SLO P99.9 20 phút. Chuyển lake lên cloud được dự báo gần gấp đôi tải nữa. Thay đổi chính - Dời việc chuẩn bị sang Applicatio…
- The Art of Being Lazy(log): Lower Latency and Higher Availability With Delayed Sequencing Bài tóm tắt · WarpStream · 2026
…ào. Đổi lại là latency: PUT object storage mất vài trăm ms, p99 produce mặc định khoảng 400 ms ; với S3 Express One Zone (S3EOZ) xuống median 105 ms, p99 170 ms. - Một produce đi b…
- Enhancing Performance in Microservice Architecture with Kitex Bài tóm tắt · ByteDance · 2024
…DS thay TCP nhanh hơn chút ít (benchmark: avg 127 → 118 µs, p99 232 → 205 µs phía client). ShmIPC : bộ nhớ chia sẻ làm kênh dữ liệu, UDS làm kênh báo sự kiện. - Biến gọi khác máy t…
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…ù: lệch có thể tồn tại mãi. Kết quả (theo Cloudflare, 2025) p99 latency nội bộ khi đọc qua KVSP dưới 5 ms, so với khoảng 80 ms p50 và 200 ms p99 khi đọc object store bên thứ ba (đã…
- How Discord Stores Trillions of Messages Bài tóm tắt · Discord · 2023
…ScyllaDB --- --- --- Số node 177 72 Đĩa mỗi node ~4 TB 9 TB p99 đọc tin lịch sử 40–125ms ~15ms p99 ghi tin 5–70ms ~5ms Chung kết World Cup 2022 tạo các đỉnh traffic theo từng bàn t…
- FollowFeed: LinkedIn's Feed Made Faster and Smarter Bài tóm tắt · LinkedIn · 2016
…i quy, nhanh hơn thư viện chấm điểm cũ 15 lần (khoảng 50 µs p99 mỗi bản ghi cho feed mobile). - Ingest bất đồng bộ qua Kafka: service Partitioner đọc stream mọi nội dung rồi ghi lạ…
- Making the LinkedIn experimentation engine 20x faster Bài tóm tắt · LinkedIn · 2020
…23 nghìn tỷ lượt evaluate/ngày , latency trung bình 700 ns (p99 3 µs), dùng trong khoảng 500 service production. - Lix Engine là thư viện chạy trong service, hiểu một DSL kiểu Lisp…
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…hơn 28–40%. Kết quả (2023) - Hit rate khoảng 99%; multi-get p99 từ 31,6 ms xuống 12,41 ms (−60,7%), p99.9 −63,7%. - Số storage node Espresso giảm 90%; trừ chi phí hạ tầng mới và CP…
- Timestone: Netflix's High-Throughput, Low-Latency Priority Queueing System Bài tóm tắt · Netflix · 2022
…tự khoá hay phối hợp. - Quy mô (2022): 30.000 dequeue/giây (p99 45 ms), 1.200 enqueue/giây (p99 25 ms), đỉnh 5.000 enqueue/giây; 15 tỉ message từ đầu năm, bị dequeue 400 tỉ lần; th…
- Building a dynamic and responsive Pinterest Bài tóm tắt · Pinterest · 2018
…hẹ; - Aperture : lịch sử impression của user tới vài tháng, p99 một chữ số ms; - RealPin : tín hiệu realtime của user; - Scorpion : nền tảng xếp hạng ML online thống nhất, tách com…
- Quora Công ty Thành viên
Quora dùng MySQL (tự shard), HBase và Redis trên AWS. Năm 2016 họ diễn tập thảm hoạ (Game Day): dựng lại cả site ở region khác chỉ từ backup, mất chưa tới 5 giờ . Về sau họ chuyển HBase sang MyRocks để dùng chung kiến…
- Building a New Rust Driver for ScyllaDB's DynamoDB API – with 58% More Throughput Bài tóm tắt · ScyllaDB · 2026
…ải. SDK AWS tăng latency mạnh, driver mới giữ thấp, nhất là p99. - Hot partition với LWT (99% request vào 10% key của một nhóm nhỏ partition): round-robin tệ hơn cả SDK AWS vì rải…
- New Tweets per second record, and how! Bài tóm tắt · Twitter · 2013
…tích hợp sẵn trong Finagle; một dòng code là có metric p50/p99. - Runtime config: hệ thống Decider bật/tắt tính năng đồng loạt trên nhiều service, cho phép theo % traffic. Code de…
- Accelerating Search and Ingestion with High-Performance gRPC in OpenSearch Bài tóm tắt · Uber · 2026
…uction, theo Uber: M3 (hệ metric nội bộ) ghi qua Bulk gRPC: p99 34,1 → 13,6 ms (−60%), p50 15,8 → 10,5 ms; độ trễ index tối đa của M3 −20–35% (quan trọng lúc failover); job Spark n…
- Benchmarking Streaming Computation Engines at Yahoo! Bài tóm tắt · Yahoo · 2015
…yến tính, latency dưới giây ở thông lượng khá cao; Storm có p99 thấp nhất. Flink ổn định từ 50.000 tới 170.000 event/giây, latency tăng vọt sau p99. - Spark Streaming (micro-batch)…