1. Trang chủ
  2. » Luận Văn - Báo Cáo

Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs

102 441 2

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 102
Dung lượng 3,17 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Ứng dụng web ngoài việc hỗ trợ Browser trên máy tính còn phát triển trên các trình duyệt với giao thức WAP.. Ứng dụng 13Instant là ứng dụng demo công nghệ Nodejs, sử dụng công nghệ Nodej

Trang 1

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trang 2

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: GS.TS NGUYỄN THANH THỦY

Hà Nội – 2014

Trang 3

LỜI CAM ĐOAN

Tôi xin cam đoan những điều sau:

- Luận văn này là do tôi thực hiện

- Những kiến thức tham khảo được tôi ghi rõ nguồn gốc và tác giả

- Tôi xin chịu trách nhiệm về nghiên cứu của mình

Hà Nội, Ngày 10 tháng 06 năm 2014

Học viên Văn Duy Đức

Trang 4

Tôi xin chân thành cảm ơn GS TS Nguyễn Thanh Thủy đã tận tình hướng dẫn cho tôi trong thời gian thực hiện luận văn Mặc dù trong quá trình thực hiện luận văn có giai đoạn không được thuận lợi nhưng những gì Thầy đã hướng dẫn, chỉ bảo đã cho tôi nhiều điều bổ ích trong thời gian thực hiện đề tài

Tôi cũng xin gửi lời cảm ơn đến tất cả các Thầy Cô đang giảng dạy tại các Khoa của Trường Đại học Công Nghệ – Đại học Quốc Gia Hà Nội (ĐHQG-HCM) đã tận tình chỉ bảo, đóng góp ý kiến để Luận văn được hoàn thiện

Hà Nội, Ngày 10tháng 06 Năm 2014

Học viên

Văn Duy Đức

Trang 5

MỞ ĐẦU

Web đóng vai trò quan trọng trong Công nghệ thông tin Web đóng vai trò kết nối người dùng Ứng dụng web được phát triển ban đầu với sự xuất hiện của HTML vào năm 1993, công bố bởi tổ chức W3C (World wide web consortium) Sau đó nhiều công nghệ web động mang đến cho người dùng và nhà phát triển trải nghiệm mới

PHP được phát triển từ năm 1999, là 1 loại Server-side scripting Tính đến nay đã áp dụng cho hơn 240 triệu trang web và 2.1 triệu máy chủ web Hiện giờ đang phát triển đến phiên bản 5.5

Ngoài PHP, Microsoft đưa ra ASP (Active server page) và ASP.NET Java thì đưa ra JSP Làm cho cộng đồng phát triển web càng thêm phong phú

Từ nhu cầu phát triển web, một kỹ thuật mới được người ta phát minh ra là Asynchronous Javascript and XML (AJAX) được chính thức công bố vào 18/02/2005 Kỹ thuật này cho phép gửi nhận dữ liệu một cách bất đồng bộ từ Client đến Web-server

Vào những năm gần đây, với sự bùng nổ của các thiết bị di động – smart phone, máy tính bảng Ứng dụng web ngoài việc hỗ trợ Browser trên máy tính còn phát triển trên các trình duyệt với giao thức WAP

NodeJS ra đời cũng nằm trong xu thế phát triển chung, NodeJS được thiết kế để xây dựng các ứng dụng Web hoặc Network nhanh, khả mở, và chạy trên nhiều thiết bị Nodejs đang được phát triển và sử dụng rộng rãi Nodejs đang ở phiên bản v0.10.28 và tính đến thời điểm này đang có 9969 revision có 524 contributor cho việc phát triển

Bài luận văn viết ra với mục đích giới thiệu về công nghệ Nodejs Phương pháp và cách làm của Nodejs khi áp dụng vào các trang web có phản ứng tức thời Sự khác biệt đó ra sao với Ajax khi mà họ sử dụng Request/response thông qua XMLHttpRequest so với Websocket của Nodejs Đồng thời giới thiệu về kiến trúc bên trong của Nodejs Hiệu năng của Nodejs so với các Application server phổ biến Ứng dụng 13Instant là ứng dụng demo công nghệ Nodejs, sử dụng công nghệ Nodejs để phát triển các tính năng đòi hỏi phản ứng tức thời trên Web như web chat, news feed, instant searching

Trang 6

Bài luận văn chia gồm 54 chương chính vớiý tưởng chủ đạo của từng chương như sau:

• Chương 1 Tổng quan về Web đáp ứng tức thời : Chương này làm rõ, giới thiệu Web đáp ứng tức thời là gì Lịch sử, các công nghệ đang sử dụng để thực hiện

• Chương 2 Nodejs : Chương này giới thiệu về Nodejs, Nodejs là gì, ý nghĩa, tácdụng Kiến trúc của Nodejs Tổ chức Module Nodejs

• Chương 3 Hiệu năng Nodejs : Chương này so sánh hiệu năng của Nodejs với cácApplication server phổ biến

• Chương 4 Ứng dụng 13Instant : Chương giới thiệu ứng dụng 13Instant Là ứngdụng áp dụng Nodejs vào để tạo ra 1 ứng dụng Web phản ứng tức thời gồm News feed và Web chat

Kết luận : Kết luận về công nghệ Nodejs, ưu điểm của Nodejs so với các nền tảng

khác Về nhỏ gọn, nhanh chóng, và dễ dàng phát triển Và đánh giá về tương lai công nghệ Nodejs

MỤC LỤC

Trang 7

DANH MỤC HÌNH VẼ

Trang 8

02 Website Hoặc được viết là web site, hoặc là site Là tập các trang

Web có liên quan đến nhau, phục vụ trong

03 WAP Wireless Application Protocol là một tiêu chuẩn kỹ thuật

cho phép truy cập thông tin qua Mạng di động

Asynchronous Javascript and XML: là một tập hợp các kỹ thuật có liên quan đến nhau trong phát triển Web để tạo ra ứng dụng Web bất đồng bộ

05 V8 V8 là 1 engine (công cụ) mã nguồn mở Javascript của

Google Viết bằng C++ và sử dụng trong Google Chrome

Trong lập trình máy tính, mẫu Thread pool (hoặc replicated workers hoặc worker-crew model) là nơi số lượng thread được tạo ra để thực hiện 1 số lượng các tác vụ

07 Libeio Là 1 thư viện đầy đủ tính năng (full-featured) I/O bất đồng

bộ cho ngôn ngữ C

Là khả năng của hệ thống, network hoặc tiến trình (process) có thể làm chủ sự tăng trưởng của công việc theo cách hợp lý hoặc là khả năng của nó có thể lớn lên để thỏa mãn sự tăng trưởng này

Một thuật ngữ trong khoa học máy tính (hoặc tên khác Message Dispatcher, Message Loop, Message Pump hoặc Run loop) Là cấu trúc lập trình mà chờ đợi là gửi đi các

sự kiện hoặc thông điệp trong 1 chương trình Mỗi request

có event handler tương ứng

Một Event loop implementation đầy đủ tính năng và hiệu năng cao mà mô hình theo libevent Được sử dụng trong GNU Virtual Private Ethernet, rxvt-unicode, auditd, Deliantra MORPG

Trang 9

11 Callback

Một thuật ngữ trong lập trình máy tính, callback là 1 đoạn code được truyền vào như 1 tham số của 1 đoạn code khác,

12 Heap memory Một vùng bộ nhớ được cấp phát động

13 Thread-stack Memory dạng stack hỗ trợ làm việc trong Thread

14 Dead-lock Là 1 trạng thái mà 2 công việc cạnh tranh chờ nhau kết

thúc, dẫn đến không công việc nào kết thúc cả

15 Ruby Event Machine

Event Machine là 1 hệ thống phần mềm được thiết kế để viết ứng dụng chuyên mở rộng cho Ruby Nó cung cấp event-driven I/O mà sử dụng reactor pattern

16 Python Twisted

Là một framework event-driven network programming được viết bởi Python Nằm dưới sự quản lý của MIT license

HTTP Server phát triển bởi Apache Software Foundation Dịch vụ HTTP service an ninh, hiệu quả, và khả mở với các chuẩn HTTP hiện có Cross platform trên cả Windows

và Linux

Proxy reverse server mã nguồn mở cho các giao thức HTTP, HTTPS, SMTP, POP3, và IMAP chạy như là Load balancer, HTTP cache và cũng là một Webserver

19 Context switch

Trong lĩnh vực máy tính, 1 context switch là 1 tiến trình lưu trữ và phục hồi trạng thái (context) của 1 process hoặc thread, làm cho việc thực thi có thể được hồi phục tại cùng điểm lưu trữ tại 1 thời điểm khác

