ประสิทธิภาพของ Node.js กับ. Net


183

ฉันอ่านมากเกี่ยวกับ Node.js ที่รวดเร็วและสามารถรองรับการโหลดจำนวนมากได้ ไม่มีใครมีหลักฐานโลกแห่งความเป็นจริงของกรอบนี้เทียบกับอื่น ๆ โดยเฉพาะอย่างยิ่ง. Net? บทความส่วนใหญ่ที่ฉันได้อ่านนั้นเป็นบทความเล็ก ๆ น้อย ๆ หรือไม่มีการเปรียบเทียบกับ. Net

ขอบคุณ


1
คุณช่วยให้แม่นยำกว่านี้ในสถานการณ์แบบไหนที่เรากำลังพูดอยู่?
Marcus Granström

1
ฉันสนใจในการเปรียบเทียบประสิทธิภาพใด ๆ ของ. Net และ Node.js สำหรับเว็บแอปพลิเคชันเปรียบเทียบที่ทำงานอยู่ใน IIS
David Merrilees

1
ฉันนึกภาพไม่ออกว่าใครสร้างเว็บไซต์ที่มีความสมบูรณ์แบบ ความต้องการจาก. Net ปัญหาพื้นฐานที่สุดที่คุณต้องพบคือมันจะไม่คุ้มค่ากับการออกใบอนุญาตตั้งแต่มีประสิทธิภาพสูง ไซต์มักต้องการการขยาย และไม่ฉันไม่ใช่ผู้เกลียดชังทางการเงิน . Net จ่ายบิล
Shane Courtrille

4
ฉันต้องทำการทดสอบภายในของ REST API ขนาดเล็กโดยใช้ Node / express / mongo และ. net webapi / mongo ใหม่และมีความแตกต่างที่สมบูรณ์แบบตามสิ่งที่ลูกค้าต้องการ แต่ในตอนท้ายของวันไม่เพียงพอที่จะทำให้ ข้อแตกต่าง คุณต้องพัฒนาแบบทดสอบของคุณเองตามสถานการณ์ของคุณเอง เราใช้เวลาสามวันในการเขียน API ที่แตกต่างกันในทั้งสองภาษาและจากนั้นอีกสองสามวันเพื่อทำการทดสอบการตั้งค่าอย่างเหมาะสม หากคุณวางแผนที่จะทำสิ่งใดจากระยะไกลอย่างจริงจังฉันขอแนะนำให้ตั้งค่าการทดสอบตามความต้องการของคุณและตัดสินใจด้วยตัวเองซึ่งจะดีกว่าสำหรับการโหลดของคุณ
AlexGad

5
@ShaneCourtrille คุณสับสน. Net (a framework) และ Windows (ระบบปฏิบัติการ) เป็นสิ่งที่แตกต่างกันมากและไม่มีข้อกำหนดสิทธิการใช้งานสำหรับ. Net (ซึ่งทำงานบน Linux เป็น Mono อย่างมาก)
rainabba

คำตอบ:


366

ความรวดเร็วและการจัดการโหลดจำนวนมากนั้นเป็นสองสิ่งที่แตกต่างกัน เซิร์ฟเวอร์ที่เร็วจริง ๆในการให้บริการหนึ่งคำขอต่อวินาทีอาจล้มเหลวโดยสิ้นเชิงถ้าคุณส่ง 500 คำขอต่อวินาที (ภายใต้โหลด )

คุณต้องพิจารณาแบบคงที่ (และแคช) เทียบกับหน้าแบบไดนามิก หากคุณกังวลเกี่ยวกับหน้าแบบสแตติก IIS อาจเป็นไปได้ที่จะชนะโหนดเนื่องจาก IIS ใช้การแคชโหมดเคอร์เนลซึ่งหมายความว่าคำขอที่ร้องขอหน้าแบบสแตติกจะไม่ออกจากเคอร์เนล

