Mình cũng từng làm cách như bạn r, chỉ khác là vì mình trả về dùng websocket chứ ko dùng push thôi Cách đó mình thấy ok, không phải giữ connection quá nhiều trên server, nhưng do leader bên mình làm bên iOS không thích cách đó, chỉ muốn request và nhận response đều bằng API hết, vậy mới mệt

Mình nghĩ vấn đề thực sự nằm ở trưởng nhóm của bạn.

Long Polling không phải là một công nghệ mới. Nó thực chất chỉ là một giải pháp không chính thống (hacky solution) để giải quyết vấn đề giao tiếp 2 chiều (bidirectional communication) do HTTP chỉ có thể giao tiếp 1 chiều. Long Polling AJAX khởi tạo kết nối HTTP và giữ kết nối tồn tại trong một khoảng thời gian để chờ phản hồi. Chính vì lẽ đó mà việc xử lý bằng Long Polling thường tốn CPU, độ trễ cao (high latency), phức tạp và kém trong việc xử lý nhiều client (scaling).

WebSocket được thiết kế để xử lý thời gian thực (realtime) và thay thế các giải pháp giao tiếp 2 chiều không chính thống hiện tại, trong đó có Long Polling. Khi thực hiện một kết nối bằng giao thức HTTP, các dữ liệu như headers, cookies và các dữ liệu khởi tạo khác, được gửi kèm ở mỗi kết nối. Trong khi đó, WebSocket được xây dựng trên nền tảng giao thức TCP và chỉ thực hiện khởi tạo kết nối một lần duy nhất trong một phiên sử dụng. Điều này giúp WebSocket giảm tối đa độ trễ do khởi tạo kết nối (latency) và loại bỏ hầu hết các dữ liệu HTTP không cần thiết. Ngoài ra, với WebSocket, sau khi kết nối được khởi tạo thành công, client hoặc server có thể gửi phản hồi ở bất cứ một thời điểm nào mà không cần phải chờ đợi tín hiệu từ bên còn lại. Khả năng này mang lại sự vượt trội cho WebSocket so với Long Polling ở cả việc giảm độ trễ của phản hồi lẫn CPU cycle cần thiết. Hơn nữa, ở thời điểm hiện tại, WebSocket là giải pháp tốt nhất để xử lý một lượng lớn client.

Để kết luận, mình khẳng định là không có lí do gì để sử dụng Long Polling thay cho WebSocket.

Bạn có thể tham khảo thêm ở các đường link chính thức dưới đây:
[1] http://www.websocket.org/quantum.html
[2] http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax-vs-webrtc-vs-server-sent-events
[3] http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet

Phiên bản Node.js LTS (Long Term Support), hay còn gọi là "Argon", là phiên bản chú trọng vào tính ổn định (stability), bảo mật (security) và tuổi thọ (lifespan). Khi một phiên bản Node.js được đưa vào LTS thì đồng nghĩa với việc sẽ không có một tính năng mới nào được cập nhật ở phiên bản đó. Thay vào đó sẽ là những thay đổi trong sửa lỗi, cập nhật bảo mật, cập nhật phiên bản npm và cải thiện hiệu năng (performance). Node.js LTS nhìn chung sẽ được kiểm tra rất cẩn thận và kỹ lưỡng trước mỗi một lần xuất bản. Phiên bản LTS sẽ được xuất bản 12 tháng một lần và được bảo trì thêm 18 tháng sau ngày hết hạn. Theo tính toán trên thì phiên bản LTS v6.x sẽ được xuất bản vào khoảng tháng 10 năm nay.

Trong khi đó, Node.js Stable chú trọng vào cập nhật tính năng và những thay đổi mới nhất. Phiên bản này sẽ được cập nhật khoảng 2 tuần đến 1 tháng một lần. Lưu ý là phiên bản này mặc dù chú trọng cập nhật nhưng vẫn là một phiên bản Stable, không phải Beta. Do đó mức độ ổn định là đủ cho mục đích sử dụng thông thường.

Nguồn gốc của việc chia phiên bản là do hiện tại Node.js không còn chịu sự quản lý của Joyent (công ty sở hữu Node.js trước kia), mà thay vào đó là Node.js Foundation, hoạt động dựa trên mô hình quản lý governance. Node.js Foundation hiện hoạt động dưới sự quản lý trực tiếp của Linux Foundation. Bạn có thể thấy cách chia phiên bản này tương đối giống với cách chia phiên bản của hệ điều hành Ubuntu mặc dù tuổi thọ của mỗi phiên bản có ngắn hơn.

