NodeJS có nhanh hơn PHP 8 không?

Hiểu mô hình Đầu vào/Đầu ra (I/O) của ứng dụng của bạn có thể có nghĩa là sự khác biệt giữa một ứng dụng xử lý tải mà nó phải chịu và một ứng dụng bị nhàu nát khi đối mặt với các trường hợp sử dụng trong thế giới thực. Có lẽ trong khi ứng dụng của bạn nhỏ và không phục vụ tải cao, nó có thể ít quan trọng hơn nhiều. Nhưng khi tải lưu lượng truy cập ứng dụng của bạn tăng lên, làm việc với mô hình I/O sai có thể khiến bạn rơi vào thế giới bị tổn thương

Qua

Brad Peabody

Với gần hai thập kỷ phát triển phần mềm kinh doanh, Brad đã lãnh đạo các nhóm web, từng là quản trị viên hệ thống Linux và phát triển mặt tiền cửa hàng trong Go

CHIA SẺ

CHIA SẺ

Hiểu mô hình Đầu vào/Đầu ra (I/O) của ứng dụng của bạn có thể có nghĩa là sự khác biệt giữa một ứng dụng xử lý tải mà nó phải chịu và một ứng dụng bị nhàu nát khi đối mặt với các trường hợp sử dụng trong thế giới thực. Có lẽ trong khi ứng dụng của bạn nhỏ và không phục vụ tải cao, nó có thể ít quan trọng hơn nhiều. Nhưng khi tải lưu lượng truy cập ứng dụng của bạn tăng lên, làm việc với mô hình I/O sai có thể khiến bạn rơi vào thế giới bị tổn thương

Và giống như hầu hết mọi tình huống có thể áp dụng nhiều cách tiếp cận, vấn đề không chỉ là cách tiếp cận nào tốt hơn mà còn là vấn đề hiểu được sự đánh đổi. Hãy đi dạo qua bối cảnh I/O và xem những gì chúng ta có thể theo dõi

Trong bài viết này, chúng ta sẽ so sánh Node, Java, Go và PHP với Apache, thảo luận về cách các ngôn ngữ khác nhau mô hình hóa I/O của chúng, ưu điểm và nhược điểm của từng mô hình và kết luận bằng một số tiêu chuẩn cơ bản. Nếu bạn lo lắng về hiệu suất I/O của ứng dụng web tiếp theo của mình, thì bài viết này là dành cho bạn

Khái niệm cơ bản về I/O. Bồi dưỡng nhanh

Để hiểu các yếu tố liên quan đến I/O, trước tiên chúng ta phải xem lại các khái niệm ở cấp độ hệ điều hành. Mặc dù không chắc là sẽ phải xử lý trực tiếp nhiều khái niệm này, nhưng bạn luôn xử lý chúng một cách gián tiếp thông qua môi trường thời gian chạy của ứng dụng của bạn. And the details matter

System Calls

Firstly, we have system calls, which can be described as follows

• Your program (in “user land,” as they say) must ask the operating system kernel to perform an I/O operation on its behalf
• A “syscall” is the means by which your program asks the kernel do something. The specifics of how this is implemented vary between OSes but the basic concept is the same. There is going to be some specific instruction that transfers control from your program over to the kernel (like a function call but with some special sauce specifically for dealing with this situation). Generally speaking, syscalls are blocking, meaning your program waits for the kernel to return back to your code
• The kernel performs the underlying I/O operation on the physical device in question (disk, network card, etc. ) and replies to the syscall. In the real world, the kernel might have to do a number of things to fulfill your request including waiting for the device to be ready, updating its internal state, etc. , but as an application developer, you don’t care about that. That’s the kernel’s job

Blocking vs. Non-blocking Calls

Now, I just said above that syscalls are blocking, and that is true in a general sense. However, some calls are categorized as “non-blocking,” which means that the kernel takes your request, puts it in queue or buffer somewhere, and then immediately returns without waiting for the actual I/O to occur. So it “blocks” for only a very brief time period, just long enough to enqueue your request

Some examples (of Linux syscalls) might help clarify. - read() is a blocking call - you pass it a handle saying which file and a buffer of where to deliver the data it reads, and the call returns when the data is there. Note that this has the advantage of being nice and simple. - epoll_create(), epoll_ctl() and epoll_wait() are calls that, respectively, let you create a group of handles to listen on, add/remove handlers from that group and then block until there is any activity. This allows you to efficiently control a large number of I/O operations with a single thread, but I’m getting ahead of myself. This is great if you need the functionality, but as you can see it’s certainly more complex to use

It’s important to understand the order of magnitude of difference in timing here. If a CPU core is running at 3GHz, without getting into optimizations the CPU can do, it’s performing 3 billion cycles per second (or 3 cycles per nanosecond). A non-blocking system call might take on the order of 10s of cycles to complete - or “a relatively few nanoseconds”. Cuộc gọi chặn thông tin được nhận qua mạng có thể mất nhiều thời gian hơn - giả sử 200 mili giây (1/5 giây) chẳng hạn. Và giả sử, ví dụ: cuộc gọi không chặn mất 20 nano giây và cuộc gọi chặn mất 200.000.000 nano giây. Quá trình của bạn đã đợi cuộc gọi chặn lâu hơn 10 triệu lần

Hạt nhân cung cấp phương tiện để thực hiện cả I/O chặn (“đọc từ kết nối mạng này và cung cấp cho tôi dữ liệu”) và I/O không chặn (“cho tôi biết khi bất kỳ kết nối mạng nào trong số này có dữ liệu mới”). Và cơ chế nào được sử dụng sẽ chặn quá trình gọi trong các khoảng thời gian khác nhau đáng kể

lập kế hoạch

Điều quan trọng thứ ba cần tuân theo là điều gì sẽ xảy ra khi bạn có nhiều luồng hoặc quy trình bắt đầu chặn

Đối với mục đích của chúng tôi, không có sự khác biệt lớn giữa luồng và quy trình. Trong cuộc sống thực, sự khác biệt đáng chú ý nhất liên quan đến hiệu suất là do các luồng chia sẻ cùng một bộ nhớ và mỗi quy trình có không gian bộ nhớ riêng, khiến các quy trình riêng biệt có xu hướng chiếm nhiều bộ nhớ hơn. Nhưng khi chúng ta đang nói về lập lịch, thì điều thực sự tóm tắt là một danh sách những thứ (luồng và quy trình giống nhau) mà mỗi thứ cần có một phần thời gian thực thi trên các lõi CPU có sẵn. Nếu bạn có 300 luồng đang chạy và 8 lõi để chạy chúng, bạn phải chia thời gian ra để mỗi luồng nhận được phần của mình, với mỗi lõi chạy trong một khoảng thời gian ngắn rồi chuyển sang luồng tiếp theo. Điều này được thực hiện thông qua một “chuyển đổi ngữ cảnh”, làm cho CPU chuyển từ chạy một luồng/tiến trình này sang luồng/tiến trình tiếp theo.

Các công tắc ngữ cảnh này có chi phí liên quan đến chúng - chúng mất một thời gian. Trong một số trường hợp nhanh, có thể dưới 100 nano giây, nhưng cũng không hiếm trường hợp mất 1000 nano giây hoặc lâu hơn tùy thuộc vào chi tiết triển khai, tốc độ/kiến trúc bộ xử lý, bộ nhớ cache của CPU, v.v.

Và càng nhiều luồng (hoặc quy trình) thì càng có nhiều chuyển đổi ngữ cảnh. Khi chúng ta đang nói về hàng nghìn luồng và hàng trăm nano giây cho mỗi luồng, mọi thứ có thể trở nên rất chậm

Tuy nhiên, về bản chất, các cuộc gọi không chặn sẽ nói với kernel “chỉ gọi cho tôi khi bạn có một số dữ liệu hoặc sự kiện mới trên bất kỳ kết nối nào trong số này. ” Các cuộc gọi không chặn này được thiết kế để xử lý hiệu quả tải I/O lớn và giảm chuyển đổi ngữ cảnh

Với tôi cho đến nay? . Let’s look at what some popular languages do with these tools and draw some conclusions about the tradeoffs between ease of use and performance… and other interesting tidbits

Xin lưu ý, mặc dù các ví dụ được hiển thị trong bài viết này là tầm thường (và một phần, chỉ hiển thị các bit có liên quan); . all) và bất kỳ thứ gì yêu cầu I/O sẽ kết thúc bằng việc thực hiện một số loại lệnh gọi I/O ngầm sẽ có tác dụng tương tự như các ví dụ đơn giản được minh họa. Ngoài ra, đối với các tình huống trong đó I/O được mô tả là "chặn" (PHP, Java), yêu cầu HTTP và phản hồi đọc và ghi chính chúng đang chặn các cuộc gọi. Một lần nữa, nhiều I/O ẩn trong hệ thống với các vấn đề về hiệu suất của người phục vụ cần tính đến

Có rất nhiều yếu tố ảnh hưởng đến việc lựa chọn ngôn ngữ lập trình cho một dự án. Thậm chí có rất nhiều yếu tố khi bạn chỉ xem xét hiệu suất. Tuy nhiên, nếu bạn lo ngại rằng chương trình của bạn sẽ bị hạn chế chủ yếu bởi I/O, liệu hiệu suất I/O có ảnh hưởng đến dự án của bạn hay không, đây là những điều bạn cần biết

Phương pháp tiếp cận “Giữ nó đơn giản”. PHP

Trở lại những năm 90, rất nhiều người đã đi giày Converse và viết kịch bản CGI bằng Perl. Sau đó, PHP xuất hiện và, như một số người thích nói về nó, nó đã giúp việc tạo các trang web động dễ dàng hơn nhiều

Mô hình PHP sử dụng khá đơn giản. Có một số biến thể của nó nhưng máy chủ PHP trung bình của bạn trông giống như

Yêu cầu HTTP đến từ trình duyệt của người dùng và truy cập máy chủ web Apache của bạn. Apache tạo một quy trình riêng cho từng yêu cầu, với một số tối ưu hóa để sử dụng lại chúng nhằm giảm thiểu số lượng nó phải thực hiện (việc tạo các quy trình nói một cách tương đối là chậm). Apache gọi PHP và yêu cầu nó chạy tệp .php thích hợp trên đĩa. Mã PHP thực thi và chặn các cuộc gọi I/O. Bạn gọi

public void doGet(HttpServletRequest request,
	HttpServletResponse response) throws ServletException, IOException
{

	// blocking file I/O
	InputStream fileIs = new FileInputStream("/path/to/file");

	// blocking network I/O
	URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
	InputStream netIs = urlConnection.getInputStream();

	// some more blocking network I/O
out.println("...");
}

Và tất nhiên, mã thực tế được nhúng ngay vào trang của bạn và các hoạt động đang bị chặn

<?php

// blocking file I/O
$file_data = file_get_contents(‘/path/to/file.dat’);

// blocking network I/O
$curl = curl_init('http://example.com/example-microservice');
$result = curl_exec($curl);

// some more blocking network I/O
$result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100');

?>

Về cách tích hợp với hệ thống, nó như thế này

Khá đơn giản. một quy trình cho mỗi yêu cầu. Các cuộc gọi I/O chỉ bị chặn. Lợi thế? . Bất lợi? . Cách tiếp cận này không mở rộng tốt vì các công cụ được cung cấp bởi kernel để xử lý I/O khối lượng lớn (epoll, v.v. ) không được sử dụng. Và để tăng thêm sự xúc phạm, việc chạy một quy trình riêng biệt cho từng yêu cầu có xu hướng sử dụng nhiều tài nguyên hệ thống, đặc biệt là bộ nhớ, đây thường là thứ đầu tiên bạn sử dụng hết trong một tình huống như thế này

Ghi chú. Cách tiếp cận được sử dụng cho Ruby rất giống với cách tiếp cận của PHP và theo cách rộng rãi, chung chung, lượn sóng bằng tay, chúng có thể được coi là giống nhau cho các mục đích của chúng tôi

Phương pháp tiếp cận đa luồng. Java

Vì vậy, Java xuất hiện, ngay vào thời điểm bạn mua tên miền đầu tiên của mình và thật tuyệt khi chỉ ngẫu nhiên nói “chấm com” sau một câu. Và Java có đa luồng được tích hợp trong ngôn ngữ, điều này (đặc biệt là khi nó được tạo) là khá tuyệt vời

Hầu hết các máy chủ web Java hoạt động bằng cách bắt đầu một luồng thực thi mới cho mỗi yêu cầu đến và sau đó trong luồng này cuối cùng sẽ gọi hàm mà bạn, với tư cách là nhà phát triển ứng dụng, đã viết

Thực hiện I/O trong Java Servlet có xu hướng trông giống như

public void doGet(HttpServletRequest request,
	HttpServletResponse response) throws ServletException, IOException
{

	// blocking file I/O
	InputStream fileIs = new FileInputStream("/path/to/file");

	// blocking network I/O
	URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
	InputStream netIs = urlConnection.getInputStream();

	// some more blocking network I/O
out.println("...");
}

Vì phương pháp

public void doGet(HttpServletRequest request,
	HttpServletResponse response) throws ServletException, IOException
{

	// blocking file I/O
	InputStream fileIs = new FileInputStream("/path/to/file");

	// blocking network I/O
	URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
	InputStream netIs = urlConnection.getInputStream();

	// some more blocking network I/O
out.println("...");
}

Một cột mốc quan trọng là trong phiên bản 1. 4 Java (và một lần nữa nâng cấp đáng kể trong 1. 7) có khả năng thực hiện các cuộc gọi I/O không chặn. Hầu hết các ứng dụng, web và các ứng dụng khác, không sử dụng nó, nhưng ít nhất nó có sẵn. Một số máy chủ web Java cố gắng tận dụng điều này theo nhiều cách khác nhau;

Java giúp chúng ta tiến gần hơn và chắc chắn có một số chức năng sẵn dùng tốt cho I/O, nhưng nó vẫn không thực sự giải quyết được vấn đề điều gì sẽ xảy ra khi bạn có một ứng dụng bị ràng buộc I/O nặng nề đang bị dồn vào

I/O không chặn với tư cách là Công dân hạng nhất. Nút

Đứa trẻ nổi tiếng trong khối khi nói đến I/O tốt hơn là Node. js. Bất kỳ ai đã có phần giới thiệu ngắn gọn nhất về Node đều được cho biết rằng nó “không chặn” và nó xử lý I/O hiệu quả. Và điều này đúng theo nghĩa chung. Nhưng ma quỷ nằm ở các chi tiết và phương tiện mà trò phù thủy này đạt được quan trọng khi nói đến hiệu suất

Về cơ bản, sự thay đổi mô hình mà Node thực hiện là thay vì về cơ bản nói “viết mã của bạn ở đây để xử lý yêu cầu”, thay vào đó họ nói “viết mã ở đây để bắt đầu xử lý yêu cầu. ” Mỗi khi bạn cần làm gì đó liên quan đến I/O, bạn đưa ra yêu cầu và đưa ra chức năng gọi lại mà Node sẽ gọi khi hoàn thành

Mã nút điển hình để thực hiện thao tác I/O trong một yêu cầu sẽ như thế này

http.createServer(function(request, response) {
	fs.readFile('/path/to/file', 'utf8', function(err, data) {
		response.end(data);
	});
});

Như bạn có thể thấy, có hai chức năng gọi lại ở đây. Cái đầu tiên được gọi khi yêu cầu bắt đầu và cái thứ hai được gọi khi có dữ liệu tệp

Điều này về cơ bản là tạo cơ hội cho Node xử lý hiệu quả I/O giữa các cuộc gọi lại này. Một tình huống thậm chí còn phù hợp hơn là khi bạn đang thực hiện lệnh gọi cơ sở dữ liệu trong Node, nhưng tôi sẽ không bận tâm đến ví dụ này vì nó có cùng một nguyên tắc. Bạn bắt đầu cuộc gọi cơ sở dữ liệu và cung cấp cho Node một chức năng gọi lại, nó thực hiện các hoạt động I/O một cách riêng biệt bằng cách sử dụng các cuộc gọi không chặn và sau đó gọi chức năng gọi lại của bạn khi có sẵn dữ liệu bạn yêu cầu. Cơ chế xếp hàng đợi các cuộc gọi I/O này và để Node xử lý nó, sau đó nhận cuộc gọi lại được gọi là “Vòng lặp sự kiện. ” Và nó hoạt động khá tốt

Tuy nhiên, có một nhược điểm đối với mô hình này. Về cơ bản, lý do của nó liên quan nhiều đến cách thức công cụ JavaScript V8 (công cụ JS của Chrome được Node sử dụng) được triển khai 1 hơn bất kỳ thứ gì khác. Mã JS mà bạn viết tất cả chạy trong một chuỗi. Hãy suy nghĩ về điều đó trong một thời điểm. Điều đó có nghĩa là trong khi I/O được thực hiện bằng cách sử dụng các kỹ thuật không chặn hiệu quả, thì JS của bạn có thể thực hiện các hoạt động liên kết với CPU sẽ chạy trong một luồng đơn, mỗi đoạn mã sẽ chặn đoạn mã tiếp theo. Một ví dụ phổ biến về nơi điều này có thể xảy ra là lặp qua các bản ghi cơ sở dữ liệu để xử lý chúng theo một cách nào đó trước khi xuất chúng cho máy khách. Đây là một ví dụ cho thấy nó hoạt động như thế nào

var handler = function(request, response) {

	connection.query('SELECT ...', function (err, rows) {

		if (err) { throw err };

		for (var i = 0; i < rows.length; i++) {
			// do processing on each row
		}

		response.end(...); // write out the results
		
	})

};

Mặc dù Node xử lý I/O một cách hiệu quả, nhưng vòng lặp

public void doGet(HttpServletRequest request,
	HttpServletResponse response) throws ServletException, IOException
{

	// blocking file I/O
	InputStream fileIs = new FileInputStream("/path/to/file");

	// blocking network I/O
	URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
	InputStream netIs = urlConnection.getInputStream();

	// some more blocking network I/O
out.println("...");
}

Tiền đề mà toàn bộ khái niệm này dựa trên là các hoạt động I/O là phần chậm nhất, do đó, điều quan trọng nhất là phải xử lý chúng một cách hiệu quả, ngay cả khi điều đó có nghĩa là thực hiện các xử lý khác theo trình tự. Điều này đúng trong một số trường hợp, nhưng không phải trong tất cả

Điểm khác là, và mặc dù đây chỉ là một ý kiến, nhưng việc viết một loạt các lệnh gọi lại lồng nhau có thể khá mệt mỏi và một số người cho rằng điều đó khiến mã khó theo dõi hơn đáng kể. Không có gì lạ khi thấy các cuộc gọi lại được lồng bốn, năm hoặc thậm chí nhiều cấp độ hơn vào sâu bên trong mã Node