ฉันเดาว่าคุณกำลังมองหาการเปรียบเทียบระหว่าง ASP.NET และโหนด ในการต่อสู้ครั้งนี้หลังจากรวบรวมและตีความทุกอย่างแล้วคุณอาจจะเข้าใกล้การแสดง อาจเป็น. NET เร็วขึ้นเล็กน้อยหรืออาจเร็วกว่าเล็กน้อยแต่อาจใกล้พอที่คุณไม่สนใจ ฉันเดิมพันบน. NET แต่ฉันไม่รู้แน่นอน

สถานที่โหนดเป็นที่น่าสนใจจริงๆสำหรับการจัดการโหลด นี่คือที่เทคโนโลยีแตกต่างกันจริงๆ ASP.NET อุทิศเธรดสำหรับแต่ละการร้องขอจากเธรดพูลและเมื่อ ASP.NET หมดการร้องขอเธรดที่พร้อมใช้งานทั้งหมดจะเริ่มการจัดคิว หากคุณให้บริการแอป "Hello World" เช่นตัวอย่างโดย @shankar นี่อาจไม่สำคัญเท่าไรเพราะเธรดจะไม่ถูกบล็อกและคุณจะสามารถจัดการคำขอได้มากก่อนที่คุณจะ ไม่มีเธรด ปัญหาเกี่ยวกับรูปแบบ ASP.NET มาเมื่อคุณเริ่มทำการร้องขอ I / O ที่บล็อกเธรด (เรียกไปยังฐานข้อมูลทำการร้องขอ http ไปยังบริการอ่านไฟล์จากดิสก์) คำขอบล็อกนี้หมายความว่าเธรดที่มีค่าของคุณจากกลุ่มเธรดไม่ได้ทำอะไรเลย ยิ่งปิดกั้นคุณโหลดแอป ASP.NET ของคุณจะสามารถให้บริการได้

เพื่อป้องกันการบล็อกนี้คุณใช้พอร์ต I / O ที่สมบูรณ์ซึ่งไม่จำเป็นต้องมีเธรดค้างไว้ในขณะที่คุณรอการตอบกลับ ASP.NET สนับสนุนสิ่งนี้ แต่น่าเสียดายที่เฟรมเวิร์ก / ไลบรารีทั่วไปใน. NET ไม่ได้รองรับ ตัวอย่างเช่น ADO.NET รองรับพอร์ต I / O ที่สมบูรณ์ แต่ Entity Framework ไม่ได้ใช้ ดังนั้นคุณสามารถสร้างแอป ASP.NET ที่เป็นแบบอะซิงโครนัสและจัดการภาระมากมาย แต่คนส่วนใหญ่ทำไม่ได้เพราะมันไม่ง่ายเท่ากับการสร้างแอพแบบซิงโครนัสและคุณอาจไม่สามารถใช้ชิ้นส่วนที่คุณชื่นชอบ ของกรอบงาน (เช่น linq ไปยังเอนทิตี) ถ้าคุณทำ

ปัญหาคือว่า ASP.NET (และ. NET Framework) ถูกสร้างขึ้นเพื่อไม่แสดงความคิดเห็นเกี่ยวกับ I / O แบบอะซิงโครนัส .NET ไม่สนใจว่าคุณเขียนรหัสซิงโครนัสหรืออะซิงโครนัสดังนั้นจึงขึ้นอยู่กับผู้พัฒนาที่จะตัดสินใจ ส่วนหนึ่งเป็นเพราะเกลียวและการเขียนโปรแกรมที่มีการดำเนินการแบบอะซิงโครนัสคิดว่า "ยาก" และ. NET ต้องการทำให้ทุกคนมีความสุข (noobs และผู้เชี่ยวชาญ) มันยิ่งยากขึ้นเพราะ. NET จบลงด้วยรูปแบบที่แตกต่างกัน 3-4 แบบสำหรับการทำ async .NET 4.5 พยายามย้อนกลับและติดตั้ง. NET Framework ใหม่เพื่อให้มีโมเดลที่มีความเห็นรอบ async IO แต่อาจใช้เวลาสักครู่จนกว่ากรอบงานที่คุณสนใจจะรองรับ

