Hiệu suất Node.js so với .Net


181

Tôi đã đọc rất nhiều về Node.js nhanh và có thể đáp ứng lượng tải lớn. Có ai có bất kỳ bằng chứng thực tế nào về điều này so với các khung khác, đặc biệt là .Net không? Hầu hết các bài viết tôi đã đọc là giai thoại hoặc không có so sánh với .Net.

Cảm ơn


1
Bạn có thể chính xác hơn trong loại kịch bản chúng ta đang nói?
Marcus Granström

1
Tôi quan tâm đến bất kỳ so sánh hiệu suất nào của .Net và Node.js cho các ứng dụng web tương đương đang chạy trong IIS.
David Merrilees

1
Tôi không thể tưởng tượng bất cứ ai xây dựng một trang web có độ hoàn hảo cao. yêu cầu ngoài .Net. Vấn đề cơ bản nhất mà bạn gặp phải là nó sẽ không hiệu quả về mặt cấp phép vì mức độ hoàn hảo cao. các trang web thường yêu cầu nhân rộng. Và không, tôi không phải là một người ghét .Net. .Net thanh toán các hóa đơn.
Shane Courtrille

4
Tôi đã phải thực hiện các thử nghiệm nội bộ của API REST nhỏ bằng cách sử dụng Node / express / mongo và .net webapi / mongo mới và có những khác biệt hoàn hảo dựa trên những gì khách hàng muốn, nhưng vào cuối ngày, không đủ để tạo ra một Sự khác biệt. Bạn cần phát triển các bài kiểm tra của riêng bạn dựa trên các kịch bản của riêng bạn. Chúng tôi mất ba ngày để viết các API khác nhau bằng cả hai ngôn ngữ và sau đó vài ngày nữa để thiết lập thử nghiệm đúng cách. Nếu bạn đang có kế hoạch thực hiện bất cứ điều gì nghiêm trọng từ xa, tôi sẽ đề nghị thiết lập các bài kiểm tra dựa trên yêu cầu của bạn và tự quyết định cái nào tốt hơn cho tải của bạn.
AlexGad

5
@ShaneCourtrille Bạn đang nhầm lẫn .Net (khung) và Windows (hệ điều hành). Chúng là những thứ rất khác nhau và KHÔNG có yêu cầu cấp phép nào cho .Net (vốn chạy khá độc đáo trên Linux dưới dạng Mono).
rainabba

Câu trả lời:


365

NHANH và xử lý rất nhiều TẢI hai điều khác nhau. Một máy chủ thực sự NHANH CHÓNG khi phục vụ một yêu cầu mỗi giây có thể hoàn toàn bị trục trặc nếu bạn gửi 500 yêu cầu mỗi giây (dưới LOAD ).

Bạn cũng phải xem xét các trang tĩnh (và được lưu trong bộ nhớ cache) so với các trang động. Nếu bạn lo lắng về các trang tĩnh, thì IIS có thể sẽ đánh bại nút vì IIS sử dụng bộ đệm ẩn chế độ kernel, điều đó có nghĩa là các yêu cầu yêu cầu một trang tĩnh thậm chí sẽ không thoát khỏi kernel.

Tôi đoán rằng bạn đang tìm kiếm một so sánh giữa ASP.NET và nút. Trong trận chiến này, sau khi mọi thứ được biên soạn / diễn giải, có lẽ bạn sẽ có hiệu suất khá gần. Có thể .NET là một FASTER nhỏ hoặc có thể là một FASTER nhỏ , nhưng có lẽ nó đủ gần để bạn không quan tâm. Tôi đặt cược vào .NET, nhưng tôi không biết chắc chắn.

Nơi mà nút thực sự hấp dẫn là để xử lý LOAD . Đây là nơi các công nghệ thực sự khác nhau. ASP.NET dành một luồng cho mỗi yêu cầu từ nhóm luồng của nó và khi ASP.NET đã hết tất cả các yêu cầu luồng có sẵn bắt đầu được xếp hàng. Nếu bạn đang phục vụ các ứng dụng "Hello World" như ví dụ của @shankar, thì điều này có thể không quan trọng lắm vì các luồng sẽ không bị chặn và bạn sẽ có thể xử lý rất nhiều yêu cầu trước bạn hết chủ đề Vấn đề với mô hình ASP.NET xảy ra khi bạn bắt đầu thực hiện các yêu cầu I / O chặn luồng (gọi tới DB, thực hiện yêu cầu http đến dịch vụ, đọc tệp từ đĩa). Các yêu cầu chặn này có nghĩa là luồng có giá trị của bạn từ nhóm luồng không làm gì cả. Bạn càng chặn nhiều hơn,LOAD ứng dụng ASP.NET của bạn sẽ có thể phục vụ.