Chúng ta quay trở lại với sự đánh đổi. Mô hình Node hoạt động tốt nếu vấn đề hiệu suất chính của bạn là I/O. Tuy nhiên, điểm yếu của nó là bạn có thể truy cập vào một chức năng đang xử lý yêu cầu HTTP và đặt mã sử dụng nhiều CPU và khiến mọi kết nối bị thu thập thông tin nếu bạn không cẩn thận

Tự nhiên không chặn. Đi

Trước khi tôi bước vào phần dành cho cờ vây, thật thích hợp để tôi tiết lộ rằng tôi là một fanboy cờ vây. Tôi đã sử dụng nó cho nhiều dự án và tôi công khai ủng hộ những lợi thế về năng suất của nó và tôi thấy chúng trong công việc của mình khi tôi sử dụng nó

Điều đó nói rằng, hãy xem cách nó xử lý I/O. Một tính năng chính của ngôn ngữ Go là nó chứa bộ lập lịch riêng. Thay vì mỗi luồng thực thi tương ứng với một luồng hệ điều hành duy nhất, nó hoạt động với khái niệm “goroutines. ” Và bộ thực thi Go có thể chỉ định một con goroutine cho một chuỗi hệ điều hành và để nó thực thi hoặc tạm dừng nó và không liên kết nó với một chuỗi hệ điều hành, dựa trên những gì con goroutine đó đang làm. Mỗi yêu cầu đến từ máy chủ HTTP của Go được xử lý trong một Goroutine riêng biệt

Sơ đồ về cách hoạt động của bộ lập lịch trình trông như thế này

Về cơ bản, điều này được thực hiện bởi nhiều điểm khác nhau trong thời gian chạy Go thực hiện lệnh gọi I/O bằng cách thực hiện yêu cầu ghi/đọc/kết nối/v.v. , đặt goroutine hiện tại vào chế độ ngủ, với thông tin để đánh thức goroutine sao lưu khi có thể thực hiện hành động tiếp theo

Trên thực tế, thời gian chạy Go đang thực hiện một số việc không quá khác biệt với những gì Node đang thực hiện, ngoại trừ cơ chế gọi lại được tích hợp trong quá trình triển khai lệnh gọi I/O và tự động tương tác với bộ lập lịch biểu. Nó cũng không bị hạn chế là phải chạy tất cả mã trình xử lý của bạn trong cùng một luồng, Go sẽ tự động ánh xạ các Goroutine của bạn tới nhiều luồng hệ điều hành mà nó cho là phù hợp dựa trên logic trong bộ lập lịch của nó. Kết quả là mã như thế này

func ServeHTTP(w http.ResponseWriter, r *http.Request) {

	// the underlying network call here is non-blocking
	rows, err := db.Query("SELECT ...")
	
	for _, row := range rows {
		// do something with the rows,
// each request in its own goroutine
	}

	w.Write(...) // write the response, also non-blocking

}

Như bạn có thể thấy ở trên, cấu trúc mã cơ bản của những gì chúng ta đang làm giống với cấu trúc của các cách tiếp cận đơn giản hơn, nhưng vẫn đạt được I/O không bị chặn ở bên trong

Trong hầu hết các trường hợp, điều này kết thúc là “tốt nhất của cả hai thế giới. ” I/O không chặn được sử dụng cho tất cả những điều quan trọng, nhưng mã của bạn có vẻ như đang chặn và do đó có xu hướng dễ hiểu và dễ bảo trì hơn. Sự tương tác giữa bộ lập lịch Go và bộ lập lịch OS xử lý phần còn lại. Nó không hoàn toàn là phép thuật, và nếu bạn xây dựng một hệ thống lớn, bạn nên dành thời gian để hiểu chi tiết hơn về cách thức hoạt động của nó;

Go có thể có lỗi của nó, nhưng nói chung, cách nó xử lý I/O không nằm trong số đó

Dối trá, dối trá chết tiệt và điểm chuẩn

Rất khó để đưa ra thời gian chính xác cho việc chuyển ngữ cảnh liên quan đến các mô hình khác nhau này. Tôi cũng có thể lập luận rằng nó ít hữu ích hơn cho bạn. Vì vậy, thay vào đó, tôi sẽ cung cấp cho bạn một số điểm chuẩn cơ bản so sánh hiệu suất máy chủ HTTP tổng thể của các môi trường máy chủ này. Hãy nhớ rằng có rất nhiều yếu tố liên quan đến hiệu suất của toàn bộ đường dẫn yêu cầu/phản hồi HTTP từ đầu đến cuối và các con số được trình bày ở đây chỉ là một số mẫu tôi tổng hợp lại để đưa ra so sánh cơ bản

Đối với mỗi môi trường này, tôi đã viết mã thích hợp để đọc trong tệp 64k với các byte ngẫu nhiên, chạy hàm băm SHA-256 trên đó N số lần (N được chỉ định trong chuỗi truy vấn của URL, e. g. ,

public void doGet(HttpServletRequest request,
	HttpServletResponse response) throws ServletException, IOException
{

	// blocking file I/O
	InputStream fileIs = new FileInputStream("/path/to/file");

	// blocking network I/O
	URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
	InputStream netIs = urlConnection.getInputStream();

	// some more blocking network I/O
out.println("...");
}

Xem các ghi chú điểm chuẩn này để biết thêm chi tiết về các môi trường được sử dụng

Trước tiên, hãy xem xét một số ví dụ đồng thời thấp. Chạy 2000 lần lặp lại với 300 yêu cầu đồng thời và chỉ một hàm băm cho mỗi yêu cầu (N=1) mang lại cho chúng tôi điều này

Thời gian là số mili giây trung bình để hoàn thành một yêu cầu trên tất cả các yêu cầu đồng thời. Thấp hơn là tốt hơn

Thật khó để đưa ra kết luận chỉ từ một biểu đồ này, nhưng điều này đối với tôi dường như là, ở khối lượng kết nối và tính toán này, chúng ta đang thấy nhiều việc phải làm hơn với việc thực thi chung của chính các ngôn ngữ, nhiều hơn thế nữa . Lưu ý rằng các ngôn ngữ được coi là "ngôn ngữ viết" (đánh máy lỏng lẻo, diễn giải động) hoạt động chậm nhất

Nhưng điều gì sẽ xảy ra nếu chúng ta tăng N lên 1000, vẫn với 300 yêu cầu đồng thời - cùng tải nhưng số lần lặp băm nhiều hơn 100 lần (tải CPU nhiều hơn đáng kể)

Thời gian là số mili giây trung bình để hoàn thành một yêu cầu trên tất cả các yêu cầu đồng thời. Thấp hơn là tốt hơn

Đột nhiên, hiệu suất của Node giảm đáng kể do các hoạt động sử dụng nhiều CPU trong mỗi yêu cầu đang chặn lẫn nhau. Và thật thú vị, hiệu năng của PHP trở nên tốt hơn nhiều (so với những cái khác) và đánh bại Java trong thử nghiệm này. (Điều đáng chú ý là trong PHP, việc triển khai SHA-256 được viết bằng C và đường dẫn thực thi tốn nhiều thời gian hơn trong vòng lặp đó, vì hiện tại chúng ta đang thực hiện 1000 lần lặp băm)

Bây giờ, hãy thử 5000 kết nối đồng thời (với N=1) - hoặc gần nhất có thể. Thật không may, đối với hầu hết các môi trường này, tỷ lệ thất bại không đáng kể. Đối với biểu đồ này, chúng tôi sẽ xem xét tổng số yêu cầu mỗi giây. càng cao càng tốt

Tổng số yêu cầu mỗi giây. Cao hơn thì tốt hơn

Và hình ảnh trông khá khác nhau. Đó là một phỏng đoán, nhưng có vẻ như ở khối lượng kết nối cao, chi phí cho mỗi kết nối liên quan đến việc tạo ra các quy trình mới và bộ nhớ bổ sung được liên kết với nó trong PHP + Apache dường như trở thành yếu tố chi phối và làm tăng hiệu suất của PHP. Rõ ràng, Go là người chiến thắng ở đây, tiếp theo là Java, Node và cuối cùng là PHP

Mặc dù các yếu tố liên quan đến thông lượng tổng thể của bạn rất nhiều và cũng rất khác nhau giữa các ứng dụng, nhưng bạn càng hiểu rõ hơn về bản chất của những gì đang diễn ra bên trong và những đánh đổi liên quan, thì bạn càng có lợi.

Tóm tắt

Với tất cả những điều trên, rõ ràng là khi ngôn ngữ phát triển, các giải pháp để xử lý các ứng dụng quy mô lớn thực hiện nhiều I/O cũng phát triển theo.

Công bằng mà nói, cả PHP và Java, mặc dù đã được mô tả trong bài viết này, đều có sẵn các triển khai I/O không chặn để sử dụng trong các ứng dụng web. Nhưng những cách này không phổ biến như các phương pháp được mô tả ở trên và chi phí hoạt động của người phục vụ để duy trì các máy chủ sử dụng các phương pháp như vậy sẽ cần được tính đến. Chưa kể mã của bạn phải được cấu trúc theo cách hoạt động với các môi trường như vậy;

Để so sánh, nếu chúng ta xem xét một số yếu tố quan trọng ảnh hưởng đến hiệu suất cũng như mức độ dễ sử dụng, chúng ta sẽ nhận được điều này

Chủ đề ngôn ngữ so với. Quá trình Non-blocking I/O'Ease of UsePHPProcessesNoJavaThreadsAvailableRequires Callbacks Node. jsThreadsYesYêu cầu gọi lạiGoThreads (goroutines)CóKhông cần gọi lại

Các luồng nói chung sẽ sử dụng bộ nhớ hiệu quả hơn nhiều so với các quy trình, vì chúng chia sẻ cùng một không gian bộ nhớ trong khi các quy trình thì không. Kết hợp điều đó với các yếu tố liên quan đến I/O không chặn, chúng ta có thể thấy rằng ít nhất với các yếu tố được xem xét ở trên, khi chúng ta di chuyển xuống danh sách, thiết lập chung vì nó liên quan đến I/O được cải thiện. Vì vậy, nếu tôi phải chọn một người chiến thắng trong cuộc thi trên, đó chắc chắn sẽ là Go

Mặc dù vậy, trên thực tế, việc chọn một môi trường để xây dựng ứng dụng của bạn có liên quan mật thiết đến mức độ quen thuộc mà nhóm của bạn có với môi trường nói trên và năng suất tổng thể mà bạn có thể đạt được với môi trường đó. Vì vậy, có thể không hợp lý khi mọi nhóm chỉ tham gia và bắt đầu phát triển các ứng dụng và dịch vụ web trong Node hoặc Go. Thật vậy, việc tìm kiếm các nhà phát triển hoặc sự quen thuộc của nhóm nội bộ của bạn thường được coi là lý do chính để không sử dụng ngôn ngữ và/hoặc môi trường khác. Điều đó nói rằng, thời gian đã thay đổi trong mười lăm năm qua, rất nhiều

Hy vọng những điều trên giúp vẽ nên một bức tranh rõ ràng hơn về những gì đang diễn ra bên trong và cung cấp cho bạn một số ý tưởng về cách xử lý khả năng mở rộng trong thế giới thực cho ứng dụng của bạn. Vui vẻ nhập và xuất

Đọc thêm trên Blog Kỹ thuật Toptal

• 4 Chỉ trích ngôn ngữ Go
• Logic có cấu trúc tốt. Hướng dẫn Golang OOP
• Đi ngôn ngữ lập trình. Hướng dẫn giới thiệu về Golang
• Sau ngần ấy năm, thế giới vẫn được hỗ trợ bởi lập trình C
• Mã Viết Mã. Giới thiệu về lý thuyết và thực hành siêu lập trình hiện đại

Thẻ

Người làm việc tự do? Tìm công việc tiếp theo của bạn.

Việc làm Lập trình viên Back-End

Xem thông tin đầy đủ

Brad Peabody

nhà phát triển

Thông tin về các Tác giả

Brad thích xây dựng và cải thiện phần mềm giải quyết các vấn đề kinh doanh trong thế giới thực và tạo ra trải nghiệm tích cực cho người dùng, cũng như có tác động kinh doanh tích cực cho tổ chức. Anh ấy được truyền cảm hứng từ văn hóa làm việc năng suất cao/sáng tạo—đi trên ranh giới giữa sự hoàn hảo và tinh thần làm cho xong việc

Thuê Brad

Bình luận

Patrick

So sánh thú vị. Một chút nitpick. Nút không "yêu cầu" các cuộc gọi lại, chắc chắn không phải vì Promise đã trở thành một tính năng gốc trong ES6 và kể từ v 7. 6, nó thậm chí còn có async/await (mặc dù đó chỉ là một vỏ bọc xung quanh lời hứa)

Patrick

So sánh thú vị. Một chút nitpick. Nút không "yêu cầu" các cuộc gọi lại, chắc chắn không phải vì Promise đã trở thành một tính năng gốc trong ES6 và kể từ v 7. 6, nó thậm chí còn có async/await (mặc dù đó chỉ là một vỏ bọc xung quanh lời hứa)

pha trộn

Bài viết hay, tôi muốn rằng bạn cũng đưa vào như một phần của các công nghệ Servlet con trai các công nghệ IO không chặn như Netty, Vert. x và AKKA. Chúng dựa trên cuộc gọi không đồng bộ và cuộc gọi không chặn, Vertx. Sử dụng một luồng trên mỗi bộ xử lý lõi và tận dụng cả hai lợi thế trên thế giới, Các cuộc gọi IO/Không đồng bộ không chặn và chỉ một vài luồng. Trân trọng, Dimitri

pha trộn

Bài viết hay, tôi muốn rằng bạn cũng đưa vào như một phần của các công nghệ Servlet con trai các công nghệ IO không chặn như Netty, Vert. x và AKKA. Chúng dựa trên cuộc gọi không đồng bộ và cuộc gọi không chặn, Vertx. Sử dụng một luồng trên mỗi bộ xử lý lõi và tận dụng cả hai lợi thế trên thế giới, Các cuộc gọi IO/Không đồng bộ không chặn và chỉ một vài luồng. Trân trọng, Dimitri

Greg

Srsly? . 4. 16; . 4. 6 Điểm chuẩn của bạn không công bằng. Bạn sử dụng phiên bản mới nhất của nút, java và go và phiên bản cũ nhất của php và apache cũ. Sử dụng php7. 1 với nginx và hiển thị kết quả (Tôi sẽ làm điều đó nhưng tôi có máy khác và bạn không cung cấp nguồn tệp điểm chuẩn để tôi thực hiện lại tất cả các bài kiểm tra)

Greg

Srsly? . 4. 16; . 4. 6 Điểm chuẩn của bạn không công bằng. Bạn sử dụng phiên bản mới nhất của nút, java và go và phiên bản cũ nhất của php và apache cũ. Sử dụng php7. 1 với nginx và hiển thị kết quả (Tôi sẽ làm điều đó nhưng tôi có máy khác và bạn không cung cấp nguồn tệp điểm chuẩn để tôi thực hiện lại tất cả các bài kiểm tra)

Andriy

Tôi muốn lưu ý một điều. Mỗi ngôn ngữ có lĩnh vực sử dụng cụ thể của riêng mình. Tôi chắc chắn 100% rằng tổ chức tài chính sẽ không sử dụng các ngôn ngữ "không chặn" ngay cả khi chúng "siêu nhanh", bởi vì chúng cần chu kỳ hoạt động an toàn và nhất quán. Trong khi "khởi động nhắn tin" có thể đi với Go / Node, vì nó không hoạt động với dữ liệu quan trọng

Andriy

Tôi muốn lưu ý một điều. Mỗi ngôn ngữ có lĩnh vực sử dụng cụ thể của riêng mình. Tôi chắc chắn 100% rằng tổ chức tài chính sẽ không sử dụng các ngôn ngữ "không chặn" ngay cả khi chúng "siêu nhanh", bởi vì chúng cần chu kỳ hoạt động an toàn và nhất quán. Trong khi "khởi động nhắn tin" có thể đi với Go / Node, vì nó không hoạt động với dữ liệu quan trọng

Roland Harrison

Bạn đã quên viết các hàm không đồng bộ trong C# Imo một cách tiếp cận tuyệt vời, giống như. Mua mã chặn chạy không đồng bộ

Roland Harrison

Bạn đã quên viết các hàm không đồng bộ trong C# Imo một cách tiếp cận tuyệt vời, giống như. Mua mã chặn chạy không đồng bộ

Samuel Lawson

Bạn nên chạy các điểm chuẩn đó với PHP7 ngay bây giờ vì nó đã được chấp nhận rộng rãi hơn trong phần mềm doanh nghiệp. Với mức tăng hiệu suất 100% được báo cáo, nó sẽ giúp Go kiếm tiền

Samuel Lawson

Bạn nên chạy các điểm chuẩn đó với PHP7 ngay bây giờ vì nó đã được chấp nhận rộng rãi hơn trong phần mềm doanh nghiệp. Với mức tăng hiệu suất 100% được báo cáo, nó sẽ giúp Go kiếm tiền

động cơ

Bỏ qua các bình luận về các phiên bản phần mềm cũ hơn, tôi thấy nội dung của bài viết rất nhiều thông tin. Tôi không ngạc nhiên với kết quả nhưng tôi đã học được điều gì đó về cách hoạt động của các môi trường khác nhau - điều này rất hữu ích. Cảm ơn bạn

động cơ

Bỏ qua các bình luận về các phiên bản phần mềm cũ hơn, tôi thấy nội dung của bài viết rất nhiều thông tin. Tôi không ngạc nhiên với kết quả nhưng tôi đã học được điều gì đó về cách hoạt động của các môi trường khác nhau - điều này rất hữu ích. Cảm ơn bạn

Fadel Chafai

Ngày phát hành Man PHP7 là ngày 3 tháng 12 năm 2015

Fadel Chafai

Ngày phát hành Man PHP7 là ngày 3 tháng 12 năm 2015

Qiong Wu

Tôi tự hỏi, liệu bạn có thường thực hiện thao tác băm trong nodejs hay bạn sẽ không viết một giao diện cho điều đó vì các tác vụ chuyên sâu của CPU được biết rõ ràng là hoạt động rất tệ trong nodejs?

Qiong Wu

Tôi tự hỏi, liệu bạn có thường thực hiện thao tác băm trong nodejs hay bạn sẽ không viết một giao diện cho điều đó vì các tác vụ chuyên sâu của CPU được biết rõ ràng là hoạt động rất tệ trong nodejs?

MichaelWebDev

Đọc tuyệt vời. Cảm ơn vì bài viết Brad

MichaelWebDev

Đọc tuyệt vời. Cảm ơn vì bài viết Brad

John Corry

php 7. 1/nginx sẽ cho thấy sự cải thiện. nhưng kết quả sẽ tương tự do (như đã giải thích sâu trong bài viết) PHP chặn IO. Điểm rút ra thực sự từ điều này là "PHP có thể dễ sử dụng, nhưng nó không 'hiệu quả'. Go có hiệu suất như mọi thứ có sẵn"

John Corry

php 7. 1/nginx sẽ cho thấy sự cải thiện. nhưng kết quả sẽ tương tự do (như đã giải thích sâu trong bài viết) PHP chặn IO. Điểm rút ra thực sự từ điều này là "PHP có thể dễ sử dụng, nhưng nó không 'hiệu quả'. Go có hiệu suất như mọi thứ có sẵn"

Peter Kokot

Cảm ơn bạn đã chia sẻ những điểm chuẩn này. Luôn hữu ích để xem mỗi nền tảng đang hoạt động tốt và không tốt. Tôi sẽ thêm một vài ghi chú cho PHP có thể thay đổi nhiều. Có một phần mở rộng Swoole cho PHP. Bạn có thể ngạc nhiên về tốc độ nhanh như thế nào. nhanh hơn gấp 10 lần so với thiết lập thông thường như đã chỉ ra ở trên. Nhưng yêu cầu một chút cài đặt và điều chỉnh vì đó không phải là ứng dụng PHP truyền thống nữa

Peter Kokot

Cảm ơn bạn đã chia sẻ những điểm chuẩn này. Luôn hữu ích để xem mỗi nền tảng đang hoạt động tốt và không tốt. Tôi sẽ thêm một vài ghi chú cho PHP có thể thay đổi nhiều. Có một phần mở rộng Swoole cho PHP. Bạn có thể ngạc nhiên về tốc độ nhanh như thế nào. nhanh hơn gấp 10 lần so với thiết lập thông thường như đã chỉ ra ở trên. Nhưng yêu cầu một chút cài đặt và điều chỉnh vì đó không phải là ứng dụng PHP truyền thống nữa

Juan Pablo Carzolio

Cảm ơn, Brad. Đọc tuyệt vời. Tôi đồng ý với một số phản đối trong các nhận xét khác (Lời hứa, PHP 7, v.v. ), nhưng những lời giải thích rất hay và bài viết có nhiều thông tin. Tôi không quen với Go và thấy khái niệm này khá thú vị. Điểm chuẩn rất hữu ích để đưa ra ý tưởng sơ bộ - con số chính xác không thực sự phù hợp với IMHO

Juan Pablo Carzolio

Cảm ơn, Brad. Đọc tuyệt vời. Tôi đồng ý với một số phản đối trong các nhận xét khác (Lời hứa, PHP 7, v.v. ), nhưng những lời giải thích rất hay và bài viết có nhiều thông tin. Tôi không quen với Go và thấy khái niệm này khá thú vị. Điểm chuẩn rất hữu ích để đưa ra ý tưởng sơ bộ - con số chính xác không thực sự phù hợp với IMHO

Stas Slesarev

Không tìm thấy bất kỳ từ nào về cách Node. js đang chạy trong điểm chuẩn của bạn. Ý tôi là, bạn đã sử dụng phân cụm (e. g. chạy `pm2 bắt đầu chỉ mục. js -i 0` để sử dụng tất cả các CPU)?

Stas Slesarev

Không tìm thấy bất kỳ từ nào về cách Node. js đang chạy trong điểm chuẩn của bạn. Ý tôi là, bạn đã sử dụng phân cụm (e. g. chạy `pm2 bắt đầu chỉ mục. js -i 0` để sử dụng tất cả các CPU)?

Mike Critchley

Đọc xuất sắc. Và không chỉ theo một cách rộng rãi, chung chung, gợn sóng bằng tay (LMAO @ that, btw). Đây không phải là lĩnh vực của tôi, nhưng tôi chắc chắn hiểu nó tốt hơn rất nhiều so với 20 phút trước nhờ điều này. Cảm ơn đã dành thời gian để viết nó lên

Mike Critchley

Đọc xuất sắc. Và không chỉ theo một cách rộng rãi, chung chung, gợn sóng bằng tay (LMAO @ that, btw). Đây không phải là lĩnh vực của tôi, nhưng tôi chắc chắn hiểu nó tốt hơn rất nhiều so với 20 phút trước nhờ điều này. Cảm ơn đã dành thời gian để viết nó lên

phra

Sử dụng cụm nodejs ít nhất. Làm thế nào bạn có thể so sánh một chương trình đa lõi với một luồng thực thi? . Điểm chuẩn này không có ý nghĩa gì với tôi

phra

Sử dụng cụm nodejs ít nhất. Làm thế nào bạn có thể so sánh một chương trình đa lõi với một luồng thực thi? . Điểm chuẩn này không có ý nghĩa gì với tôi

Ruan Kovalczyk

Mọi người là ai? . ;)