นักออกแบบของโหนดในทางกลับกันทำทางเลือกที่มีความเห็นว่า I / O ทั้งหมดควรเป็นแบบอะซิงโครนัส เนื่องจากการตัดสินใจนี้ผู้ออกแบบโหนดยังสามารถตัดสินใจได้ว่าแต่ละอินสแตนซ์ของโหนดจะเป็นเธรดเดี่ยวเพื่อลดการสลับเธรดให้น้อยที่สุดและเธรดเพียงอันเดียวจะรันโค้ดที่ได้รับการจัดคิว นั่นอาจเป็นคำขอใหม่อาจเป็นการเรียกกลับจากคำขอ DB อาจเป็นการเรียกกลับจากคำขอวางตัว http ที่คุณทำ โหนดพยายามเพิ่มประสิทธิภาพของ CPU ให้สูงสุดโดยการกำจัดสวิตช์บริบทของเธรด เนื่องจากโหนดทำให้ตัวเลือกที่มีความคิดเห็นนี้ที่ ALL I / O เป็นแบบอะซิงโครนัสนั่นหมายความว่าเฟรมเวิร์ก / ส่วนเสริมทั้งหมดสนับสนุนตัวเลือกนี้ การเขียนแอพที่มี async 100% ในโหนดง่ายขึ้น (เนื่องจากโหนดบังคับให้คุณเขียนแอปที่เป็น async)

อีกครั้งฉันไม่มีตัวเลขที่ยากที่จะพิสูจน์ไม่ทางใดก็ทางหนึ่ง แต่ฉันคิดว่าโหนดจะชนะการแข่งขันโหลดสำหรับแอปพลิเคชันเว็บทั่วไป แอป. NET (async 100%) ที่ได้รับการปรับให้เหมาะสมอย่างสูงอาจให้แอป node.js ที่เทียบเท่าเพื่อเงิน แต่ถ้าคุณใช้ค่าเฉลี่ยของ. NET ทั้งหมดและแอพโหนดทั้งหมดที่อยู่ในโหนดเฉลี่ยอาจจัดการได้มากกว่า โหลด

หวังว่าจะช่วย


39
โปรดจำไว้ว่า ASP.NET ได้สนับสนุนตัวจัดการการร้องขอ async เป็นเวลานานและด้วย MVC4 พวกเขากลายเป็นเรื่องง่ายมากที่จะใช้
fabspro

12
"คำขอการบล็อกเหล่านี้หมายความว่าเธรดที่มีค่าของคุณจากกลุ่มเธรดจะไม่ทำอะไรเลยยิ่งมีการบล็อกมากเท่าไหร่แอพ ASP.NET ของคุณก็ยิ่งน้อยลงเท่านั้นที่จะสามารถให้บริการได้" ทำไมมันถึงมีความสำคัญไม่ว่าเราจะจัดคิวล่วงหน้า (คำขอขาเข้า) หรือในแบ็กเอนด์ (เธรดงานจริง) ไม่ว่าอะไรก็ตามคำขอของลูกค้ากำลังรอการตอบกลับ ฉันคิดว่ากุญแจสำคัญที่ผู้คนมองข้ามในการอภิปรายนี้คือ "ปริมาณงาน" ไม่เกี่ยวกับจำนวนการเชื่อมต่อพร้อมกันที่เซิร์ฟเวอร์เก็บไว้มันเร็วแค่ไหนที่สามารถตอบสนองต่อการร้องขอแต่ละครั้งได้อย่างรวดเร็ว
sjdirect

19
// จะไม่ให้ฉันแก้ไขความคิดเห็นของฉันดังนั้นนี่คือสิ่งที่ฉันต้องการจะพูด // @sjdirect - ปริมาณงานไม่เหมือนกับเวลาตอบสนอง คุณถูกต้องเกี่ยวกับเวลาตอบสนอง แต่เป็นตัวเลือกระหว่างเวลาคิว + เวลาตอบสนองหรือเพียงแค่เวลาตอบสนอง การประมวลผลคำขอจะใช้เวลานานในทั้งสองสถานการณ์ (การดำเนินการแบบซิงโครนัสจะไม่ทำให้คำขอ DB ของคุณดำเนินการเร็วขึ้น) แต่ถ้าเธรดคำขอของคุณถูกบล็อกคุณก็จะเพิ่มเวลาในคิว เนื่องจากคุณไม่สามารถเริ่มประมวลผลคำขอได้จนกว่าจะทำคำขอก่อนหน้านี้เสร็จ
Matt Dotson