Để ngăn chặn việc chặn này, bạn sử dụng các cổng hoàn thành I / O không yêu cầu giữ một luồng trong khi chờ phản hồi. ASP.NET hỗ trợ điều này, nhưng thật không may, nhiều khung / thư viện phổ biến trong .NET KHÔNG. Ví dụ: ADO.NET hỗ trợ các cổng hoàn thành I / O, nhưng Entity Framework không sử dụng chúng. Vì vậy, bạn có thể xây dựng một ứng dụng ASP.NET hoàn toàn không đồng bộ và xử lý nhiều tải, nhưng hầu hết mọi người không làm thế vì nó không dễ như xây dựng một ứng dụng đồng bộ và bạn không thể sử dụng một số phần yêu thích của mình của khung (như linq đến các thực thể) nếu bạn làm.

Vấn đề là ASP.NET (và .NET Framework) đã được tạo ra để không bị tranh luận về I / O không đồng bộ. .NET không quan tâm nếu bạn viết mã đồng bộ hoặc không đồng bộ, do đó, tùy thuộc vào nhà phát triển để đưa ra quyết định này. Một phần của điều này là do phân luồng và lập trình với các hoạt động không đồng bộ được cho là "khó" và .NET muốn làm cho mọi người hài lòng (noobs và các chuyên gia). Nó thậm chí còn khó hơn vì .NET đã kết thúc với 3-4 mẫu khác nhau để thực hiện async. .NET 4.5 đang cố gắng quay lại và trang bị thêm .NET framework để có một mô hình có ý kiến ​​xung quanh async IO, nhưng có thể phải mất một thời gian cho đến khi các khung bạn quan tâm thực sự hỗ trợ nó.

Mặt khác, các nhà thiết kế của nút đã đưa ra một lựa chọn có ý kiến ​​rằng TẤT CẢ I / O nên không đồng bộ. Do quyết định này, các nhà thiết kế nút cũng có thể đưa ra quyết định rằng mỗi phiên bản của nút sẽ được phân luồng đơn để giảm thiểu chuyển đổi luồng và một luồng sẽ chỉ thực thi mã đã được xếp hàng. Đó có thể là một yêu cầu mới, nó có thể là cuộc gọi lại từ yêu cầu DB, nó có thể là cuộc gọi lại từ yêu cầu nghỉ ngơi http mà bạn đã thực hiện. Nút cố gắng tối đa hóa hiệu quả CPU bằng cách loại bỏ các chuyển đổi ngữ cảnh luồng. Bởi vì nút đưa ra lựa chọn có ý kiến ​​này rằng TẤT CẢ I / O không đồng bộ, điều đó cũng có nghĩa là tất cả các khung / tiện ích bổ sung đều hỗ trợ lựa chọn này. Việc viết các ứng dụng không đồng bộ 100% trong nút sẽ dễ dàng hơn (vì nút buộc bạn phải viết các ứng dụng không đồng bộ).

Một lần nữa, tôi không có bất kỳ số khó nào để chứng minh bằng cách này hay cách khác, nhưng tôi nghĩ rằng nút sẽ giành chiến thắng trong cuộc thi LOAD cho ứng dụng web điển hình. Ứng dụng .NET được tối ưu hóa cao (100% không đồng bộ) có thể giúp ứng dụng node.js tương đương chạy được tiền, nhưng nếu bạn lấy trung bình tất cả .NET và tất cả các ứng dụng nút ngoài đó, thì trung bình nút có thể xử lý nhiều hơn LOAD.

Mong rằng sẽ giúp.


39
Hãy nhớ rằng ASP.NET đã hỗ trợ các trình xử lý yêu cầu async trong một thời gian dài và với MVC4, chúng trở nên cực kỳ đơn giản để sử dụng.
fabspro