20 Execution stack

Trong khoa học máy tính, Excecution stack (còn gọi là callstack) là 1 cấu trúc ngăn xếp mà lưu trữ thông tin về các phương thức và chương trình đang chạy

21 Non blocking I/O

Còn được gọi là Asynchronous I/O Là 1 dạng của xử lý input/ouput mà cho phép các xử lý khác tiếp tục chạy trước khi mà giao dịch I/O chấm dứt

22 Network traffic

Network traffic hoặc data traffic trong 1 mạng máy tính Data được đo bằng Network packets

23 Postgresql Hệ quản trị cơ sở dữ liệu hướng đối tượng-quan hệ Phát

triển bằng ngôn ngữ C, và giấy phép là PostgresSQL

Trang 10

Thư viện Javascript cho ứng dụng web thời gian thực Hỗ trợ realtime, giao tiếp bi-directional cho web client và server

256 Websocket Là 1 giao thức cung cấp kênh giao tiếp full-duplex qua 1

kết nối TCP Giao thức được W3C chuẩn hóa

Trang 11

CHƯƠNG 1.TỔNG QUAN VỀ WEB ĐÁP ỨNG TỨC THỜI

Web đáp ứng thời gian tức thời được gọi bằng thuật ngữ Realtime web:

Web thời gian thực (real time web) là một tập hợp các công nghệ (technologies) và thực tiễn (practices) cho phép người dùng đầu cuối nhận được thông tin ngay sau khi nó được xuất bản bởi tác giả của nó, chứ không phải là đòi hỏi rằng họ hoặc phần mềm của

họ kiểm tra một nguồn theo định kỳ để cập nhật

Web thời gian thực (realtime web) về cơ bản là khác với tính toán thời gian thực (Realtime computing) bởi vì không có biết khi nào, nhận được một phản ứng Thông tin được truyền theo cách này thường là tin nhắn ngắn (short message), cập nhật trạng thái (status update), cảnh báo tin tức (news alert), hoặc liên kết đến tài liệu dài hơn (link to longer document) Nội dung manh tính "mềm" ở chỗ nó dựa trên ý kiến của người trên mạng xã hội, thái độ, suy nghĩ, và lợi ích - khác với tin tức chính luận hay sự kiện

Với Real-time web, thời gian đi vòng tín hiệu server đến client phải <=1s mới được coi là realtime và không được gây phiền nhiễu cho người dùng trong phiên kết nối (connection) Về tranh luận giữa mạng xã hội và real-time web, thì real-time web mặc định là mạng xã hội, còn ngược lại thì không (WEB-r xuất hiện trước Web 2.0)

Ví dụ thành công nhất của web thời gian thực là newsfeed của Facebook và Twitter Cách tiếp cận này đang được thực hiện trong mạng xã hội, các trang tìm kiếm và trang tin tức, trải nghiệm giống như instant messaging Lợi ích ban đầu là tăng sự tham gia của người sử dụng ("dòng chảy") và giảm tải máy chủ Bắt đầu từ tháng 12/2009, Google giới thiệu tại Bảo tàng lịch sử máy tính tính năng tìm kiếm thời gian thực mới của

Ajax không xuất hiện từ hư không, nhưng cái gì cũng có lý do của nó Nguồn gốc

ra đời: được làm nóng trong 1 thời gian Sau thời gian dài làm việc trên Web đã khuyến khích người tạo ra công cụ làm việc mang tên Ajax Trong kỷ nguyên bong bóng DHTML, nhà phát triển khắp thế giới giải mã những sức mạnh thú vị của Javascript và mang lại một mô hình làm việc thú vị cho Web

Trang 12

Đoạn đầu tiên và quan trọng trong câu chuyện về Ajax là XMLHttpRequest (XHR) API XHR là Javascript API dùng để truyền dữ liệu giữa Webbrrowser và Webserver Cho phép browser dùng HTTP Post (truyền data tới server) hoặc GET request (truy cập data từ server) API này là core của tương tác Ajax và 1 trong những công nghệ nền tảng của phát triển web

Đó cũng là món quà tuyệt vời nhất của MS Internet Explorer team đưa cho

Internet

Thực tế là XHR lần đầu xuất hiện trong IE5 vào năm 2000 Nguồn gốc viết bởi Alex Hopmann dưới dạng 1 Microsoft ActiveX Control XHR được tạo ra để dùng với Microsoft Outlook Web Access, thiết kế để làm mịn thao tác giữa giao diện nền nâng cao

và Microsoft Exchange Server

Mặc dầu gói phần mềm này từ Microsoft không hoàn toàn được coi như là sự bắt đầu có ý đồ Nhưng XHR hiển nhiên tăng trưởng quá giới hạn của sản phẩm ban đầu Nó được implement trong hầu hết trình duyệt chính và được chấp nhận bởi chuẩn W3C

Bên ngoài implementation của Microsoft, nhiều công ty đã mang đến những đột phát trong lĩnh vực Ajax Mặc dầu nhiều công ty thí nghiệm với những công nghệ này Nổi bật thì chỉ có 2, 1 bởi vì sự sáng tạo và thường được trích dẫn trong sự phát triển của Ajax, cái kia là vì nó là 1 người khổng lồ Internet Đó là:

• OddpostOddpost là 1 web-based email client thu phí mà khởi động vào năm

2002 Nó nâng bật parttern dạng ealmnow Với design và tương tác, nó gợi nhớ desktop mail client

Về bản chất, nó sử dụng khái niệm mà lập trình viên gọi là Data Packs để truyền những khối dữ liệu nhỏ từ server tới browser Nó làm cho 1 câu truyện cổ tích Oddpost bị Yahoo mua lại và làm thành phần cơ bản để xây dựng lại Yahoo mail

• Gmail, Google Maps

Sự thay đổi cách mạng bắt đầu 2 năm sau với Gmail, Google Suggest

và Google Maps services Ba sản phẩm trên đẩy bật kỹ thuật Ajax mạnh mẽ

và nhìn chung thổi lửa vào sự phát triển web trên thế giới Sự tương tác và phản ứng nhanh đang chỉ là câu chuyện cổ tích với công chúng Thì bất ngờ nổi dậy với các ứng dụng Google

Không nhiều người biết về việc này, nhưng những điều mà về nó rất thú vị trong sự phát triển web trên thế giới Vào thời điểm đó, người ta chỉ biết về 1 cái gì đó thú vị đang diễn ra trong việc phát triển ứng dụng web

Trang 13

WEB TRAFFIC

Các mô hình sau đây chỉ ra sự gửi/nhận dữ liệu giữa Client/server cho mô hình web

Regular http

Hình Giao tiếp http thông thường

• Client request 1 http page từ server

• Server tính toán nội dung phản hồi

• Server gửi phản hồi cho client

Ajax Polling

Hình Ajax polling

Trang 14

Ajax tạo ra connection tới server cho mỗi request, gửi request (với possible data như request method GET, POST, PUT, DELETE tham số trong url), lấy phản hồi từ server Sau đó kết nối đóng lại, đó là 1 single request, response cho mỗi lời gọi Ajax Hỗ trợ trong hầu hết trình duyệt.

Ajax long polling

Hình Ajax long poll

Tạo ra connection tới server như AJAX, nhưng thỉnh thoảng connection lại là keep-alive, trong suốt phiên mở connection có thể nhận dữ liệu từ server Client phải reconnect định kỳ sau khi connection được đóng vì timeout Trong server side, nó được đối như HTTP request – giống Ajax Được hỗ trợ trong hầu hết trình duyệt

Server-sent-Events (SSE)

Trang 15

Hình Server-sent-events

Client mở connection tới server Server gửi dữ liệu tới client khi mà nó sẵn sang SSE làm việc tốt khi mà server cần thiết gửi dữ liệu thường xuyên Không tốt khi mà client cần gửi dữ liệu

Websocket

Trang 16

Hình Websocket

Tạo ra 1 TCP connection tới server, và giữ connection lâu khi nào cần Server & client – cả 2 đều có thể đóng kết nối Giao tiếp 2 chiều, server và client trao đổi dữ liệu theo 2 chiều vào bất kỳ thời điểm nào Nó hiệu quả khi mà ứng dụng đòi hỏi thông điệp liên tục Websockets có dữ liệu framing bao gồm mặt nạ (masking) cho mỗi thông điệp từ client tới server Vì thế dữ liệu được mã hóa 1 cách đơn giản Hỗ trợ bởi 1 số trình duyệt danh tiếng

Trang 17

CHƯƠNG 2.NODEJS