6
นี่เป็นข้อมูลจริงๆขอบคุณ! สิ่งหนึ่งที่ควรทราบคือ Entity Framework 6 (RC1 ปัจจุบัน) รองรับรูปแบบอะซิงโครนัสจาก. NET 4.5 msdn.microsoft.com/en-us/data/jj819165
รัฐสภา

4
นี่เป็นการเก็งกำไรอย่างมหาศาล! มันจะเป็นการดีถ้ามีข้อมูล ปกติฉันจะตัดสินใจเกี่ยวกับหัวข้อของการแสดงต่อไป
kingPuppy

50

ฉันทำการทดสอบประสิทธิภาพพื้นฐานระหว่าง nodejs และ IIS IIS เร็วกว่า nodejs ประมาณ 2.5 เท่าเมื่อทำการออก "hello, world!" รหัสด้านล่าง

ฮาร์ดแวร์ของฉัน: Dell Latitude E6510, Core i5 (ดูอัลคอร์), 8 GB RAM, Windows 7 Enterprise 64 บิตระบบปฏิบัติการ

เซิร์ฟเวอร์โหนด

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);

default.htm

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

โปรแกรมเบนช์มาร์กของฉันเองโดยใช้ไลบรารีงานแบบขนาน:

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);
        }
    }

}
}

และผลลัพธ์:

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

สรุป: IIS เร็วกว่า nodejs ประมาณ 2.5 เท่า (บน Windows) นี่คือการทดสอบขั้นพื้นฐานมากและไม่ได้ข้อสรุป แต่ฉันเชื่อว่านี่เป็นจุดเริ่มต้นที่ดี Nodejs น่าจะเร็วกว่าบนเว็บเซิร์ฟเวอร์อื่น ๆ บนแพลตฟอร์มอื่น ๆ แต่ใน Windows IIS เป็นผู้ชนะ นักพัฒนาที่ต้องการแปลง ASP.NET MVC เป็น nodejs ควรหยุดและคิดสองครั้งก่อนดำเนินการต่อ

อัปเดต (5/17/2012) Tomcat (บน windows) ดูเหมือนจะเอาชนะ IIS hand down เร็วกว่า IIS ประมาณ 3 เท่าในการทำ html คงที่

แมวตัวผู้

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

ผลคราว

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

ข้อสรุปที่อัปเดต: ฉันใช้โปรแกรมเบนช์มาร์กหลายครั้ง Tomcat ดูเหมือนจะเป็นเซิร์ฟเวอร์ที่เร็วที่สุดในการกำหนดสถานะ HTML บน WINDOWS

อัปเดต (5/18/2012) ก่อนหน้านี้ฉันมีคำขอทั้งหมด 100,000 คำขอโดยมี 10,000 คำขอพร้อมกัน ฉันเพิ่มเป็น 1,000,000 คำขอทั้งหมดและ 100,000 คำขอพร้อมกัน IIS ออกมาในฐานะผู้ชนะกรีดร้องด้วย Nodejs ที่เลวร้ายที่สุด ฉันทำตารางผลลัพธ์ด้านล่าง:

NodeJS เทียบกับ IIS กับ Tomcat ที่ให้บริการ HTML แบบคงที่บน WINDOWS.


56
คุณกำลังเปรียบเทียบแอปเปิ้ลกับแมว เปรียบเทียบ Node.js กับ ASP.NET MVC IIS ส่วนใหญ่เร็วกว่าในการให้บริการไฟล์คงที่ แต่ฉันก็ยังสงสัยอยู่ดี
alessioalex

