Windows Server 2025 chạy tốt hơn trên ARM

• Trong so sánh Windows Server 2025 được ảo hóa, cấu hình guest ARM64 trên host ARM64 hoạt động ổn định, đồng thời cho cảm nhận phản hồi nhanh hơn ở khởi động dịch vụ, chạy console quản trị và xử lý các tác vụ thực hành
• Hai VM được cấu hình giống nhau về bộ nhớ, bộ xử lý ảo và vai trò cài đặt; trong đo đạc, hệ thống Snapdragon có biên độ dao động mức sử dụng CPU nhỏ hơn, duy trì Processor Queue Length ở mức 0 và ghi nhận giá trị CPU Wait Time Per Dispatch ổn định
• Trong các phép đo lặp lại với IIS, DNS, truy vấn Active Directory, xác thực miền và file I/O, Snapdragon X Elite gần như luôn cho ra thời gian có thể tái hiện được; Intel đôi lúc nhanh hơn ở một số lần chạy nhưng nhìn chung độ biến thiên lớn hơn
• Tác giả không quy toàn bộ khác biệt cho riêng kiến trúc CPU; cùng với đặc tính của lưu trữ, bộ nhớ, quản lý điện năng và nhiệt, độ nhất quán của độ trễ và khả năng lập lịch có thể dự đoán được mới là yếu tố quan trọng hơn với tải máy chủ ảo hóa
• Với workload đặt nặng thông lượng tối đa, x64 vẫn còn lợi thế, nhưng trong các triển khai Windows Server điển hình có nhiều tác vụ nhỏ nhạy cảm với độ trễ, sức hấp dẫn của ARM64 tăng lên; tuy vậy, nền tảng tiêu chuẩn cho đào tạo vẫn giữ x64 do ARM64 chưa hỗ trợ ảo hóa lồng nhau

---

Môi trường thử nghiệm và tiêu chí so sánh

• So sánh được thực hiện bằng cách dựng môi trường Windows Server 2025 ảo hóa trên hai hệ thống riêng biệt
  • Hệ thống Intel Core i9 thế hệ 14 chạy Windows 11, vận hành nhiều máy ảo Hyper-V
  • Hệ thống Snapdragon X Elite chạy Windows 11 on ARM cũng được cấu hình với cùng môi trường Windows Server 2025
• Do Microsoft chưa cung cấp ISO cài đặt chính thức cho Windows Server 2025 ARM trên website, bản cài đặt được tạo bằng UUP dump từ image dựa trên máy chủ cập nhật của Microsoft
• Hai VM Hyper-V được thiết lập giống nhau về bộ nhớ, bộ xử lý ảo và vai trò cài đặt
  • Snapdragon X Elite: ARM64 guest on ARM64 host
  • Intel Core i9: x64 guest on x64 host

Quan sát ban đầu và phạm vi diễn giải

• Môi trường Windows Server 2025 trên hệ thống ARM hoạt động ổn định, bình thường, và cho cảm giác nhanh hơn tổng thể ở mức có thể dùng thực tế
  • Khởi động dịch vụ nhanh hơn
  • Mở console quản trị nhanh hơn
  • Rút ngắn thời gian thực hiện các tác vụ thực hành để viết giáo trình
• Tuy vậy, tác giả không khẳng định chênh lệch hiệu năng là kết quả chỉ của riêng kiến trúc CPU
  • Lưu trữ, bộ nhớ, quản lý điện năng và đặc tính nhiệt cũng có thể ảnh hưởng đến kết quả
  • Thay vì kết luận “ARM nhanh hơn”, cần diễn giải theo đặc tính của toàn bộ hệ thống
• Tải dịch vụ điển hình của Windows Server có xu hướng nặng về thread, tập trung vào các tác vụ CPU và I/O nhỏ nhưng thường xuyên
  • Bao gồm Active Directory, DNS, DHCP, IIS, dịch vụ file SMB/NFS/DFS, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS, v.v.
  • Nhóm tác vụ này nhạy với độ trễ và chuyển ngữ cảnh, nên hiệu năng ổn định liên tục mang lại lợi ích rõ rệt