"Node.js làm mạnh các ứng dụng web của chúng tôi và cho phép đội phát triển di

chuyển nhanh hơn rất nhiều trong việc đem thiết kế vào cuộc sống Chúng tôi hạnh phúc vì sức mạnh của Javascript"

Jeff Harrell Director of Engineering in Paypal

"Node nắm giữ toàn bộ back-end, cung cấp elastic scalable cluster server để hỗ

trợ web front-end và cung cấp RES API cho partners của chúng tôi Node hoàn thiện cho chúng tôi về Javascript, JSON thông qua các platforms stack, Web, Mobile, Extension và Node, tạo hành lang cho đội phát triển của chúng tôi tối đa agility và portability."

Guy Korland CTO - Shopetti

“Trong 1 mặt khác, toàn bộ mobile software stack của chúng tôi được xây xựng

bằng Node Một lý do cho việc khả mở Lý do thứ hai là Node chỉ ra một hiệu năng lớn có thể đạt được.”

Kiran Prasad.Director of Engineering, Mobile – LinkedIN

"Node đem lại cho người dùng Azure trải nghiệm đầu tiên về end-to-end

Javascript cho sự phát triển của 1 thế hệ ứng dụng real-time hoàn toàn mới.”

Claudio CaldatoPrincipal Program Manager, Microsoft Open Technologies

Đó là nhận xét của các chuyên gia về Nodejs, và còn nhiều đánh giá nữa từ các công ty như caliper.io, c9.io… Vậy Nodejs là gì khiến họ quan tâm như vậy?

2.1 GIỚI THIỆU VỀ NODEJS

Định nghĩa Nodejs:

Là một nền tảng xây dựng trên Chrome Javascript Runtime để mà dễ dàng xây dựng ứng dụng nhanh, khả mở về Network Nodejs sử dụng mô hình hướng sự kiện mà làm cho nó nhỏ gọn và hiệu quả, là lý tưởng cho ứng dụng real-time tập trung vào dữ liệu

mà chạy trên nhiều thiết bị phân tán

Trang 18

Tác giả của Nodejs là Ryan Dahl, khởi động phát triển Nodejs vào 2009 Tư tưởng của Nodejs tương tự với Twisted trong Python hay EventMachine cho Ruby.

Công ty Joyent vận hành Nodejs, nơi mà chạy Cloud hosting service cho các ứng dụng node

Mô hình tổng quan các thành phần của NodeJS như sau:

Hình Kiến trúc Nodejs

Các thành phần trong kiến trúc Nodejs bao gồm:

Node standard library: Tập thư viện chuẩn của Nodejs

Node bindings (socket, http, …): mô hình làm việc Network

V8: Javascript engine được phát triển bởi Google – mã nguồn mở.

Libeio: Là 1 thư viện đầy đủ tính năng (full-featured) I/O bất đồng bộ cho ngôn

ngữ C

Libev:Một Event loop implementation đầy đủ tính năng và hiệu năng cao mà

mô hình theo libevent Được sử dụng trong GNU Virtual Private Ethernet, unicode, auditd, Deliantra MORPG

rxvt-• C-ares: là thư viện viết bằng C cho các truy vấn DNS bất đồng bộ.

Openssl: Thư viện mã nguồn mở thự thi Secure socket layer.

2.2 TỔNG QUAN VỀ NODEJS

Mục tiêu của Node là cung cấp một cách dễ dàng để xây dựng các chương trình mạng lưới khả năng mở rộng (scalable network programs)

Trang 19

Trong ví dụ về máy chủ web "Hello world" máy chủ web dưới đây, nhiều kết nối

từ trạm (client) có thể được xử lý đồng thời Node giao tiếp với hệ điều hành (thông qua epoll, kqueue, /dev/poll, hoặc select) rằng Node sẽ được thông báo khi một kết nối mới

được thực hiện, rồi nằm chờ (sleep) Nếu có kết nối mới, Node thực hiện lời gọi callback

Mỗi kết nối chỉ chiếm dụng 1 cấp phát bộ nhớ heap nhỏ

var http = require('http');

http.createServer(function(req, res){

res.writeHead(200,{'Content-Type':'text/plain'});

res.end('Hello World\n');

}).listen(1337,"127.0.0.1");

console.log('Server running at http://127.0.0.1:1337/');

Trang 20

Điều này trái ngược với mô hình hoạt động đồng thời phổ biến ngày nay, nơi đề hệ điều hành hỗ trợ luồng (Thread) được sử dụng Làm việc mạng dựa trên thread (Thread-based networking) là tương đối không hiệu quả và khó sử dụng Node sẽ chỉ ra hiệu quả

bộ nhớ tốt hơn nhiều dưới tải trọng cao so với hệ thống mà phân chia Thread-stack2MB cho mỗi kết nối Hơn nữa, người sử dụng Node không phải lo về dead-lock trong tiến trình (process) –vì không có khóa (lock) ở đây Hầu như không có chức năng nào trong Node trực tiếp thực hiện trên I/O, vì vậy tiến trình không bao giờ block Bởi không blocks đối tượng nào, chúng ta sẽ cần ít lập trình viên chuyên gia hơn để phát triển hệ thống

Node tương tự như trong thiết kế và chịu ảnh hưởng của hệ thống như Ruby's Event Machine hay Python Twisted Node tác động mô hình sự kiện sâu hơn -nó trình bày các vòng lặp sự kiện như là một ngôn ngữ xây dựng (construct language) thay vì như một library Trong các hệ thống khác luôn luôn có một lời gọi chặn (blocking call) để bắt đầu

sự kiện vòng lặp Thường là một người định nghĩa hành vi thông qua callbacks vào đầu một kịch bản và cuối cùng bắt đầu một máy chủ thông qua một blocking-call như EventMachine::run () Trong Node không có một lời gọi khởi động vòng lặp như vậy Node đơn giản là đi vào vòng lặp sự kiện sau khi thực thi input script Node thoát ra khỏi vòng lặp sự kiện khi không có thêm callback để thực hiện Hành vi này cũng giống như trình duyệt Javascript-vòng lặp sự kiện được ẩn cho người dùng

HTTP là một giao thức hạng nhất trong Node Thư viện Node của HTTP đã phát triển ra từ những kinh nghiệm của các tác giả phát triển và làm việc với các máy chủ web

Ví dụ, luồng dữ liệu thông qua hầu hết web framework là không thể Node cố gắng sửa chữa những vấn đề này trong HTTP Parser và API của nó Cùng với cơ sở hạ tầng hoàn toàn evented của Node, nó làm cho một nền tảng (foundation) tốt cho các thư viện web hoặc các Framework

Việc chạy vòng lặp sự kiện trên 1 tiến trình, dẫn tới câu hỏi nếu máy tính đa lõi thì sao? Không phải là tiến trình cần thiết để mở rộng quy mô các chương trình tới các máy

tính đa lõi? Bạn có thể bắt đầu tiến trình mới (new process) thông qua child_process.fork

() các tiến trình khác sẽ đượcsắp xếp chạy song song Cho trường hợp cân bằng tải kết nối yêu cầu (incoming connections) qua nhiều quy trình sử dụng module cluster

2.3 NỀN TẢNG THIẾT KẾ NODEJS

Các tính chất về NodeJS:

• Server side JS

Trang 21

• Built on Google V8

• Evented, non-blocking I/O, tương tự EventMachine hoặc Twisted

• CommonJS module system

• 8000 dòng C/C++, 2000 dòng Javascript, 14 người bổ trợ/(cung cấp/quyên góp)

Sự khác nhau về hiệu năng giữa các nền tảng

Apache sử dụng 1 tiến trình (thread) cho mỗi Connection

NGINX không dùng tiến trình, nó dùng vòng lặp sự kiện (Event loop)

Sự khác nhau nằm ở chỗ:

Context switching không miễn phíExecution stacks ngốn memory

Nhận xét: Với khối lượng lớn đồng thời (massive concurrency), không thể dùng 1

OS thread cho mỗi connection

Luồng thực hiện hoặc là block toàn bộ tiến trình hoặc ngụ ý nhiều ngăn xếp thực hiện.Ví dụ đoạn code sau

var result = db.query("select ");

Trang 22

Cho phép chương trình trở về vòng lặp sự kiện (event loop) ngay lập tức.

Không yêu cầu machinery Đó là phương pháp làm thế nào I/O cần thực hiện

Vậy tại sao mọi người không sử dụng event loops, callbacks và non-blocking I/O

Vì hai lý do cultural (văn hóa) và infrastructual (nền tảng)

"Văn hóa thiên vị" (Cultural bias)