Tùy thuộc vào mục đích sử dụng để lựa chọn phiên bản phù hợp. Nếu bạn cần sự ổn định và bảo mật ở mức độ cao nhất thì nên lựa chọn phiên bản LTS. Phiên bản này thường phù hợp với mục đích sử dụng của các công ty hay tập đoàn lớn. Còn nếu bạn yêu thích những tính năng mới, đặc biệt là tính năng mới của Javascript thì bạn nên lựa chọn phiên bản Stable. Cá nhân mình lựa chọn phiên bản Stable. Mình đã sử dụng phiên bản này được hơn nửa năm nay và chưa thấy có vấn đề gì đáng kể.

Bạn có thể tham khảo qua đường link chính thức dưới đây:
[1] https://nodejs.org/en/blog/community/node-v5/
[2] https://github.com/nodejs/LTS
[3] https://nodejs.org/en/blog/release/v5.0.0/
[4] https://nodejs.org/en/blog/release/v4.2.0/
[5] http://stackoverflow.com/questions/33661274/difference-between-4-x-lts-and-5-x-stable-nodejs-versions

Sự chậm trễ trong thực thi kết nối thứ 2 trong ví dụ mà bạn đưa ra xuất phát từ việc tác vụ CPU chuyên sâu ở kết nối thứ nhất và tác vụ xử lý kết nối thứ 2 đều được thực thi bởi một luồng (thread) duy nhất. Điều này là hoàn toàn bình thường và hợp lý.

Mình xin lấy một ví dụ để bạn dễ hiểu hơn.
Giả sử bạn đang làm việc cho một công ty với tư cách là một developer. Vào một hôm đẹp trời, thay vì thuê thêm nhân viên, sếp của bạn quyết định giao toàn bộ công việc của công ty đó cho bạn. Từ việc quét nhà, dọn dẹp, đến việc viết báo cáo, lập trình hay đi hội thảo. Tất cả các việc do một mình bạn đảm đương. Bạn có cho rằng bạn sẽ hoàn thành toàn bộ công việc đó nhanh như khi bạn chỉ phải làm duy nhất một công việc là lập trình? Câu trả lời chắc chắn sẽ là không. Để đảm bảo về mặt thời gian, việc bạn cần làm là yêu cầu sếp thuê thêm người làm và bố trí lại công việc cho phù hợp.

Quay lại với ví dụ mà bạn đưa ra, việc tất cả các tác vụ được thực thi bởi một luồng duy nhất rất giống với ví dụ minh họa trên. Trên thực tế, những tác vụ I/O (I/O tasks) hoặc tác vụ CPU chuyên sâu (CPU intensive tasks) thường hoặc nên được thực thi ở một luồng khác. Việc này giúp chúng ta tránh được thời gian phải chờ đợi trong quá trình các tác vụ đó được thực thi. Và khi các tác vụ đó được thực thi trên một luồng khác, chúng ta cũng cần biết khi nào thì các chúng được bắt đầu, được thực thi, hay đã thực thi xong thông qua việc sử dụng Event để gửi tín hiệu thông báo ngược trở lại luồng chính về trạng thái của quá trình thực thi. Quá trình này cứ được lặp đi lặp lại như vậy nên thường được gọi là mô hình Event Loop. Javascript không phải là ngôn ngữ duy nhất áp dụng mô hình này.

Bên cạnh đó, việc nói Nodejs đơn luồng là không thực sự chính xác. Thực chất, chỉ có đoạn code mà bạn viết ra ở tầng ứng dụng (application layer) là được thực thi đơn luồng. Phía sâu bên trong Nodejs, các tác vụ I/O hay CPU chuyên sâu đa số được thực thi đa luồng, và được viết bằng các ngôn ngữ khác không phải Javascript (C, C++,...).

Để kết luận, mình muốn khẳng định rằng Event Loop chỉ là một trong những mô hình được thiết kế cho việc quản lý các tác vụ không đồng bộ đòi hỏi nhiều thời gian thực thi thông qua công cụ Event. Nó không phải là một phép màu mang lại sự cải thiện về tốc độ. Cái chính vẫn nằm ở khả năng lập trình, khả năng quản lí và xử lý tác vụ một cách hợp lý của các developer.