Quan sát về khác biệt hiệu năng

• Hệ thống ARM dòng Snapdragon có xu hướng mang lại hiệu năng duy trì và ổn định hơn là theo đuổi xung boost cực cao
• CPU Intel hiện đại có thể đạt hiệu năng đỉnh cao hơn nhờ tăng tốc tần số và throttling động
  • Đổi lại, dưới tải kéo dài hoặc tải hỗn hợp, độ biến thiên trong lập lịch và độ trễ có thể tăng lên
• Trong môi trường ảo hóa, mức biến thiên này trở nên quan trọng hơn
  • Hypervisor như Hyper-V về thực chất đóng vai trò bộ lập lịch phần cứng
  • Thời điểm thực thi ở phần cứng càng dễ dự đoán thì việc lập lịch của hypervisor càng cho kết quả ổn định hơn
  • Hiệu ứng đó được phản ánh vào VM và độ phản hồi của các dịch vụ bên trong VM
• Tác giả cũng nhắc đến khả năng có khác biệt ngay trong bản build Windows Server ARM64
  • Dựa trên nhiều release note tìm thấy trực tuyến, bản ARM64 có thể tránh được một số lớp tương thích legacy và sử dụng binary hiện đại, được tối ưu hơn
  • Có quan sát rằng đây có thể là một bản build gọn gàng hơn so với x64
  • Tuy nhiên không có thêm bằng chứng cụ thể về triển khai nội bộ

Đo đạc bằng Performance Monitor

• Trên hai host Windows 11, tác giả thêm các bộ đếm Performance Monitor để đo
  • \\Processor(_Total)\\% Processor Time
    • Mức sử dụng CPU trên toàn bộ lõi
  • \\System\\Processor Queue Length
    • Số thread đang chờ thời gian CPU
    • Trong trạng thái tối ưu, nên duy trì ở 0
  • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
    • Thời gian trung bình mà bộ xử lý ảo phải chờ trước khi được lên lịch trên CPU
• Sau đó tạo tải bên trong từng VM bằng PowerShell và quan sát kết quả
  • Chạy 8 vòng lặp vô hạn, mỗi vòng lặp truy vấn lặp lại 5 tiến trình đứng đầu sau khi sắp xếp kết quả Get-Process theo mức sử dụng CPU
• Kết quả đo cho thấy Snapdragon có mẫu hiệu năng bền vững và ổn định
  • Biên độ dao động của % Processor Time nhỏ hơn nhiều
  • Processor Queue Length duy trì ở 0
  • CPU Wait Time Per Dispatch cũng giữ mức phẳng và nhất quán
• Trên hệ thống Intel, độ biến thiên do boost/throttle phản ánh rõ trong các chỉ số
  • Biên độ % Processor Time lớn hơn
  • Processor Queue Length tăng vọt theo chu kỳ
  • CPU Wait Time Per Dispatch cũng xuất hiện biến động đáng kể

Đo độ phản hồi của dịch vụ

• Trong PowerShell của từng VM, tác giả dùng Measure-Command để đo thời gian các tác vụ dịch vụ phổ biến
• Thực hiện bài test với web server IIS
  • Lặp 1000 lần lệnh Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null
• Các dịch vụ khác cũng được đo lặp lại theo cách tương tự
  • DNS
    • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
  • Truy vấn Active Directory
    • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
  • Độ trễ xác thực miền
    • Test-ComputerSecureChannel -Verbose:$false
  • File I/O
    • Tạo thư mục C:\TestFiles
    • Lặp 2000 lần thao tác tạo file, ghi nội dung, đọc và xóa file
• Qua nhiều lần chạy, hệ thống Snapdragon gần như lần nào cũng cho ra thời gian nhất quán và có thể tái hiện
• Hệ thống Intel có độ chênh lệch kết quả lớn hơn
  • Một số lần chạy thậm chí nhanh hơn Snapdragon
  • Nhưng trong đa số trường hợp lại chậm hơn
• Kết luận tổng thể là Snapdragon vượt trội trong mọi bài test

Kết luận chính

• Yếu tố chung xuyên suốt các kết quả là độ nhất quán của độ trễ
• Tải Windows Server ảo hóa đòi hỏi cao ở phản hồi nhanh với các tác vụ nhỏ nhưng thường xuyên và lập lịch có thể dự đoán được
• Với workload mà thông lượng tối đa là yếu tố quan trọng nhất, hệ thống x64 vẫn có lợi thế rõ ràng
• Ngược lại, trong môi trường như triển khai Windows Server điển hình, nơi nhiều tác vụ nhỏ nhạy cảm với độ trễ cùng chạy dưới ảo hóa, thì độ nhất quán quan trọng hơn tốc độ đỉnh thuần túy
• Trong bối cảnh đó, ARM64 trở nên hấp dẫn hơn
• ARM64 đã được dùng rộng rãi trong môi trường cloud, và tác giả cũng nhắc rằng tỷ lệ hiệu năng trên chi phí của nó tốt hơn x64
• Tác giả cho rằng Microsoft cần cân nhắc tăng tỷ trọng ARM64 trong tương lai của Windows Server
  • Hiện tại Microsoft vẫn chưa hỗ trợ đầy đủ Windows Server on ARM64
  • Tuy nhiên, có số liệu cho biết 33% máy ảo Azure mới trong năm qua là ARM64, còn ở Amazon AWS là 50%

Lựa chọn nền tảng tiêu chuẩn cho đào tạo

• Môi trường thực hành cho giáo trình vẫn tiếp tục chuẩn hóa trên x64
• Lý do là cấu hình bài thực hành có bao gồm ảo hóa lồng nhau
• Do Hyper-V chưa hỗ trợ ảo hóa lồng nhau trên ARM64, ARM64 hiện chưa thể được chọn làm môi trường mặc định cho đào tạo
• Học viên vẫn có thể tự điều chỉnh cấu hình để vượt qua giới hạn này, nhưng một trong các mục tiêu của giáo trình là tính tái hiện, nên ưu tiên môi trường có thể hoạt động giống nhau theo từng bước
• Ở thời điểm hiện tại, với mục đích đào tạo, x64 vẫn là lựa chọn thực tế hơn

[GN⁺]

Ý kiến trên Hacker News

• Họ đã công khai đầy đủ cấu hình, giả định, thậm chí cả mã cần để tái hiện thử nghiệm, nhưng lại thiếu chính kết quả cảm nhận thực tế, nên tôi hơi nghi ngờ. Tôi muốn biết cụ thể ARM thực sự nhanh hơn bao nhiêu
  • Có lý do tôi cố ý bỏ phần ảnh chụp màn hình đầu ra. Tôi muốn tránh để bài viết bị biến thành một bài benchmark, và tôi nghĩ kết quả có thể thay đổi tùy phần cứng ARM hoặc từng mẫu Snapdragon X Elite cụ thể, dễ gây hiểu lầm. Thay vào đó, tôi đưa vào snippet PowerShell để bất kỳ ai cũng có thể tự tái hiện. Kết quả sơ bộ là VM Snapdragon nhanh hơn VM Intel khoảng 20~80% tùy bài test, với DNS khoảng 20%, IIS khoảng 50%, còn lại phần lớn gần 80%
• Nếu nhìn từ góc độ lập trình viên Windows, khả năng cao đây là tác động của segment heap. Trong triển khai heap của Windows có hai dòng độc lập là NT heap cũ và segment heap từ thập niên 2010, trong đó segment heap hiệu quả hơn về phân mảnh bộ nhớ và tái sử dụng các vùng cấp phát nhỏ. Tuy vậy, Windows cực kỳ coi trọng tính tương thích ngược, nên họ không chuyển đồng loạt mặc định vì ứng dụng cũ có thể phụ thuộc vào các hành vi nguy hiểm như use-after-free hoặc cả cấu trúc nội bộ của NT heap. Vì vậy họ chọn phương án dung hòa: mặc định dùng segment heap cho các executable dạng packaged, còn unpackaged thì giữ nguyên. Nhưng khi quá trình chuyển sang UWP thất bại, hệ sinh thái Windows lại bị chia cắt hơn nữa, và phần lớn phần mềm quan trọng vẫn ở dạng x64 unpackaged. Trong khi đó, binary arm64 ít có khả năng là mã legacy cũ, nên trên arm segment heap được bật mặc định. Tôi nghĩ đây là một phần không nhỏ lý do khiến người dùng cảm thấy Windows trên arm phản hồi tốt hơn. Sẽ rất thú vị nếu ép bật segment heap trên x64 rồi chạy lại bài test này. Theo từng executable, có thể đặt DWORD FrontEndHeapDebugOptions thành 8 dưới HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe, còn toàn cục thì đặt DWORD Enabled thành 3 dưới HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap. Trên máy dev của tôi, sau khi bật toàn cục tôi chưa thấy vấn đề gì, và mức dùng bộ nhớ giảm khoảng 15% theo bài test
  • Với workload nặng RAM/CPU của tôi, Segment Heap luôn cho hiệu năng tổng thể tốt hơn khoảng 7% so với NT Heap. Toàn bộ công việc gộp lại hoàn thành nhanh hơn 7%. Nếu những chứng nhận kiểu "Compatible with Windows XXX" ngày xưa vẫn còn tồn tại trên Windows 10/11, có lẽ nên thêm mục kiểm tra segment heap vào đó để đem lại lợi ích về hiệu năng, hiệu quả điện năng và môi trường cho nhiều ứng dụng lẫn người dùng hơn. Và vấn đề của UWP, theo tôi, không phải ở công nghệ mà ở việc cứ khăng khăng gắn nó với packaging và Store, điều này xung đột với chính cách một hệ điều hành như Windows tồn tại
  • Nếu ai quan tâm, có thể opt-in hành vi này bằng cách đặt heapType thành SegmentHeap trong application manifest của executable. Tài liệu có giải thích
  • Chính những mẹo thực chiến như thế này mới là giá trị của HN. Tôi tò mò không biết khóa registry toàn cục có cần khởi động lại không, hay nó có hiệu lực ngay từ lúc executable bắt đầu chạy
  • Nội dung này thú vị ở mức nên được lưu lại thành một bài blog hơn là chỉ là bình luận trên diễn đàn
  • Trước đây tôi từng thấy thiết lập toàn cục này được giải thích theo kiểu 0 so với non-zero, nên tôi thắc mắc vì sao giá trị lại là 3. Không biết 2 có ý nghĩa gì, và có thể tự tra ý nghĩa các giá trị kiểu này ở đâu
• Cách bài viết nói "ARM không chạy theo boost clock cao mà cho hiệu năng ổn định" nghe hơi cường điệu. Mọi hệ thống ARM tôi từng dùng đều có frequency scaling, và ở điểm đó chúng hoạt động khá giống x86. Cuối cùng khác biệt có lẽ chỉ là chúng tăng lên cao đến mức nào
  • Dù còn tùy workload, nhưng trong môi trường cloud ở nhiều tổ chức tôi từng làm việc, chỉ riêng việc chuyển sang ARM từ x86 cũng đã tiết kiệm chi phí khá đáng kể. Giá instance thấp hơn, mà hiệu quả cũng tốt hơn. Đặc biệt ở một tổ chức có môi trường tự động scale động hàng trăm node Kubernetes, chỉ cần chuyển x86 -> ARM mà không thay đổi gì thêm cũng đã dự đoán thận trọng là tiết kiệm khoảng 15%, và thực tế đạt được đúng mức đó. Nếu workload bị giới hạn bởi CPU và ít phụ thuộc vào tính năng đặc thù của x86, con số còn có thể lớn hơn nhiều so với 15%
• Nếu điểm mấu chốt là hiệu năng của CPU ARM ít dao động hơn và dễ dự đoán hơn, thì dùng CPU server như Epyc thay vì CPU desktop cũng có thể mang lại lợi ích tương tự. CPU server có biên độ thay đổi xung nhịp nhỏ hơn và chính sách boost cũng bớt hung hăng hơn. Ngay cả với phần cứng desktop hiện có, bạn cũng có thể tắt Turbo trong BIOS để cố định CPU Intel ở xung cơ bản, từ đó tạo ra hiệu năng thấp hơn nhưng ổn định và dễ dự đoán hơn để so sánh
  • Trong power plan cũng có thể tắt hành vi turbo. Chỉ là tùy trường hợp, tùy chọn đó có thể không hiện sẵn trong GUI
• Tôi tò mò liệu Windows on ARM có dùng VBS hay Virtualization Based Security không, và trong VM thì có hỗ trợ nested virtualization để dùng nó không. Ngoài ra cũng đáng quan tâm là liệu các biện pháp giảm thiểu lỗ hổng CPU có bị áp hai lần trong VM, từ đó ảnh hưởng đến hiệu năng hay không. Phần lớn các vấn đề hiệu năng thường gặp khi chạy Windows trong VM dạo gần đây đến từ đây. Nhưng tiếc là bài viết không nhắc đến phần này
• Tôi muốn biết cấu hình RAM và storage của hai hệ thống. Bên Snapdragon có thể dùng RAM dạng package nên interconnect nhanh hơn, còn bên x86 là DIMM nên đường trace có thể dài hơn. Storage hay model CPU cũng có thể ảnh hưởng lớn đến chênh lệch hiệu năng. Benchmark thường kích thích quá mức một phần của hệ thống, nên tôi nghĩ khác biệt thật sự có thể đến từ RAM, syscall, SSD hay yếu tố khác chứ không hẳn là kiến trúc ARM
  • Cả hai hệ thống đều dùng DDR5 hàn trên mainboard và SSD NVMe. Thậm chí SSD bên Intel còn là mẫu Samsung nhanh hơn so với Foresee bên Snapdragon
• Trên Linux thì mọi thứ chạy tốt hơn hết, và không lãng phí chu kỳ vào overhead giám sát
• Bài viết có vẻ như cố tình né không nói rõ bộ xử lý Intel là gì, nên tôi tự hỏi có phải mình đã bỏ sót gì không
  • CPU dùng là Intel Core i9 thế hệ 14
• Trên máy chủ HV, người ta thường tắt C States, đặt power management ở mức high để ngăn x86 bị hạ xung. Nếu ngăn CPU dao động lên xuống, hiệu năng có thể cải thiện khá nhiều. Nhưng thường thì những việc này không được làm trên thiết bị cá nhân hay thiết bị phòng lab
  • Hoặc đơn giản là chỉ cần tắt turbo boost
• Đọc xong tôi thấy có hai ý chính. Thứ nhất, ARM64 kém “thông minh” hơn x64, nên thay vì lặp lại việc boost và throttling hung hăng như Core i9, nó cho ra hiệu năng ổn định hơn, nhờ đó việc scheduling của OS trở nên dễ hơn. Thứ hai, Windows trên ARM có ít gánh nặng lịch sử hơn x64, nên bản build ARM tự thân có thể đã hiệu quả hơn. Rốt cuộc tôi tự hỏi liệu CPU throttling có đang trở nên quá thông minh đến mức phản tác dụng hay không
  • Tuy vậy cũng cần nhìn đây là trường hợp thử server OS trên CPU x86 desktop. Các CPU server x86 như AMD Epyc hay Intel Xeon có dải thay đổi xung nhịp nhỏ hơn và chính sách cũng ít hung hăng hơn, nên cho hiệu năng ổn định và dễ dự đoán hơn CPU desktop. Đặc tính này có lợi cho workload đa luồng, còn CPU desktop do được tinh chỉnh cho đỉnh hiệu năng đơn luồng nên có thể lại bất lợi với đa luồng