12
@alessioalex: ฉันไม่เข้าใจว่าทำไมการเปรียบเทียบนี้ไม่ถูกต้อง ฉันกำลังเปรียบเทียบเวลาตอบกลับของ html คงที่ IIS กำลังหา html สแตติกแบบคงที่จาก default.htm ในขณะที่เซิร์ฟเวอร์ nodejs กำลังทำสตริงเดียวกันและ IIS จะออกมาข้างหน้า การเปรียบเทียบแอปพลิเคชัน ASP.NET MVC จะต้องใช้ความพยายามและเวลามากขึ้นและฉันวางแผนที่จะทำในภายหลัง
Shankar

28
ตกลงบอกว่า IIS ดีกว่าที่ให้บริการไฟล์คงที่บน Windows มากกว่า Node IIS ให้บริการเฉพาะไฟล์แบบคงที่และเช่น (เช่น Apache หรือ NGINX) โหนดจะทำมากกว่านั้น คุณควรจะเปรียบเทียบ ASP.NET MVC กับ Node (ทำการสืบค้นฐานข้อมูลดึงข้อมูลจากบริการภายนอก ฯลฯ ) คุณจะเห็นประสิทธิภาพที่เพิ่มขึ้นอย่างมากเมื่อใช้ Node ผ่าน ASP.NET MVC
alessioalex

27
หากคุณกำลังจะทำสิ่งนี้โปรดเข้าใจธรรมชาติของโหนดเป็นอย่างน้อย กระบวนการหนึ่งโหนดสามารถใช้แกนเดียวเท่านั้น ดังนั้นสิ่งที่คุณเปรียบเทียบคือกระบวนการโหนดที่ทำงานบนแกนเดียวกับ IIS และกระบวนการ Tomcat โดยใช้หลายคอร์ เพื่อเปรียบเทียบอย่างถูกต้องคุณต้องรันโหนดคลัสเตอร์ ดูnodejs.org/api/cluster.htmlสำหรับวิธีแก้ปัญหาคลัสเตอร์ที่ใช้งานง่าย อย่างไรก็ตามฉันสามารถบอกคุณได้จากประสบการณ์ความแตกต่างระหว่างโหนดและ async c # คือ 10-15% วิธีใดขึ้นอยู่กับสิ่งที่คุณทำ
AlexGad

14
การทดสอบไฟล์สแตติกด้วยโหนดและ IIS และ Tomcat นั้นไม่มีความหมาย ก่อนอื่นโหนดไม่ดีสำหรับไฟล์สแตติก แต่มันไม่ได้หมายถึงการเป็นจริง (ใช้เครื่องมือที่เหมาะสมสำหรับงานที่เหมาะสม) หากมีคนกังวลเกี่ยวกับความเร็วของไฟล์คงที่พวกเขาควรใช้ CDN ต่อไป
AlexGad

26

เซิร์ฟเวอร์ NIO (Node.js ฯลฯ ) มีแนวโน้มที่จะเร็วกว่าเซิร์ฟเวอร์ BIO (IIS ฯลฯ ) การสำรองเรียกร้องของฉัน, TechEmpower เป็น บริษัท ที่เชี่ยวชาญในเว็บมาตรฐานกรอบ พวกเขาเปิดกว้างและมีวิธีทดสอบมาตรฐานที่เป็นมาตรฐานทั้งหมด

การทดสอบรอบที่ 9 เป็นปัจจุบันล่าสุด (พฤษภาคม 2014) มีการทดสอบรสชาติของ IIS มากมาย แต่ดูเหมือนว่า aspnet-stripped จะเป็นตัวแปร IIS ที่เร็วที่สุด

นี่คือผลลัพธ์ในการตอบสนองต่อวินาที (สูงกว่าดีกว่า):

  • การทำให้เป็นอันดับ JSON
    • nodejs: 228,887
    • aspnet-ปล้น: 105,272
  • คำค้นหาเดียว
    • nodejs-MySQL: 88,597
    • aspnet-ปล้นดิบ: 47,066
  • หลายคำค้นหา
    • nodejs-MySQL: 8,878
    • aspnet-ปล้นดิบ: 3,915
  • ข้อความธรรมดา
    • nodejs: 289,578
    • aspnet-ปล้น: 109,136