@Quốc-Cường đã nói:

• Ý mình là hãy dùng cái gì có sẵn , đừng quá đi sâu vào bên trong bản chất của 1 ngôn ngữ làm gì.
• Chúng ta biết tiếng Viết rồi cần quái gì học tiếng Anh nữa.

2 lời khuyên tồi tệ nhất mà mình từng nghe. Mình nghĩ bạn cần nghiêm túc xem xét lại quan điểm học của bạn.

Trước tiên, bạn cần hiểu được nguyên nhân của tình trạng trên.

Một biến được định nghĩa bằng từ khóa var sẽ tồn tại trong phạm vị một hàm (function scope). Do vậy, ở ví dụ của bạn, biến k sẽ bị ghi đè sau mỗi một vòng lặp. Mặt khác, request là một hàm không đồng bộ (async function) nên ở thời điểm hàm này được thực thi thì vòng lặp đã được thực thi xong và biến k có giá trị là 10 (giá trị của vòng lặp cuối cùng).

Có 3 cách để giải quyết vấn đề:

• Closure
  • Nhược điểm là code khó đọc và tốn bộ nhớ.

for(var k=1; k<=10; k++){
    (function(i){
        var url = 'http://www.24h.com.vn/'+i;
        request(url, function(err, response, body){
            console.log(i);
        });
    })(k)
}

• Recursion (hồi quy)
  • Nhược điểm là chậm, do các hàm không đồng bộ, thay vì được thực thi song song, sẽ được thực thi có thứ tự.

function next(i) {
    if (i > 11)  return;
    var url = 'http://www.24h.com.vn/' + i;
    request(url, function (err, response, body) {
        console.log(i);
        next(++i);
    });
}
next(1);

• Định nghĩa biến bằng từ khóa let
  • Đây là giải pháp tốt nhất trong trường hợp này. Nhược điểm duy nhất của phương pháp này là từ khóa let hiện tại chỉ có sẵn ở strict mode. Từ khóa let sẽ định nghĩa một biến mà phạm vị tồn tại của nó chỉ trong một cặp block (block scope). Do đó biến sẽ không bị ghi đè qua các vòng lặp.

//kích hoạt strict mode
'use strict';
for(let i=1; i<=10; i++){
        var url = 'http://www.24h.com.vn/'+i;
        request(url, function(err, response, body){
            console.log(i);
        });
}

Lỗi này có thể do nhiều nguyên nhân. Nhưng nguyên nhân cốt lỗi thường là:

• MySQL server không nghe kết nối trên cổng 3306.
  MySQL có thể nghe kết nối qua unix socket hoặc bất kì một cổng nào khác tùy thuộc vào cài đặt. Trường hợp MySQL server nghe kết nối qua unix socket, bạn có thể sử dụng thuộc tính socketPath thay cho thuộc tính host và port của module node mysql để kết nối đến server. Đường dẫn tới file socket trên Linux thường là /var/run/mysqld/mysqld.sock. Trường hợp MySQL server đang nghe kết nối trên một cổng khác, bạn chỉ cần đổi sang cổng đó là được.

• Đã tồn tại kết nối tới MySQL server ở cổng 3306.
  Lỗi này thường do copy gây lặp code dẫn đến việc MySQL server từ chối kết nối đã tồn tại. Để sửa lỗi này, bạn cần tiến hành rà soát lại và loại bỏ đoạn code gây ra lặp kết nối.

• Firewall chặn kết nối tới cổng 3306.
  Trường hợp này hiếm khi xảy ra do cổng 3306 là cổng mặc định của MySQL server, một database server rất nổi tiếng trên thế giới. Do đó không có firewall của OS nào chặn cổng này ở chế độ mặc định. Vấn đề này thường chỉ xảy ra do lỗi chủ quan từ phía developer, chỉnh sửa firewall khác với mặc định. Và hiển nhiên, để sửa lỗi này, bạn cần chỉnh sửa lại quy tắc lọc của firewall để cho phép cổng này hoạt động.

Mong bài viết này giúp ích được cho bạn.