Hãy so sánh 2 đoạn code sau:

Trang 23

Thường bị từ chối vì quá phức tạp.

Thiếu nền tảng (Missing Infrastructure)

• POSIX async file I/O không tồn tại

• Man pages không thông báo nếu 1 function truy cập ổ đĩa

• Không có closure hoặc anonymous function trong C, làm cho việc callback khó khăn

• Thư viện database không hỗ trợ support Async query

• Giải mã DNS bất đồng bộ không phải chuẩn hóa trên hầu hết hệ thống

Và quá nhiều nền tảng

Event Machine, Twisted, AnyEvent cung cấp nền tảng Vòng lặp sự kiện (Event loop)

rất tốt

• Dễ dàng tạo các máy chủ hiệu quả

Nhưng người dùng khó hiểu làm các nào để kết nối với các thư viện khác.

• Người dùng vẫn đòi hỏi Kiến thức chuyên gia (expert knowledge) về vòng lặp sự kiện (event loops), non-blocking I/O

• Văn hóa của Javascript đã hướng tới lập trình hướng sự kiện (evented programming)

Về dự án Node.js:

Để cung cấp một cơ sở hạ tầng (infrastructure) hoàn toàn hướng sự kiện evented, non-blocking và tính đồng thời cao (concurrency)

Mục tiêu thiết kế của Nodejs

• Không function nào thao tác trực tiếp I/O

• Để nhận thông tin từ ổ đĩa, network, hoặc 1 tiến trình khác nhất thiết cần 1

callback

• Ở mức thấp:

o Stream mọi thứ, không bắt buộc buffering dữ liệu

o Không remove tính năng tại POSIX layer Ví dụ hỗ trợ bán-đóng (half-closed) kết nối TCP

• Có hỗ trợ built-in cho những giao thức quan trọng nhất TCP, DNS, HTTP

• Hỗ trợ nhiều tính năng của HTTP

o Chunked request và response

o Keep alive

o Giữ request cho ứng dụng comet

• API quen thuộc với Javascript client-side và old school UNIX hackers

• Platform independent

Các thành phần bên trong – internal design

Trang 24

Vào năm 1999, một trong những trang web ftp bận rộn nhất, cdrom.com, thực sự

xử lý 10.000 khách hàng đồng thời thông qua một đường ống (pipe) Gigabit Ethernet Tính đến năm 2001, tốc độ tương đương được cung cấp bởi nhiều ISP (Nhà cung cấp dịch vụ), những người màkỳ vọngđiều đó ngày càng trở nên phổ biến với khách hàng doanh nghiệp lớn

Và mô hình máy khách dẹt (thin) của máy tính dường như được trở lại trong phong cách - thời gian này với máy chủ trên Internet, phục vụ hàng ngàn khách hàng

Với tư duy đó, ở đây có vài lưu ý về cách cấu hình hệ điều hành và viết code để hỗ trợ hàng ngàn khách hàng Các cuộc thảo luận xoay quanh hệ điều hành lai-Unix, được nhiều sự quan tâm, và hệ điều hành Windows cũng được xem xét (cover)

Các Site liên quan

• Trang cá nhân của Nick Black Fast UNIX Servers black.com/dankwiki/index.php/Network_servers)

Trang 25