Ruan Kovalczyk

Mọi người là ai? . ;)

xer0x

Ý tưởng tuyệt vời, đó sẽ là một cách hay để xây dựng ứng dụng Node trong thế giới thực. Bài viết này sẽ minh bạch hơn nếu tác giả có Fibonacci thay vì SHA256 cho bản demo này

xer0x

Ý tưởng tuyệt vời, đó sẽ là một cách hay để xây dựng ứng dụng Node trong thế giới thực. Bài viết này sẽ minh bạch hơn nếu tác giả có Fibonacci thay vì SHA256 cho bản demo này

Julius Koronci

Bài báo tuyệt vời. khá hài lòng với kết quả PHP. bởi vì thêm một vài máy chủ vào PHP vẫn rẻ hơn so với phát triển bằng nút hoặc java. )

Julius Koronci

Bài báo tuyệt vời. khá hài lòng với kết quả PHP. bởi vì thêm một vài máy chủ vào PHP vẫn rẻ hơn so với phát triển bằng nút hoặc java. )

nikos

tốt, bạn không phải lúc nào cũng sử dụng lời hứa để tuần tự hóa hoàn toàn mọi thứ hoặc bạn sẽ cần một đối tượng toàn cầu sẽ giữ mọi thứ bạn cần hoặc trả lại một đối tượng mọi lúc từ lời hứa sẽ giữ mọi thứ ngay từ đầu, vì vậy dù sao đi nữa, mọi thứ trở nên phức tạp khi cấu trúc

nikos

tốt, bạn không phải lúc nào cũng sử dụng lời hứa để tuần tự hóa hoàn toàn mọi thứ hoặc bạn sẽ cần một đối tượng toàn cầu sẽ giữ mọi thứ bạn cần hoặc trả lại một đối tượng mọi lúc từ lời hứa sẽ giữ mọi thứ ngay từ đầu, vì vậy dù sao đi nữa, mọi thứ trở nên phức tạp khi cấu trúc

phra

bạn có say rượu hay không?

phra

bạn có say rượu hay không?

phra

nhận xét rất hữu ích. chúc mừng. bạn là một anh hùng thực sự

phra

nhận xét rất hữu ích. chúc mừng. bạn là một anh hùng thực sự

Ruan Kovalczyk

Cảm ơn bạn

Ruan Kovalczyk

Cảm ơn bạn

nikos

tại sao bạn nghĩ như vậy?

nikos

tại sao bạn nghĩ như vậy?

Ryan Winchester

Please include Elixir next time! - Pinterest goes from 30 servers to 15 moving from Java to Elixir - Bleacher Report goes from 150 servers to 5 moving from Rails to Elixir

Ryan Winchester

Please include Elixir next time! - Pinterest goes from 30 servers to 15 moving from Java to Elixir - Bleacher Report goes from 150 servers to 5 moving from Rails to Elixir

Brad

Thanks. Đúng, những lời hứa có thể giúp dễ đọc, nhưng bạn vẫn cần một chức năng được gọi lại. Các lời hứa chủ yếu giúp ích để bạn không nhận được chức năng lồng sâu, mã trông khá giống nhau

Brad

Thanks. Đúng, những lời hứa có thể giúp dễ đọc, nhưng bạn vẫn cần một chức năng được gọi lại. Các lời hứa chủ yếu giúp ích để bạn không nhận được chức năng lồng sâu, mã trông khá giống nhau

Mihai Tudor

Vâng, tiêu chuẩn PHP này trông giống như khi khủng long đi lang thang quanh đây. Tôi không nói rằng bạn nên sử dụng PHP khi bạn đang tạo một API được sử dụng nhiều, nhưng dưới một giới hạn, nó là một đối thủ cạnh tranh tốt cho mọi thứ khác trên thị trường. Tôi muốn xem điểm chuẩn này được tạo lại bằng PHP 7. x

Mihai Tudor

Vâng, tiêu chuẩn PHP này trông giống như khi khủng long đi lang thang quanh đây. Tôi không nói rằng bạn nên sử dụng PHP khi bạn đang tạo một API được sử dụng nhiều, nhưng dưới một giới hạn, nó là một đối thủ cạnh tranh tốt cho mọi thứ khác trên thị trường. Tôi muốn xem điểm chuẩn này được tạo lại bằng PHP 7. x

Brad

Cơ chế nào bạn đang đề cập cụ thể? . Nhưng bạn cũng phải tính đến ý tưởng rằng nếu bạn phải sử dụng nhóm luồng để thực hiện một thao tác đơn giản, thì đó là rất nhiều công việc của nhà phát triển để ảnh hưởng đến một cái gì đó đơn giản. Tôi không chắc điều đó phản ánh chính xác quá trình phát triển của thế giới thực thường diễn ra như thế nào. Điều đó nói rằng, bạn đúng rằng hiệu suất chắc chắn có thể thấy một sự cải thiện lớn NẾU bạn làm thêm công việc phát triển. Thật dễ dàng để thực hiện các cuộc gọi trong hàm xử lý mà không biết cường độ CPU của chúng và vô tình làm những gì tôi đã làm ở đây

Brad

Cơ chế nào bạn đang đề cập cụ thể? . Nhưng bạn cũng phải tính đến ý tưởng rằng nếu bạn phải sử dụng nhóm luồng để thực hiện một thao tác đơn giản, thì đó là rất nhiều công việc của nhà phát triển để ảnh hưởng đến một cái gì đó đơn giản. Tôi không chắc điều đó phản ánh chính xác quá trình phát triển của thế giới thực thường diễn ra như thế nào. Điều đó nói rằng, bạn đúng rằng hiệu suất chắc chắn có thể thấy một sự cải thiện lớn NẾU bạn làm thêm công việc phát triển. Thật dễ dàng để thực hiện các cuộc gọi trong hàm xử lý mà không biết cường độ CPU của chúng và vô tình làm những gì tôi đã làm ở đây

Alexander Roddis

Cái này

Alexander Roddis

Cái này

Brad

https. // tải lên. disquscdn. com/images/90484bb6980dc60025ff6881661a55687b96bfbe0251fb27393a32fec18d6cd4. jpg Để trả lời các bình luận PHP 7. Thẳng thừng, đây là một lời chỉ trích hợp lệ. Nhưng tôi cũng không nghĩ rằng nó thay đổi quan điểm chung của bài viết, đó là các mô hình được sử dụng, không phải điểm chuẩn cụ thể. Điều đó nói rằng, CentOS (mới nhất và lớn nhất) ra mắt với PHP 5. 4. Và PHP cũng nổi tiếng với việc phá vỡ mọi thứ giữa các phiên bản (ít nhất là trong cuốn sách của tôi và tôi đã trải qua quá trình này với các ứng dụng chính nhiều lần), vì vậy việc chạy mọi thứ trên phiên bản mới nhất không phải lúc nào cũng đơn giản, có rất nhiều PHP . x vẫn còn người dùng (https. // đã bán. be/notes/php-versions-stats-2017-1-edition). Tôi chắc chắn thừa nhận rằng PHP 7 chắc chắn sẽ làm tốt hơn về hiệu suất, không bao gồm đó là một sự giám sát từ phía tôi

Brad

https. // tải lên. disquscdn. com/images/90484bb6980dc60025ff6881661a55687b96bfbe0251fb27393a32fec18d6cd4. jpg Để trả lời các bình luận PHP 7. Thẳng thừng, đây là một lời chỉ trích hợp lệ. Nhưng tôi cũng không nghĩ rằng nó thay đổi quan điểm chung của bài viết, đó là các mô hình được sử dụng, không phải điểm chuẩn cụ thể. Điều đó nói rằng, CentOS (mới nhất và lớn nhất) ra mắt với PHP 5. 4. Và PHP cũng nổi tiếng với việc phá vỡ mọi thứ giữa các phiên bản (ít nhất là trong cuốn sách của tôi và tôi đã trải qua quá trình này với các ứng dụng chính nhiều lần), vì vậy việc chạy mọi thứ trên phiên bản mới nhất không phải lúc nào cũng đơn giản, có rất nhiều PHP . x vẫn còn người dùng (https. // đã bán. be/notes/php-versions-stats-2017-1-edition). Tôi chắc chắn thừa nhận rằng PHP 7 chắc chắn sẽ làm tốt hơn về hiệu suất, không bao gồm đó là một sự giám sát từ phía tôi

Brad

Lol, có sự thật về điều đó. )

Brad

Lol, có sự thật về điều đó. )

Brad

Điểm hợp lệ. Bản thân tôi không biết số liệu thống kê về điều đó là gì nhưng vâng, tôi chắc chắn rằng rất nhiều thiết lập sản xuất được nhóm lại và điều này chắc chắn sẽ giúp giảm bớt tắc nghẽn CPU. Là một lưu ý thú vị về điều này, nó có một số tác dụng phụ như thực tế là khi bạn sinh ra nhiều quy trình, bạn cũng tạo một bản sao của bất kỳ tài nguyên nào trên mỗi quy trình - bộ nhớ chung của quy trình, bộ đệm, tệp ánh xạ mem, v.v. Đây không nhất thiết phải là một vấn đề lớn nhưng trong một ứng dụng phức tạp, nó chắc chắn có thể làm tăng thêm sự phình to mà bạn không có ý định và sẽ không có khi bạn chỉ chạy một bản sao của nút

Brad

Điểm hợp lệ. Bản thân tôi không biết số liệu thống kê về điều đó là gì nhưng vâng, tôi chắc chắn rằng rất nhiều thiết lập sản xuất được nhóm lại và điều này chắc chắn sẽ giúp giảm bớt tắc nghẽn CPU. Là một lưu ý thú vị về điều này, nó có một số tác dụng phụ như thực tế là khi bạn sinh ra nhiều quy trình, bạn cũng tạo một bản sao của bất kỳ tài nguyên nào trên mỗi quy trình - bộ nhớ chung của quy trình, bộ đệm, tệp ánh xạ mem, v.v. Đây không nhất thiết phải là một vấn đề lớn nhưng trong một ứng dụng phức tạp, nó chắc chắn có thể làm tăng thêm sự phình to mà bạn không có ý định và sẽ không có khi bạn chỉ chạy một bản sao của nút

Antonio Gallo

tôi hy vọng ít nhất anh ấy đã bật xcache OP. -P

Antonio Gallo

tôi hy vọng ít nhất anh ấy đã bật xcache OP. -P

Alexandr Cherednichenko

50 xu của tôi. Trong nút, bạn cũng có thể không sử dụng các cuộc gọi lại. Với trình tạo async/await và async, bạn có thể viết mã thực sự rõ ràng. Tất nhiên, đó không phải là luồng "gọi lại ít hơn" thực sự, do triển khai nội bộ của nó. Nhưng nếu chúng ta đang nói về "Dễ sử dụng", điều đó không thực sự quan trọng. Và nó vốn được hỗ trợ trong node7. Và với TS hoặc Babel, bạn có thể dịch sang các phiên bản trước, bạn cần hỗ trợ

Alexandr Cherednichenko

50 xu của tôi. Trong nút, bạn cũng có thể không sử dụng các cuộc gọi lại. Với trình tạo async/await và async, bạn có thể viết mã thực sự rõ ràng. Tất nhiên, đó không phải là luồng "gọi lại ít hơn" thực sự, do triển khai nội bộ của nó. Nhưng nếu chúng ta đang nói về "Dễ sử dụng", điều đó không thực sự quan trọng. Và nó vốn được hỗ trợ trong node7. Và với TS hoặc Babel, bạn có thể dịch sang các phiên bản trước, bạn cần hỗ trợ

Martin

Sẽ thật tuyệt nếu bao gồm Elixir trong này. Rốt cuộc, đó là một mô hình khác và mô hình thời gian chạy khác

Martin

Sẽ thật tuyệt nếu bao gồm Elixir trong này. Rốt cuộc, đó là một mô hình khác và mô hình thời gian chạy khác

Alek

Cung cấp cho PHP4 một vòng quay tiếp theo

Alek

Cung cấp cho PHP4 một vòng quay tiếp theo

kumarchetansharma

Xin chào Ryan, chúng tôi đã chuyển từ PHP5. 6 lên PHP7, số lượng công nhân giảm và mức sử dụng CPU cũng bằng một nửa so với công nhân chúng tôi có với PHP5. 6. Chúng tôi có trung bình 1500 lượt truy cập mỗi giây trên haproxy của mình

kumarchetansharma

Xin chào Ryan, chúng tôi đã chuyển từ PHP5. 6 lên PHP7, số lượng công nhân giảm và mức sử dụng CPU cũng bằng một nửa so với công nhân chúng tôi có với PHP5. 6. Chúng tôi có trung bình 1500 lượt truy cập mỗi giây trên haproxy của mình

kumarchetansharma

Ồ. Sâu sắc. đợi tí. "PHP v5. 4. 16; . 4. 6"? @bradliusgp. disqus bạn thực sự là một fanboi Go. Nhưng vẫn đọc tốt

kumarchetansharma

Ồ. Sâu sắc. đợi tí. "PHP v5. 4. 16; . 4. 6"? @bradliusgp. disqus bạn thực sự là một fanboi Go. Nhưng vẫn đọc tốt

Alejandro Pablo

“Một cột mốc quan trọng là ở phiên bản 1. 4Java (. ) đã đạt được khả năng thực hiện các cuộc gọi I/O không chặn. “Phải, 15 năm trước. Vui lòng cung cấp mã nguồn cho từng điểm chuẩn, không có nó thì bài viết này không có ý nghĩa gì

Alejandro Pablo

“Một cột mốc quan trọng là ở phiên bản 1. 4Java (. ) đã đạt được khả năng thực hiện các cuộc gọi I/O không chặn. “Phải, 15 năm trước. Vui lòng cung cấp mã nguồn cho từng điểm chuẩn, không có nó thì bài viết này không có ý nghĩa gì

Tony

Hãy thử lại với PHP-FPM 7. x

Tony

Hãy thử lại với PHP-FPM 7. x

Gỗ Sid

Bạn không bao giờ cần phải giữ một đối tượng toàn cầu. Thanh toán bluebird's. Lan tràn()