ในทุกกรณี Node.js มีแนวโน้มที่จะเป็น 2x + เร็วกว่า IIS


1
ยกเว้นการทดสอบการสืบค้นหลายตัวโดยที่ ASPNET มีสองรายการ (aspnet-stripped-raw และ aspnet-mysql-raw) ที่ทั้งสองเอาชนะ nodejs-mysql ซึ่งเป็นรายการ njs อันดับต้น
GalacticCowboy

4
การทดสอบแบบสอบถามหลายรายการไม่ได้เป็นการทดสอบความเร็วของเซิร์ฟเวอร์อย่างแน่นอน ส่วนใหญ่เป็นการทดสอบความเร็วไดรเวอร์ MySQL NodeJS ส่วนใหญ่ใช้ฐานข้อมูล NO-SQL เช่น MongoDB, CouchDB โปรแกรมควบคุม MySQL อาจไม่ได้รับการปรับให้เหมาะสม การทำให้เป็นอนุกรม Json และการทดสอบ Plaintext มีแนวโน้มที่จะให้ความเร็วเซิร์ฟเวอร์ที่บริสุทธิ์ - ฉันเชื่อถือพวกเขามากขึ้น
ttekin

ถ้าฉันใช้โหนด IIS จะทำอย่างไร ประสิทธิภาพของฉันจะลดลงหรือจะเหมือนกัน
Umashankar

3
ขอบคุณสำหรับลิงค์ไปยังหน้าเกณฑ์มาตรฐาน คำตอบอาจต้องมีการอัพเดทสิ่งต่าง ๆ อาจเปลี่ยนแปลงไปเล็กน้อยเมื่อเทียบกับ. NET Core 2.1 ตัวอย่างเช่น 2018 JSON benchmark benchmark แสดงรายการ ASP.NET Core ที่ 971,122 คำร้องขอ / วินาทีและ Node.js ที่ 561,593 คำร้องขอ / วินาทีดังนั้นวันนี้ ASP.NET Core ก็ดูเหมือนจะเร็วกว่า Node.js เกือบสองเท่า
stakx - ไม่สนับสนุน

13

ฉันต้องเห็นด้วยกับ Marcus Granstrom สถานการณ์เป็นสิ่งสำคัญมากที่นี่

ความจริงแล้วดูเหมือนว่าคุณกำลังตัดสินใจสร้างผลกระทบทางสถาปัตยกรรมสูง คำแนะนำของฉันคือการแยกพื้นที่ของความกังวลและทำ "อบ" ระหว่างสิ่งที่คุณกำลังพิจารณาสแต็ค

ในตอนท้ายของวันที่คุณต้องรับผิดชอบในการตัดสินใจและฉันไม่คิดว่าข้ออ้าง "คนที่แต่งตัวประหลาดใน Stackoverflow แสดงให้ฉันเห็นบทความที่บอกว่ามันจะดี" จะตัดกับเจ้านายของคุณ


1
ฉันกำลังมองหาบางอย่างที่จะโน้มน้าวใจผู้คน (รวมถึงหัวหน้าของฉันด้วย) มันคุ้มค่าที่จะพิจารณาว่าเป็นทางเลือกหนึ่งในเว็บไซต์ MVC.net ไม่ใช่เพื่อโน้มน้าวพวกเขาเราควรแลกเปลี่ยน สิ่งที่ฉันได้พบในตอนนี้คือเกร็ดเล็กเกร็ดน้อยที่กล่าวถึงว่าสามารถรองรับการโหลดได้มากขึ้นและทำงานได้ดีขึ้น มีใครพิสูจน์เรื่องนี้จริงเหรอ?
David Merrilees

17
แต่เกิดอะไรขึ้นกับเว็บไซต์ MVC ทำไมคุณพยายามค้นหาทางเลือก นั่นคือสิ่งที่สำคัญที่สุด Q. หากปัญหาคือสุนัขช้าภายใต้การโหลดพร้อมกันอย่างหนักคุณควรตรวจสอบให้แน่ใจว่าคุณใช้ async.net หากยังช้าอยู่คุณจะต้องแยกแยะรหัสของคุณและดูว่าคอขวดของคุณอยู่ตรงไหน จากประสบการณ์ของฉันไม่แตกต่างกันมากระหว่างโหนดและ async net ในสถานการณ์โลกจริง คุณสามารถเปลี่ยนแพลตฟอร์มของคุณได้ แต่คุณอาจเปลี่ยนคอขวด / ชุดปวดหัวหนึ่งชุดสำหรับชุดโค้ดคอขวด / ปวดหัวอีกชุดหนึ่ง
AlexGad

1

ความแตกต่างหลักที่ฉันเห็นคือโหนด. js เป็นภาษาการเขียนโปรแกรมแบบไดนามิก (การตรวจสอบประเภท) ดังนั้นประเภทจะต้องได้รับในเวลาทำงาน ภาษาที่พิมพ์อย่างรุนแรงเช่น C # .NET มีเหตุผลที่เป็นไปได้มากกว่าที่จะชนะการต่อสู้กับ Node .js (และ PHP เป็นต้น) โดยเฉพาะการคำนวณที่มีราคาแพง โดยวิธี. NET ควรมีการทำงานร่วมกันแบบดั้งเดิมที่ดีกว่ากับ C / C ++ กว่า node. js


4
ข้อเสนอแนะของคุณว่าการพิมพ์ "อ่อนแอ" ใน JS ทำให้ช้าลงเป็นสิ่งที่ผิดและไม่เกี่ยวข้องและไม่ว่าจะเป็นการเปรียบเทียบแอปเปิ้ลและสโตน (แม้แต่ส้มก็จะคุ้นเคยมากกว่าสิ่งที่คุณแนะนำ)
rainabba

7
@rainabba เมื่อคุณเปรียบเทียบการคำนวณบางอย่าง (เช่นฟีโบนักชีของ x) เขาถูกต้องอย่างสมบูรณ์
Stan

5
@steve จริงแล้วเนื่องจาก Z คุณยังคงไม่สามารถพูดได้ว่าเพราะ JS เป็นภาษาและ. Net เป็นกรอบงาน พวกมันต่างกันอย่างสิ้นเชิง .Net รันไทม์ถูกรวบรวมสำหรับสถาปัตยกรรมตัวประมวลผลเฉพาะและดังนั้นคุณจึงไม่สามารถเปลี่ยนประสิทธิภาพการทำงานของโค้ดเฉพาะสำหรับฮาร์ดแวร์ชิ้นเดียวได้อย่างมีนัยสำคัญ ในฐานะที่เป็น V8 แสดงให้เห็นว่า JS สามารถตีความและดำเนินการและความเร็วที่แตกต่างกันมากและไม่มีเหตุผลที่จะคิดว่าวันหนึ่งรหัส fibonacci ของคุณที่เขียนใน JS จะไม่ทำงานเพียงอย่างรวดเร็วเหมือนกับรหัสที่เรียกใช้ผ่าน CLR (น่าจะเป็น เร็วกว่า) แอปเปิ้ลและหิน; ที่ผมกล่าวว่า.
rainabba

1
อาจเป็นสิ่งที่ถูกต้อง แต่ในสายตาของฉันฉันไม่รู้จักประเทศอื่น ๆ ในประเทศจีนโปรแกรมเมอร์จำนวนมากที่ฉันสัมภาษณ์เพียงรู้จัก EF หรือ Linq ถึง Sql กรอบงานเหล่านี้ลดประสิทธิภาพของ. net อย่างมาก
dexiang

1
สิ่งเดียวกันสามารถพูดกับ JS ในขณะที่ JS กำลังติดตาม fibonacci คุณคิดว่า. NET จะยังคงอยู่ในที่ที่มันรออยู่หรือไม่?
quanben
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.