programming php

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

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

Qua

Brad Peabody

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

CHIA SẺ

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

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

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

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

System Calls

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

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

Blocking vs. Non-blocking Calls

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

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

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

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

lập kế hoạch

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

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

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

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

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

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

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

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

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

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

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

Yêu cầu HTTP đến từ trình duyệt của người dùng và truy cập máy chủ web Apache của bạn. Apache tạo một quy trình riêng cho từng yêu cầu, với một số tối ưu hóa để sử dụng lại chúng nhằm giảm thiểu số lượng nó phải thực hiện (việc tạo các quy trình nói một cách tương đối là chậm). Apache gọi PHP và yêu cầu nó chạy tệp .php thích hợp trên đĩa. Mã PHP thực thi và chặn các cuộc gọi I/O. Bạn gọi public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // blocking file I/O InputStream fileIs = new FileInputStream("/path/to/file"); // blocking network I/O URLConnection urlConnection = (new URL("//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

<?php // blocking file I/O $file_data = file_get_contents(‘/path/to/file.dat’); // blocking network I/O $curl = curl_init('//example.com/example-microservice'); $result = curl_exec($curl); // some more blocking network I/O $result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100'); ?>

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

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

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

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

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

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

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

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // blocking file I/O InputStream fileIs = new FileInputStream("/path/to/file"); // blocking network I/O URLConnection urlConnection = (new URL("//example.com/example-microservice")).openConnection(); InputStream netIs = urlConnection.getInputStream(); // some more blocking network I/O out.println("..."); }

Vì phương pháp public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // blocking file I/O InputStream fileIs = new FileInputStream("/path/to/file"); // blocking network I/O URLConnection urlConnection = (new URL("//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, 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ó khả năng thực hiện các cuộc gọi I/O không chặn. Hầu hết các ứng dụng, web và các ứng dụng khác, không sử dụng nó, nhưng ít nhất nó có sẵn. Một số máy chủ web Java cố gắng tận dụng điều này theo nhiều cách khác nhau;

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

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

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

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

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

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

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

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

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

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. Điều này có nghĩa là nếu bạn có 10.000 kết nối, thì vòng lặp đó có thể thu thập dữ liệu toàn bộ ứng dụng của bạn, tùy thuộc vào thời gian cần thiết. Mỗi yêu cầu phải chia sẻ một lát thời gian, mỗi lần một yêu cầu, trong luồng chính của bạn

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

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

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

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

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

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

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

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

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

func ServeHTTP(w http.ResponseWriter, r *http.Request) { // the underlying network call here is non-blocking rows, err := db.Query("SELECT ...") for _, row := range rows { // do something with the rows, // each request in its own goroutine } w.Write(...) // write the response, also non-blocking }

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

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

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

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

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

Đối với mỗi môi trường này, tôi đã viết mã thích hợp để đọc trong tệp 64k với các byte ngẫu nhiên, chạy hàm băm SHA-256 trên đó N số lần (N được chỉ định trong chuỗi truy vấn của URL, e. g. , public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // blocking file I/O InputStream fileIs = new FileInputStream("/path/to/file"); // blocking network I/O URLConnection urlConnection = (new URL("//example.com/example-microservice")).openConnection(); InputStream netIs = urlConnection.getInputStream(); // some more blocking network I/O out.println("..."); } 4) và in kết quả băm ở dạng hex. Tôi chọn cách này vì đây là một cách rất đơn giản để chạy các điểm chuẩn giống nhau với một số I/O nhất quán và một cách được kiểm soát để tăng mức sử dụng CPU

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

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

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

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

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

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

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

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

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

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

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

Tóm tắt

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

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

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

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

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

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

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

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

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

Thẻ

PHPJavaI/OGoNode. js

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

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

Xem thông tin đầy đủ

Brad Peabody

nhà phát triển

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

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

Thuê Brad

Bình luận

Patrick

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

Patrick

pha trộn

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

pha trộn

Greg

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

Greg

Andriy

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

Andriy

Roland Harrison

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

Roland Harrison

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

Samuel Lawson

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

Samuel Lawson

động cơ

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

động cơ

Fadel Chafai

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

Fadel Chafai

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

Qiong Wu

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

Qiong Wu

MichaelWebDev

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

MichaelWebDev

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

John Corry

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

John Corry

Peter Kokot

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

Peter Kokot

Juan Pablo Carzolio

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

Juan Pablo Carzolio

Stas Slesarev

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

Stas Slesarev

Mike Critchley

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

Mike Critchley

phra

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

phra

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

Ruan Kovalczyk

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

Ruan Kovalczyk

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

xer0x

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

xer0x

Julius Koronci

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

Julius Koronci

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

nikos

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

nikos

phra

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

phra

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

phra

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

phra

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

Ruan Kovalczyk

Cảm ơn bạn

Ruan Kovalczyk

Cảm ơn bạn

nikos

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

nikos

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

Ryan Winchester

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

Ryan Winchester

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

Brad

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

Brad

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

Brad

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

Brad

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

Brad

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

Brad

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/điểm chuẩn/

Martin

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

Boban Petrović

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

Boban Petrović

Áp-ra-ham Sánchez

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

Áp-ra-ham Sánchez

Decebal Dobrica

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

Decebal Dobrica

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. và trên thực tế, một số ngân hàng đang bắt đầu áp dụng PHP, điều này thật tuyệt vời. vì chất lượng như nhau mà giá rẻ gấp 10 lần. sẽ rẻ hơn khi sử dụng thêm một vài máy chủ so với việc thuê thêm 2 nhà phát triển Java trong vài năm tới

Julius Koronci

kelunik

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

kelunik

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

Stefano Fratini

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

Stefano Fratini

Rossen Hristov

Còn ASP thì sao. NET?

Rossen Hristov

Còn ASP thì sao. NET?

Jonathan Sterling

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

Jonathan Sterling

umka

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

umka

Niranjan Godbole

Go không có lệnh gọi lại và không giống như java, trình thu gom rác của nó được tối ưu hóa để có độ trễ thấp (

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

System Calls

Blocking vs. Non-blocking Calls

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. Đi

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

Tóm tắt

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

Bình luận

Bài Viết Liên Quan

Toplist

Bài mới nhất

Chủ đề