Khi đặt câu hỏi về vấn đề này, bạn cần đưa ra hình ảnh trước và sau khi resize, câu lệnh mà bạn sử dụng để resize và mô tả ảnh kỳ vọng. Có như vậy thì người đọc mới có thể hiểu và đưa ra câu trả lời tốt nhất cho bạn.

Sự chậm trễ trong thực thi kết nối thứ 2 trong ví dụ mà bạn đưa ra xuất phát từ việc tác vụ CPU chuyên sâu ở kết nối thứ nhất và tác vụ xử lý kết nối thứ 2 đều được thực thi bởi một luồng (thread) duy nhất. Điều này là hoàn toàn bình thường và hợp lý.

Mình xin lấy một ví dụ để bạn dễ hiểu hơn.
Giả sử bạn đang làm việc cho một công ty với tư cách là một developer. Vào một hôm đẹp trời, thay vì thuê thêm nhân viên, sếp của bạn quyết định giao toàn bộ công việc của công ty đó cho bạn. Từ việc quét nhà, dọn dẹp, đến việc viết báo cáo, lập trình hay đi hội thảo. Tất cả các việc do một mình bạn đảm đương. Bạn có cho rằng bạn sẽ hoàn thành toàn bộ công việc đó nhanh như khi bạn chỉ phải làm duy nhất một công việc là lập trình? Câu trả lời chắc chắn sẽ là không. Để đảm bảo về mặt thời gian, việc bạn cần làm là yêu cầu sếp thuê thêm người làm và bố trí lại công việc cho phù hợp.

Quay lại với ví dụ mà bạn đưa ra, việc tất cả các tác vụ được thực thi bởi một luồng duy nhất rất giống với ví dụ minh họa trên. Trên thực tế, những tác vụ I/O (I/O tasks) hoặc tác vụ CPU chuyên sâu (CPU intensive tasks) thường hoặc nên được thực thi ở một luồng khác. Việc này giúp chúng ta tránh được thời gian phải chờ đợi trong quá trình các tác vụ đó được thực thi. Và khi các tác vụ đó được thực thi trên một luồng khác, chúng ta cũng cần biết khi nào thì các chúng được bắt đầu, được thực thi, hay đã thực thi xong thông qua việc sử dụng Event để gửi tín hiệu thông báo ngược trở lại luồng chính về trạng thái của quá trình thực thi. Quá trình này cứ được lặp đi lặp lại như vậy nên thường được gọi là mô hình Event Loop. Javascript không phải là ngôn ngữ duy nhất áp dụng mô hình này.

Bên cạnh đó, việc nói Nodejs đơn luồng là không thực sự chính xác. Thực chất, chỉ có đoạn code mà bạn viết ra ở tầng ứng dụng (application layer) là được thực thi đơn luồng. Phía sâu bên trong Nodejs, các tác vụ I/O hay CPU chuyên sâu đa số được thực thi đa luồng, và được viết bằng các ngôn ngữ khác không phải Javascript (C, C++,...).

Để kết luận, mình muốn khẳng định rằng Event Loop chỉ là một trong những mô hình được thiết kế cho việc quản lý các tác vụ không đồng bộ đòi hỏi nhiều thời gian thực thi thông qua công cụ Event. Nó không phải là một phép màu mang lại sự cải thiện về tốc độ. Cái chính vẫn nằm ở khả năng lập trình, khả năng quản lí và xử lý tác vụ một cách hợp lý của các developer.

Lỗi này có thể do nhiều nguyên nhân. Nhưng nguyên nhân cốt lỗi thường là:

• MySQL server không nghe kết nối trên cổng 3306.
  MySQL có thể nghe kết nối qua unix socket hoặc bất kì một cổng nào khác tùy thuộc vào cài đặt. Trường hợp MySQL server nghe kết nối qua unix socket, bạn có thể sử dụng thuộc tính socketPath thay cho thuộc tính host và port của module node mysql để kết nối đến server. Đường dẫn tới file socket trên Linux thường là /var/run/mysqld/mysqld.sock. Trường hợp MySQL server đang nghe kết nối trên một cổng khác, bạn chỉ cần đổi sang cổng đó là được.

• Đã tồn tại kết nối tới MySQL server ở cổng 3306.
  Lỗi này thường do copy gây lặp code dẫn đến việc MySQL server từ chối kết nối đã tồn tại. Để sửa lỗi này, bạn cần tiến hành rà soát lại và loại bỏ đoạn code gây ra lặp kết nối.

