2011-12-02 40 views
5

Tôi sử dụng node.js để gửi yêu cầu http. Tôi có một yêu cầu để đo thời gian cần thiết.đo thời gian yêu cầu http với node.js

start = getTime() 
http.send(function(data) {end=getTime()}) 

Nếu tôi gọi getTime bên trong gọi lại phản ứng http, có rủi ro mà callback của tôi không được gọi ngay lập tức khi phản ứng cames lại do các sự kiện khác trong hàng đợi. Rủi ro như vậy cũng tồn tại nếu tôi sử dụng mã đồng bộ java hoặc C# thông thường cho tác vụ này, vì có thể một luồng khác đã nhận được sự chú ý trước tôi.

start = getTime() 
http.send() 
end=getTime() 

Làm thế nào để node.js so sánh với nền tảng khác (đồng bộ) - liệu cơ hội của tôi có tốt hơn hoặc tệ hơn không?

+0

Bạn không thể làm điều này mà không có mức độ thấp (C++) móc trực tiếp vào vòng lặp sự kiện – Raynos

+0

bạn có nghĩa là tôi cần phải tự mình triển khai mô-đun http hoặc có một số cơ chế mở rộng mà tôi có thể sử dụng không? –

+4

Tôi có nghĩa là bạn muốn biết _exactly_ khi gói tcp thô quay lại. Không có cách nào để thực hiện việc này, sau đó đợi trình xử lý http của bạn được gọi. Chỉ có một lượng nhỏ độ trễ giữa hai (một lượng không đáng kể so với thời gian lưu lượng mạng). – Raynos

Trả lời

1

Quan sát tuyệt vời!

Theory:

Nếu bạn đang thực hiện vi điểm chuẩn, có tồn tại một số cân nhắc mà khả năng có thể nghiêng đo:

  1. Các sự kiện khác trong vòng lặp sự kiện đó đã sẵn sàng để bắn cùng với http gửi trong câu hỏi, và được thực hiện tuần tự trước khi gửi có được một cơ hội - nút cụ thể.

  2. Chuyển đổi luồng/quá trình có thể xảy ra bất kỳ lúc nào trong khoảng thời gian gửi hoạt động - chung chung.

  3. Bộ đệm I/O của hạt nhân có khối lượng hạn chế gây ra sự chậm trễ tùy ý - Hệ điều hành/tải công việc/tải hệ thống cụ thể.

  4. Độ trễ phát sinh trong việc thu thập thời gian hệ thống - ngôn ngữ/thời gian chạy cụ thể.

  5. Chunking/Buffering dữ liệu: socket [http implementation] cụ thể.

Thực hành:

Noe bị (1), trong khi một sợi chuyên dụng của Java/C# không có vấn đề này. Nhưng khi nút triển khai mô hình I/O không bị chặn theo sự kiện, các sự kiện khác sẽ không gây ra các hiệu ứng chặn, thay vào đó sẽ được đặt vào hàng đợi sự kiện. Chỉ những cái đã sẵn sàng sẽ bị sa thải và độ trễ phát sinh do chúng sẽ là chức năng của công việc I/O mà chúng phải thực hiện, và bất kỳ hành động CPU nào được thực hiện trong callback liên quan của chúng. Trên thực tế, những thực tế này sẽ trở nên không đáng kể và được so sánh trong so sánh, do các hiệu ứng có thể nhìn thấy nhiều hơn (2) đến (5). Ngoài ra, viết thường không chặn, có nghĩa là chúng sẽ được thực hiện mà không cần đợi lặp vòng lặp tiếp theo để chạy. Và cuối cùng, khi viết được thực hiện, gọi lại được ban hành trong dòng và tuần tự, không có năng suất cho một sự kiện ở giữa. Trong ngắn hạn, nếu bạn so sánh một luồng Java chuyên dụng đang thực hiện chặn I/O với mã Node, bạn sẽ thấy các phép đo Java tốt, nhưng trong các ứng dụng quy mô lớn, nỗ lực chuyển đổi ngữ cảnh luồng sẽ bù đắp lợi ích này và nút hiệu suất sẽ nổi bật.

Hy vọng điều này sẽ hữu ích.

Các vấn đề liên quan