Gỗ Sid

Bạn không bao giờ cần phải giữ một đối tượng toàn cầu. Thanh toán bluebird's. Lan tràn()

Kabir Baidya

Khi bạn nói "chu kỳ chạy an toàn và nhất quán", IMHO đó là một tuyên bố tương đối. Bạn có thể giải thích lý do tại sao bạn nghĩ Go / Node không đủ "chu kỳ hoạt động an toàn và nhất quán" cho các tổ chức tài chính trong năm 2017 không?

Kabir Baidya

Khi bạn nói "chu kỳ chạy an toàn và nhất quán", IMHO đó là một tuyên bố tương đối. Bạn có thể giải thích lý do tại sao bạn nghĩ Go / Node không đủ "chu kỳ hoạt động an toàn và nhất quán" cho các tổ chức tài chính trong năm 2017 không?

Kabir Baidya

Node cũng nhẹ như PHP và lưu trữ Node trên máy chủ không thực sự đắt. Bạn có thể mua các máy chủ có sẵn với giá rẻ nhất từ ​​DigitalOcean hoặc linode và bạn đã sẵn sàng sử dụng và tất nhiên có thể mở rộng quy mô khi có nhu cầu

Kabir Baidya

Node cũng nhẹ như PHP và lưu trữ Node trên máy chủ không thực sự đắt. Bạn có thể mua các máy chủ có sẵn với giá rẻ nhất từ ​​DigitalOcean hoặc linode và bạn đã sẵn sàng sử dụng và tất nhiên có thể mở rộng quy mô khi có nhu cầu

Andriy

Khi chúng ta đang nói về các hoạt động tài chính, chúng yêu cầu một vài thay đổi trong cơ sở dữ liệu (tăng ở đó, chèn cái đó, thay đổi thứ khác, v.v.). Vì vậy, có một số điều cần khắc phục khi sử dụng ngôn ngữ không chặn. 1. Đừng để bị mất trong một cuộc gọi lại, bởi vì tất cả các hoạt động đó nên được gọi từng cái một. Trong trường hợp thất bại, mọi thứ nên được hoàn nguyên. 2. Giữ thứ tự của các yêu cầu (đặc biệt là tăng/giảm cùng một số dư từ các tài nguyên (thiết bị) khác nhau). Ngoài ra, tôi không gặp phải bất kỳ phần mềm ngân hàng, phần mềm giao dịch hay thậm chí cổng thanh toán nào hoạt động trên các ngôn ngữ không đồng bộ, chủ yếu là Java (một số trường hợp là Python/C++)

Andriy

Khi chúng ta đang nói về các hoạt động tài chính, chúng yêu cầu một vài thay đổi trong cơ sở dữ liệu (tăng ở đó, chèn cái đó, thay đổi thứ khác, v.v.). Vì vậy, có một số điều cần khắc phục khi sử dụng ngôn ngữ không chặn. 1. Đừng để bị mất trong một cuộc gọi lại, bởi vì tất cả các hoạt động đó nên được gọi từng cái một. Trong trường hợp thất bại, mọi thứ nên được hoàn nguyên. 2. Giữ thứ tự của các yêu cầu (đặc biệt là tăng/giảm cùng một số dư từ các tài nguyên (thiết bị) khác nhau). Ngoài ra, tôi không gặp phải bất kỳ phần mềm ngân hàng, phần mềm giao dịch hay thậm chí cổng thanh toán nào hoạt động trên các ngôn ngữ không đồng bộ, chủ yếu là Java (một số trường hợp là Python/C++)

kirilltitov

và so sánh nó với ANSI C đơn giản

kirilltitov

và so sánh nó với ANSI C đơn giản

maer

Bạn không biết cách sử dụng nút. js

maer

Bạn không biết cách sử dụng nút. js

Julius Koronci

nó không phải là máy chủ đắt tiền. sự phát triển (nhà phát triển, thời gian, tài nguyên). đó là lý do tại sao PHP chiếm 83% trang web

Julius Koronci

nó không phải là máy chủ đắt tiền. sự phát triển (nhà phát triển, thời gian, tài nguyên). đó là lý do tại sao PHP chiếm 83% trang web

Mike

Tôi có thể tranh luận với vị trí của bạn. Nó tương đối dễ sử dụng, chẳng hạn như Python Tornado trong lĩnh vực ngân hàng mà không có bất kỳ nhược điểm nào về tốc độ tốt, hiệu suất cao và với "chu kỳ chạy an toàn và nhất quán". Có nhiều cách để làm một số. g. với sự trợ giúp của một số trình chặn giao dịch, v.v.)

Mike

Tôi có thể tranh luận với vị trí của bạn. Nó tương đối dễ sử dụng, chẳng hạn như Python Tornado trong lĩnh vực ngân hàng mà không có bất kỳ nhược điểm nào về tốc độ tốt, hiệu suất cao và với "chu kỳ chạy an toàn và nhất quán". Có nhiều cách để làm một số. g. với sự trợ giúp của một số trình chặn giao dịch, v.v.)

Andreas Galazis

bạn có thể vui lòng đăng mã chạy cho từng ngôn ngữ và môi trường nó được chạy/cách nó chạy không?

Andreas Galazis

bạn có thể vui lòng đăng mã chạy cho từng ngôn ngữ và môi trường nó được chạy/cách nó chạy không?

Martin

Tôi tin rằng đây là điểm chuẩn có thẩm quyền và khách quan nhất trên các khung web. https. //www. công nghệ. com/điểm chuẩn/

Martin

Tôi tin rằng đây là điểm chuẩn có thẩm quyền và khách quan nhất trên các khung web. https. //www. công nghệ. com/điểm chuẩn/

Boban Petrović

Hiệu suất của PHP + Apache phụ thuộc rất nhiều vào việc tối ưu hóa Apache cho tải cụ thể, phiên bản và cài đặt PHP cũng như bộ đệm opcode đang sử dụng. Vì vậy, điểm chuẩn ở đây không liên quan. Ngoài ra, rất nhiều người nói về nginx + php-fpm , nhưng tất cả các bài kiểm tra trang php đơn lẻ của tôi đều cho thấy apache+mod_ssl hoạt động tốt hơn ~10%. Kết quả trang web nói chung tốt nhất là với nginx+apache+mod_ssl

Boban Petrović

Hiệu suất của PHP + Apache phụ thuộc rất nhiều vào việc tối ưu hóa Apache cho tải cụ thể, phiên bản và cài đặt PHP cũng như bộ đệm opcode đang sử dụng. Vì vậy, điểm chuẩn ở đây không liên quan. Ngoài ra, rất nhiều người nói về nginx + php-fpm , nhưng tất cả các bài kiểm tra trang php đơn lẻ của tôi đều cho thấy apache+mod_ssl hoạt động tốt hơn ~10%. Kết quả trang web nói chung tốt nhất là với nginx+apache+mod_ssl

Áp-ra-ham Sánchez

Điều này là tuyệt vời và như vậy, rất luận chiến như tôi có thể thấy trong các bình luận. xD Có lẽ tôi đồng ý với một số người php, nó nên được thử nghiệm với php7 và nginx. Nhưng bài viết này đã giúp tôi hiểu ra rất nhiều điều và tuy nhiên tôi vẫn ngạc nhiên về sức mạnh của cờ vây. Thanks

Áp-ra-ham Sánchez

Điều này là tuyệt vời và như vậy, rất luận chiến như tôi có thể thấy trong các bình luận. xD Có lẽ tôi đồng ý với một số người php, nó nên được thử nghiệm với php7 và nginx. Nhưng bài viết này đã giúp tôi hiểu ra rất nhiều điều và tuy nhiên tôi vẫn ngạc nhiên về sức mạnh của cờ vây. Thanks

Decebal Dobrica

Rất giỏi trong việc mô tả I/O và thích ý tưởng so sánh chúng giữa các ngôn ngữ. Điểm chuẩn luôn bị ràng buộc chủ quan, tôi sẽ không bận tâm đến những bình luận trái chiều ở đây. Bài viết này có những hiểu biết sâu sắc về các mô hình I/O dành cho những người có thể không tìm kiếm xung quanh vì họ đang bận làm việc khác. Đối với bất kỳ ai đang cố gắng cạnh tranh điểm chuẩn hoặc lấy lại chúng, trung tâm docker có sẵn tất cả 4 ngôn ngữ này trong các vùng chứa chính thức, dễ chạy và dễ dàng chuyển đổi giữa các phiên bản

Decebal Dobrica

Rất giỏi trong việc mô tả I/O và thích ý tưởng so sánh chúng giữa các ngôn ngữ. Điểm chuẩn luôn bị ràng buộc chủ quan, tôi sẽ không bận tâm đến những bình luận trái chiều ở đây. Bài viết này có những hiểu biết sâu sắc về các mô hình I/O dành cho những người có thể không tìm kiếm xung quanh vì họ đang bận làm việc khác. Đối với bất kỳ ai đang cố gắng cạnh tranh điểm chuẩn hoặc lấy lại chúng, trung tâm docker có sẵn tất cả 4 ngôn ngữ này trong các vùng chứa chính thức, dễ chạy và dễ dàng chuyển đổi giữa các phiên bản

Ram Lal

php5. 4? . o bạn đang so sánh táo với cam. ) hãy xem http. //rojan. com. np/scraping-nodejs-vs-php/#comment-1128148853. ) sau đó chạy thử trên php 7. 2 với opcache JIT sử dụng phần mở rộng swoole. đây vẫn không phải là táo-táo mà gần hơn nhiều. ) có lẽ bạn cũng có thể mã nguồn mã chuẩn của mình. )

Ram Lal

php5. 4? . o bạn đang so sánh táo với cam. ) hãy xem http. //rojan. com. np/scraping-nodejs-vs-php/#comment-1128148853. ) sau đó chạy thử trên php 7. 2 với opcache JIT sử dụng phần mở rộng swoole. đây vẫn không phải là táo-táo mà gần hơn nhiều. ) có lẽ bạn cũng có thể mã nguồn mã chuẩn của mình. )

Jonathan Sterling

PHP chiếm 83% web vì WordPress quá phổ biến. Đó là, những người thậm chí không biết PHP đang sử dụng nó và triển khai lặp đi lặp lại cùng một mã WordPress cốt lõi. Các trang web WordPress chậm, cồng kềnh và có lỗ hổng bảo mật. Chỉ vì một ngôn ngữ phổ biến không có nghĩa là tỷ lệ phần trăm nhà phát triển biết ngôn ngữ đó lớn hơn, ngôn ngữ đó rẻ hơn và/hoặc phát triển nhanh hơn hoặc ngôn ngữ đó sử dụng ít tài nguyên hơn. Ngoài ra, nếu bạn nhìn vào số liệu thống kê sử dụng cho các trang web có lưu lượng truy cập cao, Java và C# phổ biến hơn PHP ( https. // w3tech. com/công nghệ/chi tiết/pl-php/tất cả/tất cả). WordPress là một lựa chọn tuyệt vời cho các trang web nhỏ hơn, nơi hiệu suất không quá quan trọng, nhưng khi nói đến các ứng dụng doanh nghiệp, hiệu suất cao, nhiều triệu người dùng, thì nó không được sử dụng rộng rãi. Node, Go, Java và C# phù hợp hơn nhiều trong những tình huống này, vì các điểm chuẩn ở trên cho thấy rõ ràng

Jonathan Sterling

PHP chiếm 83% web vì WordPress quá phổ biến. Đó là, những người thậm chí không biết PHP đang sử dụng nó và triển khai lặp đi lặp lại cùng một mã WordPress cốt lõi. Các trang web WordPress chậm, cồng kềnh và có lỗ hổng bảo mật. Chỉ vì một ngôn ngữ phổ biến không có nghĩa là tỷ lệ phần trăm nhà phát triển biết ngôn ngữ đó lớn hơn, ngôn ngữ đó rẻ hơn và/hoặc phát triển nhanh hơn hoặc ngôn ngữ đó sử dụng ít tài nguyên hơn. Ngoài ra, nếu bạn nhìn vào số liệu thống kê sử dụng cho các trang web có lưu lượng truy cập cao, Java và C# phổ biến hơn PHP ( https. // w3tech. com/công nghệ/chi tiết/pl-php/tất cả/tất cả). WordPress là một lựa chọn tuyệt vời cho các trang web nhỏ hơn, nơi hiệu suất không quá quan trọng, nhưng khi nói đến các ứng dụng doanh nghiệp, hiệu suất cao, nhiều triệu người dùng, thì nó không được sử dụng rộng rãi. Node, Go, Java và C# phù hợp hơn nhiều trong những tình huống này, vì các điểm chuẩn ở trên cho thấy rõ ràng

Julius Koronci

bạn đang phạm sai lầm trong giả định của bạn. trong khi wordpress có hơn 80 triệu trang web PHP có hơn 800 triệu trang web. Tôi đã xem số liệu thống kê thích hợp và PHP là hàng đầu. Java và c# được sử dụng cho các trang web công ty, hệ thống ngân hàng. các trang web có lưu lượng truy cập không cao. và trên thực tế, một số ngân hàng đang bắt đầu áp dụng PHP, điều này thật tuyệt vời. vì chất lượng như nhau mà giá rẻ gấp 10 lần. sẽ rẻ hơn khi sử dụng thêm một vài máy chủ so với việc thuê thêm 2 nhà phát triển Java trong vài năm tới

Julius Koronci

bạn đang phạm sai lầm trong giả định của bạn. trong khi wordpress có hơn 80 triệu trang web PHP có hơn 800 triệu trang web. Tôi đã xem số liệu thống kê thích hợp và PHP là hàng đầu. Java và c# được sử dụng cho các trang web công ty, hệ thống ngân hàng. các trang web có lưu lượng truy cập không cao. và trên thực tế, một số ngân hàng đang bắt đầu áp dụng PHP, điều này thật tuyệt vời. vì chất lượng như nhau mà giá rẻ gấp 10 lần. sẽ rẻ hơn khi sử dụng thêm một vài máy chủ so với việc thuê thêm 2 nhà phát triển Java trong vài năm tới

kelunik

Trên thực tế, PHP cũng hỗ trợ non-blocking I/O. Xem https. //github. com/ampphp/amp + https. //github. com/ampphp/aerys

kelunik

Trên thực tế, PHP cũng hỗ trợ non-blocking I/O. Xem https. //github. com/ampphp/amp + https. //github. com/ampphp/aerys

Stefano Fratini

Những gì tôi thấy ở đây không khớp với những gì bạn thấy trên https. //www. công nghệ. com/benchmarks/ và trải nghiệm cá nhân của tôi Xử lý đồng thời 5k yêu cầu bằng php?

Stefano Fratini

Những gì tôi thấy ở đây không khớp với những gì bạn thấy trên https. //www. công nghệ. com/benchmarks/ và trải nghiệm cá nhân của tôi Xử lý đồng thời 5k yêu cầu bằng php?

Rossen Hristov

Còn ASP thì sao. NET?

Rossen Hristov

Còn ASP thì sao. NET?

Jonathan Sterling

À vâng, tôi sai về lập luận WordPress - bạn đúng. Điều đó nói rằng, tôi nghĩ rằng một khi bạn đã vượt qua các nhà phát triển PHP cấp thấp đang tạo các trang web đơn giản và bắt đầu xem xét các nhà phát triển PHP có kinh nghiệm có thể xây dựng một cái gì đó như Facebook, chi phí bắt đầu cân bằng. Tôi biết chủ một cửa hàng PHP ở Leeds, Anh luôn than thở rằng anh ấy không thể tìm được những nhà phát triển PHP giỏi. Anh ấy cho biết đại đa số những người đến phỏng vấn chỉ có thể tạo các trang web đơn giản, không phải những thứ cấp doanh nghiệp mà công ty anh ấy phát triển. Vì vậy, trong khi PHP chắc chắn có thể hoạt động ở quy mô doanh nghiệp (như chúng ta thấy ở Facebook, Wikipedia và những người khác), thì ở mức đó, chi phí bắt đầu bằng với chi phí của các nhà phát triển Java/C#/Go (chỉ cần nhìn vào những gì Facebook trả cho nhân viên của họ). Đối với những thứ đơn giản hơn, tôi đồng ý - không có lý do gì để không sử dụng PHP

Jonathan Sterling

À vâng, tôi sai về lập luận WordPress - bạn đúng. Điều đó nói rằng, tôi nghĩ rằng một khi bạn đã vượt qua các nhà phát triển PHP cấp thấp đang tạo các trang web đơn giản và bắt đầu xem xét các nhà phát triển PHP có kinh nghiệm có thể xây dựng một cái gì đó như Facebook, chi phí bắt đầu cân bằng. Tôi biết chủ một cửa hàng PHP ở Leeds, Anh luôn than thở rằng anh ấy không thể tìm được những nhà phát triển PHP giỏi. Anh ấy cho biết đại đa số những người đến phỏng vấn chỉ có thể tạo các trang web đơn giản, không phải những thứ cấp doanh nghiệp mà công ty anh ấy phát triển. Vì vậy, trong khi PHP chắc chắn có thể hoạt động ở quy mô doanh nghiệp (như chúng ta thấy ở Facebook, Wikipedia và những người khác), thì ở mức đó, chi phí bắt đầu bằng với chi phí của các nhà phát triển Java/C#/Go (chỉ cần nhìn vào những gì Facebook trả cho nhân viên của họ). Đối với những thứ đơn giản hơn, tôi đồng ý - không có lý do gì để không sử dụng PHP

umka

Ồ. theo ý kiến ​​của tôi phụ đề "Lies, Damned Lies and Benchmarks" sẽ là tiêu đề tốt hơn cho toàn bộ bài báo. Có vẻ như tập hợp các ví dụ từ stackoverflow. Tôi có nhiều câu hỏi cho tác giả. - Tại sao bạn dùng 1 máy để chạy benchmark và ứng dụng. Ứng dụng và điểm chuẩn phải được bắt đầu trên các đơn vị khác nhau. - Tại sao bạn đọc toàn bộ tệp trong mã của mình để băm, bộ đệm byte sẽ tốt hơn - Tại sao bạn sử dụng HTTP để đo điểm chuẩn?

umka

Ồ. theo ý kiến ​​của tôi phụ đề "Lies, Damned Lies and Benchmarks" sẽ là tiêu đề tốt hơn cho toàn bộ bài báo. Có vẻ như tập hợp các ví dụ từ stackoverflow. Tôi có nhiều câu hỏi cho tác giả. - Tại sao bạn dùng 1 máy để chạy benchmark và ứng dụng. Ứng dụng và điểm chuẩn phải được bắt đầu trên các đơn vị khác nhau. - Tại sao bạn đọc toàn bộ tệp trong mã của mình để băm, bộ đệm byte sẽ tốt hơn - Tại sao bạn sử dụng HTTP để đo điểm chuẩn?

Niranjan Godbole

Go không có lệnh gọi lại và không giống như java, trình thu gom rác của nó được tối ưu hóa để có độ trễ thấp (<1 mili giây). Có những người đã có tài chính bằng cách sử dụng ngân hàng Go - Monzo

Niranjan Godbole

Go không có lệnh gọi lại và không giống như java, trình thu gom rác của nó được tối ưu hóa để có độ trễ thấp (<1 mili giây). Có những người đã có tài chính bằng cách sử dụng ngân hàng Go - Monzo

Niranjan Godbole

Go là người chiến thắng rõ ràng ở đây. . )

Niranjan Godbole

Go là người chiến thắng rõ ràng ở đây. . )

Nabtron

Vì vậy, đây là cách các nhà phát triển 3% hàng đầu của DUMB do TopTal lựa chọn. hoan hô

Nabtron

Vì vậy, đây là cách các nhà phát triển 3% hàng đầu của DUMB do TopTal lựa chọn. hoan hô

Julius Koronci

vâng mọi người luôn là một vấn đề. tìm một nhà phát triển phù hợp luôn khó khăn bất kể ngôn ngữ nào. Tôi không kiếm được ít hơn bất kỳ nhà phát triển Java nào, đó là sự thật. lợi ích thực sự của PHP không nằm ở tiền lương. chồi trong thời gian phát triển và số lượng nhà phát triển. PHP chỉ được tạo ra để phát triển web nhanh. và bạn có thể phát triển một trang web nhanh hơn rất nhiều so với Java hoặc. asp. cũng như tìm kiếm các nhà phát triển thích hợp trong Java hoặc. asp khó hơn trong PHP. Nếu bạn có một dự án lớn hơn, bạn có thể có một vài tiền bối và nhiều hậu bối. tiền bối khó tìm nhưng hậu bối lại là chuyện khác. PHP rất dễ học và thậm chí còn dễ dàng hơn để dẫn dắt đàn em đến với mã phù hợp. trong khi với Java hoặc. asp điều này gần như là không thể. bản thân các ngôn ngữ rất khó, khó học. vì vậy có một nhóm đàn em là một trở ngại hơn là một tài sản. Nhưng công bằng mà nói, trải nghiệm của bạn bạn là một trải nghiệm chung. mọi người có thể bắt đầu viết PHP qua đêm. ngay cả những người không có kinh nghiệm lập trình cũng có thể tạo một trang web đơn giản trong vòng một tuần. điều này tốt và xấu cùng một lúc. và có hàng trăm người như vậy đến hẹn

Julius Koronci

vâng mọi người luôn là một vấn đề. tìm một nhà phát triển phù hợp luôn khó khăn bất kể ngôn ngữ nào. Tôi không kiếm được ít hơn bất kỳ nhà phát triển Java nào, đó là sự thật. lợi ích thực sự của PHP không nằm ở tiền lương. chồi trong thời gian phát triển và số lượng nhà phát triển. PHP chỉ được tạo ra để phát triển web nhanh. và bạn có thể phát triển một trang web nhanh hơn rất nhiều so với Java hoặc. asp. cũng như tìm kiếm các nhà phát triển thích hợp trong Java hoặc. asp khó hơn trong PHP. Nếu bạn có một dự án lớn hơn, bạn có thể có một vài tiền bối và nhiều hậu bối. tiền bối khó tìm nhưng hậu bối lại là chuyện khác. PHP rất dễ học và thậm chí còn dễ dàng hơn để dẫn dắt đàn em đến với mã phù hợp. trong khi với Java hoặc. asp điều này gần như là không thể. bản thân các ngôn ngữ rất khó, khó học. vì vậy có một nhóm đàn em là một trở ngại hơn là một tài sản. Nhưng công bằng mà nói, trải nghiệm của bạn bạn là một trải nghiệm chung. mọi người có thể bắt đầu viết PHP qua đêm. ngay cả những người không có kinh nghiệm lập trình cũng có thể tạo một trang web đơn giản trong vòng một tuần. điều này tốt và xấu cùng một lúc. và có hàng trăm người như vậy đến hẹn

Brad

Đáng buồn thay, có vẻ như điểm chuẩn đã làm lu mờ toàn bộ điểm của bài viết. Vui lòng đọc bài viết nếu bạn không. Để trả lời câu hỏi của bạn. "một máy", cho tính thực tế. Đọc toàn bộ tệp và HTTP - vì mục đích là để kiểm tra I/O, không chỉ bản thân hiệu năng của ngôn ngữ. Nếu bất cứ điều gì, tôi nên loại bỏ băm. Trên máy chủ Java, tôi đã sử dụng Tomcat chủ yếu vì tôi cảm thấy nó đại diện cho việc triển khai Java "trung bình" - tôi có thể sai về điều đó, tôi đã không thực hiện nhiều nghiên cứu về số liệu thống kê triển khai Java hiện tại. Và tôi không chắc ý nghĩa của việc sao chép SO là gì - những ví dụ đó nhằm mục đích gần nhất có thể với chức năng tương đương trong mỗi ngôn ngữ, tôi đã viết chúng như vậy

Brad

Đáng buồn thay, có vẻ như điểm chuẩn đã làm lu mờ toàn bộ điểm của bài viết. Vui lòng đọc bài viết nếu bạn không. Để trả lời câu hỏi của bạn. "một máy", cho tính thực tế. Đọc toàn bộ tệp và HTTP - vì mục đích là để kiểm tra I/O, không chỉ bản thân hiệu năng của ngôn ngữ. Nếu bất cứ điều gì, tôi nên loại bỏ băm. Trên máy chủ Java, tôi đã sử dụng Tomcat chủ yếu vì tôi cảm thấy nó đại diện cho việc triển khai Java "trung bình" - tôi có thể sai về điều đó, tôi đã không thực hiện nhiều nghiên cứu về số liệu thống kê triển khai Java hiện tại. Và tôi không chắc ý nghĩa của việc sao chép SO là gì - những ví dụ đó nhằm mục đích gần nhất có thể với chức năng tương đương trong mỗi ngôn ngữ, tôi đã viết chúng như vậy

Jimin Hsieh

Nếu bạn muốn so sánh công việc chuyên sâu về I/O trong Java thì không ai bằng servlet. Có Netty, Vert. x và Akka

Jimin Hsieh

Nếu bạn muốn so sánh công việc chuyên sâu về I/O trong Java thì không ai bằng servlet. Có Netty, Vert. x và Akka

Miguel García López

Đặt điểm chuẩn và so sánh sang một bên (tuy nhiên, chúng rất sâu sắc), tôi đặc biệt đánh giá cao phần giáo dục về cách đồng bộ hóa. so với. không đồng bộ. I/O cuối cùng được điều khiển đến hệ điều hành. Đây là điều mà tôi thấy mọi người không biết (cũng không quan tâm đến. ) trong khi điều quan trọng là phải hiểu tất cả. Như đã chỉ ra, đối với thế giới Java có Vert. x (được xây dựng trên Netty cho async. I/O) Tôi chắc chắn khuyên bạn nên xem xét. Cảm ơn vì bài đăng

Miguel García López

Đặt điểm chuẩn và so sánh sang một bên (tuy nhiên, chúng rất sâu sắc), tôi đặc biệt đánh giá cao phần giáo dục về cách đồng bộ hóa. so với. không đồng bộ. I/O cuối cùng được điều khiển đến hệ điều hành. Đây là điều mà tôi thấy mọi người không biết (cũng không quan tâm đến. ) trong khi điều quan trọng là phải hiểu tất cả. Như đã chỉ ra, đối với thế giới Java có Vert. x (được xây dựng trên Netty cho async. I/O) Tôi chắc chắn khuyên bạn nên xem xét. Cảm ơn vì bài đăng

Александр Холодов

https. // tải lên. disquscdn. com/images/bb1099d8b862515fc13cdc0217e4d918638618bfb691562ac0f983aadee185ea. jpg

Александр Холодов

https. // tải lên. disquscdn. com/images/bb1099d8b862515fc13cdc0217e4d918638618bfb691562ac0f983aadee185ea. jpg

Danila Matveev

Bài khủng khiếp và có hại. Hãy xóa nó vì lợi ích lớn. 1) các ngăn xếp ngẫu nhiên được so sánh và sau đó được đặt tên theo ngôn ngữ 2) cấu hình môi trường bị bỏ qua 3) thiếu hiểu biết về các môi trường và thực tiễn có thể so sánh được 4) chi tiết đo lường bị bỏ sót nhưng cực kỳ quan trọng, chẳng hạn như đối với java

Danila Matveev

Bài khủng khiếp và có hại. Hãy xóa nó vì lợi ích lớn. 1) các ngăn xếp ngẫu nhiên được so sánh và sau đó được đặt tên theo ngôn ngữ 2) cấu hình môi trường bị bỏ qua 3) thiếu hiểu biết về các môi trường và thực tiễn có thể so sánh được 4) chi tiết đo lường bị bỏ sót nhưng cực kỳ quan trọng, chẳng hạn như đối với java

Noir Alsafar

Bạn có thể đăng mã nguồn mà bạn đã điểm chuẩn không?

Noir Alsafar

Bạn có thể đăng mã nguồn mà bạn đã điểm chuẩn không?

Brad

Xem https. // người đậu. io/bài đăng/máy chủ-env-điểm chuẩn/

Brad

Xem https. // người đậu. io/bài đăng/máy chủ-env-điểm chuẩn/

Oleg Abrashaev

Bred, hãy cập nhật bài viết của bạn với php7. 1 + kết quả php-fpm + nginx. Thật xấu hổ cho bạn và làm tổn hại danh tiếng của bạn với tư cách là chuyên gia khi đăng kết quả cho php 5 quá cũ. 4 với apache =/

Oleg Abrashaev

Bred, hãy cập nhật bài viết của bạn với php7. 1 + kết quả php-fpm + nginx. Thật xấu hổ cho bạn và làm tổn hại danh tiếng của bạn với tư cách là chuyên gia khi đăng kết quả cho php 5 quá cũ. 4 với apache =/

Brad

Oleg, có rất nhiều, rất nhiều cấu hình khác nhau có thể cho cả bốn ngôn ngữ được thảo luận. Như đã đề cập ở nơi khác, các phiên bản PHP và Apache mà tôi đã sử dụng là phiên bản mặc định đi kèm với CentOS mới nhất. Tôi nghĩ sẽ rất có tính xây dựng nếu thực hiện thêm các điểm chuẩn với các tình huống phổ biến khác và liên kết với chúng từ đây. Nếu ai đó làm một bộ đủ toàn diện, tôi chắc chắn rằng tôi có thể cập nhật bài viết chính để bao gồm một liên kết đến nó, nếu không thì chỉ cần bao gồm các bình luận liên kết. Nhưng thật không may, đây không phải là thứ tôi có thời gian để làm. Mã tôi đã sử dụng ở đây. https. // người đậu. io/post/server-env-benchmarks/ Vui lòng đóng góp so sánh của riêng bạn

Brad

Oleg, có rất nhiều, rất nhiều cấu hình khác nhau có thể cho cả bốn ngôn ngữ được thảo luận. Như đã đề cập ở nơi khác, các phiên bản PHP và Apache mà tôi đã sử dụng là phiên bản mặc định đi kèm với CentOS mới nhất. Tôi nghĩ sẽ rất có tính xây dựng nếu thực hiện thêm các điểm chuẩn với các tình huống phổ biến khác và liên kết với chúng từ đây. Nếu ai đó làm một bộ đủ toàn diện, tôi chắc chắn rằng tôi có thể cập nhật bài viết chính để bao gồm một liên kết đến nó, nếu không thì chỉ cần bao gồm các bình luận liên kết. Nhưng thật không may, đây không phải là thứ tôi có thời gian để làm. Mã tôi đã sử dụng ở đây. https. // người đậu. io/post/server-env-benchmarks/ Vui lòng đóng góp so sánh của riêng bạn

Noir Alsafar

Bạn thiết lập nút. máy chủ js sai. Bạn đã chặn chủ đề bằng cách sử dụng phiên bản đồng bộ hóa của sha256. Bạn nên sử dụng các mô-đun gốc vanilla đi kèm với Node. js để thực sự thực hiện kiểm tra và sử dụng, bạn nên sử dụng phiên bản không đồng bộ, không phải phiên bản chặn vòng lặp sự kiện. Bạn có biết rằng. Bạn nên chạy lại số của bạn. bài viết của bạn là phi thường ngoại trừ phần này. Rất vui được trợ giúp nếu bạn muốn tôi gửi mã nguồn cho bạn?

Noir Alsafar

Bạn thiết lập nút. máy chủ js sai. Bạn đã chặn chủ đề bằng cách sử dụng phiên bản đồng bộ hóa của sha256. Bạn nên sử dụng các mô-đun gốc vanilla đi kèm với Node. js để thực sự thực hiện kiểm tra và sử dụng, bạn nên sử dụng phiên bản không đồng bộ, không phải phiên bản chặn vòng lặp sự kiện. Bạn có biết rằng. Bạn nên chạy lại số của bạn. bài viết của bạn là phi thường ngoại trừ phần này. Rất vui được trợ giúp nếu bạn muốn tôi gửi mã nguồn cho bạn?

Oleg Abrashaev

Hãy nhìn vào điểm chuẩn này. Tôi nghĩ rằng đây là một https chính xác và nổi tiếng nhất. //www. công nghệ. com/benchmarks/#section=data-r14&hw=ph&test=query trong vòng 14 mới nhất PHP raw nhanh hơn raw go trong nhiều truy vấn và điểm chuẩn. Điểm chuẩn này đáng tin cậy và được thực hiện đúng. Điểm chuẩn của bạn sẽ không hợp lý nếu bạn lấy các phiên bản từ các năm khác nhau cho tất cả các ngôn ngữ. Nó không chính xác, nó không so sánh được gì, và nếu bạn nhìn vào các bình luận - nhiều người cũng nghĩ như vậy. Ngoài ra, tôi đến đây từ bản dịch tiếng Nga của bài viết này trên https. // habrahabr. ru/company/mailru/blog/329258/ qua đường bưu điện. ru. Và ở đây trong các bình luận, mọi người cũng bực mình về một phiên bản php mà bạn đã chọn và tại sao lại là với Apache. Trong thế giới thực hiện nay, các nhà phát triển php sử dụng php7 và nginx + php-fpm. Và những người trong các bình luận nói rằng, như ở đây trong các bình luận, tác giả đó không đủ tiêu chuẩn, anh ta không biết gì về php và sự so sánh này không có ý nghĩa gì. Bạn thấy những gì tôi đang nói với bạn về? . thư chẵn. ru nhận ra rằng bằng cách dịch bài viết này, họ đã phạm sai lầm. Bạn cần thêm hoặc sửa kết quả cho php, nếu không thì không sửa được

Oleg Abrashaev

Hãy nhìn vào điểm chuẩn này. Tôi nghĩ rằng đây là một https chính xác và nổi tiếng nhất. //www. công nghệ. com/benchmarks/#section=data-r14&hw=ph&test=query trong vòng 14 mới nhất PHP raw nhanh hơn raw go trong nhiều truy vấn và điểm chuẩn. Điểm chuẩn này đáng tin cậy và được thực hiện đúng. Điểm chuẩn của bạn sẽ không hợp lý nếu bạn lấy các phiên bản từ các năm khác nhau cho tất cả các ngôn ngữ. Nó không chính xác, nó không so sánh được gì, và nếu bạn nhìn vào các bình luận - nhiều người cũng nghĩ như vậy. Ngoài ra, tôi đến đây từ bản dịch tiếng Nga của bài viết này trên https. // habrahabr. ru/company/mailru/blog/329258/ qua đường bưu điện. ru. Và ở đây trong các bình luận, mọi người cũng bực mình về một phiên bản php mà bạn đã chọn và tại sao lại là với Apache. Trong thế giới thực hiện nay, các nhà phát triển php sử dụng php7 và nginx + php-fpm. Và những người trong các bình luận nói rằng, như ở đây trong các bình luận, tác giả đó không đủ tiêu chuẩn, anh ta không biết gì về php và sự so sánh này không có ý nghĩa gì. Bạn thấy những gì tôi đang nói với bạn về? . thư chẵn. ru nhận ra rằng bằng cách dịch bài viết này, họ đã phạm sai lầm. Bạn cần thêm hoặc sửa kết quả cho php, nếu không thì không sửa được

Brad

Cảm ơn Oleg. tôi hiểu. Điều duy nhất tôi có thể nói với bạn là a) bài viết không bao giờ nhằm mục đích so sánh hiệu suất ngôn ngữ chung - đó là về các mô hình I/O và so sánh cách mọi thứ hoạt động. Và b) có nhiều lời chỉ trích có thể xảy ra (những người PHP theo đuổi tôi về phiên bản và Apache, những người Node muốn thấy nó chạy trong một cụm và những người Java nghĩ rằng tôi nên sử dụng thứ gì đó vốn là NIO, danh sách . Và tôi sẽ không cập nhật bài viết đơn giản vì nó không bao giờ có nghĩa là một so sánh toàn diện về hiệu suất ngôn ngữ - một lần nữa, đó là về các mô hình I/O. Tôi cũng nghĩ rằng văn bản trong bài viết làm rõ điều đó. Tôi rất vui khi thấy các liên kết đến thông tin khác cung cấp các so sánh khác và tôi đánh giá cao thời gian của bạn trong việc mô tả tình huống và ở một mức độ nào đó tôi đồng ý với bạn, nhưng một lần nữa, tôi sẽ không cập nhật điểm chuẩn của bài viết. Về điểm danh tiếng của tôi, vấn đề vẫn là thiết lập tôi đã sử dụng là mặc định với một bản phân phối Linux lớn. Ý định của tôi không phải là phá vỡ PHP bằng cách sử dụng phiên bản cũ, mà sử dụng một thiết lập chung đơn giản và chỉ cần thực hiện "cài đặt yum" trên bản phân phối dựa trên RedHat sẽ cấu thành điều đó. Tôi nghĩ điều đó rõ ràng đối với bất kỳ ai nhìn vào nó một cách khách quan. Tôi chắc rằng nhiều nhà phát triển PHP sẽ ghét tôi trong nhiều năm tới vì điều đó - đi kèm với lãnh thổ. Tôi không ghét họ - Tôi hoan nghênh dữ liệu và lượt xem bổ sung. Hy vọng rằng tất cả những gì có ý nghĩa

Brad

Cảm ơn Oleg. tôi hiểu. Điều duy nhất tôi có thể nói với bạn là a) bài viết không bao giờ nhằm mục đích so sánh hiệu suất ngôn ngữ chung - đó là về các mô hình I/O và so sánh cách mọi thứ hoạt động. Và b) có nhiều lời chỉ trích có thể xảy ra (những người PHP theo đuổi tôi về phiên bản và Apache, những người Node muốn thấy nó chạy trong một cụm và những người Java nghĩ rằng tôi nên sử dụng thứ gì đó vốn là NIO, danh sách . Và tôi sẽ không cập nhật bài viết đơn giản vì nó không bao giờ có nghĩa là một so sánh toàn diện về hiệu suất ngôn ngữ - một lần nữa, đó là về các mô hình I/O. Tôi cũng nghĩ rằng văn bản trong bài viết làm rõ điều đó. Tôi rất vui khi thấy các liên kết đến thông tin khác cung cấp các so sánh khác và tôi đánh giá cao thời gian của bạn trong việc mô tả tình huống và ở một mức độ nào đó tôi đồng ý với bạn, nhưng một lần nữa, tôi sẽ không cập nhật điểm chuẩn của bài viết. Về điểm danh tiếng của tôi, vấn đề vẫn là thiết lập tôi đã sử dụng là mặc định với một bản phân phối Linux lớn. Ý định của tôi không phải là phá vỡ PHP bằng cách sử dụng phiên bản cũ, mà sử dụng một thiết lập chung đơn giản và chỉ cần thực hiện "cài đặt yum" trên bản phân phối dựa trên RedHat sẽ cấu thành điều đó. Tôi nghĩ điều đó rõ ràng đối với bất kỳ ai nhìn vào nó một cách khách quan. Tôi chắc rằng nhiều nhà phát triển PHP sẽ ghét tôi trong nhiều năm tới vì điều đó - đi kèm với lãnh thổ. Tôi không ghét họ - Tôi hoan nghênh dữ liệu và lượt xem bổ sung. Hy vọng rằng tất cả những gì có ý nghĩa

Brad

Cảm ơn Noir, Mã nguồn nằm trong liên kết ở trên. Vâng, bạn nói đúng, tôi biết điều đó và tôi cảm thấy mình đã nói rõ điều đó trong nội dung bài báo. Lý do là bài viết nói về các mô hình I/O và các môi trường khác nhau như thế nào - trên thực tế, sự khác biệt này là điểm minh họa - để chỉ ra cách thức hoạt động của nó và sự khác biệt đó là gì. Tôi đánh giá cao đầu vào nhưng tôi sẽ không cập nhật điểm chuẩn của bài viết. Tuy nhiên, nếu có các điểm chuẩn bổ sung nên được liên kết trong các nhận xét, tôi nghĩ đó cũng là một cách hay để cung cấp các điểm đối lập và nhiều dữ liệu hơn. (Nếu có điều gì đó thực sự toàn diện hơn nhiều về cùng một chủ đề - so sánh các mô hình I/O, tôi nghĩ điều đó cũng hợp lý khi cập nhật nội dung bài viết bằng một liên kết đến. )

Brad

Cảm ơn Noir, Mã nguồn nằm trong liên kết ở trên. Vâng, bạn nói đúng, tôi biết điều đó và tôi cảm thấy mình đã nói rõ điều đó trong nội dung bài báo. Lý do là bài viết nói về các mô hình I/O và các môi trường khác nhau như thế nào - trên thực tế, sự khác biệt này là điểm minh họa - để chỉ ra cách thức hoạt động của nó và sự khác biệt đó là gì. Tôi đánh giá cao đầu vào nhưng tôi sẽ không cập nhật điểm chuẩn của bài viết. Tuy nhiên, nếu có các điểm chuẩn bổ sung nên được liên kết trong các nhận xét, tôi nghĩ đó cũng là một cách hay để cung cấp các điểm đối lập và nhiều dữ liệu hơn. (Nếu có điều gì đó thực sự toàn diện hơn nhiều về cùng một chủ đề - so sánh các mô hình I/O, tôi nghĩ điều đó cũng hợp lý khi cập nhật nội dung bài viết bằng một liên kết đến. )

Oleg Abrashaev

Nó có ý nghĩa, cảm ơn vì đã làm rõ. Nhưng vẫn còn nhiều phiên bản mới nhất của Node và Java đã được sử dụng và bạn có thể thấy rằng những người Java và Node nói chung hài lòng. Yêu cầu của họ để thêm cụm hoặc sử dụng NIO giống như một sự bổ sung và cải tiến có thể. Nhưng với PHP, nó hoàn toàn bị hỏng, chúng tôi thậm chí không nói về những bổ sung ở đó. Phiên bản PHP trong "CentOS mới nhất" luôn lỗi thời. Ví dụ: nếu bạn sử dụng Ubuntu mới nhất, bạn sẽ tìm thấy php7 ở đó theo mặc định. Ngoài ra, chúng tôi có một số lựa chọn nổi tiếng để cài đặt PHP mới nhất trên hệ điều hành với gói lỗi thời. đó là dấu chấm. gỡ lỗi cho Debian - https. //www. dotdeb. org/ Và đó là Sury PPA cho Ubuntu - https. //bệ phóng. net/~ondrej/+archive/ubuntu/php Tôi không biết về các nguồn tương tự cho thế giới yum, tôi chủ yếu là người dùng thông minh, nhưng việc tra Google bằng "php7 centos" mang lại cho tôi giải pháp chỉ sau 5 giây với một giải pháp bổ sung . Nhìn vào đây - https. // webtatic. com/packages/php70/ Tôi hiểu rằng ý nghĩa của bài viết này là so sánh mô hình I/O chứ không phải bản thân hiệu năng của ngôn ngữ. Nhưng vấn đề và vấn đề chính ở đây là thiếu sự chuẩn bị. Đối với tôi, đối với lập trình viên và kỹ sư có kinh nghiệm, rõ ràng là dành ít nhất 5-10 phút để đọc một cái gì đó về công nghệ mà tôi muốn chạm vào. Nếu tôi là bạn và sẽ nghĩ đến việc viết bài báo như vậy, tôi chắc chắn sẽ cài đặt các phiên bản mới nhất của tất cả các trình biên dịch và thông dịch. Because for me as a programmer it's natural and obvious that I need to work with latest versions. Still, considering my clarification above, there is no any real reason to not spend 10 minutes to do a minimum research and install latest versions. That's the main issue here and exactly this factor harms this article the most

Oleg Abrashaev

Nó có ý nghĩa, cảm ơn vì đã làm rõ. Nhưng vẫn còn nhiều phiên bản mới nhất của Node và Java đã được sử dụng và bạn có thể thấy rằng những người Java và Node nói chung hài lòng. Yêu cầu của họ để thêm cụm hoặc sử dụng NIO giống như một sự bổ sung và cải tiến có thể. Nhưng với PHP, nó hoàn toàn bị hỏng, chúng tôi thậm chí không nói về những bổ sung ở đó. Phiên bản PHP trong "CentOS mới nhất" luôn lỗi thời. Ví dụ: nếu bạn sử dụng Ubuntu mới nhất, bạn sẽ tìm thấy php7 ở đó theo mặc định. Ngoài ra, chúng tôi có một số lựa chọn nổi tiếng để cài đặt PHP mới nhất trên hệ điều hành với gói lỗi thời. đó là dấu chấm. gỡ lỗi cho Debian - https. //www. dotdeb. org/ Và đó là Sury PPA cho Ubuntu - https. //bệ phóng. net/~ondrej/+archive/ubuntu/php Tôi không biết về các nguồn tương tự cho thế giới yum, tôi chủ yếu là người dùng thông minh, nhưng việc tra Google bằng "php7 centos" mang lại cho tôi giải pháp chỉ sau 5 giây với một giải pháp bổ sung . Nhìn vào đây - https. // webtatic. com/packages/php70/ Tôi hiểu rằng ý nghĩa của bài viết này là so sánh mô hình I/O chứ không phải bản thân hiệu năng của ngôn ngữ. Nhưng vấn đề và vấn đề chính ở đây là thiếu sự chuẩn bị. Đối với tôi, đối với lập trình viên và kỹ sư có kinh nghiệm, rõ ràng là dành ít nhất 5-10 phút để đọc một cái gì đó về công nghệ mà tôi muốn chạm vào. Nếu tôi là bạn và sẽ nghĩ đến việc viết bài báo như vậy, tôi chắc chắn sẽ cài đặt các phiên bản mới nhất của tất cả các trình biên dịch và thông dịch. Because for me as a programmer it's natural and obvious that I need to work with latest versions. Still, considering my clarification above, there is no any real reason to not spend 10 minutes to do a minimum research and install latest versions. That's the main issue here and exactly this factor harms this article the most

Oleg Abrashaev

php7 have almost twice improved it's performance in comparison to php5. 6 so, we will definitely see different results. I'm not saying that PHP would win against Go but at leas it would lost with a better results, not like in the article

Oleg Abrashaev

php7 have almost twice improved it's performance in comparison to php5. 6 so, we will definitely see different results. I'm not saying that PHP would win against Go but at leas it would lost with a better results, not like in the article

Oleg Abrashaev

There are his sources https. //peabody. io/post/server-env-benchmarks/

Oleg Abrashaev

There are his sources https. //peabody. io/post/server-env-benchmarks/

Oleg Abrashaev

In general, you are right, and results will not be very different with PHP 7. But the thing which violates this article authority and meaning isn't the version of PHP itself, but it shows that author hasn't spent his time in preparation for this article. This fact harms author authority and reputation. That's why it was better to use latest versions. And there would not any arguments in comments (which now about 50% of all comments here and under the Russian translation of this article the same situation). We are programmers, engineers and this is author target audience. And this audience like when things made smart, precisely and technically right

Oleg Abrashaev

In general, you are right, and results will not be very different with PHP 7. But the thing which violates this article authority and meaning isn't the version of PHP itself, but it shows that author hasn't spent his time in preparation for this article. This fact harms author authority and reputation. That's why it was better to use latest versions. And there would not any arguments in comments (which now about 50% of all comments here and under the Russian translation of this article the same situation). We are programmers, engineers and this is author target audience. And this audience like when things made smart, precisely and technically right

Filip Petkovski

Nice article, thanks for investing the time and effort. However, I have to say I cringed when I saw your PHP setup. Your workflow was testing Apache, not PHP performance . ) It is also a good practice to put labels on your chart axes so that they can be interpreted more easily

Filip Petkovski

Nice article, thanks for investing the time and effort. However, I have to say I cringed when I saw your PHP setup. Your workflow was testing Apache, not PHP performance . ) It is also a good practice to put labels on your chart axes so that they can be interpreted more easily

Rohan Kapadia

Where can I see the date on which this article was posted? When it comes to benchmarking, old and stale information is worse than no information

Rohan Kapadia

Where can I see the date on which this article was posted? When it comes to benchmarking, old and stale information is worse than no information

Dan Dollins

Excellent tutorial, so great and fluid . thanks

Dan Dollins

Excellent tutorial, so great and fluid . thanks

John Robie

Not using PHP7, and not even a mention of Elixir? I want my money back

John Robie

Not using PHP7, and not even a mention of Elixir? I want my money back

Marcin K

Node process relatively light. 50mb on startup and max 1. 4GB maximum imposed by V8, depends if you code is abusing GC or not. On 4x Core machine you should have 8GB ram and start node with pm2 https. //github. com/Unitech/pm2 pm2 start app. js -i 4 I would agree phra, these benchmarks are pointless. They also do not test real life applications. fetching something from DB would be more suitable test. In CRUD type app it is possible that node would be order magnitude faster than PHP

Marcin K

Node process relatively light. 50mb on startup and max 1. 4GB maximum imposed by V8, depends if you code is abusing GC or not. On 4x Core machine you should have 8GB ram and start node with pm2 https. //github. com/Unitech/pm2 pm2 start app. js -i 4 I would agree phra, these benchmarks are pointless. They also do not test real life applications. fetching something from DB would be more suitable test. In CRUD type app it is possible that node would be order magnitude faster than PHP

Wasin Thonkaew

Thanks for article. It lights me up, and I could found it sooner. Although quite surprise for nodejs result, but I do know now I need to use cluster when running nodejs. Thanks for article. I have a question though. For testing, how you simulate concurrent request? Which tool do we use or we write a script to send out those requests in chunk, but if so how do we know they will end up in concurrent?

Wasin Thonkaew

Thanks for article. It lights me up, and I could found it sooner. Although quite surprise for nodejs result, but I do know now I need to use cluster when running nodejs. Thanks for article. I have a question though. For testing, how you simulate concurrent request? Which tool do we use or we write a script to send out those requests in chunk, but if so how do we know they will end up in concurrent?

Steven Sagaert

I think the Java setup is not the most modern. Next to that classic "blocking io in threadpool" I'd like to see more modern JVM based server architectures like Akka based ones (either Java or Scala) or Vert. x (several JVM languages) or Kotlin coroutines. I'd also like to see Erlang web servers & Elixir+ Phoenix in the benchmark and . Net (with async/await, orléans framework)

Steven Sagaert

I think the Java setup is not the most modern. Next to that classic "blocking io in threadpool" I'd like to see more modern JVM based server architectures like Akka based ones (either Java or Scala) or Vert. x (several JVM languages) or Kotlin coroutines. I'd also like to see Erlang web servers & Elixir+ Phoenix in the benchmark and . Net (with async/await, orléans framework)

Declan Nnadozie

All the same, you are GOOD . -p, from what i can see here, PHP and Java may not have flexiblility Node. JS offers, one writing c/c++ addons is relatively easier than Java JNI/C interface. Once again thanks Brad, you expanded my horizon

Declan Nnadozie

All the same, you are GOOD . -p, from what i can see here, PHP and Java may not have flexiblility Node. JS offers, one writing c/c++ addons is relatively easier than Java JNI/C interface. Once again thanks Brad, you expanded my horizon

Adam Patterson

It comes down the the right tool for the job. If your building an API then maybe Python, Go, or Node make sense. But if you tuning for High IO on a website then you need to consider the ecosystems for mature frameworks, integration of front end and back end teams. I bet 9 times out of 10 you will have a PHP front end. Maybe you're building a web app, then again, you need to address those concerns. Brad mentioned this but what kind of talent can you attract and retain in your area, what kind of costs are associated with these environments. If you are going for IO then you probably have some form of proxy caching or a load balancer or both. I don't think you can look at a languages numbers and make a sound judgment call

Adam Patterson

It comes down the the right tool for the job. If your building an API then maybe Python, Go, or Node make sense. But if you tuning for High IO on a website then you need to consider the ecosystems for mature frameworks, integration of front end and back end teams. I bet 9 times out of 10 you will have a PHP front end. Maybe you're building a web app, then again, you need to address those concerns. Brad mentioned this but what kind of talent can you attract and retain in your area, what kind of costs are associated with these environments. If you are going for IO then you probably have some form of proxy caching or a load balancer or both. I don't think you can look at a languages numbers and make a sound judgment call

Alvaro Urbaez

It would be interesting to see what configuration you had in thread pool in Java test, that is a critical parameter to face a bunch of traffic in a Java application. So, I think these tests are really improveables, but at least they give a look of this matter. Thanks

Alvaro Urbaez

It would be interesting to see what configuration you had in thread pool in Java test, that is a critical parameter to face a bunch of traffic in a Java application. So, I think these tests are really improveables, but at least they give a look of this matter. Thanks

Michal Boška

With regards to java, have a look at https. //www. playframework. com/ or http. //vertx. io/ . It is not uncommon to write non blocking IO code in Java nowadays, having all the benefits of async IO processing (requiring only as many threads as CPU cores) and also benefits of multithreading (being able to share immutable data structures within a single process, not having to do IPC which often slows the process down etc) Would be interesting to see benchmark between these languages using Play or Vert. x with Java (instead of blocking servlet spec)

Michal Boška

With regards to java, have a look at https. //www. playframework. com/ or http. //vertx. io/ . It is not uncommon to write non blocking IO code in Java nowadays, having all the benefits of async IO processing (requiring only as many threads as CPU cores) and also benefits of multithreading (being able to share immutable data structures within a single process, not having to do IPC which often slows the process down etc) Would be interesting to see benchmark between these languages using Play or Vert. x with Java (instead of blocking servlet spec)

Acidic

I opened this page because I was thinking "Should I learn a new language instead of continuing to use Go". this made me have a laugh, I think I'll stick with Go

Acidic

I opened this page because I was thinking "Should I learn a new language instead of continuing to use Go". this made me have a laugh, I think I'll stick with Go

Hayden James

Plus starting with PHP 5. 5+opcache is enabled by default. So PHP 7 + opcache would be more like 5x faster than what was benched above. Strange that they would go with no longer supported PHP 5. 4 in 2017, but makes sense because it's the slowest. This is why you should only trust your own benchmarks haha

Hayden James

Plus starting with PHP 5. 5+opcache is enabled by default. So PHP 7 + opcache would be more like 5x faster than what was benched above. Strange that they would go with no longer supported PHP 5. 4 in 2017, but makes sense because it's the slowest. This is why you should only trust your own benchmarks haha

Binh Thanh Nguyen

Thanks, nice post

Binh Thanh Nguyen

Thanks, nice post

wshafer

And I'm also wondering who still uses the apache prefork with the php mod anymore?

wshafer

And I'm also wondering who still uses the apache prefork with the php mod anymore?

Maxim Kuderko

PHP 7. x FPM with preforked workers + opcache + nginx properly configured on quad code cpu could go even further than 5k rps

Maxim Kuderko

PHP 7. x FPM with preforked workers + opcache + nginx properly configured on quad code cpu could go even further than 5k rps

Charlie

It appears that the author chose 5. 4. 16 because it is bundled in RedHat/Oracle/CentOS/Scientific Linux v7. # rpm -qa . grep php php-5. 4. 16-43. el7_4. x86_64 php-cli-5. 4. 16-43. el7_4. x86_64 php-common-5. 4. 16-43. el7_4. x86_64 I don't think Node or Go are bundled at all, but might be available in EPEL. RH7 bundles two JREs. # rpm -qa . grep ^java . sort java-1. 7. 0-openjdk-1. 7. 0. 161-2. 6. 12. 0. 0. 1. el7_4. x86_64 java-1. 7. 0-openjdk-headless-1. 7. 0. 161-2. 6. 12. 0. 0. 1. el7_4. x86_64 Java-1. 8. 0-openjdk-1. 8. 0. 151-1. b12. el7_4. x86_64 java-1. 8. 0-openjdk-headless-1. 8. 0. 151-1. b12. el7_4. x86_64 javapackages-tools-3. 4. 1-11. el7. noarch

Charlie

It appears that the author chose 5. 4. 16 because it is bundled in RedHat/Oracle/CentOS/Scientific Linux v7. # rpm -qa . grep php php-5. 4. 16-43. el7_4. x86_64 php-cli-5. 4. 16-43. el7_4. x86_64 php-common-5. 4. 16-43. el7_4. x86_64 I don't think Node or Go are bundled at all, but might be available in EPEL. RH7 bundles two JREs. # rpm -qa . grep ^java . sort java-1. 7. 0-openjdk-1. 7. 0. 161-2. 6. 12. 0. 0. 1. el7_4. x86_64 java-1. 7. 0-openjdk-headless-1. 7. 0. 161-2. 6. 12. 0. 0. 1. el7_4. x86_64 Java-1. 8. 0-openjdk-1. 8. 0. 151-1. b12. el7_4. x86_64 java-1. 8. 0-openjdk-headless-1. 8. 0. 151-1. b12. el7_4. x86_64 javapackages-tools-3. 4. 1-11. el7. noarch

Tarun Ramakrishna

Frankly, when I last tried simple request/response benchmarking with some CPU activity in the request handling, the Java version smoked both node and go at high RPM after the JVM was sufficiently warmed up. Something strange going on

Tarun Ramakrishna

Frankly, when I last tried simple request/response benchmarking with some CPU activity in the request handling, the Java version smoked both node and go at high RPM after the JVM was sufficiently warmed up. Something strange going on

Arthur V Zhuk

Conclusion. No one agrees with the results

Arthur V Zhuk

Conclusion. No one agrees with the results

WC Plunger

Promises are just callback wrappers

WC Plunger

Promises are just callback wrappers

alexandrestrzelewicz

Hoàn toàn đúng, điểm chuẩn này thậm chí không nói về nút phân cụm. js but talk about many web workers for java and php. The author of this benchmark is unknowledgable about Node. js in production, this is a real shame and remove any sense of a potencial real world benchmark

alexandrestrzelewicz

Hoàn toàn đúng, điểm chuẩn này thậm chí không nói về nút phân cụm. js but talk about many web workers for java and php. The author of this benchmark is unknowledgable about Node. js in production, this is a real shame and remove any sense of a potencial real world benchmark

Ruiheng Wang

it's Opcache now

Ruiheng Wang

it's Opcache now

David

or Atari BASIC

David

or Atari BASIC

Eddy WM

In Java, these days devs are using Vert. X, Akka, Reactor and others which are mostly event-driven, non-blocking and adhere to the Reactive Manifesto. Serverlets are old days way of doing backend systems in Java

Eddy WM

In Java, these days devs are using Vert. X, Akka, Reactor and others which are mostly event-driven, non-blocking and adhere to the Reactive Manifesto. Serverlets are old days way of doing backend systems in Java

Jon Forrest

I suggest you go back and proofread this article. For example " your JS can that is doing CPU-bound operations"

Jon Forrest

I suggest you go back and proofread this article. For example " your JS can that is doing CPU-bound operations"

Ahmad Samiei

Java is built for concurrent computing by default. Multithreading is one of the options you have and you only do multi-threaded when it make sense. It's not the default option to work with Java (it was popular many many years ago). And your Java code is horribly old school. The PHP version you're using is really really old (2012) and also nobody uses your setup with Apache anymore. PHP7. X's raw performance is almost three times faster than the version you're using. Node had a significant performance improvement after version 8. But you're using v6

Ahmad Samiei

Java is built for concurrent computing by default. Multithreading is one of the options you have and you only do multi-threaded when it make sense. It's not the default option to work with Java (it was popular many many years ago). And your Java code is horribly old school. The PHP version you're using is really really old (2012) and also nobody uses your setup with Apache anymore. PHP7. X's raw performance is almost three times faster than the version you're using. Node had a significant performance improvement after version 8. But you're using v6

Fab

Not even a mention of Elixir/Erlang ?? Wtf

Fab

Not even a mention of Elixir/Erlang ?? Wtf

Dustin Deus

Hi, I would like to see how Node 9 performed (TurboFan) and then you can also use the native Crypto module

Dustin Deus

Hi, I would like to see how Node 9 performed (TurboFan) and then you can also use the native Crypto module

Grant Jenks

Python comparison at https. //gist. github. com/grantjenks/dacc0a1e7fa9a08264439b9c6a05ec5b The Python results are really good. 5,347 requests per second for Python vs 6,856 for Golang. I expected more from Golang. My guess is the benchmark is CPU-bound so all the time is spent reading the file and hashing it. For Python, that all happens in optimized C code

Grant Jenks

Python comparison at https. //gist. github. com/grantjenks/dacc0a1e7fa9a08264439b9c6a05ec5b The Python results are really good. 5,347 requests per second for Python vs 6,856 for Golang. I expected more from Golang. My guess is the benchmark is CPU-bound so all the time is spent reading the file and hashing it. For Python, that all happens in optimized C code

kenton_2233

What about the WebSockets for PHP (http. //socketo. me/) ? Php can do the non blocking I/O now days

kenton_2233

What about the WebSockets for PHP (http. //socketo. me/) ? Php can do the non blocking I/O now days

Paco Meraz

Ikr, no use of Elixir/Erlang that wouldhave shredded the others. Also no ruby, no Python. nothing

Paco Meraz

Ikr, no use of Elixir/Erlang that wouldhave shredded the others. Also no ruby, no Python. nothing

Rus Brushkoff

nodejs has async/await which do not block. Seems like your synthetic tests are unaware about this. https. //stackoverflow. com/questions/46004290/will-async-await-block-a-thread-node-js So your cheat tests writers must read the following first. https. //www. w3. org/TR/workers/ And try to rewrite the JS tests accordingly, with something like. https. //www. npmjs. com/package/webworker-threads Go can compare to JS only using poor cheating

Rus Brushkoff

nodejs has async/await which do not block. Seems like your synthetic tests are unaware about this. https. //stackoverflow. com/questions/46004290/will-async-await-block-a-thread-node-js So your cheat tests writers must read the following first. https. //www. w3. org/TR/workers/ And try to rewrite the JS tests accordingly, with something like. https. //www. npmjs. com/package/webworker-threads Go can compare to JS only using poor cheating

Ellina Bereza

PHP is ideal for implementing projects with sequential execution and active use of relational databases. NodeJS is best for creating microservices and solving problems based on the event model. https. //applikeysolutions. com/blog/node-js-vs-php-for-server-side-development That's all not so evident, though

Ellina Bereza

PHP is ideal for implementing projects with sequential execution and active use of relational databases. NodeJS is best for creating microservices and solving problems based on the event model. https. //applikeysolutions. com/blog/node-js-vs-php-for-server-side-development That's all not so evident, though

Richard A

PHP 5. 4 from 2012-2013 And Apache vs the rest. Fair fight. Why not Php 7. 1 And Nginx?

Richard A

PHP 5. 4 from 2012-2013 And Apache vs the rest. Fair fight. Why not Php 7. 1 And Nginx?

giuseppe d

For high request rate you should never use a single php backend app (it is not designed to do that). Bạn nên sử dụng HHVM. Anyway, thanks for the clear explanation

giuseppe d

For high request rate you should never use a single php backend app (it is not designed to do that). Bạn nên sử dụng HHVM. Anyway, thanks for the clear explanation

Sarath Uch

I realized that Go is a compiled code and it's a super amazing language; Very lighting performance

Sarath Uch

I realized that Go is a compiled code and it's a super amazing language; Very lighting performance

Kolja Kutschera

To be fair, use nodejs with its native clustering to make use of all cpus like the others and than run the benchmark again. Please fix this post . D

Kolja Kutschera

To be fair, use nodejs with its native clustering to make use of all cpus like the others and than run the benchmark again. Please fix this post . D

Jonas Steinberg

I can't say for elixir, but I think Ruby and Python would have lost handily. Decent analysis (better than this, in general, I feel) is here (benchmarking setup seems better and more clear). https. //www. linkedin. com/pulse/ruby-vs-php-python-simple-microservice-performance-comparison-per/

Jonas Steinberg

I can't say for elixir, but I think Ruby and Python would have lost handily. Decent analysis (better than this, in general, I feel) is here (benchmarking setup seems better and more clear). https. //www. linkedin. com/pulse/ruby-vs-php-python-simple-microservice-performance-comparison-per/

Jonas Steinberg

The explanation part I found very insightful, especially, believe it or not, from an operations perspective. My team has recently deployed ELK at scale and we found, basically for the first time ever, that tuning threads, IOPS, server specs, etc actually really, really matters at scale. And much of what you cover initially adds insight to what I've found for myself. I must say though. you lost me at the benchmarking. And I don't mean the apples/oranges/preferences arguments that seems to be afflicting everyone else, but rather the fact that, at least for me, you didn't elaborate on your benchmarking setup very well. I think the reason why there are so many criticisms in the comments is that this could've been a great piece of analysis, but ended up being fairly mediocre in the end, which is disappointing. But I think next time you'll nail it

Jonas Steinberg

The explanation part I found very insightful, especially, believe it or not, from an operations perspective. My team has recently deployed ELK at scale and we found, basically for the first time ever, that tuning threads, IOPS, server specs, etc actually really, really matters at scale. And much of what you cover initially adds insight to what I've found for myself. I must say though. you lost me at the benchmarking. And I don't mean the apples/oranges/preferences arguments that seems to be afflicting everyone else, but rather the fact that, at least for me, you didn't elaborate on your benchmarking setup very well. I think the reason why there are so many criticisms in the comments is that this could've been a great piece of analysis, but ended up being fairly mediocre in the end, which is disappointing. But I think next time you'll nail it

Jonas Steinberg

Additionally, according to https. //www. techempower. com/benchmarks/#section=data-r15&hw=ph&test=fortune&b=2&s=1&l=gcrv5b NodeJS out performs Go by 200% for fairly typical database queries and client responses. Setups were *highly* similar

Jonas Steinberg

Additionally, according to https. //www. techempower. com/benchmarks/#section=data-r15&hw=ph&test=fortune&b=2&s=1&l=gcrv5b NodeJS out performs Go by 200% for fairly typical database queries and client responses. Setups were *highly* similar

Ezequiel Valenzuela

Thank you for adding Python to the list. Having looked at your "gist" (and other comments here), I'd say that possibly the best framework and design (for Python) hasn't been put forward yet. tornado + a thread pool. The code would not be really that big, and it'd have the chance of performing the hashing in parallel (as the Python lock would be released just before performing the low-level "hashing"), so it'd benefit of the parallel execution that Go is doing for you (assuming it has been tuned to use the maximum number of threads it'd deem appropriate), making the comparison more representative of equivalent execution profiles

Ezequiel Valenzuela

Thank you for adding Python to the list. Having looked at your "gist" (and other comments here), I'd say that possibly the best framework and design (for Python) hasn't been put forward yet. tornado + a thread pool. The code would not be really that big, and it'd have the chance of performing the hashing in parallel (as the Python lock would be released just before performing the low-level "hashing"), so it'd benefit of the parallel execution that Go is doing for you (assuming it has been tuned to use the maximum number of threads it'd deem appropriate), making the comparison more representative of equivalent execution profiles

Grant Jenks

I’m sure the Python code can be made faster just as the other solutions could be made faster too. But the point was to show how the simple solution was competitively fast. My solution already uses a pool of workers to process requests in parallel and completely sidesteps issues with the Python global interpreter lock. It’s in the last line where it says “workers=8”

Grant Jenks

I’m sure the Python code can be made faster just as the other solutions could be made faster too. But the point was to show how the simple solution was competitively fast. My solution already uses a pool of workers to process requests in parallel and completely sidesteps issues with the Python global interpreter lock. It’s in the last line where it says “workers=8”

Ezequiel Valenzuela

I appreciate that. However, when you're "hammering" an http server for which you're handling the requests in your chosen programming language/framework (Python), having 8 "workers", with each of them behaving (mostly) synchronously, is not going to do much in terms of producing a low standard deviation in terms of execution time for any given request. Also, even in the case where each "worker" is assigned a CPU thread (assuming you've got 8 CPU threads to play with), each of them might be busy doing CPU intensive work (such as calculating a hash) instead of servicing the I/O-bound network traffic (or even file reading), which is ultimately a design inefficiency, and (more importantly) adding latency to almost every request. In that regard, my point was that tornado will deal with the I/O for each of those network connections (very) efficiently, whilst freeing the CPU to do the CPU-intensive work. That way, you should basically be spending most of the CPU time doing the hashing (which (AFAIK) should be implemented in C by the Python standard library), which is an inescapable cost. I'd guess that Python should do only slightly worse than a native (or JIT-ed) language/framework, to account for the Python bytecode execution. Maybe having requests ultimately waiting to be serviced (as they're waiting in the "worker" queue) only makes those requests perform badly, and others (the ones being serviced) perform very well (as they benefit from having the CPU to themselves), giving roughly the same "mean" value for the sample set. But I'm not sure about that. That might need some measuring, before venturing a verdict

Ezequiel Valenzuela

I appreciate that. However, when you're "hammering" an http server for which you're handling the requests in your chosen programming language/framework (Python), having 8 "workers", with each of them behaving (mostly) synchronously, is not going to do much in terms of producing a low standard deviation in terms of execution time for any given request. Also, even in the case where each "worker" is assigned a CPU thread (assuming you've got 8 CPU threads to play with), each of them might be busy doing CPU intensive work (such as calculating a hash) instead of servicing the I/O-bound network traffic (or even file reading), which is ultimately a design inefficiency, and (more importantly) adding latency to almost every request. In that regard, my point was that tornado will deal with the I/O for each of those network connections (very) efficiently, whilst freeing the CPU to do the CPU-intensive work. That way, you should basically be spending most of the CPU time doing the hashing (which (AFAIK) should be implemented in C by the Python standard library), which is an inescapable cost. I'd guess that Python should do only slightly worse than a native (or JIT-ed) language/framework, to account for the Python bytecode execution. Maybe having requests ultimately waiting to be serviced (as they're waiting in the "worker" queue) only makes those requests perform badly, and others (the ones being serviced) perform very well (as they benefit from having the CPU to themselves), giving roughly the same "mean" value for the sample set. But I'm not sure about that. That might need some measuring, before venturing a verdict

Grant Jenks

I added "japronto" to the comparison which is on the bleeding-edge of Python web server frameworks. Hiệu suất hiện tại nhanh hơn 13% so với golang. Thiết kế của nó tương tự như bottle+gunicorn ở chỗ nó sử dụng mô hình worker trước fork. But each of those workers uses async-IO (irrelevant for your benchmark) and a fast HTTP parser

Grant Jenks

I added "japronto" to the comparison which is on the bleeding-edge of Python web server frameworks. Hiệu suất hiện tại nhanh hơn 13% so với golang. Thiết kế của nó tương tự như bottle+gunicorn ở chỗ nó sử dụng mô hình worker trước fork. But each of those workers uses async-IO (irrelevant for your benchmark) and a fast HTTP parser

kevin_lee

could you share the source code you used to run these tests

kevin_lee

could you share the source code you used to run these tests

Dmitry Sokulev

Using curl_multi_exec with php will beat all of these

Dmitry Sokulev

Using curl_multi_exec with php will beat all of these

Namjith Aravind

Our application is built on PHP 7 and what we could realize the real bottleneck is the blocking calls (I/O)to MySQL and Redis. We are able to manage with persistent connections since PHP does not have Connection Pool (Persistend connections will close in the end of process life), But the thing i would like to know is , Is there any language feature (Go (Goroutine),Akka Http(Actor)) are able to solve this with connection pool(Use dedicated less number of connections instead one connection per request)

Namjith Aravind

Our application is built on PHP 7 and what we could realize the real bottleneck is the blocking calls (I/O)to MySQL and Redis. We are able to manage with persistent connections since PHP does not have Connection Pool (Persistend connections will close in the end of process life), But the thing i would like to know is , Is there any language feature (Go (Goroutine),Akka Http(Actor)) are able to solve this with connection pool(Use dedicated less number of connections instead one connection per request)

n0m1s

Have a look at the PHP extension called swoole [1] and then throw away nginx and Apache . -) Here's an example benchmark with PHP swoole wiping the floor with nodejs [2]. [1] https. //www. swoole. com/index. en. html [2] https. //www. phòng thí nghiệm w3c. com/php-7-1-swoole-v1-9-5-vs-node-js-benchmark-test-php7-swoole-beats-node-js/

n0m1s

Have a look at the PHP extension called swoole [1] and then throw away nginx and Apache . -) Here's an example benchmark with PHP swoole wiping the floor with nodejs [2]. [1] https. //www. swoole. com/index. en. html [2] https. //www. phòng thí nghiệm w3c. com/php-7-1-swoole-v1-9-5-vs-node-js-benchmark-test-php7-swoole-beats-node-js/

Namjith Aravind

Is it fine to use with zend framework 2?

Namjith Aravind

Is it fine to use with zend framework 2?

Gary Fry

First of all, thank you Brad for spending your time to research. Getting something out there, for people to find and react to means we're looking for genuine peer-reviewed results. To have people give you any feedback is a compliment. So well-done. Clearly you're not massively familiar with the nuances of all of the languages in your benchmarks, but you've got a good instinct. You mentioned "we’re seeing times that more to do with the general execution of the languages themselves, much more so that the I/O. ". You are right. In the case of Java, when you start Java code, it has to load a not-so-insignificant amount of code into memory from the file system before any code gets executed. That's an overhead which is a factor in any language, so if you're timing it from the shell, that would be bad, so hopefully your timings were derived from code-land, rather than script-land. Java has something called a Just-in-time (JIT) compiler that self-optimises code execution paths after a number of iterations in a loop of code. If you allow the JVM to warm up (I think 10K iterations) - https. //stackoverflow. com/questions/36370483/jvm-warmup-queries?rq=1, then things get cooking, performance-wise. Also, the Garbage collector and the heap size settings could be tweaked to improve Java performance. No doubt, GoLang and Node would have a swiss-army knife of performance enhancers up their sleeves too. so just saying. . -) Getting each application to an optimal point where your benchmarks make sense is a challenge, but well worth the journey. There's clearly a demand for the work you're doing, so keep going

Gary Fry

First of all, thank you Brad for spending your time to research. Getting something out there, for people to find and react to means we're looking for genuine peer-reviewed results. To have people give you any feedback is a compliment. So well-done. Clearly you're not massively familiar with the nuances of all of the languages in your benchmarks, but you've got a good instinct. You mentioned "we’re seeing times that more to do with the general execution of the languages themselves, much more so that the I/O. ". You are right. In the case of Java, when you start Java code, it has to load a not-so-insignificant amount of code into memory from the file system before any code gets executed. That's an overhead which is a factor in any language, so if you're timing it from the shell, that would be bad, so hopefully your timings were derived from code-land, rather than script-land. Java has something called a Just-in-time (JIT) compiler that self-optimises code execution paths after a number of iterations in a loop of code. If you allow the JVM to warm up (I think 10K iterations) - https. //stackoverflow. com/questions/36370483/jvm-warmup-queries?rq=1, then things get cooking, performance-wise. Also, the Garbage collector and the heap size settings could be tweaked to improve Java performance. No doubt, GoLang and Node would have a swiss-army knife of performance enhancers up their sleeves too. so just saying. . -) Getting each application to an optimal point where your benchmarks make sense is a challenge, but well worth the journey. There's clearly a demand for the work you're doing, so keep going

Santeri

I completely agree with this comment (was actually looking if it is posted already). The author most probably doesn't know very much about a basic scaling feature of NodeJS and the use of clustering. It is extremely easy to spin up threads as well as relatively simple to set-up separate child processes in order to handle heavier blocking computation tasks. Using a Node child process to send a scientific computation over to a separate Python interpreter and wait for the response is also common. All in all what I mean is that a very much more efficient utilization of the underlying resources (CPU) is possible than what is shown here

Santeri

I completely agree with this comment (was actually looking if it is posted already). The author most probably doesn't know very much about a basic scaling feature of NodeJS and the use of clustering. It is extremely easy to spin up threads as well as relatively simple to set-up separate child processes in order to handle heavier blocking computation tasks. Using a Node child process to send a scientific computation over to a separate Python interpreter and wait for the response is also common. All in all what I mean is that a very much more efficient utilization of the underlying resources (CPU) is possible than what is shown here

davidriss

To make this comparison to be fair, I hope you have used a node. js cluster, otherwise you would be running everything in a single thread. The idea of Node. js cluster is that you will run as many node. js concurrrent processes as you have cpu cores. This feature is built in to the core packages of node. js, and done the right way you need less than 10 lines of code to make use of it without any changes to your source code. https. //nodejs. org/api/cluster. html

davidriss

To make this comparison to be fair, I hope you have used a node. js cluster, otherwise you would be running everything in a single thread. The idea of Node. js cluster is that you will run as many node. js concurrrent processes as you have cpu cores. This feature is built in to the core packages of node. js, and done the right way you need less than 10 lines of code to make use of it without any changes to your source code. https. //nodejs. org/api/cluster. html

Natalia N

It's a very comprehensive article, thank you for your job. Some say that Node is better for complex single-page applications as they have heavy I/O workload characteristics. https. //softmedialab. com/blog/nodejs-vs-php/ What do you think?

Natalia N

It's a very comprehensive article, thank you for your job. Some say that Node is better for complex single-page applications as they have heavy I/O workload characteristics. https. //softmedialab. com/blog/nodejs-vs-php/ What do you think?

Lemuel Adane

I agree

Lemuel Adane

I agree

Lemuel Adane

But if you 'toe-to-toe' PHP7 with Go, Go will still win

Lemuel Adane

But if you 'toe-to-toe' PHP7 with Go, Go will still win

Robert Mennell

I found this in 2018 as a top search result. Don't come here. This benchmark is so badly written it doesn't even pass the test of "Is it fair" by a long shot. Can we get this taken down?

Robert Mennell

I found this in 2018 as a top search result. Don't come here. This benchmark is so badly written it doesn't even pass the test of "Is it fair" by a long shot. Can we get this taken down?

Kıran Ali

what about . net core, it's worth to include here I guess

Kıran Ali

what about . net core, it's worth to include here I guess

James Suárez

YOUR BENCHMARK IS NOT GOOD FOR REAL PEOPLE. Almost people talk very bad about CPU intensive in Node because have only one thread in your core. BUt why don't say that Nodejs have cluster module. With the good configuration of cluster (one cluster for each core) , can beat in performance almost like a golang or any other language that have thread support of your benchmarks I will try to make the benchmarks using a cluster and will see noticed differences

James Suárez

YOUR BENCHMARK IS NOT GOOD FOR REAL PEOPLE. Almost people talk very bad about CPU intensive in Node because have only one thread in your core. BUt why don't say that Nodejs have cluster module. With the good configuration of cluster (one cluster for each core) , can beat in performance almost like a golang or any other language that have thread support of your benchmarks I will try to make the benchmarks using a cluster and will see noticed differences

James Suárez

You don't need start cluster each request, opening a cluster for each core one time at the beginning, can beat the performance of other languagues you used for benchmark. I always see people taking that nodejs is bad for cpu intensive, but is really? With a good cluster environment you will get same performance like other language can get using threads

James Suárez

You don't need start cluster each request, opening a cluster for each core one time at the beginning, can beat the performance of other languagues you used for benchmark. I always see people taking that nodejs is bad for cpu intensive, but is really? With a good cluster environment you will get same performance like other language can get using threads

James Suárez

Is the same thing for NodeJs. Trong điểm chuẩn, tất cả các ngôn ngữ đều có hỗ trợ đa lõi (với luồng/quy trình) và nodejs cũng có hỗ trợ đa lõi (sử dụng mô-đun cụm) nhưng ở đây lập trình viên không áp dụng cho NodeJS. With NodeJs cluster you will get 2x performance at least, depending on CPU cores

James Suárez

Is the same thing for NodeJs. Trong điểm chuẩn, tất cả các ngôn ngữ đều có hỗ trợ đa lõi (với luồng/quy trình) và nodejs cũng có hỗ trợ đa lõi (sử dụng mô-đun cụm) nhưng ở đây lập trình viên không áp dụng cho NodeJS. With NodeJs cluster you will get 2x performance at least, depending on CPU cores

Brad

Thanks to all of you to provided constructive feedback and meaningful discussion on this topic. Please also note that responses which are primarily negative/not constructive don't help anyone. I wrote this article to help provide information for people to use in their own projects, decision making, etc. - that's the point of the article. Opinions and feedback are welcome. But I don't feed trolls

Brad

Thanks to all of you to provided constructive feedback and meaningful discussion on this topic. Please also note that responses which are primarily negative/not constructive don't help anyone. I wrote this article to help provide information for people to use in their own projects, decision making, etc. - that's the point of the article. Opinions and feedback are welcome. But I don't feed trolls

I J

Well written. Performance was considered highly from the start of Go. Languages like python and Ruby should not be mention in terms of Non-blocking IO. If added tomorrow, it will still be a copied concept - not part of the main language; leading to mediocre performance. For high scale performance app, go with Go

I J

Well written. Performance was considered highly from the start of Go. Languages like python and Ruby should not be mention in terms of Non-blocking IO. If added tomorrow, it will still be a copied concept - not part of the main language; leading to mediocre performance. For high scale performance app, go with Go

Hridyansh Thakur

how about binary ?

Hridyansh Thakur

how about binary ?

Harish Sivakumar

Hey Brad, Kindly give a quick view of performance of rest api calls with request response time for the below languages Node. js vs Django vs PHP vs Go vs Java(jsp or serlvet even rmi) Thanks in Advance, Regards, Hariharan

Harish Sivakumar

Hey Brad, Kindly give a quick view of performance of rest api calls with request response time for the below languages Node. js vs Django vs PHP vs Go vs Java(jsp or serlvet even rmi) Thanks in Advance, Regards, Hariharan

John Robie

This seems to be a common response of Node. js devs. Setting up clustering is additional code, and getting the nodes within the cluster to communicate is not a trivial matter – let alone communicating across multiple machines. Let's face it, Node's strength is that it blurred the lines between frontend and backend devs. But as a legitimate backend choice, it's far from ideal. I'd pick Elixir and Go over Node every day of the week. Elixir can have hundreds of thousands of simultaneous requests on one machine, without having to deal with any vertical scaling quirks. Scaling horizontally is easy (nodes connect via IP address). And that's not even talking about JS's syntax, which is atrocious (only slightly better than PHP's)

John Robie

This seems to be a common response of Node. js devs. Setting up clustering is additional code, and getting the nodes within the cluster to communicate is not a trivial matter – let alone communicating across multiple machines. Let's face it, Node's strength is that it blurred the lines between frontend and backend devs. But as a legitimate backend choice, it's far from ideal. I'd pick Elixir and Go over Node every day of the week. Elixir can have hundreds of thousands of simultaneous requests on one machine, without having to deal with any vertical scaling quirks. Scaling horizontally is easy (nodes connect via IP address). And that's not even talking about JS's syntax, which is atrocious (only slightly better than PHP's)

face1m

Really enjoyed reading your article as well as your critics comments. Both very informative

Roberto Spadim

php7+swoole?

Marek Tenus

If you use PHP you should use amp, react, pthreads or swoolie. It let you use threads and results should be many times better

Marcus Cemes

This is a little late, but it's worth a shout. First of all, fantastic job for the effort you put into this! However, the Node.js benchmark is extremely disadvantaged! For hashing, you used a (now deprecated) Javascript library. That's like writing the hash function yourself in PHP.. It's very slow, insecure, and just generally a very bad idea! Data will stay hanging in memory until the garbage collector runs! Node.js has always had a native crypto module (just like the fs module that lets your interact with the filesystem). The crypto module has native bindings to OpenSSL, and runs crypto operations low-level leveraging hardware accelerated hash functions. Not to mention, it's more secure, as it can byte-level exact memory allocation/deallocation.

Marek Marczak

You're wrong. Have you ever heard about uvloop? Libuv based loops for Python (uvloop ) and PHP (i. e swoole) perform on par with Node or even better

Fakhar Anwar

From technical perspective, Did you ever test Compiled Asynchronous Swoole (PHP Framework) ? I saw many banchmarks where they say Swoole is 03 times faster than Node. js and competes Go-Lang. With its ease of learning and cost-effectiveness, i believe Linux, PHP7 with Swoole together go far ahead in the race of technologies. PLUS, from Business Perspective, "Throughput" (Performance / Stability / Speed) is proportional to Computing Hardware (+ Event Loop). For the sake of argument, if Swoole PHP takes more hardware resources, one can say "Hardware is much cheaper than HR / Development costs associated with Node. JS, Go-Lang and JAVA". Therefore, ease of learning and Availability of less costly PHP-resources makes the PHP win. How do you think about that ?

Spitfire Fran

I don't understand your argument here, do you really know how to scale stateless applications? The best thing about NodeJS is that it implies (generally speaking) that you're building a stateless service, so scaling it horizontally is really natural. For Kubernetes it's just a perfect match. I'm not saying that Go/Elixir doesn't do better for CPU intensive tasks, but I really don't understand your argument. "Setting up clustering is additional code, and getting the nodes within the cluster to communicate is not a trivial matter". IO bound tasks can be done easily on NodeJS, the productivity (talking about npm here) is a huge gain. CPU intensive tasks can be done in Rust, that kills everything that you can argument about performance in Go/Elixir/Java except for productivity

John Robie

Of course I know how, and I've done it in multiple languages, including Elixir and Node in k8s. Bạn có biết làm thế nào? . In the real-world, just because an app is "stateless", does not mean it is fully isolated. For instance, creating a cluster of Elixir nodes that share in-memory cache, or socket connection presence (getting User. 1 connected on Node. A to chat with User. 2 on Node. B) or process hand-off when terminating a node. They may be stateless, but they're still connected. All of that is easy in Elixir (largely due to Actor Model), and complex in Node (which is why I see so many Node tutorials utilizing Redis; which isn't necessary in Elixir). Vertical scaling in Node requires a cluster (even in k8s). Elixir automatically utilizes all available cores. There are good reasons to use Node, but productivity and performance aren't very good reasons, IMO

Giles Thompson

Blown away by GO's performance as per your benchmarks 4000 requests per second is fantastic. I suppose direct platform compilation will always out perform interpretation no matter how mature Java's excellent Just-In-Time (JIT) compiler performs

Giles Thompson

I don't know. I remember seeing benchmarks indicating that NIO performed worse than blocking IO as far as response times is concerned at scale. Whilst the throughput of NIO will obviously be higher, the request/response cycle of each individual operation was shown to be slower

stargt

Thanks. Nice article. May I translate it into Korean, if you don't mind? @bradliusgp. disqus If you're okay, I am gonna publish that on my blog and leave the original link

Brad

I have no problem with this

Leonardo Rojas

+1

Alex Mills

I've used all these languages - literally all. I started on WAMP. Went to Java, Node, then started doing some Golang. There is just no way PHP can keep up with the rest. Something has to be wrong here. You can't spawn a new process for each request and expect it to keep up

OAH

man that is one hell of an article. Nice job but would love to see the bench mark for php 7. 4

artit91

You forgot the most important fact. NodeJs is thread safe, and go use locks everywhere. With NodeJs, you will never experience weird locking issues and you usually scale nodejs and PHP on process level, so starting a lot of processes to handle requests. Your points about single thread performance is irrelevant because both go and nodejs will run a single core (max dual core machine) In terms of performance, it's Java with arguably nicer syntax

Fakhar Anwar

Good point. Và tôi hiểu bạn đến từ đâu. A long queue of non-blocking I/O can slow down individual request / response significantly even if the over-all throughput will be higher. Based on above speculation, "Long Queues of non-blocking I/Os" can be good only for background processing running separate to Request / Response, other way round is that for user's Request / Response time there should be a way to monitor size of "queue of non-blocking tasks" and keep it not too big

Fakhar Anwar

Swoole in PHP (And co-routines in Core-PHP) allow Asynchronous I/O (Concurrent Pocessing in single thread). They are a minimum of 8 times faster than Node. JS and Fastest (Scalable and higher throughput) so far with MySQL. You dont need a separate Web Server running to run Swoole

Fakhar Anwar

Even Swoole for PHP (C++ compiled PHP Extension) is father of Node. JS, . NET and Java. I mean faster and has higher throughput, and allows Asynch (Concurrent / Reactive) prorgamming paradigm

T. Todua

Not objective. What's worth comparing with PHP, if not using PHP SWOOLE?

Boris Kleshch

it's Golang promotion lol

Alexander Danilov

You should run node per each core, not just single pod. Lol, toptal, lol. What a shame

Epp Core

Callbacks on server side are really bad practice in my opinion. I would never use non-blocking functions in crucial environments. Even if you need parallel computing I dont think spawning a separate process will cost you much more memory than forking a thread unless you have billions of users and threads make you save billions of $ of memory modules, but this is not a problem with the vast majority of cases

Shakil Ahmed

NodeJS should be run in cluster mode. Sorry, but the comparison is flawed

Fakhar Anwar

I think comparison is biased as you are comparing Traditoinal PHP engine (PHP-FPM) and PHP version 7. Theo nghiên cứu của tôi, Swoole (Hơn cả Async. PHP) has an architecture more Reliable than NodeJS and highly performant than NodeJS and contains more Network features for IoT, Event-streaming, Micro-services and Connected Apps, along with its better adoptability (ease of use of PHP). Swoole is production-grade and ready to be used with PHP8. 0 JIT. Checkout Techempower benchmarks where it shows little lower than Go but much higher in rank than NodeJS. So i take Swoole (in PHP) as best trade-off in terms of Performance and Ease of Use, specially for micro-services

Fakhar Anwar

PHP Performance. If you want to compare I/O intensive job in PHP, no one would compare PHP-FPM to NodeJS. There is Swoole at least twice faster than NodeJS and approx. equal to Go-lang in throughput in almost all popular published benchmarks like TechEmpower and Benchmark Games. Swoole's Better Architecture. Swoole has multiple reactor-threads ensure higher load balance and separation of IO-intensive task and CPU-intensive tasks in Worker Process and Task Worker Process respectively makes a more reliable Architecture. In addition to Speed / Throughput, Swoole has more features / power than NodeJS, as an example, you can initiate new Processes and can communicate with your newly-created Process and/or OS- Processes, directly, without those cpu-/memory- inefficient third-party Queus like RaabitMQ

Harald

I came across this article a few years later, but it still seems relevant and of course helpful. Thank you for sharing

Harald

OK, for the Java-World not 100% up-to-date in 2021, because newer technologies like Quarkus, Micronaut or GraalVM could do better probably

FirefoxGuru

I just want to launch a server on GCP API. 😂 I've done Java and PHP in uni about 7 years ago but I'm aware Node and Go are the hot goodies right now. I also want this snippet to run server side. Thank you for the write up. . )

kogi123

I do not know how was it 4 years ago when this article was written, but currently PHP has very good and working threading support. Libraries usually don't use it yet, you don't get it in your usual linux php packages but if necessary, it is available (though usually you need to make your own PHP compilation to enable it). So using it, non-blocking IO is also possible and I am using it in my PHP server, though not in requests handling as I never actually needed it there (I have only one Database connection in there per request and more would be just nuisance to manage). I am just using it in my PHP background processes and there it works pretty well

Sergiu Petrica

"And PHP is also notorious for breaking things between versions" Wut? If anything, PHP is so annoyingly backwards-compatible to the point they refuse to fix some of the irritatinig inconsistencies in their standard library

lamer

All reviewed platform have support of the non-blocking IO. But main point of the article that Go has intrinsic support of non-blocking IO because of internal scheduler under hood

Matt

Điểm chuẩn vô nghĩa. Uses 4 core machine with single NodeJS process against threaded PHP. Spawn cluster of 4 NodeJS processes and multiply the throughput several times over as CPU becomes unblocked

Matt

Any benchmark against node in a multi-core machine using a single NodeJS process is null and void. That's not how NodeJS works

Matt

1. Swoole không phải là xử lý đơn lẻ trong "một luồng" Điều đó hoàn toàn ngược lại với mục đích của nó. 2. "a minimum of 8 times faster than Node. JS" is hilarious and completely baseless. What benchmark?, what deployment structure? What load? 2. A single NodeJS process cannot be compared to any multi-threaded execution model. Một cụm quy trình NodeJS trên máy đa lõi là điểm chuẩn công bằng hơn nhiều. Đối với công việc chuyên sâu về I/O như cổng API, DAL đơn giản, đây thường là cách nhanh nhất bạn có thể nhận được, đặc biệt là làm việc với JSON (v8 được tối ưu hóa siêu hạng cho điều này ở lớp thời gian chạy), do đó được sử dụng cho mục đích chính xác này trong các công ty như Netflix. 3. No serious company starts greenfield PHP in 2021

CharlES

This man, despite his wisdom, modifies everything as he pleases

Aron

Try with PHP 8 JIT with Swoole (concurrent nonblocking IO) or the same with ReactPHP with PHP 8. 1(async nonblocking IO). difference almost negligible against go especially with Swoole (which and beat NodeJS by miles)

Dario Cangialosi

what about ECMAScript's "async/await" and ECMAScript's "promises" ("ES promises" work alone and with async/await too)

Nikhil Suthar

Thanks for good article, I have one use case where I have to read 1 to 5 Lakh records from Oracle Database and create PDF File. Which language will do better I/O and handle such large data? Which is best fit for this use case - Node.js , Java, Python or Go ? Please suggest....

Hanro50

Nodejs does have the option to split itself up onto different threads with the cluster module as others have mentioned. The thing however is that in terms of node the author did not mentioned that the callback hell they described can be easily fixed with using asynchronous JavaScript or Promises. Node also provides synchronous versions of the file handling functions

How much faster is NodeJS than PHP?

Is node js better than PHP?

Should I learn PHP or Node JS in 2022?

What is faster than node JS?