• Firewall chặn kết nối tới cổng 3306.
  Trường hợp này hiếm khi xảy ra do cổng 3306 là cổng mặc định của MySQL server, một database server rất nổi tiếng trên thế giới. Do đó không có firewall của OS nào chặn cổng này ở chế độ mặc định. Vấn đề này thường chỉ xảy ra do lỗi chủ quan từ phía developer, chỉnh sửa firewall khác với mặc định. Và hiển nhiên, để sửa lỗi này, bạn cần chỉnh sửa lại quy tắc lọc của firewall để cho phép cổng này hoạt động.

Mong bài viết này giúp ích được cho bạn.

Bạn chỉ cần thay thế process.EventEmitter bằng require('events') thì warning này sẽ biến mất.

Đây là một trong những thay đổi gây lỗi (breaking changes) ở phiên bản Node.js v6 so với phiên bản Node.js v5 trước đó. process.EventEmitter sẽ bị gỡ bỏ hoàn toàn ở phiên bản Node.js v7.

Dưới đây là danh sách các thay đổi gây lỗi tương tự như trên ở phiên bản Node.js v6:
https://github.com/nodejs/node/wiki/Breaking-changes-between-v5-and-v6

P/s. Để nhận được câu trả lời tốt hơn, bạn nên đính kèm đoạn code gây ra warning vào câu hỏi của mình để người trả lời có thể đưa ra câu trả lời chính xác nhất.

Vấn đề này thường do những vòng lặp hoặc hồi quy vô hạn gây ra. Bạn cần cô lập và chạy từng file để kiểm tra xem vòng lặp hay hồi quy nào gây ra tình trạng trên. Dưới đây là một ví dụ về tình trạng 100% CPU usage do developer quên không trả về một callback dẫn đến tình trạng hồi quy vô hạn (endless recursion).

• http://stackoverflow.com/questions/10167477/how-to-debug-node-js-causing-100-cpu-usage

Câu hỏi của bạn vẫn chung chung, mơ hồ và không đủ thông tin để mình có thể đưa ra câu trả lời chính xác. Tốt nhất bạn cần tìm đúng đoạn code gây ra tình trạng trên và đính kèm vào câu hỏi để mọi người có thể dễ dàng giúp bạn.

Quan điểm của mình khi học là cần học từ những nguồn chính thống và đáng tin cậy. Nó sẽ đảm bảo bạn học được kiến thức mới và chính xác nhất. Tuy nhiên, các nguồn tài liệu chất lượng cao hiện tại đều được viết bằng tiếng Anh. Do đó chúng đòi hỏi người đọc phải có trình độ tiếng Anh nhất định. Điều này thường là cản trở lớn đối với các developers của Việt Nam.

Dựa vào tiêu chuẩn trên thì mình sẽ khuyến khích bạn học WebRTC từ những nguồn dưới đây:
Demo
https://webrtc.github.io/samples/
Đường link trên là thư mục chứa đựng tất cả các demo cung cấp bởi WebRTC Team. Đây là những demo chính thống, đầy đủ và được WebRTC Team cập nhật liên tục.
Tutorial
http://www.html5rocks.com/en/tutorials/webrtc/basics/
Bài hướng dẫn trên được viết bởi một trong những người viết API WebRTC trên Chrome là Sam Dutton.
MDN
https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC
Các bài viết trên Mozilla Developer Network luôn có độ chính xác cao, cập nhật liên tục và rất dễ hiểu. MDN được coi là một trong những nguồn tham khảo kiến thức về Web tốt nhất ở thời điểm hiện tại.
Specification (W3C)
https://www.w3.org/TR/webrtc/
Bên trên là bản tiêu chuẩn kỹ thuật của WebRTC. Tất cả các trình duyệt Web khi xây dựng WebRTC API đều phải tuân theo bản tiêu chuẩn kỹ thuật đó. Ưu điểm của nó là thông tin được cập nhật rất nhanh chóng và có độ chính xác gần như tuyệt đối. Nhược điểm là khó đọc, đòi hỏi người đọc phải có kiến thức căn bản về API mà mình đang tìm hiểu.

Mình vẫn chưa rõ về vấn đề kích thước ảnh. Kích thước bạn nhận được là bao nhiêu? Kích thước mong muốn là bao nhiêu?