12
"Những yêu cầu chặn này có nghĩa là luồng có giá trị của bạn từ nhóm luồng không làm gì cả. Bạn càng chặn nhiều, ứng dụng ASP.NET của bạn sẽ càng ít khả năng phục vụ." Tại sao vấn đề là chúng ta xếp hàng trước (yêu cầu đến) hoặc trong phần phụ trợ (luồng công việc thực tế)? Không có vấn đề gì, yêu cầu của khách hàng đang chờ phản hồi. Tôi nghĩ chìa khóa mà mọi người bỏ qua trong cuộc tranh luận này là "Thông lượng". Nó không phải là về bao nhiêu kết nối đồng thời mà một máy chủ nắm giữ, nó có thể đáp ứng nhanh như thế nào với từng yêu cầu phải không?
sjdirect

19
// Không để tôi chỉnh sửa nhận xét của mình, vì vậy đây là những gì tôi muốn nói .// @sjdirect - Thông lượng không giống như thời gian phản hồi. Bạn có quyền quan tâm đến thời gian phản hồi, nhưng đó là lựa chọn giữa thời gian xếp hàng + thời gian phản hồi hoặc chỉ là thời gian phản hồi. Việc xử lý yêu cầu sẽ mất nhiều thời gian trong cả hai trường hợp (Thực hiện đồng bộ sẽ KHÔNG làm cho yêu cầu DB của bạn thực thi nhanh hơn), nhưng nếu luồng yêu cầu của bạn bị chặn, thì bạn cũng sẽ thêm thời gian xếp hàng vào yêu cầu bởi vì bạn thậm chí không thể bắt đầu xử lý yêu cầu cho đến khi các yêu cầu trước đó được thực hiện.
Matt Dotson

6
Điều này thực sự có nhiều thông tin, cảm ơn bạn! Một điều cần lưu ý là Entity Framework 6 (hiện là RC1) hiện hỗ trợ mẫu không đồng bộ từ .NET 4.5. msdn.microsoft.com/en-us/data/jj819165
quốc hội

4
Đây là đầu cơ cực lớn! Nó sẽ là tuyệt vời để có dữ liệu. Đó thường là cách tôi quyết định cách tiến hành với các chủ đề về hiệu suất.
kingPuppy

50

Tôi đã thực hiện một bài kiểm tra hiệu năng thô sơ giữa nodejs và IIS. IIS nhanh hơn khoảng 2,5 lần so với nodejs khi phát ra "xin chào, thế giới!". mã dưới đây.

phần cứng của tôi: Dell Latitude E6510, Core i5 (lõi kép), RAM 8 GB, HĐH Windows 7 Enterprise 64 bit

nút máy chủ

runs at http://localhost:9090/
/// <reference path="node-vsdoc.js" />
var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, { "Content-Type": "text/html" });
response.write("<p>hello, world!</p>");
response.end();
}).listen(9090);

mặc định

hosted by iis at http://localhost/test/
<p>hello, world!</p>

chương trình điểm chuẩn của riêng tôi bằng cách sử dụng thư viện song song tác vụ:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using System.Diagnostics;

namespace HttpBench
{
class Program
{
    private int TotalCount = 100000;
    private int ConcurrentThreads = 1000;
    private int failedCount;
    private int totalBytes;
    private int totalTime;
    private int completedCount;
    private static object lockObj = new object();

    /// <summary>
    /// main entry point
    /// </summary>
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run(args);
    }

    /// <summary>
    /// actual execution
    /// </summary>
    private void Run(string[] args)
    {
        // check command line
        if (args.Length == 0)
        {
            this.PrintUsage();
            return;
        }
        if (args[0] == "/?" || args[0] == "/h")
        {
            this.PrintUsage();
            return;
        }

        // use parallel library, download data
        ParallelOptions options = new ParallelOptions();
        options.MaxDegreeOfParallelism = this.ConcurrentThreads;
        int start = Environment.TickCount;
        Parallel.For(0, this.TotalCount, options, i =>
            {
                this.DownloadUrl(i, args[0]);
            }
        );
        int end = Environment.TickCount;

        // print results
        this.Print("Total requests sent: {0}", true, this.TotalCount);
        this.Print("Concurrent threads: {0}", true, this.ConcurrentThreads);
        this.Print("Total completed requests: {0}", true, this.completedCount);
        this.Print("Failed requests: {0}", true, this.failedCount);
        this.Print("Sum total of thread times (seconds): {0}", true, this.totalTime / 1000);
        this.Print("Total time taken by this program (seconds): {0}", true, (end - start) / 1000);
        this.Print("Total bytes: {0}", true, this.totalBytes);
    }

    /// <summary>
    /// download data from the given url
    /// </summary>
    private void DownloadUrl(int index, string url)
    {
        using (WebClient client = new WebClient())
        {
            try
            {
                int start = Environment.TickCount;
                byte[] data = client.DownloadData(url);
                int end = Environment.TickCount;
                lock (lockObj)
                {
                    this.totalTime = this.totalTime + (end - start);
                    if (data != null)
                    {
                        this.totalBytes = this.totalBytes + data.Length;
                    }
                }
            }
            catch
            {
                lock (lockObj) { this.failedCount++; }
            }
            lock (lockObj)
            {
                this.completedCount++;
                if (this.completedCount % 10000 == 0)
                {
                    this.Print("Completed {0} requests.", true, this.completedCount);
                }
            }
        }
    }

    /// <summary>
    /// print usage of this program
    /// </summary>
    private void PrintUsage()
    {
        this.Print("usage: httpbench [options] <url>");
    }

    /// <summary>
    /// print exception message to console
    /// </summary>
    private void PrintError(string msg, Exception ex = null, params object[] args)
    {
        StringBuilder sb = new System.Text.StringBuilder();
        sb.Append("Error: ");
        sb.AppendFormat(msg, args);
        if (ex != null)
        {
            sb.Append("Exception: ");
            sb.Append(ex.Message);
        }
        this.Print(sb.ToString());
    }

    /// <summary>
    /// print to console
    /// </summary>
    private void Print(string msg, bool isLine = true, params object[] args)
    {
        if (isLine)
        {
            Console.WriteLine(msg, args);
        }
        else
        {
            Console.Write(msg, args);
        }
    }

}
}

và kết quả:

IIS: httpbench.exe http://localhost/test

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 97
Total time taken by this program (seconds): 16
Total bytes: 2000000

nodejs: httpbench.exe http://localhost:9090/

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 234
Total time taken by this program (seconds): 27
Total bytes: 2000000

kết luận: IIS nhanh hơn nodejs khoảng 2,5 lần (trên Windows). Đây là một thử nghiệm rất thô sơ, và không có nghĩa là kết luận. Nhưng tôi tin rằng đây là một điểm khởi đầu tốt. Nodejs có thể nhanh hơn trên các máy chủ web khác, trên các nền tảng khác, nhưng trên Windows IIS là người chiến thắng. Các nhà phát triển đang tìm cách chuyển đổi ASP.NET MVC của họ sang nodejs nên tạm dừng và suy nghĩ kỹ trước khi tiếp tục.

Đã cập nhật (17/05/2012) Tomcat (trên windows) dường như đánh bại IIS, nhanh hơn khoảng 3 lần so với IIS trong việc loại bỏ html tĩnh.

mèo con

index.html at http://localhost:8080/test/
<p>hello, world!</p>

kết quả tomcat

httpbench.exe http://localhost:8080/test/
Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 31
Total time taken by this program (seconds): 5
Total bytes: 2000000

cập nhật kết luận: tôi đã chạy chương trình điểm chuẩn nhiều lần. Tomcat dường như là máy chủ nhanh nhất trong việc khai thác HTML STATIC, TRÊN WINDOWS.

Cập nhật (18/05/2012) Trước đây tôi có 100.000 tổng số yêu cầu với 10.000 yêu cầu đồng thời. Tôi đã tăng nó lên 1.000.000 tổng số yêu cầu và 100.000 yêu cầu đồng thời. IIS xuất hiện với tư cách là người chiến thắng gào thét, với Nodejs là người xấu nhất. Tôi đã lập bảng kết quả dưới đây:

NodeJS vs IIS vs Tomcat phục vụ HTML STATIC trên WINDOWS.


55
Bạn đang so sánh táo với mèo. So sánh Node.js với ASP.NET MVC. Hầu hết IIS nhanh hơn trong việc phục vụ các tệp tĩnh, mặc dù tôi thực sự nghi ngờ điều đó.
alessioalex

12
@alessioalex: tôi không hiểu tại sao sự so sánh này không hợp lệ. Tôi đang so sánh thời gian phản hồi cho html tĩnh. IIS đang loại bỏ html tĩnh từ default.htmlm, trong khi máy chủ của nodejs đang thực hiện cùng một chuỗi và IIS xuất hiện trước. So sánh một ứng dụng ASP.NET MVC sẽ đòi hỏi nhiều nỗ lực và thời gian hơn và tôi dự định sẽ thực hiện nó sau.
Shankar

28
Ok, giả sử rằng IIS tốt hơn trong việc phục vụ các tệp tĩnh trên Windows so với Node. IIS chỉ phục vụ các tệp tĩnh và như vậy (như Apache hoặc NGINX), Node còn làm được nhiều hơn thế. Bạn nên so sánh ASP.NET MVC với Node (truy vấn cơ sở dữ liệu, truy xuất dữ liệu từ một dịch vụ bên ngoài, v.v.). Bạn sẽ thấy hiệu suất tăng rất lớn với Node qua ASP.NET MVC.
alessioalex

27
Nếu bạn sẽ làm điều này, ít nhất hãy hiểu bản chất của nút. Một quá trình Node chỉ có thể sử dụng một lõi đơn. Vì vậy, những gì bạn đang so sánh là một quá trình nút chạy trên một lõi với quy trình IIS và tomcat bằng nhiều lõi. Để so sánh đúng, bạn cần chạy cụm nút. Xem nodejs.org/api/cluster.html để biết cách sử dụng giải pháp cụm đơn giản. Tuy nhiên, tôi có thể cho bạn biết từ kinh nghiệm, sự khác biệt giữa nút và async c # là 10-15% tùy theo những gì bạn đang làm.
AlexGad

14
Ngoài ra, kiểm tra các tệp tĩnh với nút và IIS và Tomcat là vô nghĩa. Trước hết, nút không tuyệt vời cho các tệp tĩnh, nhưng nó không thực sự có nghĩa (sử dụng đúng công cụ cho đúng công việc). Nếu ai đó lo lắng về tốc độ của tệp tĩnh, họ vẫn nên sử dụng CDN.
AlexGad

25

Máy chủ NIO (Node.js, v.v.) có xu hướng nhanh hơn máy chủ BIO. (IIS, v.v.). Để đáp lại yêu cầu của tôi, TechEmpower là một công ty chuyên về điểm chuẩn khung web . Họ rất cởi mở và có một cách tiêu chuẩn để kiểm tra tất cả các framewrks.

Các bài kiểm tra vòng 9 hiện là mới nhất (tháng 5 năm 2014). Có rất nhiều hương vị IIS được thử nghiệm, nhưng aspnet tước dường như là biến thể IIS nhanh nhất.

Dưới đây là kết quả trả lời mỗi giây (cao hơn là tốt hơn):

  • Tuần tự hóa JSON
    • nútjs: 228,887
    • tước aspnet: 105,272
  • Truy vấn đơn
    • nodejs-mysql: 88,597
    • aspnet-tước-raw: 47,066
  • Nhiều truy vấn
    • nodejs-mysql: 8,878
    • aspnet-tước-raw: 3,915
  • Văn bản thô
    • nútjs: 289,578
    • tước aspnet: 109,136

Trong mọi trường hợp, Node.js có xu hướng nhanh hơn gấp 2 lần so với IIS.


1
Ngoại trừ trong bài kiểm tra Nhiều truy vấn, trong đó ASPNET có hai mục (aspnet-tước-raw và aspnet-mysql-raw) mà cả hai đều đánh bại nodejs-mysql, đó là mục nhập njs hàng đầu.
GalacticCowboy

3
Chà, kiểm tra nhiều truy vấn không chính xác kiểm tra tốc độ máy chủ. Nó chủ yếu là kiểm tra tốc độ trình điều khiển MySQL. NodeJS chủ yếu sử dụng cơ sở dữ liệu NO-SQL như MongoDB, CouchDB. Trình điều khiển MySQL có thể không được tối ưu hóa. Các thử nghiệm tuần tự hóa và Plaintext của Json có xu hướng cho tốc độ máy chủ thuần túy - tôi tin tưởng chúng hơn.
ttekin

Nếu tôi sử dụng nút IIS thì sao? là hiệu suất của tôi sẽ xuống cấp hoặc sẽ giống nhau.
Umashankar

3
Cảm ơn các liên kết đến trang điểm chuẩn. Tuy nhiên, câu trả lời có thể cần một bản cập nhật, mọi thứ có thể đã thay đổi khá nhiều với sự ra đời của .NET Core 2.1. Ví dụ: điểm chuẩn tuần tự hóa JSON 2018 liệt kê ASP.NET Core ở mức 971.122 yêu cầu / giây và Node.js ở mức 561.593 yêu cầu / giây, vì vậy ngày nay ASP.NET Core sẽ xuất hiện nhanh gần gấp đôi so với Node.js về mặt đó.
stakx - không còn đóng góp

13

Tôi phải đồng ý với Marcus Granstrom kịch bản rất quan trọng ở đây.

Thành thật mà nói có vẻ như bạn đang đưa ra một quyết định kiến ​​trúc có tác động cao. Lời khuyên của tôi sẽ là cách ly các khu vực quan tâm và thực hiện "nướng" giữa bất kỳ ngăn xếp nào bạn đang xem xét.

Vào cuối ngày, bạn chịu trách nhiệm về quyết định này và tôi không nghĩ cái cớ "Một người nào đó trên Stackoverflow đã cho tôi xem một bài báo nói rằng nó sẽ ổn" Sẽ cắt nó với sếp của bạn.


1
Tôi đang tìm kiếm thứ gì đó để thuyết phục mọi người (bao gồm cả sếp của tôi), đáng để xem xét như một giải pháp thay thế cho trang web MVC.net, không thuyết phục họ chúng ta nên trao đổi. Tất cả những gì tôi tìm thấy cho đến nay là những giai thoại đề cập rằng nó có thể hỗ trợ tải nhiều hơn và hoạt động tốt hơn. Có ai thực sự chứng minh điều này?
David Merrilees

17
Nhưng điều gì là sai với trang web MVC? TẠI SAO bạn đang cố gắng tìm một sự thay thế? Đó là điều quan trọng nhất Q. Nếu vấn đề là chó chậm tải nặng, thì bạn nên chắc chắn rằng mình đang sử dụng async.net. Nếu nó vẫn thực sự chậm, thì bạn cần chia nhỏ mã của mình và tìm ra điểm nghẽn của bạn. Theo kinh nghiệm của tôi, không có sự khác biệt lớn giữa mạng nút và mạng không đồng bộ trong các kịch bản THẾ GIỚI. Bạn có thể thay đổi nền tảng của mình, nhưng có thể bạn sẽ chỉ cần thay đổi một bộ tắc nghẽn / đau đầu mã cho một bộ tắc nghẽn / đau đầu mã khác.
AlexGad

1

Sự khác biệt chính mà tôi thấy là nút .js là ngôn ngữ lập trình động (kiểm tra kiểu), vì vậy các kiểu phải ở thời gian chạy. Các ngôn ngữ được gõ mạnh như C # .NET về mặt lý thuyết có nhiều tiềm năng hơn sẽ chiến thắng trong cuộc chiến chống lại Node .js (và PHP, v.v.), đặc biệt là nơi tính toán đắt đỏ. Nhân tiện, .NET nên có khả năng tương tác tốt hơn với C / C ++ so với nút .js.


4
Ý kiến ​​của bạn rằng việc gõ "yếu" trong JS làm chậm nó là sai và không liên quan và bất kể, đó là so sánh Táo và Đá (ngay cả Oranges cũng sẽ giống với những gì bạn đề xuất).
rainabba

7
@rainabba Khi bạn so sánh tính toán của một số loại (ví dụ: Wikipedia của x), anh ấy hoàn toàn chính xác.
Stan

5
@steve Trên thực tế, với Z, bạn vẫn không thể nói rằng vì JS là ngôn ngữ và .Net là khung. Chúng là những thứ hoàn toàn khác nhau. Thời gian chạy .Net được biên dịch cho một kiến ​​trúc bộ xử lý cụ thể và do đó bạn không thể thay đổi hiệu suất của một đoạn mã cụ thể đáng kể cho một phần cứng. Như V8 đã cho thấy, JS có thể được giải thích và thực thi và tốc độ cực kỳ khác nhau và không có lý do gì để nghĩ rằng một ngày nào đó, mã Wikipedia của bạn được viết bằng JS sẽ không chạy nhanh như mã chạy qua CLR (rất có thể, nó sẽ là nhanh hơn). Táo và đá; như tôi đã nói.
rainabba

1
có thể bạn đúng, nhưng trong tầm nhìn của tôi, tôi không biết các quốc gia khác, ở Trung Quốc, nhiều lập trình viên mà tôi đã phỏng vấn chỉ biết đến EF hoặc Linq cho Sql, các khung này làm giảm đáng kể hiệu suất của .net
dexiang

1
Điều tương tự có thể được nói với JS. Trong khi JS đang bắt kịp trên MySpace, bạn có thực sự nghĩ rằng .NET sẽ vẫn ở nơi nó đang chờ không?
quanben
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.