(http://nick-• Trong năm 2003, Felix Von Leitner đặt đồng thời cả 1 Page (http://bulk.fefe.de/scalability/) và 1 bài thuyết trình (http://bulk.fefe.de/scalable-networking.pdf) về vấn đề Khả năng mở rộng mạng (network scalability), so sánh nhiều lời gọi hàm và các hệ điều hành khác nhau Một trong những góc nhìn của ông là nhân Linux 2.6 hoàn toàn chiến thắng nhân 2.4, nhưng có nhiều đồ thị tốt đưa cho người lập trình hệ thống các tư tưởng trong 1 số thời điểm (thought for

(http://beta.slashdot.org/story/39727), rất thú vị khi xem khi nào có người theo dõi benchmarks tăng cường kết quả của Felix.)

Ebook cần đọc

• Unix Network Programming: Networking Apis: Sockets and Xti (Volume1) - W.Richard Stevens Nó mô tả nhiều chiến lược I/O và pitfalls liên quan đến việc viết server hiệu năng cao Nó thậm chí nói về bài toán 'thundering herd' (http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html)

o Và nếu bạn đọc rồi, hãy đọc 1 ghi chú của Jefff Darcy về thiết kế máy chủ hiệu năng cao

o Sách hữu ích khác cho ai mà "sử dụng" chứ không phải "phát triển" 1 web server là "Building Scalable Web Sites" bởi Carl Henderson

I/O Frameworks

Những thư viện đóng gói và sẵn sàng và trừu tượng hóa kỹ thuật được trình bày dưới đây, độc lập hóa mã nguồn người phát triển với hệ điều hành và làm cho nó khả chuyển (portable)

ACE, 1 framework C++ cồng kềnh, object/oriented implementations cho

những chiến lược I/O và những thứ hữu ích khác Cụ thể, việc Reactor là 1 con đường OO để thực hiện nonblocking I/O, và Proactor là phương pháp

OO để làm I/O bất đồng bộ

ASIO: I/O framework C++, là 1 thành phần của thư viện Boost Nó tương

tự bản cập nhật ACE trong thời đại STL

libevent, framework gọn nhẹ, viết bằng C, của Niels Provos Hỗ trợ Kqueue

và select, và hỗ trợ poll và epoll

Những người phát triển thì nỗ lực với các nền tảng gọn nhẹ nhất:

Trang 26

Poller: nền tảng I/O C++ gọn nhẹ mà implement level-triggered readiness API (API

sự sẵn sang kích hoạt mức level), sử dụng bất kỳ API nền dưới (underlying) mà bạn mong muốn (poll, select, /dev/poll, kqueue, hoặc sigio) Nó là hữu ích để đo đạc (benchmarks) để so sánh hiệu năng giữa các APIs Tài liệu này kết nối đến lớn con Poller ở dưới để mô tả các readiness API sử dụng thế nào

rn là nền tảng I/O viết trên C Giấy phép LGPL Nó được sử dụng trong một số sản

phẩm thương mại

• Matt Welsh viết 1 bài báo năm 2000, về việc làm thế nào để cân bằng việc sử dụng worker thread và kỹ thuật event-driven khi xây dựng máy chủ khả mở (scalable servers) Bài báo mô tả về Framework Sandstorm I/O của ông ấy

• Thư viện Cory Nelson scale: cho Windows, async socket, pipe I/O

Chiến lược tiếp cận I/O Strategies

Thiết kế cho phần mềm Networking có nhiều lựa chọn, sau đây là 1 số phương pháp:

• Nên/không nên và làm thế nào thao tác nhiều lệnh I/O từ 1 single thread

o Không: sử dụng lời gọi blocking/synchonous

o Sử dụng non blocking calls (Ví dụ lệnh write() và đặt O_NONBLOCK để khởi tạo I/O, và sẵn sàng cảnh báo (ví dụ poll() hoặc /dev/poll) để biết khi nào là tốt khi khởi tạo I/O kế tiếp trên kênh đó Thông thường chỉ sử dụng được với network I/O, chứ không phải disk I/O )

o Sử dụng Asynchronous call (ví dụ aio_write()) để bắt đầu I/O và cảnh báo hoàn thiện (ví dụ tính hoặc hoặc cổng kết thúc) để biết khi nào I/O kết thúc Tốt cho cả I/O mạng và I/O ổ cứng

• Làm thế nào kiểm soát phục vụ mã nguồn (code servicing) trên mỗi máy

Trang 27

 1 máy trạng thái - state machine (1 chút bí truyền - esoteric, nhưng phổ biến trong một số nơi - circle)

 1 sự tiếp tục continuation (1 chút bí truyền, nhưng phổ biến ở 1 số nơi - circle)

o 1 OS-level thread cho mỗi client (ví dụ classic Java với navite threads)

o 1 OS-level thread cho mỗi active client (Ví dụ Tomcat với apache front end; NT completion ports; thread pools)

• Khi nào thì nên/không nên sử dụng dịch vụ O/S chuẩn, hoặc cho 1 số code vào kernel (ví dụ 1 custom driver, kernel module, hoặc VxD)

Năm tổ hợp sau đây là phổ biến:

1 Phục vụ nhiều clients với mỗi thread, và sử dụng non blocking I/O và triggered readiness notification

level-2 Phục vụ nhiều clients với mỗi thread, và sử dụng nonblocking I/O readiness change notification

3 Phục vụ nhiều client với mỗi server thread, sử dụng asynchronous I/O

4 Phục vụ 1 client với 1 server thread, sử dụng blocking I/O

5 Xây dựng kernel code vào kernel

1) Phục vụ nhiều client với mỗi thread, sử dụng non blocking I/O và level-triggered readiness notification

Đặt non blocking mode cho mọi network handles, sử dụng select() hoặc poll() để nói rằng handle network nào đang chờ dữ liệu Là phương pháp cổ truyền Với chiến lược này, kernel nói với bạn khi nào mô tả tập tin (file descriptor - FD) là sẵn sàng, bạn có làm hay không việc gì với mô tả tập tin kể từ lần cuối (Tên gọi 'level-triggered' đến từ thiết kế phần cứng; đối nghịch với 'edge triggered' Jonathhon Lemon giới thiệu thuật ngữ này trong bài báo tại BSDCON 2000 về kqueue())

Lưu ý: đó là đặc biệt quan trọng phải nhớ rằng thông báo sẵn sàng (readiness notification) từ kernel chỉ là một gợi ý, mô tả tập tin (FD) có thể không sẵn sàng nữa khi bạn cố gắng đọc dữ liệu từ nó Đó là lý do tại sao điều quan trọng là sử dụng chế độ không chặn (non blocking) khi sử dụng thông báo sẵn sàng

Trang 28

Một nút cổ chai quan trọng trong phương pháp này là read() hoặc sendfile() từ đĩa

sẽ block nếu trang (page) không ở trong core tại thời điểm hiện tại; thiết lập non-blocking mode trên disk file handle đĩa không có tác dụng Điều tương tự xảy ra cho memory-mapped disk file Trong lần đầu tiên máy chủ cần disk I/O, nó xử lý việc blocks, mọi clients phải chờ đợi, và vì thế hiệu năng không-tiến trình đó (that raw nonthreaded performance) là lãng phí

Đây là những gì I/O không đồng bộnói về, nhưng trên các hệ thống mà thiếu AIO, worker thread hoặc processmà thao tác I/O cũng có thể gặp phải (get around) nút cổ chai này Một cách tiếp cận là sử dụng các tập tin bộ nhớ ánh xạ, vànếu mincore() chỉ ra rằng I/O là cần thiết, yêu cầu một worker thực thi I/O, và tiếp tục xử lý lưu lượng mạng Jef Poskanzer (một kỹ sư ) đề cập rằng Pai, Druschel, và máy chủ web của Flash Zwaenepoel trong năm 1999 sử dụng thủ thuật này, họ đã đưa ra một bài nói chuyện tại Usenix '99 Có

vẻ như mincore() có sẵn trong BSD hướng Unix như là FreeBSD và Solaris, nhưng không phải là một phần của Single Unix specification Nó sẵn có như là một phần của Linux trong kernel 2.3.51

Nhưng trong tháng 11 năm 2003, tại danh sách freebsd-hacker, Vivek Pei và cộng

sự báo cáo kết quả rất tốt sử dụng hồ sơ trên toàn hệ thống máy chủ web Flash của họ để tấn công tắc nghẽn Một nút cổ chai họ tìm thấy là mincore Một thứ khác thực tế là sendfile block việc truy cập đĩa (disk access), họ cải thiện hiệu năng bằng một

hàmsendfile() sửa đổi mà trả về EWOULDBLOCK khi trang (page) nó đang tìm nạp

chưa có trong core (Không chắc chắn làm thế nào bạn nói cho người dùng disk page hiện nay là cư trú (resident) dường như với tôi những gì thực sự cần thiết ở đây là

aio_sendfile().) Kết quả cuối cùng của việc tối ưu hóa của họ là điểm số 800 SpecWeb99 trên một box 1GHZ/1GB FreeBSD, tốt hơn bất cứ điều gì trong hồ sơ ởspec.org.

Có 1 loạt cách để 1 single thread nói tập con blocking sockets nào đã sẵn sàng cho I/O:

Hàm select() cổ điển:

Không may, select() bị hạn chế bởi FD_SETSIZE Giới hạn này được biên dịch vào thư viện std và chương trình người dùng (Một số version thư viện của C cho phép bạn tăng hạn chế này vào thời gian biên dịch)

poll() cổ điển

Trang 29

Không có giới hạn đặt cứng về số lượng mô tả tập tin mà poll() mà

có thể xử lý, nhưng nó không trở nên chậm trong khoảng một vài nghìn, khi

mà hầu hết các mô tả tập tin đang nhàn rỗi tại một thời điểm, và quét qua hàng ngàn mô tả tập tin cần có thời gian

Một số hệ điều hành (ví dụ như Solaris 8) tăng tốc độ poll() và các cộng sự bằng cách sử dụng các kỹ thuật như poll hinting, được thực hiện và chuẩn hóa bởi Niels Provos cho Linux trong năm 1999

Xem Poller_poll (cc, h, tiêu chuẩn) để biết một ví dụ về cách sử dụng poll() thay thế cho nhau với các chương trình thông báo sẵn sàng khác

/dev/poll

Đây là sự thay thế poll được tiến cử cho Solaris

Ý tưởng đằng sau /dev/poll là để tận dụng lợi thế của thực tế là thông thường poll() được gọi nhiều lần với các đối số giống nhau Với /dev/poll, bạn sẽ có được một open handle cho /dev/poll, và cho hệ điều hành biết mỗi khi có file nào mà bạn muốn ghi vào handle đó, từ đó về sau, bạn chỉ cần đọc các bộ mô tả tập tin hiện đang sẵn sàng từ handle đó

Nó xuất hiện lặng lẽ trong Solaris 7 (xem patchid 106.541) nhưng việccông bố công khai đầu tiên của nó là trong Solaris 8; theo Sun, 750 clients, tốt hơn poll 10%

Thực thi (implementation) khác nhau của /dev/poll đã được thử trên Linux, nhưng không ai trong số họ thực hiện được như epoll, và không bao giờ thực sự hoàn thành Sử dụng /dev/poll trên Linux là không nên

Xem Poller_devpoll (cc, tiêu chuẩn h) cho một ví dụ về cách sử dụng /dev/poll thay thế cho nhau với nhiều chiến lược thông báo sẵn sàng khác (Chú ý - ví dụ được cho Linux /dev/poll ,chưa chắc chạy đúng trên Solaris.)

Trang 30

Sự thông báo thay đổi Readiness (hoặc edge-triggered readiness notification) có nghĩa là bạn cho Kernel một mô tả tập tin, sau đó, khi FD (mô tả tập tin) chuyển đổi từ

not ready đến ready, kernel thông báo cho bạn bằng một cách nào đó Nó giả sử sau đó

bạn biết FD đã sẵn sàng, và không gửi readiness notification nào cùng loại tớiFD đó cho

đến khi bạn cho FD trở về not ready (ví dụ như cho khi bạn nhận được lỗi

EWOULDBLOCK trên lời gọi send, hoặc recv, hoặc accept, hoặc lời gọi recv trả về ít hơn số bytes yêu cầu)

Khi bạn sử dụng readiness notification, bạn phải chuẩn bị cho các sự kiện giả mạo, khi mà một common implementationđánh tín hiệu sẵn sàng mỗi khi có packets được nhận, bất kể mô tả tập tin là sẵn sàng hay không

Điều này đối lập với readiness notification "level-triggered" (Kích hoạt mức level)

Bỏ qua 1 chút những sai lầm của lập trình viên, vì nếu bạn bỏ lỡ chỉ là một sự kiện, kết nối sự kiện đó bị mắc kẹt mãi mãi Tuy nhiên, người ta đã tìm thấy rằng edge-triggered readiness notification làm cho việc lập trình non-blocking clients với OpenSSL dễ dàng hơn, vì vậy nó đáng để thử

[Banga, Mogul, Drusha '99] mô tả loại chiến lược này trong năm 1999

Có một số API cho phép lấy thông báo về “mô tả tập tin trở nên sẵn sang”:

Giống như /dev/poll, bạn cấp phát một listening object, nhưng thay vì mở tập tin /dev/poll, bạn gọi kqueue () để cấp phát Để thay đổi các sự kiện bạn đang lắng nghe, hoặc lấy danh sách các sự kiện hiện hành, bạn gọi kevent() trên FD (file descriptor) mà kqueue() trả về Nó có thể lắng nghe không chỉ cho socket readiness, mà còn cho các tập tin plain readiness (plain file readiness), tín hiệu, và với cả I/O completion

Lưu ý: vào tháng 10 năm 2000, thư viện luồng trên FreeBSD không tương tác tốt với kqueue (); rõ ràng, khi mà kqueue () chặn (blocks), toàn bộ tiến trình bị chặn (the entire process blocks), chứ không chỉ các thread được gọi

Xem Poller_kqueue (cc, h, benchmark) để biết ví dụ về cách sử dụng kqueue() thay thế cho nhau với nhiều chiến lược khác

Trang 31

Các ví dụ và các thư viện sử dụng kqueue ():

o PyKQueue - một Python binding cho kqueue ()

o Ví dụ của Ronald F Guilmette về Echo server, xem them trên bài đăng của anh ta vào ngày 28/09/2000 trên freebsd.questions

epoll

Đây là sự tiến cử thay thế cho edge-triggered pollcho nhân Linux 2.6

Vào ngày 11/07/2001, Davide Libenzi đề xuất một thay thế cho tín hiệu thời gian thực; bản vá của ông cung cấp cái ông gọi là /dev/epoll Điều này cũng giống như readiness notification thời gian thực, nhưng nó hợp lại những sự kiện không cần thiết, và có một chiến lược hiệu quả hơn để thu hồi số lượng lớn sự kiện

Epoll đã được sáp nhập vào kernel tree 2.5cũng như 2.5.46 sau khi giao diện của nó đã được thay đổi từ một tập tin đặc biệt trong /dev đến một lời gọi hệ thống, sys_epoll Một bản vá cho các phiên bản cũ của epoll có sẵn trong kernel 2.4

Có một cuộc tranh luận kéo dài về thống nhất epoll, aio, và các nguồn sự kiện khác trên mailing list linux-kernel vào thời điểm gần Halloween 2002 Nó chưa có thể xảy ra, nhưng Davide đang tập trung vào vào epoll tổng quát trước

Tin tức nhanh về Kevent của Polyakov (Linux 2.6 +): vào 09/02/2006, và một lần nữa vào ngày 09 Tháng Bảy 2006, Evgeniy Polyakov đăng các bản vá lỗi

mà dường như thống nhất epoll và aio, mục tiêu của ông là để hỗ trợ Network AIO

Giao diện mạng mới (đề xuất cho Linux 2.6 +) của Drepper:

Tại OLS 2006, Ulrich Drepper đề xuất một API mạng không

đồng bộ ốc độ cao mới (new high-speed asynchronous networking)

Xem thêm để tham khảo :

 bài báo của ông ta, slide của ông ta "Nhu cầu không đồng bộ, Zero-Copy mạng I / O" (The need of

Asynchronous, Zero-Copy Network I/O)

 Chủ đề LWN vào 22/7

Realtime signals

Đây là đề nghị thay thế edge-triggered poll cho Linux kernel 2.4

Hạt nhân Linux 2.4 có thể bàn giaosocket readiness events thông qua một tín hiệu thời gian thực cụ thể Dưới đây là cách để bật hành vi này lên:

Trang 32

sigaddset(&sigset, signum);

sigaddset(&sigset, SIGIO);

sigprocmask(SIG_BLOCK, &m_sigset, NULL);

/* For each file descriptor, invoke F_SETOWN, F_SETSIG, and set O_ASYNC */fcntl(fd, F_SETOWN, (int) getpid());

fcntl(fd, F_SETSIG, signum);

flags = fcntl(fd, F_GETFL);

flags |= O_NONBLOCK|O_ASYNC;

fcntl(fd, F_SETFL, flags);

Trang 33

Điều này sẽ gửi tín hiệu khi mà một hàmI/O bình thường như là read() hay write() hoàn tất Để sử dụng nó, viết một cuộc vòng lặp ngoạipoll(), và bên trong nó, sau khi bạn

đã xử lý tất cả các fd được thông báo bởi poll(), bạn gọi lặp hàm sigwaitinfo ()

Nếu sigwaitinfo hoặc sigtimedwait trả về tín hiệu thời gian thực, siginfo.si_fd và siginfo.si_band cho bạn trước gần như giống nhau về thông tin như là pollfd.fd và

pollfd.revents, sau khi lời gọi poll(), vì vậy bạn xử lý I/O, và tiếp tục gọi sigwaitinfo().

Nếu sigwaitinfo trả về một SIGIO truyền thống, hàng đợi tín hiệu tràn, bạn flush

hàng đợi tín hiệu bằng cách tạm thời thay đổi signal handler vềSIG_DFL, và phá vỡ

đường quay trở lạivòng lặp outer poll()

Xem Poller_sigio (cc, h) cho một ví dụ về cách sử dụng rtsignals thay thế với nhiều chiến lược thông báo sẵn sàng khác (other readiness notification schemes)

Xem phhttpd của Zach Brown có mã nguồn ví dụ mà sử dụng tính năng này trực

tiếp (Nếu không; khó hình dung ra vềphhttpd)

[Provos, Lever, và Tweedie 2000] mô tả một chuẩn mực mới của phhttpd sử dụng một biến thể của sigtimedwait (), sigtimedwait4 (), cho phép bạn lấy nhiều tín hiệu với một lời gọi hàm Điều thú vị là lợi ích chủ yếu của sigtimedwait4 () cho họ dường như là

nó cho phép các ứng dụng để đánh giá hệ thống quá tải (vì vậy nó có thể hành xử một cách thích hợp) (Lưu ý rằng poll() cung cấp các phép đo tương tự của hệ thống quá tải.)

Signal-per-fd

Chandra và Mosberger đề xuất một sửa đổi cho các phương pháp tiếp cận tín hiệu thời gian thực được gọi là "tín hiệu cho mỗi fd" (signal-per-fd)cái mà làm giảm hoặc loại

bỏ thời gian thực tín hiệu tràn hàng đợi bởi kết hợp các sự kiện dư thừa

Mặc dù vậy, nó không tốt hơn epoll Bài báo của họ (www.hpl.hp.com/techreports/2000/HPL-2000-174.html) so sánh hiệu suất của chương trình này với select() và /dev poll

Vitaly Luban công bố một bản vá thực thi chiến lược nàyvào 18 tháng 5 năm 2001;

Bản vá của ông có tại www.luban.org/GPL/gpl.html (Lưu ý: vào tháng 9 năm 2001, có

thể vẫn còn vấn đề vềtính ổn định với bản vá này dưới tải trọng nặng dkftpbenchat tại

4500 người dùng có thể kích hoạt một các thao tác.)

Xem Poller_sigfd (cc, h) cho một ví dụ về cách sử dụng signal-per-fd thay thế cho nhiều chương trình thông báo sẵn sàng khác

3) Phục vụ nhiều Clients với mỗi tiến trình server, và sử dụng Asynchronous I/O

Trang 34

Điều này vẫn chưa trở thành phổ biến trong Unix, có lẽ vì vài hệ điều hành hỗ trợ đồng bộ I/O, cũng có thể bởi vì nó (như không chặn I/O) yêu cầu xem xét lại ứng dụng của bạn Theo tiêu chuẩn Unix, I/O không đồng bộ được cung cấp bởi aio_interface, trong

đó liên kết một tín hiệu và giá trị so với từng thao tác I/O Tín hiệu và giá trị của chúng được xếp hàng đợi và chuyển giao hiệu quả cho tiến trình người dung (user process) Điều này là từ các phần mở rộng thời gian thực 1003.1b POSIX, và cũng là trong Mô tả kỹ thuật Single Unix, phiên bản 2

AIO thường được sử dụng với thông báo hoàn thành edge-triggered, tức là một tín hiệu được xếp hàng đợi khi thao tác được hoàn tất (Nó cũng có thể được sử dụng với mức độ kích hoạt thông báo hoàn thành bằng cách gọi aio_suspend.)

glibc 2.1 và phiên bản cao hơn cung cấp một thực thi tổng thể bằng văn bản về việc tuân thủ các tiêu chuẩn hơn hiệu suất

Thực thi của Ben LaHaise cho Linux AIO đã được sáp nhập vào hạt nhân Linux phiên bản 2.5.32 Nó không sử dụng kernel threads, và có một underlying api rất hiệu quả, nhưng (tại phiên bản 2.6.0-test2) không hỗ trợ sockets (Ngoài ra còn có một bản vá AIOcho kernel 2.4, nhưng việc thực hiện trên 2.5/2.6 là hơi khác nhau.) Thông tin thêm:

• Trang "hạt nhân không đồng bộ I/O (AIO) Hỗ trợ cho Linux" mà cố gắng để kết hợp chặt chẽ tất cả các thông tin về việc thực thi của nhân 2.6 của AIO (đăng vào 16 Tháng 9 năm 2003) (http://lse.sourceforge.net/io/aio.html)

• Round3: aio vs /dev/epoll bởi Benjamin C.R.La Haise

(http://www.linuxsymposium.org/)

• Asynchronous IO support trong Linux 2.5, bởi Bhattacharya, Pratt, Pulaverty

và Morgan, IBM, thuyết trình lại OLS' 2003

• Design notes trên Asynchronous I/O (AIO) cho Linux bởi Suparna

Bhattacharya, so sánh Ben's AIO với SGI's KAIO và 1 số dự án AIO khác

• Linux AIO home page - Bản vá lỗi sơ bộ của Ben, mailing list …

• Bản lưu linux aio mailling list

• Libaio-oracle: thư viện thực thi Posix AIO chuẩn trên đầu trang của libaio

Suparna cũng đề xuất có 1 cái nhìn tại tiếp cận của DAFS API về AIO

Red Hat AS và Suse SLES cả 2 cùng cung cấp 1 thực thi hiệu năng cao (high performance implementation) trên nhân 2.4; Nó liên quan đến (một cách không giống hệt toàn bộ) với thực thi của nhân 2.6

Trang 35

Vào tháng 2 năm 2006, một nỗ lực mới được tạo ra để cung cấp Network AIO; xem chú thích bên trên về AIO dựa trên nhân của Evgeniy Polyakov.

Vào 1999, SGI implemented tốc độ cao AIO cho Linux Tại version 1.1, nó được nói là tốt với cả đĩa I/O và sockets Nó trông có vẻ sử dụng kernerl threads Nó cũng hữu dụng cho những người mà không thể đợi AIO của Ben để hỗ trợ sockets

Cuốn sách của O'Reilly POSIX 4: Lập trình cho thế giới thực (Programming for the Real world) được nói rằng bao gồm 1 giới thiệu tốt về AIO

Một hướng dẫn có từ trước đó, không chuẩn hóa, thực thi AIO trên Solaris trực tuyến tại Sunsite Nó có thể có giá trị về mặt hình thức, nhưng hãy lưu ý bạn có thể cần chuyển đổi trong tâm trí từ "aioread" thành "aio_read", …

Chú ý rằng AIO không cung cấp con đường để mở các file mà không blocking disk I/O Nếu bạn có thể care về sự tạm dừng gây ra bởi việc mở file, linux gợi ý bạn có thể

đơn giản là gọi open() trong 1 thread khác thay vì mong muốn 1 lời gọi hệ thống aio_open().

Trên nền tảng Window, I/O bất đồng bộ liên đới đến thuật ngữ "Overlapped I/O"

và IOCP hoặc "I/O Completion Port" IOCP của Microsoft tổ hợp kỹ thuật từ trước như I/O bất đồng bộ (vd aio_write) và cảnh báo kết thúc hàng đợi (queued completion notification) (như sử dụng aio_sigevent field với aio_write) và 1 ý tưởng mới của nắm giữ một số truy vấn để giữ số lượng tiến trình đang chạy liên quan đến 1 hằng số IOCP Xem

thêm thông tin tại Inside I/O completion ports bởi Mark Russinovich tại sysinternals.com Cuốn sách của Jeffery Richter "Programming Server-Side Applications for Microsoft Windows 2000".

4) Phục vụ một Client với mỗi server thread.

Trang 36

Thiết lập lệnh read() và write() BLOCK Có sự không lợi ích của việc sử dụng toàn

bộ stack frame cho mỗi client, gây tốn bộ nhớ Nhiều OS cũng có vấn đề handling (xử lý) nhiều hơn vài trăm Thread Nếu mỗi thread ngốn 2Mb bộ nhớ ngăn xếp (1 con số thông thường), bạn sẽ hết "bộ nhớ ảo" (virtual memory) tại 2^30/2^21 = 512 threads trên 1 máy 32bit với 1GB user-accessible VM (giống như, thông thường linux được shipped trên nền x86) Bạn có thể làm điều này bằng cách cho mỗi thread 1 ngăn xếp bé hơn, nhưng khi

mà hầu hết thư viện tiến trình không cho phép tăng thread stack mỗi khi được tạo ra, làm việc đó nghĩa là việc thiết kế chương trình của bạn để tối ưu bộ nhớ sử dụng Bạn cũng có thể làm việc này bằng các chuyển đổi về bộ xử lý 64 bit

Sự hỗ trợ tiến trình trong Linux, FreeBSD, và Solaris đang tiến triển, và bộ xử lý

64 bit là đâu đó ở đường biên ngay cả với người dùng chính Có lẽ trong tương lai không quá xa, những người mà thích sử dụng 1 thread cho mỗi client sẽ có khả năng sử dụng mô hình này cho 10K clients Tuy nhiên, tại thời điểm này, nếu bạn thực sự muốn hỗ trợ nhiều clients đến thế, tốt hơn là sử dụng các mô hình khác

Linux Threads

Linux thread là tên của 1 thư viện tiến trình chuẩn Linux Nó được tích hợp vào glibc từ glibc2.0, và hầu như phục vụ Linux, nhưng với hiệu năng không ưu tú và hỗ trợ tín hiệu (signal)

NGPT: Tiến trình Posix thế hệ mới cho Linux

NGPT là 1 project bắt đầu bởi IBM để mang hỗ trợ tiến tình Post-compliant tốt vào Linux Nó là 1 phiên bản ổn định 2.2 hiện tại, và chạy tốt Nhưng team NGPTđã thông báo rằng họ đang đưa NGPT codebase về chế độ chỉ hỗ trợ (support-only mode) - họ cho rằng đó là cách tốt nhất để hỗ trợ cộng đồng Linux trong giai đoạn dài Team NGPT sẽ tiếp tục làm việc để cải tiến Linux thread, nhưng hiện giờ tập trung vào tăng cường NPTL (Kudos đến NGPT team cho công việc của họ và cách lich sự mà họ thừa nhận NPTL.)

NPTL: Thư viện tiến trình nguyên bản (Native Posix Thread Library) Posix cho Linux

NPTL là 1 dự án bởi Ulrich Drepper và Ingo Molnar để mang hỗ trợ tiến trình

"đẳng cấp thế giới" vào Linux

Vào 5/10/2003, NPTL được ghép vào cây cvs glibc và 1 thư mục add-on (ví dụ linux threads), vì thế nó sẽ hầu như hiển nhiên được Release cùng với bản Release tiếp theo của glibc

Trang 37

Phiên bản phân phối chính đầu tiên mà bao gồm 1 snapshot của NPTL là Red Hat

9 (Có 1 chút bất tiện với người dùng, nhưng 1 số người cần 'break the ice' - phá băng)

Các liên kết của NPTL:

• Mailing list cho thảo luận của NPTL

• Mã nguồn của NPTL

• Phát ngôn đầu tiên cho NPTL

• Bài báo nguyên bản mô tả thiết kế chốt của NPTL

• Bài báo đánh giá lại mô tả thiết kế cuối cùng của NPTL

• Đo đạc của Ingo Molnar chỉ ra nó có thể nắm giữ 10^6 thread

• Đo đạc của Ulrich so sánh hiệu năng của Tiến trình Linux, NPTL và IBM NGPT

Nó có vẻ đưa ra NPTL nhanh hơn NGPT

Mô tả lịch sử của của NPTL

Vào tháng 3-2002, Bill Abt của nhóm NGPT, glibc maintainer Ulrich Drepper, và một số người khác gặp để hình dung cái gì cần làm với Linux Threads Một ý tưởng đưa

ra tại cuộc họp để tăng cường hiệu năng của mutex; Rusty Russel và cộng sự sau đó thực thi mutex không gian người dùng nhanh (fast userspace mutexes (futexes)), cái mà bây giờ được dùng cho NGPT và NPTL Hầu hết người dự mường tượng NGPT nên được sát nhập vào glibc

Ulrich Drepper, mặc dù vậy, không thích NGPT, và miêu tả anh ta có thể làm tốt hơn (Với những người đã từng thử đóng góp 1 phiên bản vào glibc, đó không phải là sự ngạc nhiên lớn) Sau vài tháng, Ulrich Drepper, Ingo Molnar và 1 số người đóng góp cho glibc và nhân thay đổi mà làm ra 1 thứ gọi là Native Posix Threads Library (NPTL) NPTL sử dụng mọi cải tiến của kernel thiết kế cho NGPT, và lấy lợi thế cho một số cái mới Ingo Molnar mô tả cải tiến như sau:

Trong khi NPTL sử dụng 3 tính năng nhân được giới thiệu trong NGPT: getpid() trả về PID< CLONE_THREAD và futexes; NPTL cũng sử dụng (và dựa trên) một tập cao hơn tính năng nhân, phát triển như một thành phần của dự án.

Một số mục NGPT giới thiệu về nhân xung quanh 2.5.8 được sửa đổi, làm sạch và mở rộng, như là nắm giữ nhóm tiến trình (thread group handling) (CLONE_THREAD) [Việc thay đổi CLONE_THREAD mà ảnh hưởng tới sự tương thích NGPT được đồng

bộ với NGPT folks, để chắc rằng NGPT không đi vào bất kỳ con đường sai lầm nào]

Trang 38

Tính năng lõi nhân cho và sử dụng bởi NPTL được mô tả trong bài báo thiết kế (design white paper) http://people.redhat.com/drepper/nptl-design.pdf

1 danh sách: hỗ trợ TLS, đa clone mở rộng (CLONE_SETTLS, CLONE_SETID, CLONE_CREATEID), nắm giữ tín hiệu tiến trình Posix, mở rộng sys_exit() (hoàn thiện TID futex upon VM release), lời gọi sys_exit_group(), cải thiện sys_execve() và hỗ trợ cho thread được detach.

Nó cũng đưa vào việc mở rộng không gian PID - ví vị procfs bị hỏng ngắt bởi vì giả thuyết 64K PID, max_pid, và việc cấp phát pid làm việc khả mở Cộng thêm 1 số của cải tiến đã làm rất tốt

Về bản chất, tính năng mới là không tiếp cận so sánh 1:1 với tiến trình, nhân lõi bây giờ hỗ trợ bất kỳ thứ gì nơi mà nó có thể cải tiến tiến trình Và chúng ta chính xác là làm những nhu cầu tối thiểu tập hợp context switches, và lời gọi nhân lõi cho mọi nguyên thủy về cơ bản của tiến trình.

Một sự khác nhau lớn giữa 2 thứ đó là NPTL là mô hình tiến trình 1:1, trong khi NGPT là

1 mô hình tiến trình M:N (xem ở dưới) Mặc dù như vậy, sự đo đạc ban đầu của Ulrich có

vẻ chỉ ra rằng NPTL thực sự là nhanh hơn NGPT

Hỗ trợ tiến trình Free BSD

FreeBSD hỗ trợ cả Linux Threads và 1 thư viện tiến trình không gian người dùng Cũng thế, một thực thi M:N gọi đến KSE được giới thiệu trong Free BSD 5.0

Vào 25-03-2003, Jeff Roberson đăng tải 1 bài viết trên freebsd-arch:

Nhờ tổ chức cung cấp bởi Julian, David Xu, Mini, Dan Eischen và mọi người khác đã tham gia với KSE và phát triển libpthread Mini và tôi đã phát triển 1 thực thi tiến trình 1:1 Mã nguồn này làm việc song song với KSE và không phá vỡ nó theo bất cứ cách nào Nó thực tế mang lại tiến trình M:N gần hơn bởi kiểm thử shared bit

Vào tháng 7-2006, Robert Watson đề xuất 1 cái thực hiện 1:1 tiến trình mặc định trong FreeBsd 7.x:

Tôi biết điều này đã được tranh cãi trong quá khứ, nhưng tôi hình dung 7.x đang lăn tới, đây là thời điểm để nghĩ về nó nữa Trong đo đạc với nhiều ứng dụng thông thường

và kịch bản, libthr mô tả hiệu năng tốt hơn rất nhiều libpthread libthr cũng thực thi

Trang 39

chéo 1 số lượng lớn nền tảng khác Tiến cử đầu tiên mà chúng tôi là với MySQL và những người dùng tiến trình siêu trọng đó là "Đổi sang dùng libthr", đó cũng là gợi ý!

Và đề nghị của strawman đó là: làm cho libthr là thư viện tiến trình mặc định trên 7.x.

Trang 40

Hỗ trợ tiến trình Net BSD

Theo một ghi chú của Noriyuki Soda:

Nhân-lõi hỗ trợ tiến trình M:N dựa trên mô hình Scheduler Activations (Kích hoạt thời gian biểu) được gộp vào NetBSD vào 2003-01-18

Để xem chi tiết xem, 1 thực thi của kích hoạt thời gian biểu trên hệ điều hành NetBSD viết bởi Nathan J Wiliams, Wasabi System Inc, thuyết trình tại FREENIX 02

Hỗ trợ tiến trình Solaris

Hỗ trợ tiến trình trong Solaris đang tiến triển từ Solaris 2 đến Solaris 8, thư viện tiến trình mặc định sử dụng mô hình M:N, nhưng Solaris 9 sử dụng hỗ trợ tiến trình mặc định 1:1 Xem hướng dẫn lập trình đa tiến trình cho Sun và Ghi chú của Sun về Java và tiến trình Solaris

Hỗ trợ tiến trình Java trong JDK 1.3.x và cũ hơn

Được biết rộng rãi, Java tới JDK 1.3.x không hỗ trợ bất kỳ phương thức nào để nắm giữ kết nối mạng mà nhiều hơn 1 thread mỗi client Volanomark là một siêu đo đạc (microbenchmark) mà đo đạc thông lượng trong thông điệp trên mỗi giây tại số lượng lớn nhiều kết nối đồng thời Vào tháng 5-2003, Thực thi JDK 1.3 từ nhiều nhà cung cấp, thực

tế là có khả năng nắm giữ 10K kết nối đồng thời, mặc dầu với sự giảm mạnh về hiệu năng Xem bảng 4 (của Volano) cho ý tưởng JVM nào có thể nắm giữ 10K kết nối, và làm thế nào hiệu năng chịu đựng khi mà số kết nối tăng lên

Ghi chú: Tiến trình 1:1 so với tiến trình M:N

Có 1 sự lựa chọn khi thực thi thư viện tiến trình: bạn có thể vừa đưa tất cả hỗ trợ tiến trình vào Nhân-lõi (gọi là mô hình tiến trình 1:1), hoặc bạn có thể dịch chuyển 1 ít vào không gian người dùng (cái này gọi là mô hình tiến trình M:N) Có 1 điều, M:N được tin rằng có hiệu năng cao hơn, nhưng nó quá phức tạp để mà khó làm đúng, và hầu hết mọi người rời khỏi nó

• Tại sao Ingo Molnar thích 1:1 hơn M:N

• Sun dịch chuyển về tiến trình 1:1

• NGPT là thư viện tiến trình M:N cho Linux

• Mặc dầu Ulrich Drepper có kế hoạch sử dụng tiến trình M:N trong thư viện tiến trình M:N, ông ấy đã chuyển đổi về mô hình 1:1

• MacOSX thể hiện sử dụng tiến trình 1:1

Ngày đăng: 30/11/2015, 12:09

HÌNH ẢNH LIÊN QUAN

Hình . Ajax long poll - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Ajax long poll (Trang 14)
Hình . Server-sent-events - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Server-sent-events (Trang 15)
Hình . Websocket - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Websocket (Trang 16)
Hình . Benchmark Nginx, node, tornado, thin - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Benchmark Nginx, node, tornado, thin (Trang 62)
Hình . Biểu đồ Benchmark Nginx, thin, tornado, node - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ Benchmark Nginx, thin, tornado, node (Trang 63)
Hình . Biểu đồ benchmark Nginx,thin,tornado - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ benchmark Nginx,thin,tornado (Trang 64)
Hình . Biểu đồ Benchmark nginx, thin, tornado, node theo response time - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ Benchmark nginx, thin, tornado, node theo response time (Trang 65)
Hình . Biểu đồ benchmark Nginx, thin, tornado, node_buffer - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ benchmark Nginx, thin, tornado, node_buffer (Trang 67)
Hình . Biểu đồ thời gian phản hồi - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ thời gian phản hồi (Trang 77)
Hình . Biểu đồ tốc độ truyền dữ liệu (MBps) - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ tốc độ truyền dữ liệu (MBps) (Trang 78)
Hình . Biểu đồ tốc độ truyền dữ liệu (Byte-rate) - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Biểu đồ tốc độ truyền dữ liệu (Byte-rate) (Trang 81)
Hình . Mô hình tổng quát 13instant - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Mô hình tổng quát 13instant (Trang 89)
Hình . Use case 13Instant - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Use case 13Instant (Trang 90)
Hình . Trang newsfeed của 13Instannt - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Trang newsfeed của 13Instannt (Trang 97)
Hình . Instant chat của 13instant - Thử nghiệm triển khai dịch vụ web hướng thời gian đáp ứng tức thời qua công nghệ nodejs
nh Instant chat của 13instant (Trang 98)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w