Còn về vấn đề chất lượng ảnh, hàm scale chú trọng vào performance nên chỉ mặc định sử dụng filter box nên chất lượng ảnh không cao. Nếu bạn quan tâm đến chất lượng ảnh, bạn nên sử dụng hàm resize thay cho scale vì hàm resize sử dụng filter lanczos, chạy chậm hơn nhưng cho chất lượng ảnh tốt hơn rất nhiều.

Lỗi này là do công cụ Visual Studio cần thiết cho C++ chưa được cài đặt trên Windows của bạn.
Để giải quyết vấn đề này, trước hết, bạn cần chạy lệnh npm install --msvs_version=2015 để cần đặt công cụ. Sau đó bạn tiến hành cài đặt module bcrypt như thông thường.

Nguồn tham khảo:
[1] http://stackoverflow.com/questions/32556295/npm-install-error-the-build-tools-for-v120-platform-toolset-v120-cannot
[2] https://github.com/ncb000gt/node.bcrypt.js/issues/260

Khi đặt câu hỏi về vấn đề này, bạn cần đưa ra hình ảnh trước và sau khi resize, câu lệnh mà bạn sử dụng để resize và mô tả ảnh kỳ vọng. Có như vậy thì người đọc mới có thể hiểu và đưa ra câu trả lời tốt nhất cho bạn.

Câu hỏi của bạn quá rộng và chung chung. Có thể có hàng nghìn lỗi dẫn đến tình trạng đó. Bạn cần đi sâu mô tả chi tiết và xử lý từng lỗi một. Để có thể nhận được câu trả lời hữu ích, bạn nên đính kèm các thông tin như đoạn code hay log liên quan ở câu hỏi của mình.

Mình cũng từng làm cách như bạn r, chỉ khác là vì mình trả về dùng websocket chứ ko dùng push thôi Cách đó mình thấy ok, không phải giữ connection quá nhiều trên server, nhưng do leader bên mình làm bên iOS không thích cách đó, chỉ muốn request và nhận response đều bằng API hết, vậy mới mệt

Mình nghĩ vấn đề thực sự nằm ở trưởng nhóm của bạn.

Long Polling không phải là một công nghệ mới. Nó thực chất chỉ là một giải pháp không chính thống (hacky solution) để giải quyết vấn đề giao tiếp 2 chiều (bidirectional communication) do HTTP chỉ có thể giao tiếp 1 chiều. Long Polling AJAX khởi tạo kết nối HTTP và giữ kết nối tồn tại trong một khoảng thời gian để chờ phản hồi. Chính vì lẽ đó mà việc xử lý bằng Long Polling thường tốn CPU, độ trễ cao (high latency), phức tạp và kém trong việc xử lý nhiều client (scaling).

WebSocket được thiết kế để xử lý thời gian thực (realtime) và thay thế các giải pháp giao tiếp 2 chiều không chính thống hiện tại, trong đó có Long Polling. Khi thực hiện một kết nối bằng giao thức HTTP, các dữ liệu như headers, cookies và các dữ liệu khởi tạo khác, được gửi kèm ở mỗi kết nối. Trong khi đó, WebSocket được xây dựng trên nền tảng giao thức TCP và chỉ thực hiện khởi tạo kết nối một lần duy nhất trong một phiên sử dụng. Điều này giúp WebSocket giảm tối đa độ trễ do khởi tạo kết nối (latency) và loại bỏ hầu hết các dữ liệu HTTP không cần thiết. Ngoài ra, với WebSocket, sau khi kết nối được khởi tạo thành công, client hoặc server có thể gửi phản hồi ở bất cứ một thời điểm nào mà không cần phải chờ đợi tín hiệu từ bên còn lại. Khả năng này mang lại sự vượt trội cho WebSocket so với Long Polling ở cả việc giảm độ trễ của phản hồi lẫn CPU cycle cần thiết. Hơn nữa, ở thời điểm hiện tại, WebSocket là giải pháp tốt nhất để xử lý một lượng lớn client.

Để kết luận, mình khẳng định là không có lí do gì để sử dụng Long Polling thay cho WebSocket.

Bạn có thể tham khảo thêm ở các đường link chính thức dưới đây:
[1] http://www.websocket.org/quantum.html
[2] http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax-vs-webrtc-vs-server-sent-events
[3] http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet