programming php

Nút js hay php nào nhanh hơn?

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Ẻ

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 xét 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. Và các chi tiết quan trọng

Cuộc gọi hệ thống

Đầu tiên, chúng tôi có các cuộc gọi hệ thống, có thể được mô tả như sau

Chương trình của bạn [ở “vùng đất người dùng” như họ nói] phải yêu cầu nhân hệ điều hành thay mặt nó thực hiện thao tác I/O
“Tòa nhà chọc trời” là phương tiện mà chương trình của bạn yêu cầu hạt nhân làm điều gì đó. Các chi tiết cụ thể về cách thực hiện điều này khác nhau giữa các hệ điều hành nhưng khái niệm cơ bản là giống nhau. Sẽ có một số hướng dẫn cụ thể chuyển điều khiển từ chương trình của bạn sang kernel [giống như lệnh gọi hàm nhưng với một số loại nước sốt đặc biệt dành riêng để xử lý tình huống này]. Nói chung, các tòa nhà chọc trời đang bị chặn, nghĩa là chương trình của bạn đợi hạt nhân quay trở lại mã của bạn
Hạt nhân thực hiện thao tác I/O cơ bản trên thiết bị vật lý được đề cập [đĩa, card mạng, v.v. ] và trả lời cuộc gọi tòa nhà. Trong thế giới thực, kernel có thể phải thực hiện một số việc để đáp ứng yêu cầu của bạn, bao gồm chờ thiết bị sẵn sàng, cập nhật trạng thái bên trong của thiết bị, v.v. , nhưng là một nhà phát triển ứng dụng, bạn không quan tâm đến điều đó. Đó là công việc của kernel

chặn so với. Cuộc gọi không chặn

Bây giờ, tôi vừa nói ở trên rằng các tòa nhà chọc trời đang chặn, và điều đó đúng theo nghĩa chung. Tuy nhiên, một số cuộc gọi được phân loại là "không chặn", có nghĩa là hạt nhân nhận yêu cầu của bạn, đặt nó vào hàng đợi hoặc bộ đệm ở đâu đó, sau đó trả về ngay lập tức mà không cần đợi I/O thực sự xảy ra. Vì vậy, nó chỉ “chặn” trong một khoảng thời gian rất ngắn, chỉ đủ lâu để xử lý yêu cầu của bạn

Một số ví dụ [về cuộc gọi tòa nhà của Linux] có thể giúp làm rõ. - read[] là một cuộc gọi chặn - bạn chuyển cho nó một thẻ điều khiển cho biết tệp nào và bộ đệm của nơi gửi dữ liệu mà nó đọc và cuộc gọi trả về khi có dữ liệu ở đó. Lưu ý rằng điều này có lợi thế là đẹp và đơn giản. -

1 và

2 lần lượt là các cuộc gọi cho phép bạn tạo một nhóm bộ điều khiển để nghe, thêm/xóa bộ xử lý khỏi nhóm đó rồi chặn cho đến khi có bất kỳ hoạt động nào. Điều này cho phép bạn kiểm soát hiệu quả một số lượng lớn thao tác I/O bằng một luồng duy nhất, nhưng tôi đang vượt lên chính mình. Điều này thật tuyệt nếu bạn cần chức năng này, nhưng như bạn có thể thấy, nó chắc chắn phức tạp hơn để sử dụng

Điều quan trọng là phải hiểu thứ tự độ lớn của sự khác biệt về thời gian ở đây. Nếu lõi CPU đang chạy ở tốc độ 3GHz, thì CPU có thể thực hiện mà không cần tối ưu hóa, thì nó đang thực hiện 3 tỷ chu kỳ mỗi giây [hoặc 3 chu kỳ mỗi nano giây]. Một cuộc gọi hệ thống không chặn có thể mất khoảng 10 giây để hoàn thành chu kỳ - hoặc “tương đối vài nano giây”. 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 của bộ xử lý, bộ đệm 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 ngữ cảnh

Với tôi cho đến nay? . Hãy xem một số ngôn ngữ phổ biến làm gì với những công cụ này và rút ra một số kết luận về sự cân bằng giữa tính dễ sử dụng và hiệu suất… và các mẩu tin thú vị khác

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, thì đâ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 đánh giá cao nó, nó đã làm cho các trang web động trở nên 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 quy trình 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

3 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["//example.com/example-microservice"]].openConnection[];
	InputStream netIs = urlConnection.getInputStream[];

	// some more blocking network I/O
out.println["..."];
}

0 bằng PHP và dưới mui xe, nó thực hiện cuộc gọi tòa nhà read[] và chờ kết quả

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

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. Thuận lợi? . Điều 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["//example.com/example-microservice"]].openConnection[];
	InputStream netIs = urlConnection.getInputStream[];

	// some more blocking network I/O
out.println["..."];
}

Vì phương thức

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["//example.com/example-microservice"]].openConnection[];
	InputStream netIs = urlConnection.getInputStream[];

	// some more blocking network I/O
out.println["..."];
}

2 của chúng tôi ở trên tương ứng với một yêu cầu và được chạy trong luồng riêng của nó, thay vì một quy trình riêng cho từng yêu cầu yêu cầu bộ nhớ riêng, chúng tôi có một luồng riêng. Điều này có một số đặc quyền thú vị, như có thể chia sẻ trạng thái, dữ liệu được lưu trong bộ nhớ cache, v.v. giữa các luồng vì chúng có thể truy cập vào bộ nhớ của nhau, nhưng tác động đến cách nó tương tác với lịch trình vẫn gần giống với những gì đang được thực hiện trong ví dụ PHP trước đó. Mỗi yêu cầu nhận được một luồng mới và các thao tác I/O khác nhau sẽ chặn bên trong luồng đó cho đến khi yêu cầu được xử lý hoàn toàn. Các luồng được gộp lại để giảm thiểu chi phí tạo và hủy chúng, tuy nhiên, hàng nghìn kết nối có nghĩa là hàng nghìn luồng không tốt cho bộ lập lịch biểu

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ó đượ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ó sẵn 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 kịch bản 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ó nguyên tắc giống hệt nhau. 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. Under the hood, the reason for it has a lot more to do with how the V8 JavaScript engine [Chrome’s JS engine that is used by Node] is implemented 1 than anything else. The JS code that you write all runs in a single thread. Think about that for a moment. Đ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["//example.com/example-microservice"]].openConnection[];
	InputStream netIs = urlConnection.getInputStream[];

	// some more blocking network I/O
out.println["..."];
}

3 trong ví dụ trên đang sử dụng các chu kỳ CPU bên trong luồng chính duy nhất của bạn. This means that if you have 10,000 connections, that loop could bring your entire application to a crawl, depending on how long it takes. Each request must share a slice of time, one at a time, in your main thread

The premise this whole concept is based on is that the I/O operations are the slowest part, thus it is most important to handle those efficiently, even if it means doing other processing serially. This is true in some cases, but not in all

The other point is that, and while this is only an opinion, it can be quite tiresome writing a bunch of nested callbacks and some argue that it makes the code significantly harder to follow. 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

We’re back again to the trade-offs. The Node model works well if your main performance problem is I/O. However, its achilles heel is that you can go into a function that is handling an HTTP request and put in CPU-intensive code and bring every connection to a crawl if you’re not careful

Tự nhiên không chặn. Go

Before I get into the section for Go, it’s appropriate for me to disclose that I am a Go fanboy. 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ó

That said, let’s look at how it deals with I/O. One key feature of the Go language is that it contains its own scheduler. Instead of each thread of execution corresponding to a single OS thread, it works with the concept of “goroutines. ” And the Go runtime can assign a goroutine to an OS thread and have it execute, or suspend it and have it not be associated with an OS thread, based on what that goroutine is doing. Each request that comes in from Go’s HTTP server is handled in a separate Goroutine

The diagram of how the scheduler works looks like this

Under the hood, this is implemented by various points in the Go runtime that implement the I/O call by making the request to write/read/connect/etc. , put the current goroutine to sleep, with the information to wake the goroutine back up when further action can be taken

In effect, the Go runtime is doing something not terribly dissimilar to what Node is doing, except that the callback mechanism is built into the implementation of the I/O call and interacts with the scheduler automatically. 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 Goroutines 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ó. The result is code like this

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 tôi đ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. ” Non-blocking I/O is used for all of the important things, but your code looks like it is blocking and thus tends to be simpler to understand and maintain. The interaction between the Go scheduler and the OS scheduler handles the rest. It’s not complete magic, and if you build a large system, it’s worth putting in the time to understand more detail about how it works; but at the same time, the environment you get “out-of-the-box” works and scales quite well

Go may have its faults, but generally speaking, the way it handles I/O is not among them

Lies, Damned Lies and Benchmarks

It is difficult to give exact timings on the context switching involved with these various models. 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

For each of these environments, I wrote the appropriate code to read in a 64k file with random bytes, ran a SHA-256 hash on it N number of times [N being specified in the URL’s query string, 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["//example.com/example-microservice"]].openConnection[];
	InputStream netIs = urlConnection.getInputStream[];

	// some more blocking network I/O
out.println["..."];
}

4] and print the resulting hash in hex. I chose this because it’s a very simple way to run the same benchmarks with some consistent I/O and a controlled way to increase CPU usage

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

First, let’s look at some low concurrency examples. Running 2000 iterations with 300 concurrent requests and only one hash per request [N=1] gives us this

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

It’s hard to draw a conclusion from just this one graph, but this to me seems that, at this volume of connection and computation, we’re seeing times that more to do with the general execution of the languages themselves, much more so that the I/O. Note that the languages which are considered “scripting languages” [loose typing, dynamic interpretation] perform the slowest

But what happens if we increase N to 1000, still with 300 concurrent requests - the same load but 100x more hash iterations [significantly more CPU load]

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

All of a sudden, Node performance drops significantly, because the CPU-intensive operations in each request are blocking each other. 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. [It’s worth noting that in PHP the SHA-256 implementation is written in C and the execution path is spending a lot more time in that loop, since we’re doing 1000 hash iterations now]

Now let’s try 5000 concurrent connections [with N=1] - or as close to that as I could come. Unfortunately, for most of these environments, the failure rate was not insignificant. Đố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. The higher the better

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. It’s a guess, but it looks like at high connection volume the per-connection overhead involved with spawning new processes and the additional memory associated with it in PHP+Apache seems to become a dominant factor and tanks PHP’s performance. Clearly, Go is the winner here, followed by Java, Node and finally PHP

While the factors involved with your overall throughput are many and also vary widely from application to application, the more you understand about the guts of what is going on under the hood and the tradeoffs involved, the better off you’ll be

In Summary

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. Not to mention that your code must be structured in a way that works with such environments; your “normal” PHP or Java web application usually will not run without significant modifications in such an environment

As a comparison, if we consider a few significant factors that affect performance as well as ease of use, we get this

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 [GoThreads]CóKhông cần gọi lại

Threads are generally going to be much more memory efficient than processes, since they share the same memory space whereas processes don’t. Combining that with the factors related to non-blocking I/O, we can see that at least with the factors considered above, as we move down the list the general setup as it related to I/O improves. 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

Even so, in practice, choosing an environment in which to build your application is closely connected to the familiarity your team has with said environment, and the overall productivity you can achieve with it. So it may not make sense for every team to just dive in and start developing web applications and services in Node or Go. Indeed, finding developers or the familiarity of your in-house team is often cited as the main reason to not use a different language and/or environment. Điều đó nói rằng, thời gian đã thay đổi trong mười lăm năm qua, rất nhiều

Hopefully the above helps paint a clearer picture of what is happening under the hood and gives you some ideas of how to deal with real-world scalability for your application. Vui vẻ nhập và xuất

thẻ

PHPJavaI/OGoNode. js

Freelancer? Find your next job.

Back-End Developer Jobs

View full profile

Brad Peabody

nhà phát triển

About the author

Brad likes to build and improve software that solves real-world business problems and creates a positive experience for users, as well as having a positive business impact for the organization. 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

Hire Brad

Comments

Patrick

Interesting comparison. One little 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 it even has async/await [even though that's just a wrapper around promises]

Patrick

Dimix

Nice article, I would like that you also include as part of Servlet technologies son non blocking IO technologies like 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. Uses a thread per core processor and takes both world advantages, Non Blocking IO / Async Calls and just a couple of threads. Trân trọng, Dimitri

Dimix

Greg

Srsly? . 4. 16; Apache v2. 4. 6 Your benchmark is unfair. You use newest version of node, java and go and oldest version of php and old apache. Use php 7. 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

Andriy

I would like to notice one thing. Each language has its own specific area of use. I am 100% sure that financial institution will not go with "non-blocking" languages even if they are "super-mega fast", because they need secure and consistent running cycle. 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

Roland Harrison

You forgot writing async functions in c# Imo a great approach, reads like. Blocking code buy runs asynchronous

Roland Harrison

You forgot writing async functions in c# Imo a great approach, reads like. Blocking code buy runs asynchronous

Samuel Lawson

You should run those benchmarks with PHP7 now that it has gained wider acceptance in enterprise software. 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

You should run those benchmarks with PHP7 now that it has gained wider acceptance in enterprise software. 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

bengine

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. Thank you

bengine

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

I am wondering, would you usually perform the hash operation within nodejs or wouldnt you write an interface for that since CPU intensive tasks are explicitly known to perform terribly in nodejs? how would nodejs compare in that case?

Qiong Wu

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 should show an improvement. but the results will be similar because of [as explained in depth in the article] PHP's IO blocking. Đ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

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. several 10x faster than the usual setup as pointed above. But requires a bit of installation and adjustments since that is not traditional PHP application anymore

Peter Kokot

Juan Pablo Carzolio

Thanks, Brad. Great read. I agree with some of the objections in other comments [Promises, PHP 7, etc. ], but the explanations are very good and the article informative. I wasn't familiar with Go and find the concept quite interesting. The benchmarks are useful to give a rough idea - the exact numbers are not really that relevant IMHO

Juan Pablo Carzolio

Stas Slesarev

Did not found any word on how Node. js is running in your benchmarks. Ý tôi là, bạn đã sử dụng phân cụm [e. g. run `pm2 start index. js -i 0` to use all CPUs] ? If not, then we could consider this benchmark as unfair for NodeJS, because Go uses all CPUs for his routines

Stas Slesarev

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]. This isn't my field, but I definitely understand it a helluva lot better than I did 20 minutes ago thanks to this. Cảm ơn đã dành thời gian để viết nó lên

Mike Critchley

phra

Use a nodejs cluster at least. How can you compare a multicore program with a single thread execution? Everybody uses nodejs clusters in production. This benchmark means nothing to me

phra

Use a nodejs cluster at least. How can you compare a multicore program with a single thread execution? Everybody uses nodejs clusters in production. This benchmark means nothing to me

Ruan Kovalczyk

Who is Everybody? I do not know him. ;]

Ruan Kovalczyk

Who is Everybody? I do not know him. ;]

xer0x

Great idea, that would be a good way to build a real-world Node app. This article would have been more transparent if the author had Fibonacci instead of SHA256 for this demo

xer0x

Great idea, that would be a good way to build a real-world Node app. This article would have been more transparent if the author had Fibonacci instead of SHA256 for this demo

Julius Koronci

Great article. pretty happy with the PHP results. because adding a few more servers to PHP is still cheaper than developing with node or java . ]

Julius Koronci

Great article. pretty happy with the PHP results. because adding a few more servers to PHP is still cheaper than developing with node or 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

phra

are you drunk or what?

phra

are you drunk or what?

phra

nhận xét rất hữu ích. chúc mừng. you are a real hero

phra

nhận xét rất hữu ích. chúc mừng. you are a real hero

Ruan Kovalczyk

Cảm ơn bạn

Ruan Kovalczyk

Cảm ơn bạn

nikos

why do u think so ?

nikos

why do u think so ?

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. True, promises can help with readability, but you still need a function that gets called back. 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

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

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

Alexander Roddis

Cái này

Alexander Roddis

Cái này

Brad

https. // tải lên. disquscdn. com/hình ảnh/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

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

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

Ồ. 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

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

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

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

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

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/benchmarks/

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/benchmarks/

Boban Petrović

Performance of PHP + Apache depends a lot on Apache optimisations for specific load, and PHP version and settings as well as opcode cache in use. So benchmark here is not relevant. Also, a lot of people talks about nginx + php-fpm , but all of my single php page tests showed that apache+mod_ssl performs ~10% better. The best general site results was witg nginx+apache+mod_ssl

Boban Petrović

Abraham Sanchez

This Article is amazing and so, so polemic as I can see in comments. xD Probably I'm agree with some php people, it should be tested with php7 and nginx. But this article helped me to understand a lot of things and however I'm still surprised about the power of Go. Thanks

Abraham Sanchez

Decebal Dobrica

Great job at describing I/O and love the idea of comparing them across languages. Benchmarks are always bound to be subjective, I wouldn't mind conflicting comments around here. This article has good insights into I/O models for people that maybe are not looking around because they're busy doing something else. For anyone trying to contest the benchmarks or re-take them docker hub has all of these 4 languages available in official containers, easy to run and easy to switch between versions

Decebal Dobrica

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

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

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. and actually some banks are starting to adopt PHP which is amazing. 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

kelunik

In fact, PHP supports non-blocking I/O as well. See https. //github. com/amphp/amp + https. //github. com/ampphp/aerys

kelunik

In fact, PHP supports non-blocking I/O as well. See https. //github. com/amphp/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

Rossen Hristov

What about ASP. NET?

Rossen Hristov

What about ASP. NET?

Jonathan Sterling

Ah yes, I'm wrong on the WordPress argument - you're right. That said, I think once you get passed the entry-level PHP developers that are making simple sites, and start looking at experienced PHP developers that can build something like Facebook, the costs start to equalize. I know the owner of a PHP shop in Leeds, England that always laments that he can't find good PHP developers. He said the vast majority of people that come in to interview can only make simple sites, not the enterprise-grade stuff his company develops. So whilst PHP can definitely work on an enterprise scale [as we see at Facebook, Wikipedia, and others], at that level the costs start to equal that of Java/C#/Go developers anyway [just look at what Facebook pays their employees]. For simpler stuff, I agree - no reason not to use PHP

Jonathan Sterling

umka

Oh. in my opinion subtitle "Lies, Damned Lies and Benchmarks" will be better title for whole article. It looks like set of examples from stackoverflow. I have multiple questions for author. - Why you use one machine for run benchmark and applications. Application and benchmark must be started on different units. - Why are you read whole file in your code for hashing, byte buffers will be better - Why you use HTTP for benchmarking? Simple console app is fair way for creating IO-benchmarks[no time spent for http-message parsing, start application server and many other things] - Why you don`t implement simple http-server for Java[as in Go and Node exmaples] and start using Tomcat? Junior developers can be confused after articles like that

umka

Niranjan Godbole

Go doesn't have callbacks and unlike java, its garbage collector is optimised for low latency [ < 1 millisecond]. There are people already in finance using Go - Monzo bank

Niranjan Godbole

Go doesn't have callbacks and unlike java, its garbage collector is optimised for low latency [ < 1 millisecond]. There are people already in finance using Go - Monzo bank

Niranjan Godbole

Go is the clear winner here. . ]

Niranjan Godbole

Go is the clear winner here. . ]

Nabtron

So this is how DUMB top 3% developers selected by TopTal are. bravo

Nabtron

So this is how DUMB top 3% developers selected by TopTal are. bravo

Julius Koronci

yeah people are always an issue. finding a proper developer is always hard no matter the language. 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. the real benefit of PHP is not in the salaries. bud in development time and number of developers. PHP is just made for fast web development. and you can develop a website a hell lot faster than in Java or . asp. also finding proper developers in Java or . asp is harder than in PHP. If you have a bigger project, it is ok to have a few seniors and a lot of juniors. as far as seniors, they are hard to find but juniors is another thing. PHP is easy to learn and even easier to lead juniors to proper code. while with Java or . asp this is almost not possible. the languages by itself are very difficult, hard to learn. so having a team of juniors is more a hindrance than an asset. But to be fair the experience of your friend is a common one. everyone can start writing PHP overnight. even people with no programming experience can create a simple site within a week. this is good and bad at the same time. and there are hundreds of such people coming for appointments

Julius Koronci

Brad

Sadly it seems like the benchmarks have overshadowed the entire point of the article. Please read the article if you didn't. To answer your questions. "one machine", for practicality. Reading whole files and HTTP - because the point was to test I/O, not just the language performance itself. If anything, I should have removed the hashing. On the Java server I used Tomcat mainly because I felt it was more representative of an "average" Java deployment - I could be wrong on that, I didn't do a bunch of research on current Java deployment stats. And I'm not sure what the jab about SO copying is all about - those examples are intended to be as close as practically possible to equivalent functionality in each language, I wrote them as such

Brad

Jimin Hsieh

If you want to compare I/O intensive job in Java, no one would servlet. There is Netty,Vert. x, and Akka

Jimin Hsieh

If you want to compare I/O intensive job in Java, no one would servlet. There is Netty,Vert. x, and Akka

Miguel García López

Benchmarking and comparisons aside [insightful as they are however], I particularly appreciate the educating part on how sync. vs. async. I/O is finally driven to the OS. This is something I keep finding people are not aware of [nor care about. ] whilst it being crucial to understanding it all. As already pointed out, for the Java world there is the Vert. x project [built on top of Netty for async. I/O] I definitely recommend taking a look into. Thanks for the post

Miguel García López

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

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

Noir Alsafar

Can you post your source code that you benchmarked? It'd be helpful to see that you setup your test servers optimally and unbiased

Noir Alsafar

Can you post your source code that you benchmarked? It'd be helpful to see that you setup your test servers optimally and unbiased

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 Abrazhaev

Bred, pleasu update your article with php7. 1 + php-fpm + nginx results. It's a shame for you and harm your reputation as specialist to post results for so old php 5. 4 version with apache =/

Oleg Abrazhaev

Bred, pleasu update your article with php7. 1 + php-fpm + nginx results. It's a shame for you and harm your reputation as specialist to post results for so old php 5. 4 version with apache =/

Brad

Oleg, there are many, many different configurations possible for all four languages discussed. As mentioned elsewhere the PHP and Apache versions I used are the default that come with the latest CentOS. I think it would be very constructive to do further benchmarks with other common scenarios and link to them from here. If someone does a comprehensive enough set I'm sure I can get the main article updated to include a link to it, otherwise just include the link the comments. But this is unfortunately not something I have time to work on. The code I used is here. https. //peabody. io/post/server-env-benchmarks/ Please feel free to contribute your own comparisons

Brad

Noir Alsafar

You setup the node. js server wrong. You blocked the thread by using a sync version of sha256. You should use the vanilla native modules that come with Node. js to actually perform the test, and use you should use the async version, not one that blocks the event loop. You know that. You should rerun your numbers. Your post is phenomenal except for this part. Happy to help if you if you want me to send you source code?

Noir Alsafar

Oleg Abrazhaev

Hãy nhìn vào điểm chuẩn này. I think this is the most accurate and well-known one https. //www. techempower. com/benchmarks/#section=data-r14&hw=ph&test=query in latest round 14 PHP raw faster than raw go in multiple queries and fortunes benchmarks. This benchmark is reliable and done right. Your benchmark doesn't make sense if you took versions from different years for all languages. It's not accurate, it compares nothing, and if you will look at the comments - many people think the same. 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ì. You see what I'm telling you about? This article in a current state only harms your reputation in all languages in which it translated. 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 Abrazhaev

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 đó. I'm happy to see links to other information that provides other comparisons and I appreciate your time in describing the situation, and to a degree I agree with you, but again, I won't be updating the article benchmarks. 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 đó. I think that's clear to anyone objectively looking at it. 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

Oleg Abrazhaev

It makes sense, thanks for the clarification. 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. Their claims to add cluster or to use NIO looks like an addition and possible improvement. But with PHP it completely screwed up, we are not even talking about additions there. PHP version in "the latest CentOS" was always outdated. 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. Also, we have some famous choices to install latest PHP on OS with an outdated package. đó 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 I don't know about the same sources for yum world, I'm a mostly apt user, but googling by "php7 centos" gives me in 5 sec a solution with only one additional command to yum [install rpm first]. 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. Bởi vì đối với tôi, với tư cách là một lập trình viên, việc tôi cần làm việc với các phiên bản mới nhất là điều hiển nhiên và hiển nhiên. Tuy nhiên, xem xét phần giải thích của tôi ở trên, không có lý do thực sự nào để không dành 10 phút để thực hiện nghiên cứu tối thiểu và cài đặt các phiên bản mới nhất. That's the main issue here and exactly this factor harms this article the most

Oleg Abrazhaev

php7 đã cải thiện gần như gấp đôi hiệu suất của nó so với php5. 6 như vậy, chắc chắn chúng ta sẽ thấy những kết quả khác nhau. 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 Abrazhaev

Có nguồn của anh ấy https. //peabody. io/bài đăng/máy chủ-env-điểm chuẩn/

Oleg Abrazhaev

Có nguồn của anh ấy https. //peabody. io/bài đăng/máy chủ-env-điểm chuẩn/

Oleg Abrazhaev

Nói chung, bạn đúng và kết quả sẽ không khác lắm với PHP 7. Nhưng điều vi phạm thẩm quyền và ý nghĩa của bài viết này không phải là phiên bản của PHP, mà nó cho thấy rằng tác giả đã không dành thời gian chuẩn bị cho bài viết này. Thực tế này làm tổn hại đến quyền lực và danh tiếng của tác giả. Đó là lý do tại sao tốt hơn là sử dụng các phiên bản mới nhất. Và sẽ không có bất kỳ tranh luận nào trong các bình luận [mà hiện tại có khoảng 50% tất cả các bình luận ở đây và dưới bản dịch tiếng Nga của bài viết này có cùng tình huống]. Chúng tôi là lập trình viên, kỹ sư và đây là đối tượng mục tiêu của tác giả. Và khán giả này thích khi mọi thứ được thực hiện một cách thông minh, chính xác và đúng kỹ thuật

Oleg Abrazhaev

Filip Petkovski

Bài viết hay, cảm ơn bạn đã đầu tư thời gian và công sức. Tuy nhiên, tôi phải nói rằng tôi đã rùng mình khi thấy thiết lập PHP của bạn. Your workflow was testing Apache, not PHP performance . ] Đây cũng là một cách thực hành tốt để đặt nhãn trên trục biểu đồ của bạn để chúng có thể được diễn giải dễ dàng hơn

Filip Petkovski

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

Hướng dẫn tuyệt vời, rất tuyệt vời và trôi chảy. thanks

Dan Dollins

Hướng dẫn tuyệt vời, rất tuyệt vời và trôi chảy. thanks

John Robie

Không sử dụng PHP7 và thậm chí không đề cập đến Elixir?

John Robie

Không sử dụng PHP7 và thậm chí không đề cập đến Elixir?

Marcin K

Node process relatively light. 50mb khi khởi động và tối đa 1. Tối đa 4GB do V8 áp đặt, tùy thuộc vào việc mã của bạn có đang lạm dụng GC hay không. Trên máy 4x Core, bạn nên có 8GB ram và bắt đầu nút với pm2 https. //github. com/Unitech/pm2 pm2 start app. js -i 4 Tôi đồng ý rằng, những điểm chuẩn này là vô nghĩa. They also do not test real life applications. fetching something from DB would be more suitable test. Trong ứng dụng loại CRUD, có thể nút sẽ có cường độ đặt hàng nhanh hơn PHP

Marcin K

Wasin Thonkaew

Cảm ơn vì bài viết. Nó soi sáng cho tôi, và tôi có thể tìm thấy nó sớm hơn. Mặc dù khá bất ngờ với kết quả của nodejs nhưng mình biết hiện tại mình cần sử dụng cluster khi chạy nodejs. Cảm ơn vì bài viết. Tôi có một câu hỏi mặc dù. Để thử nghiệm, cách bạn mô phỏng yêu cầu đồng thời?

Wasin Thonkaew

Steven Sagaert

Tôi nghĩ thiết lập Java không phải là hiện đại nhất. Bên cạnh "chặn io trong luồng" cổ điển đó, tôi muốn xem các kiến trúc máy chủ dựa trên JVM hiện đại hơn như các kiến trúc dựa trên Akka [Java hoặc Scala] hoặc Vert. x [một số ngôn ngữ JVM] hoặc Kotlin coroutines. Tôi cũng muốn xem các máy chủ web Erlang và Elixir Phoenix trong điểm chuẩn và. Net [với async/await, orléans framework]

Steven Sagaert

Declan Nnadozie

Tất cả đều giống nhau, bạn TỐT. -p, từ những gì tôi có thể thấy ở đây, PHP và Java có thể không có nút linh hoạt. 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

Adam Patterson

It comes down the the right tool for the job. Nếu bạn đang xây dựng một API thì có lẽ Python, Go hoặc Node sẽ hợp lý. Nhưng nếu bạn điều chỉnh IO cao trên một trang web thì bạn cần xem xét các hệ sinh thái cho các khung trưởng thành, tích hợp các nhóm giao diện người dùng và người dùng cuối. Tôi cá là 9/10 bạn sẽ có giao diện người dùng PHP. Có thể bạn đang xây dựng một ứng dụng web, nhưng một lần nữa, bạn cần giải quyết những lo ngại đó. Brad đã đề cập đến điều này nhưng loại nhân tài nào bạn có thể thu hút và giữ lại trong khu vực của mình, loại chi phí nào liên quan đến những môi trường này. Nếu bạn đang sử dụng IO thì có thể bạn có một số dạng bộ nhớ đệm proxy hoặc bộ cân bằng tải hoặc cả hai. I don't think you can look at a languages numbers and make a sound judgment call

Adam Patterson

Álvaro Urbaez

Sẽ rất thú vị khi xem bạn có cấu hình nào trong nhóm luồng trong thử nghiệm Java, đó là một tham số quan trọng để đối mặt với một loạt lưu lượng truy cập trong ứng dụng Java. Vì vậy, tôi nghĩ rằng những bài kiểm tra này thực sự có thể cải thiện được, nhưng ít nhất chúng cũng đưa ra cái nhìn về vấn đề này. Cảm ơn

Álvaro Urbaez

Michal Boška

Liên quan đến java, hãy xem https. //www. khung chơi. com/ hoặc http. //đỉnh. io/ . Ngày nay, không có gì lạ khi viết mã IO không chặn trong Java, có tất cả các lợi ích của xử lý IO không đồng bộ [chỉ yêu cầu nhiều luồng như lõi CPU] và cả lợi ích của đa luồng [có thể chia sẻ cấu trúc dữ liệu bất biến trong một quy trình, . x bằng Java [thay vì chặn thông số kỹ thuật của servlet]

Michal Boška

có tính axit

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

có tính axit

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

HaydenJames

Cộng với việc bắt đầu với PHP 5. 5+opcache is enabled by default. So PHP 7 + opcache would be more like 5x faster than what was benched above. Kỳ lạ là họ sẽ không còn hỗ trợ PHP 5. 4 vào năm 2017, nhưng có ý nghĩa vì nó chậm nhất. Đây là lý do tại sao bạn chỉ nên tin vào tiêu chuẩn của riêng bạn haha

HaydenJames

Bình Thành Nguyễn

Thanks, nice post

Bình Thành Nguyễn

Thanks, nice post

người đánh cá

Và tôi cũng đang tự hỏi ai còn dùng apache prefork với php mod nữa không?

người đánh cá

Và tôi cũng đang tự hỏi ai còn dùng apache prefork với php mod nữa không?

Maxim Kuderko

PHP7. x FPM với các công nhân được chia sẵn + opcache + nginx được định cấu hình đúng trên cpu mã bốn có thể tiến xa hơn 5k rps

Maxim Kuderko

PHP7. x FPM với các công nhân được chia sẵn + opcache + nginx được định cấu hình đúng trên cpu mã bốn có thể tiến xa hơn 5k rps

Charlie

Có vẻ như tác giả đã chọn 5. 4. 16 vì nó được đóng gói trong RedHat/Oracle/CentOS/Scientific Linux v7. # vòng/phút -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 Tôi không nghĩ rằng Node hoặc Go hoàn toàn không được đóng gói, nhưng có thể có sẵn trong EPEL. RH7 gói hai JRE. # vòng/phút -qa. grep ^java . sắp xếp 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

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

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

Totally right, this benchmark does not even speak about clustering node. 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

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

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. Nó không phải là tùy chọn mặc định để làm việc với Java [nó đã phổ biến từ nhiều năm trước]. 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 đã có sự cải thiện hiệu suất đáng kể sau phiên bản 8. But you're using v6

Ahmad Samiei

Fab

Not even a mention of Elixir/Erlang ?? Wtf

Fab

Not even a mention of Elixir/Erlang ?? Wtf

Dustin Deus

Xin chào, tôi muốn xem Node 9 hoạt động như thế nào [TurboFan] và sau đó bạn cũng có thể sử dụng mô-đun Crypto gốc

Dustin Deus

Xin chào, tôi muốn xem Node 9 hoạt động như thế nào [TurboFan] và sau đó bạn cũng có thể sử dụng mô-đun Crypto gốc

Grant Jenks

Python comparison at https. //gist. github. com/grantjenks/dacc0a1e7fa9a08264439b9c6a05ec5b Kết quả Python thực sự tốt. 5,347 requests per second for Python vs 6,856 for Golang. Tôi mong đợi nhiều hơn từ Golang. Tôi đoán là điểm chuẩn bị giới hạn bởi CPU nên toàn bộ thời gian dành cho việc đọc tệp và băm nó. Đối với Python, tất cả điều đó xảy ra trong mã C được tối ưu hóa

Grant Jenks

kenton_2233

Thế còn WebSockets cho PHP [http. //ổ cắm. tôi/] ?

kenton_2233

Thế còn WebSockets cho PHP [http. //ổ cắm. tôi/] ?

Paco Meraz

Ikr, không sử dụng Elixir/Erlang sẽ xé nát những thứ khác. Cũng không có ruby, không có Python. không có gì

Paco Meraz

Ikr, không sử dụng Elixir/Erlang sẽ xé nát những thứ khác. Cũng không có ruby, không có Python. không có gì

Rus Brushkoff

nodejs có async/await không chặn. Có vẻ như các bài kiểm tra tổng hợp của bạn không biết về điều này. https. // stackoverflow. com/câu hỏi/46004290/will-async-await-block-a-thread-node-js Vì vậy, người viết bài kiểm tra gian lận của bạn phải đọc phần sau trước. https. //www. w3. org/TR/workers/ Và cố gắng viết lại các bài kiểm tra JS cho phù hợp, với nội dung như. https. //www. npmjs. com/package/webworker-threads Go có thể so sánh với JS chỉ bằng cách gian lận kém

Rus Brushkoff

Ellina Bereza

PHP là lý tưởng để triển khai các dự án thực hiện tuần tự và sử dụng tích cực cơ sở dữ liệu quan hệ. NodeJS là cách tốt nhất để tạo microservice và giải quyết vấn đề dựa trên mô hình sự kiện. https. //applikeysolutions. com/blog/node-js-vs-php-for-server-side-Development

Ellina Bereza

Richard A

PHP5. 4 từ 2012-2013 Và Apache so với phần còn lại. Cuộc chiến công bằng. Tại sao không Php 7. 1 Và Nginx?

Richard A

PHP5. 4 từ 2012-2013 Và Apache so với phần còn lại. Cuộc chiến công bằng. Tại sao không Php 7. 1 Và Nginx?

giuseppe d

Đối với tỷ lệ yêu cầu cao, bạn không bao giờ nên sử dụng một ứng dụng phụ trợ php duy nhất [nó không được thiết kế để làm điều đó]. Bạn nên sử dụng HHVM. Dù sao, cảm ơn vì lời giải thích rõ ràng

giuseppe d

Sarath Uch

Tôi nhận ra rằng Go là một mã được biên dịch và nó là một ngôn ngữ siêu tuyệt vời;

Sarath Uch

Tôi nhận ra rằng Go là một mã được biên dịch và nó là một ngôn ngữ siêu tuyệt vời;

Kolja Kutschera

Công bằng mà nói, hãy sử dụng nodejs với phân cụm gốc của nó để tận dụng tất cả cpus giống như các cpus khác và hơn là chạy lại điểm chuẩn. Hãy sửa bài này. D

Kolja Kutschera

Jonas Steinberg

Tôi không thể nói về thuốc tiên, nhưng tôi nghĩ Ruby và Python sẽ thua một cách dễ dàng. Phân tích tốt [nói chung, tôi cảm thấy tốt hơn cái này] ở đây [thiết lập điểm chuẩn có vẻ tốt hơn và rõ ràng hơn]. https. //www. linkin. com/pulse/ruby-vs-php-python-simple-microservice-performance-comparison-per/

Jonas Steinberg

Phần giải thích tôi thấy rất sâu sắc, đặc biệt, tin hay không, từ góc độ hoạt động. Nhóm của tôi gần đây đã triển khai ELK trên quy mô lớn và về cơ bản, lần đầu tiên chúng tôi nhận thấy rằng việc điều chỉnh luồng, IOPS, thông số kỹ thuật của máy chủ, v.v. thực sự rất quan trọng ở quy mô lớn. Và phần lớn những gì bạn trình bày ban đầu bổ sung thêm cái nhìn sâu sắc cho những gì tôi đã tìm thấy cho chính mình. tôi phải nói mặc dù. bạn thua tôi ở điểm chuẩn. Và ý tôi không phải là những tranh luận về táo/cam/tùy chọn dường như đang ảnh hưởng đến những người khác, mà thực tế là, ít nhất là đối với tôi, bạn đã không giải thích rõ ràng về thiết lập điểm chuẩn của mình. Tôi nghĩ lý do tại sao có quá nhiều lời chỉ trích trong các bình luận là vì đây có thể là một phần phân tích tuyệt vời, nhưng cuối cùng lại trở nên khá tầm thường, điều đó thật đáng thất vọng. Nhưng tôi nghĩ lần tới bạn sẽ làm được

Jonas Steinberg

Ngoài ra, theo https. //www. công nghệ. com/benchmarks/#section=data-r15&hw=ph&test=fortune&b=2&s=1&l=gcrv5b Hiệu suất vượt trội của NodeJS Tăng 200% đối với các truy vấn cơ sở dữ liệu khá điển hình và phản hồi của khách hàng. Các thiết lập * rất * giống nhau

Jonas Steinberg

Ezequiel Valenzuela

Cảm ơn bạn đã thêm Python vào danh sách. Sau khi xem "ý chính" của bạn [và các nhận xét khác ở đây], tôi muốn nói rằng có thể khung và thiết kế tốt nhất [dành cho Python] vẫn chưa được đưa ra. cơn lốc xoáy + một nhóm chủ đề. Mã sẽ không thực sự lớn như vậy và nó sẽ có cơ hội thực hiện việc băm song song [vì khóa Python sẽ được giải phóng ngay trước khi thực hiện "băm" ở mức độ thấp], vì vậy nó sẽ có lợi cho việc thực hiện song song.

Ezequiel Valenzuela

Grant Jenks

Tôi chắc rằng mã Python có thể được tạo nhanh hơn cũng như các giải pháp khác cũng có thể được tạo nhanh hơn. Nhưng vấn đề là chỉ ra giải pháp đơn giản có tính cạnh tranh nhanh như thế nào. Giải pháp của tôi đã sử dụng một nhóm công nhân để xử lý các yêu cầu song song và hoàn toàn vượt qua các vấn đề với khóa trình thông dịch toàn cục Python. Nó ở dòng cuối cùng có ghi “workers=8”

Grant Jenks

Ezequiel Valenzuela

tôi trân trọng điều đó. Tuy nhiên, khi bạn đang "xử lý" một máy chủ http mà bạn đang xử lý các yêu cầu bằng ngôn ngữ/khung lập trình đã chọn [Python], có 8 "công nhân", với mỗi người trong số họ hoạt động [hầu hết] đồng bộ, sẽ không hoạt động. . Ngoài ra, ngay cả trong trường hợp mỗi "công nhân" được chỉ định một luồng CPU [giả sử bạn có 8 luồng CPU để xử lý], mỗi người trong số họ có thể bận thực hiện công việc chuyên sâu của CPU [chẳng hạn như tính toán hàm băm] thay vì bảo dưỡng . Về vấn đề đó, quan điểm của tôi là cơn lốc xoáy sẽ xử lý I/O cho từng kết nối mạng đó [rất] hiệu quả, đồng thời giải phóng CPU để thực hiện công việc sử dụng nhiều CPU. Theo cách đó, về cơ bản, bạn nên dành phần lớn thời gian của CPU để thực hiện việc băm [mà [AFAIK] nên được triển khai trong C bởi thư viện chuẩn Python], đây là một chi phí không thể tránh khỏi. Tôi đoán rằng Python chỉ nên hoạt động kém hơn một chút so với ngôn ngữ/khung công tác gốc [hoặc JIT-ed], để giải thích cho việc thực thi mã byte Python. Có thể việc các yêu cầu cuối cùng đang chờ được phục vụ [vì chúng đang chờ trong hàng đợi "công nhân"] chỉ khiến những yêu cầu đó hoạt động kém và những yêu cầu khác [những yêu cầu đang được phục vụ] hoạt động rất tốt [vì chúng được hưởng lợi từ việc có CPU cho chính chúng] . Nhưng tôi không chắc về điều đó. Điều đó có thể cần một số phép đo, trước khi đưa ra phán quyết

Ezequiel Valenzuela

Grant Jenks

Tôi đã thêm "japronto" vào phần so sánh nằm trên các khung máy chủ web Python. 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. Nhưng mỗi công nhân đó đều sử dụng async-IO [không liên quan đến điểm chuẩn của bạn] và trình phân tích cú pháp HTTP nhanh

Grant Jenks

kevin_lee

bạn có thể chia sẻ mã nguồn bạn đã sử dụng để chạy các thử nghiệm này không

kevin_lee

bạn có thể chia sẻ mã nguồn bạn đã sử dụng để chạy các thử nghiệm này không

Dmitry Sokulev

Sử dụng curl_multi_exec với php sẽ đánh bại tất cả những thứ này

Dmitry Sokulev

Sử dụng curl_multi_exec với php sẽ đánh bại tất cả những thứ này

Namjith Aravind

Ứng dụng của chúng tôi được xây dựng trên PHP 7 và những gì chúng tôi có thể nhận ra nút cổ chai thực sự là các cuộc gọi chặn [I/O] tới MySQL và Redis. Chúng tôi có thể quản lý với các kết nối liên tục vì PHP không có Nhóm kết nối [Kết nối liên tục sẽ đóng khi kết thúc vòng đời của quy trình], nhưng điều tôi muốn biết là, Có tính năng ngôn ngữ nào không [Go [Goroutine], Akka

Namjith Aravind

n0m1s

Hãy xem tiện ích mở rộng PHP có tên là swoole [1] và sau đó vứt bỏ nginx và Apache. -] Đây là một điểm chuẩn ví dụ với PHP swoole lau sàn bằng nodejs [2]. [1] https. //www. swool. com/chỉ mục. vi. 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

Namjith Aravind

Sử dụng với zend framework 2 có ổn không?

Namjith Aravind

Sử dụng với zend framework 2 có ổn không?

Gary Fry

Lời đầu tiên xin cảm ơn Brad đã bỏ thời gian nghiên cứu. Đưa ra một cái gì đó để mọi người tìm thấy và phản ứng có nghĩa là chúng tôi đang tìm kiếm kết quả đánh giá ngang hàng thực sự. Để mọi người cho bạn bất kỳ phản hồi nào là một lời khen. rất tốt. Rõ ràng là bạn không quen thuộc lắm với các sắc thái của tất cả các ngôn ngữ trong điểm chuẩn của mình, nhưng bạn có một bản năng tốt. Bạn đã đề cập "chúng tôi đang thấy nhiều lần liên quan đến việc thực thi chung của các ngôn ngữ, nhiều hơn nữa để I/O. ". Bạn đúng rồi. Trong trường hợp của Java, khi bạn khởi động mã Java, nó phải tải một lượng mã không đáng kể vào bộ nhớ từ hệ thống tệp trước khi bất kỳ mã nào được thực thi. Đó là một chi phí chung, là một yếu tố trong bất kỳ ngôn ngữ nào, vì vậy nếu bạn định thời gian cho nó từ trình bao, điều đó sẽ rất tệ, vì vậy, hy vọng rằng thời gian của bạn được lấy từ vùng mã, thay vì vùng tập lệnh. Java có một thứ gọi là trình biên dịch Just-in-time [JIT] tự tối ưu hóa các đường dẫn thực thi mã sau một số lần lặp lại trong một vòng lặp mã. Nếu bạn cho phép JVM khởi động [tôi nghĩ là 10 nghìn lần lặp lại] - https. // stackoverflow. com/questions/36370483/jvm-warmup-queries?rq=1, sau đó mọi thứ sẽ được nấu chín, hiệu suất khôn ngoan. Ngoài ra, bộ thu gom rác và cài đặt kích thước heap có thể được điều chỉnh để cải thiện hiệu suất Java. Không còn nghi ngờ gì nữa, GoLang và Node cũng sẽ có một con dao cải tiến hiệu suất của quân đội Thụy Sĩ. vì vậy chỉ cần nói. . -] Đưa mỗi ứng dụng đến một điểm tối ưu mà điểm chuẩn của bạn có ý nghĩa là một thách thức, nhưng rất xứng đáng với hành trình. Rõ ràng có nhu cầu cho công việc bạn đang làm, vì vậy hãy tiếp tục

Gary Fry

Santeri

Tôi hoàn toàn đồng ý với nhận xét này [thực sự đang tìm xem nó đã được đăng chưa]. Tác giả có lẽ không biết nhiều về tính năng mở rộng cơ bản của NodeJS và việc sử dụng phân cụm. Cực kỳ dễ dàng để quay các luồng cũng như tương đối đơn giản để thiết lập các quy trình con riêng biệt để xử lý các tác vụ tính toán khối nặng hơn. Việc sử dụng quy trình con Node để gửi một phép tính khoa học tới một trình thông dịch Python riêng biệt và chờ phản hồi cũng rất phổ biến. Nói chung, điều tôi muốn nói là việc sử dụng các tài nguyên cơ bản [CPU] hiệu quả hơn rất nhiều so với những gì được hiển thị ở đây

Santeri

davidris

Để so sánh này được công bằng, tôi hy vọng bạn đã sử dụng một nút. js, nếu không, bạn sẽ chạy mọi thứ trong một chuỗi. Ý tưởng của nút. js là bạn sẽ chạy bao nhiêu nút. js xử lý đồng thời khi bạn có lõi cpu. Tính năng này được tích hợp vào các gói cốt lõi của nút. js và được thực hiện đúng cách, bạn cần ít hơn 10 dòng mã để sử dụng nó mà không có bất kỳ thay đổi nào đối với mã nguồn của bạn. https. //nodejs. tổ chức/api/cụm. html

davidris

Natalya N

Đó là một bài viết rất toàn diện, cảm ơn vì công việc của bạn. Một số người nói rằng Node tốt hơn cho các ứng dụng trang đơn phức tạp vì chúng có đặc điểm khối lượng công việc I/O nặng. https. //softmedialab. com/blog/nodejs-vs-php/ Bạn nghĩ sao?

Natalya N

Lemuel Adane

tôi đồng ý

Lemuel Adane

tôi đồng ý

Lemuel Adane

Nhưng nếu bạn 'toe-toe' PHP7 với Go, Go vẫn sẽ thắng

Lemuel Adane

Nhưng nếu bạn 'toe-toe' PHP7 với Go, Go vẫn sẽ thắng

Robert Mennell

Tôi đã tìm thấy điều này vào năm 2018 như một kết quả tìm kiếm hàng đầu. Đừng đến đây. Điểm chuẩn này được viết quá tệ, nó thậm chí còn không vượt qua được bài kiểm tra "Có công bằng không" trong một thời gian dài. Chúng ta có thể gỡ cái này xuống được không?

Robert Mennell

Kıran Ali

Thế còn. net, tôi đoán nó đáng để đưa vào đây

Kıran Ali

Thế còn. net, tôi đoán nó đáng để đưa vào đây

James Suárez

ĐIỂM CHUẨN CỦA BẠN KHÔNG TỐT CHO NGƯỜI THẬT. Hầu hết mọi người nói rất tệ về việc sử dụng nhiều CPU trong Node vì chỉ có một luồng trong lõi của bạn. BUt sao không nói là Nodejs có cluster module. Với cấu hình tốt của cụm [một cụm cho mỗi lõi], có thể đánh bại hiệu suất gần giống như golang hoặc bất kỳ ngôn ngữ nào khác có hỗ trợ luồng cho điểm chuẩn của bạn. Tôi sẽ thử tạo điểm chuẩn bằng cách sử dụng cụm và sẽ thấy sự khác biệt rõ rệt

James Suárez

Bạn không cần bắt đầu phân cụm từng yêu cầu, mở một cụm cho từng lõi ngay từ đầu, có thể đánh bại hiệu suất của các ngôn ngữ khác mà bạn đã sử dụng để đo điểm chuẩn. Tôi luôn thấy mọi người cho rằng nodejs không tốt cho việc sử dụng nhiều cpu, nhưng có thực sự như vậy không?

James Suárez

Điều tương tự đối với 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. Với cụm NodeJs, bạn sẽ nhận được ít nhất gấp đôi hiệu suất, tùy thuộc vào lõi CPU

James Suárez

Brad

Cảm ơn tất cả các bạn đã cung cấp phản hồi mang tính xây dựng và thảo luận có ý nghĩa về chủ đề này. Cũng xin lưu ý rằng các phản hồi chủ yếu là tiêu cực/không mang tính xây dựng sẽ không giúp được gì cho bất kỳ ai. Tôi đã viết bài viết này để giúp cung cấp thông tin cho mọi người sử dụng trong các dự án của riêng họ, ra quyết định, v.v. - đó là điểm chính của bài viết. Ý kiến và phản hồi được chào đón. Nhưng tôi không nuôi troll

Brad

tôi J

viết tốt. Hiệu suất được đánh giá cao ngay từ đầu Go. Các ngôn ngữ như python và Ruby không nên được đề cập về IO không chặn. Nếu được thêm vào ngày mai, nó vẫn sẽ là một khái niệm được sao chép - không phải là một phần của ngôn ngữ chính; . Đối với ứng dụng hiệu suất quy mô cao, hãy sử dụng Go

tôi J

Hridyansh Thakur

làm thế nào về nhị phân?

Hridyansh Thakur

làm thế nào về nhị phân?

Harish Sivakumar

Này Brad, Vui lòng cung cấp một cái nhìn nhanh về hiệu suất của các cuộc gọi api còn lại với thời gian phản hồi yêu cầu cho các ngôn ngữ bên dưới Nút. js vs Django vs PHP vs Go vs Java[jsp hoặc serlvet thậm chí rmi] Cảm ơn trước, Trân trọng, Hariharan

Harish Sivakumar

John Robie

Đây dường như là một phản ứng phổ biến của Node. nhà phát triển js. Thiết lập phân cụm là mã bổ sung và để các nút trong cụm giao tiếp không phải là vấn đề nhỏ – chưa nói đến giao tiếp trên nhiều máy. Hãy đối mặt với nó, điểm mạnh của Node là nó làm mờ ranh giới giữa các nhà phát triển frontend và backend. Nhưng với tư cách là một lựa chọn phụ trợ hợp pháp, nó không phải là lý tưởng. Tôi sẽ chọn Elixir và Go over Node mỗi ngày trong tuần. Elixir có thể có hàng trăm nghìn yêu cầu đồng thời trên một máy mà không phải xử lý bất kỳ vấn đề quy mô theo chiều dọc nào. Dễ dàng mở rộng theo chiều ngang [các nút kết nối qua địa chỉ IP]. Và đó thậm chí còn chưa nói về cú pháp của JS, cú pháp này rất tệ [chỉ tốt hơn một chút so với cú pháp của PHP]

John Robie

khuôn mặt1m

Thực sự rất thích đọc bài viết của bạn cũng như bình luận phê bình của bạn. Cả hai đều rất nhiều thông tin

Roberto Spadim

php7 + len?

Marek Tenus

Nếu bạn sử dụng PHP, bạn nên sử dụng amp, Reac, pthreads hoặc swoolie. Nó cho phép bạn sử dụng các chủ đề và kết quả sẽ tốt hơn nhiều lần

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

Bạn sai rồi. Bạn đã bao giờ nghe nói về uvloop chưa? . e swoole] hoạt động ngang bằng với Node hoặc thậm chí tốt hơn

Fakhar Anwar

Từ góc độ kỹ thuật, Bạn đã bao giờ kiểm tra Bộ đệm không đồng bộ được biên dịch [Khung công tác PHP] chưa? . js và thi đấu Go-Lang. Với tính dễ học và tiết kiệm chi phí, tôi tin rằng Linux, PHP7 với Swoole sẽ cùng nhau tiến xa trong cuộc đua công nghệ. PLUS, từ góc độ kinh doanh, "Thông lượng" [Hiệu suất / Độ ổn định / Tốc độ] tỷ lệ thuận với Phần cứng máy tính [+ Vòng lặp sự kiện]. Để tranh luận, nếu Swoole PHP chiếm nhiều tài nguyên phần cứng hơn, người ta có thể nói "Phần cứng rẻ hơn nhiều so với chi phí Nhân sự / Phát triển liên quan đến Node. JS, Go-Lang và JAVA". Do đó, tính dễ học và tính sẵn có của các tài nguyên PHP ít tốn kém hơn khiến PHP giành chiến thắng. Bạn nghĩ thế nào về điều đó?

lửa cháy

Tôi không hiểu lập luận của bạn ở đây, bạn có thực sự biết cách mở rộng các ứng dụng không trạng thái không? . Đối với Kubernetes, đó chỉ là một sự kết hợp hoàn hảo. Tôi không nói rằng Go/Elixir không hoạt động tốt hơn đối với các tác vụ sử dụng nhiều CPU, nhưng tôi thực sự không hiểu lập luận của bạn. "Thiết lập phân cụm là mã bổ sung và để các nút trong cụm giao tiếp không phải là vấn đề nhỏ". Các tác vụ ràng buộc IO có thể được thực hiện dễ dàng trên NodeJS, năng suất [nói về npm ở đây] là một mức tăng rất lớn. Các tác vụ chuyên sâu về CPU có thể được thực hiện trong Rust, điều này giết chết mọi thứ mà bạn có thể tranh luận về hiệu suất trong Go/Elixir/Java ngoại trừ năng suất

John Robie

Tất nhiên là tôi biết cách thực hiện và tôi đã thực hiện bằng nhiều ngôn ngữ, bao gồm cả Elixir và Node trong k8s. Bạn có biết làm thế nào? . Trong thế giới thực, chỉ vì một ứng dụng "không trạng thái", không có nghĩa là nó bị cô lập hoàn toàn. Chẳng hạn, tạo một cụm các nút Elixir chia sẻ bộ đệm trong bộ nhớ hoặc sự hiện diện của kết nối ổ cắm [nhận Người dùng. 1 được kết nối trên Nút. A để trò chuyện với Người dùng. 2 trên nút. B] hoặc xử lý chuyển giao khi chấm dứt một nút. Chúng có thể không trạng thái, nhưng chúng vẫn được kết nối. Tất cả điều đó đều dễ dàng trong Elixir [phần lớn là do Mô hình diễn viên] và phức tạp trong Node [đó là lý do tại sao tôi thấy rất nhiều hướng dẫn về Node sử dụng Redis; điều này không cần thiết trong Elixir]. Chia tỷ lệ dọc trong Nút yêu cầu một cụm [ngay cả trong k8s]. Elixir tự động sử dụng tất cả các lõi có sẵn. Có nhiều lý do chính đáng để sử dụng Node, nhưng năng suất và hiệu suất không phải là lý do chính đáng, IMO

Giles Thomson

Bị thổi bay bởi hiệu suất của GO theo điểm chuẩn của bạn 4000 yêu cầu mỗi giây thật tuyệt vời. Tôi cho rằng quá trình biên dịch nền tảng trực tiếp sẽ luôn thực hiện diễn giải bất kể trình biên dịch Just-In-Time [JIT] xuất sắc của Java hoạt động như thế nào

Giles Thomson

Tôi không biết. Tôi nhớ đã thấy các điểm chuẩn chỉ ra rằng NIO hoạt động kém hơn so với việc chặn IO khi có liên quan đến thời gian phản hồi trên quy mô lớn. Trong khi thông lượng của NIO rõ ràng sẽ cao hơn, chu kỳ yêu cầu/phản hồi của từng hoạt động riêng lẻ được chứng minh là chậm hơn

stargt

Cảm ơn. bài viết hay. Tôi có thể dịch nó sang tiếng Hàn, nếu bạn không phiền? . disqus Nếu bạn ổn, tôi sẽ xuất bản nó trên blog của mình và để lại liên kết gốc

Brad

Tôi không có vấn đề với điều này

Leonardo Rojas

Alex Mills

Tôi đã sử dụng tất cả các ngôn ngữ này - nghĩa đen là tất cả. Tôi đã bắt đầu trên WAMP. Đi đến Java, Node, sau đó bắt đầu làm một số Golang. Không có cách nào PHP có thể theo kịp phần còn lại. Có gì đó không ổn ở đây. Bạn không thể tạo ra một quy trình mới cho mỗi yêu cầu và mong đợi nó sẽ theo kịp

OAH

người đàn ông đó là một địa ngục của một bài báo. Làm tốt lắm nhưng rất thích xem điểm chuẩn cho php 7. 4

artit91

Bạn đã quên sự thật quan trọng nhất. NodeJs là luồng an toàn và hãy sử dụng khóa ở mọi nơi. Với NodeJ, bạn sẽ không bao giờ gặp phải các sự cố khóa kỳ lạ và bạn thường mở rộng quy mô của nodejs và PHP ở cấp độ quy trình, vì vậy hãy bắt đầu nhiều quy trình để xử lý các yêu cầu. Điểm của bạn về hiệu suất luồng đơn không liên quan vì cả go và nodejs sẽ chạy một lõi [máy lõi kép tối đa] Về hiệu suất, đó là Java với cú pháp đẹp hơn được cho là

Fakhar Anwar

Điểm tốt. Và tôi hiểu bạn đến từ đâu. Một hàng dài các I/O không bị chặn có thể làm chậm đáng kể yêu cầu/phản hồi của từng cá nhân ngay cả khi thông lượng tổng thể sẽ cao hơn. Dựa trên suy đoán ở trên, "Hàng đợi dài của I/O không bị chặn" chỉ có thể tốt cho quá trình xử lý nền chạy riêng biệt với Yêu cầu/Phản hồi, cách khác là đối với thời gian Yêu cầu/Phản hồi của người dùng, nên có một cách để theo dõi kích thước của

Fakhar Anwar

Swoole trong PHP [Và các đồng quy trình trong Core-PHP] cho phép I/O không đồng bộ [Xử lý đồng thời trong một luồng]. Chúng nhanh hơn tối thiểu 8 lần so với Node. JS và Nhanh nhất [Có thể mở rộng và thông lượng cao hơn] cho đến nay với MySQL. Bạn không cần một Web Server riêng chạy để chạy Swoole

Fakhar Anwar

Ngay cả Swoole cho PHP [Phần mở rộng PHP được biên dịch C++] cũng là cha đẻ của Node. JS,. NET và Java. Ý tôi là nhanh hơn và có thông lượng cao hơn, đồng thời cho phép mô hình lập trình Async [Đồng thời/Phản ứng]

T. Todua

Không khách quan. Có gì đáng để so sánh với PHP, nếu không sử dụng PHP SWOOLE?

Boris Klesch

đó là quảng cáo Golang lol

Alexander Danilov

Bạn nên chạy nút trên mỗi lõi, không chỉ một nhóm. Lol, toptal, lol. Xấu hổ làm sao

lõi Epp

Theo tôi, các cuộc gọi lại ở phía máy chủ thực sự không tốt. Tôi sẽ không bao giờ sử dụng các chức năng không chặn trong các môi trường quan trọng. Ngay cả khi bạn cần tính toán song song, tôi không nghĩ rằng việc sinh ra một quy trình riêng biệt sẽ khiến bạn tốn nhiều bộ nhớ hơn so với việc rẽ nhánh một luồng trừ khi bạn có hàng tỷ người dùng và các luồng giúp bạn tiết kiệm hàng tỷ đô la mô-đun bộ nhớ, nhưng đây không phải là vấn đề với khối lượng lớn

Shakil Ahmed

NodeJS nên được chạy ở chế độ cụm. Xin lỗi, nhưng so sánh là thiếu sót

Fakhar Anwar

Tôi nghĩ rằng so sánh là sai lệch khi bạn đang so sánh công cụ PHP truyền thống [PHP-FPM] và PHP phiên bản 7. Theo nghiên cứu của tôi, Swoole [Hơn cả Async. PHP] có kiến trúc Đáng tin cậy hơn NodeJS và có hiệu suất cao hơn NodeJS, đồng thời chứa nhiều tính năng Mạng hơn cho IoT, Truyền phát sự kiện, Dịch vụ vi mô và Ứng dụng được kết nối, cùng với khả năng áp dụng tốt hơn [dễ sử dụng PHP]. Swoole là cấp sản xuất và sẵn sàng để sử dụng với PHP8. 0 JIT. Kiểm tra các điểm chuẩn của Techempower nơi nó hiển thị thấp hơn một chút so với Go nhưng có thứ hạng cao hơn nhiều so với NodeJS. Vì vậy, tôi coi Swoole [bằng PHP] là sự đánh đổi tốt nhất về Hiệu suất và Dễ sử dụng, đặc biệt dành cho các dịch vụ vi mô

Fakhar Anwar

Hiệu suất PHP. Nếu bạn muốn so sánh công việc chuyên sâu I/O trong PHP, không ai so sánh PHP-FPM với NodeJS. Có Swoole nhanh hơn ít nhất hai lần so với NodeJS và xấp xỉ. ngang bằng với Go-lang về thông lượng trong hầu hết các tiêu chuẩn được công bố phổ biến như TechEmpower và Benchmark Games. Kiến trúc tốt hơn của Swoole. Swoole có nhiều luồng phản ứng đảm bảo cân bằng tải cao hơn và tách biệt tác vụ sử dụng nhiều IO và tác vụ sử dụng nhiều CPU trong Worker Process và Task Worker Process tương ứng tạo nên một Kiến trúc đáng tin cậy hơn. Ngoài Tốc độ / Thông lượng, Swoole còn có nhiều tính năng / sức mạnh hơn NodeJS, ví dụ: bạn có thể khởi tạo Quy trình mới và có thể giao tiếp trực tiếp với Quy trình và/hoặc Hệ điều hành mới được tạo mà không cần cpu-/bộ nhớ- đó.

Harald

Tôi tình cờ thấy bài viết này vài năm sau đó, nhưng nó vẫn có vẻ phù hợp và tất nhiên là hữu ích. Cảm ơn bạn đã chia sẻ

Harald

OK, đối với Thế giới Java không cập nhật 100% vào năm 2021, bởi vì các công nghệ mới hơn như Quarkus, Micronaut hoặc GraalVM có thể làm tốt hơn

FirefoxGuru

Tôi chỉ muốn khởi chạy một máy chủ trên API GCP. 😂 Tôi đã học Java và PHP ở trường đại học khoảng 7 năm trước nhưng tôi biết Node và Go đang là những sản phẩm hot hiện nay. Tôi cũng muốn đoạn mã này chạy phía máy chủ. Cảm ơn bạn đã viết lên. . ]

kogi123

Tôi không biết cách đây 4 năm khi bài viết này được viết như thế nào, nhưng hiện tại PHP đã hỗ trợ luồng rất tốt và đang hoạt động. Các thư viện thường chưa sử dụng nó, bạn không có nó trong các gói php linux thông thường của mình nhưng nếu cần, nó có sẵn [mặc dù thông thường bạn cần tạo trình biên dịch PHP của riêng mình để kích hoạt nó]. Vì vậy, sử dụng nó, IO không chặn cũng có thể và tôi đang sử dụng nó trong máy chủ PHP của mình, mặc dù không xử lý yêu cầu vì tôi chưa bao giờ thực sự cần nó ở đó [tôi chỉ có một kết nối Cơ sở dữ liệu trong đó cho mỗi yêu cầu và hơn thế nữa sẽ chỉ gây phiền toái . Tôi chỉ đang sử dụng nó trong các quy trình nền PHP của mình và ở đó nó hoạt động khá tốt

Sergiu Petrica

"Và PHP cũng khét tiếng vì phá vỡ mọi thứ giữa các phiên bản" Wut?

lamer

Tất cả nền tảng được đánh giá đều có hỗ trợ IO không chặn. Nhưng điểm chính của bài viết là Go có hỗ trợ nội tại của non-blocking IO do có bộ lập lịch nội bộ bên trong

Matt

Điểm chuẩn vô nghĩa. Sử dụng máy 4 lõi với quy trình NodeJS đơn chống lại luồng PHP. Sinh ra cụm 4 quy trình NodeJS và nhân thông lượng lên nhiều lần khi CPU được bỏ chặn

Matt

Bất kỳ điểm chuẩn nào đối với nút trong máy đa lõi sử dụng một quy trình NodeJS duy nhất đều vô hiệu. Đó không phải là cách NodeJS hoạt động

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. "nhanh hơn tối thiểu 8 lần so với Node. JS" vui nhộn và hoàn toàn vô căn cứ. Điểm chuẩn nào?, cấu trúc triển khai nào? . Một quy trình NodeJS đơn lẻ không thể so sánh với bất kỳ mô hình thực thi đa luồng nào. 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. Không có công ty nghiêm túc nào bắt đầu lĩnh vực xanh PHP vào năm 2021

CharlES

Người đàn ông này, bất chấp sự khôn ngoan của mình, sửa đổi mọi thứ theo ý mình

Aron

Hãy thử với PHP 8 JIT với Swoole [IO không chặn đồng thời] hoặc tương tự với ReactPHP với PHP 8. 1 [IO không chặn không đồng bộ]. sự khác biệt gần như không đáng kể so với đi, đặc biệt là với Swoole [đánh bại NodeJS hàng dặm]

Dario Cangialosi

còn về "lời hứa" của ECMAScript "async/await" và ECMAScript ["lời hứa IS" hoạt động một mình và với cả async/await]

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 có tùy chọn tự phân tách thành các luồng khác nhau với mô-đun cụm như những người khác đã đề cập. Tuy nhiên, vấn đề là về nút, tác giả đã không đề cập rằng địa ngục gọi lại mà họ mô tả có thể dễ dàng khắc phục bằng cách sử dụng JavaScript hoặc Promise không đồng bộ. Nút cũng cung cấp các phiên bản đồng bộ của các chức năng xử lý tệp

PHP có chậm hơn nút JS không?

Tốc độ & Hiệu suất . js và PHP trực tiếp, Node. js thực thi nhanh hơn nhiều so với PHP .

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

Rõ ràng là Nút. js vượt trội về tốc độ , trong khi PHP có nhiều tài nguyên và hỗ trợ hơn. Mặc dù điều quan trọng là chọn ngôn ngữ phù hợp nhất với dự án của bạn, nhưng bạn nên nhớ rằng cuối cùng thì chúng cũng phục vụ cùng một mục đích. Đôi khi, không có lợi thế cực đoan nào khi chọn cái này hay cái kia.

JavaScript hay PHP cái nào nhanh hơn?

So sánh giữa PHP và JavaScript kết thúc với tỷ số từ 3 đến 5 – JavaScript đánh bại PHP . Cả hai ngôn ngữ đều khá tốt về hỗ trợ cộng đồng, khả năng mở rộng và các ứng dụng phù hợp với chúng. JavaScript chắc chắn hiệu quả hơn về tốc độ và tính phổ quát.

PHP có tốt hơn nút JS không?

Trong khi nói về PHP vs NodeJS, Node. js là ngôn ngữ lập trình không đồng bộ, hướng sự kiện và không chặn, trong khi PHP là ngôn ngữ lập trình đồng bộ. Điều này có nghĩa là nút. js là một lựa chọn tốt hơn để tăng tốc quá trình phát triển so với PHP

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

Cuộc gọi hệ thống

chặn so với. Cuộc gọi không chặn

lập kế hoạch

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

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

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

Tự nhiên không chặn. Go

Lies, Damned Lies and Benchmarks

In Summary

Comments

PHP có chậm hơn nút JS không?

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

JavaScript hay PHP cái nào nhanh hơn?

PHP có tốt hơn nút JS không?

Bài Viết Liên Quan

Toplist mới

Bài mới nhất

Chủ Đề