Tìm kiếm
40 kết quả cho “Hiệu năng”. Tìm không phân biệt dấu.
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- An AKS Performance Journey: Part 1 — Sizing Everything Up Bài tóm tắt · ASOS · 2021
…t bằng NodeJS: phục vụ mọi trang danh mục, tìm kiếm, thương hiệu; tải cao thứ hai trong các ứng dụng front-end, hàng trăm QPS , phải co giãn theo đỉnh như Black Friday. - Từ test h…
- How We Improved Website Performance by Evolving Our Infrastructure Bài tóm tắt · Wix · 2021
…r-infrastructure) Bối cảnh - Wix phục vụ hàng triệu site , nhiều site làm từ lâu và không ai sửa nữa; là môi trường quản lý nên phần lớn hiệu năng nằm trong tay nền tảng chứ không…
- An AKS Performance Journey: Part 2 — Networking It Out Bài tóm tắt · ASOS · 2021
…hơn Cloud Services khoảng 100 ms ở percentile cao. Log có nhiều timeout gọi API, kèm lỗi getaddrinfo EAI AGAIN từ NodeJS và các lần chờ đúng 5 giây . Thay đổi chính - Race của con…
- Dismissing Python Garbage Collection at Instagram Bài tóm tắt · Instagram · 2017
…của CPython là reference counting; GC chỉ để phá vòng tham chiếu. - Lợi ích đến từ hai phía: (a) thêm RAM để chạy thêm worker; (b) IPC của CPU tăng ~10% vì cache-miss giảm 2–3% (nh…
- 1 million is so 2011 Bài tóm tắt · WhatsApp · 2012
…giới hạn thật. Phần lớn giới hạn mặc định của OS thấp hơn nhiều so với khả năng phần cứng. - Chọn runtime theo bài toán: kết nối dài, nhiều, ít tính toán là đúng sở trường của BEA…
- Why Discord is switching from Go to Rust Bài tóm tắt · Discord · 2020
…ải quét toàn bộ LRU cache để xác định cái gì còn được tham chiếu. - Vá tạm trong Go: chia nhỏ LRU cache thì spike nhỏ hơn, nhưng p99 tăng vì cache miss nhiều hơn. Họ chọn một điểm…
- How We Upgrade Kubernetes on GKE Bài tóm tắt · Gojek · 2020
…ý ; team Engineering Platform của Gojek phải theo kịp trên nhiều cụm GKE. - Cụm tạo bằng Terraform + GitOps : module tạo cụm trong repo riêng, plan và apply chạy trong CI. Thay đổi…
- Follow Up - Preventing Upgrade Failures from etcd v3.5 to v3.6 Bài tóm tắt · etcd (CNCF) · 2025
…h etcd chỉ cho phép tối đa một learner (thành viên chưa bỏ phiếu); bootstrap thất bại nếu có từ hai learner trở lên. Sự cố, lần 1 - Từ v3.5.1 (một thay đổi năm 2021) tới v3.5.19, k…
- Moving Velo to Multiple Container Sites: The Why, The How and The Lessons Learned Bài tóm tắt · Wix · 2021
…Khách lớn xuất hiện thì cần chạy backend của một site trên nhiều container. - Lưới tính toán cũ chạy Docker container không có orchestrator cấp cao, nên Wix phải tự viết cơ chế điề…
- Quantifying infrastructure noise in agentic coding evals Bài tóm tắt · Anthropic · 2026
…một môi trường để viết code, chạy test, cài dependency qua nhiều lượt; runtime không còn là container thụ động mà là một phần của bài toán. Bảng xếp hạng thường cách nhau vài điểm…
- Embedded SRE at Mercari Bài tóm tắt · Mercari · 2022
…) Bài của engineering manager team Microservices SRE, giới thiệu mô hình; bài kể từ góc nhìn một SRE nhúng là . Mọi nhận định là theo Mercari. Bối cảnh - Chuyển từ team ops tập tru…
- 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,…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Navigating the Spark 3 and EMR 6 Upgrade Journey at Slack Bài tóm tắt · Slack · 2024
…SLA (gồm dữ liệu billing và usage của khách). - Lý do nâng: hiệu năng (Adaptive Query Execution cho dataset lệch), bảo mật (log4j mới), chi phí. Thay đổi chính - Dự án một năm, hai…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- 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.
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- 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…
- Upgrading a 56TB database that's growing at 250GB per day with (nearly) no downtime Bài tóm tắt · Trigger.dev · 2026
…hông có giờ thấp điểm (chạy background job của người khác, nhiều múi giờ); một run có thể kéo dài nhiều tháng; khách mất doanh thu nếu downtime. - Bắt buộc nâng cấp Postgres 14.15…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Đổ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.
- Rest.li 2.x and a Protocol Upgrade Story Bài tóm tắt · LinkedIn · 2015
…/chuỗi rỗng) và không tương thích ngược với 1.0. Server mới hiểu cả hai, client mới gửi 2.0 tới server cũ thì hỏng. Đồ thị gọi gồm hàng chục service. Thay đổi chính - Handshake qua…
- 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…
- Độ 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:
- 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.
- 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".
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- 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:
- 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:
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- 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ả…
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…