Thực hiện một bài kiểm tra căng thẳng trên ứng dụng web?

Trước đây, tôi đã sử dụng Microsoft Web Stress Tool và Pylot để kiểm tra các ứng dụng web. Tôi đã viết một trang chủ đơn giản, tập lệnh đăng nhập và hướng dẫn trang web (trong một trang web thương mại điện tử thêm một vài mục vào giỏ hàng và thanh toán).

Chỉ cần nhấn mạnh vào trang chủ với một số ít các nhà phát triển sẽ luôn luôn tìm ra một vấn đề lớn. Nhiều vấn đề về khả năng mở rộng sẽ xuất hiện ở giai đoạn thứ hai, và thậm chí nhiều hơn - sau khi ra mắt.

URL của các công cụ tôi đã sử dụng là Microsoft Homer (còn gọi là Microsoft Web Stress Tool ) và Pylot .

Các báo cáo được tạo bởi các công cụ này không bao giờ có ý nghĩa đối với tôi và tôi sẽ dành nhiều giờ để cố gắng tìm ra loại tải đồng thời nào mà trang web có thể hỗ trợ. Nó luôn luôn có giá trị bởi vì các lỗi và tắc nghẽn ngu ngốc nhất sẽ luôn xuất hiện (ví dụ, cấu hình sai của máy chủ web).

Bạn đã làm gì, bạn đã sử dụng công cụ gì và bạn đã có thành công gì với cách tiếp cận của mình? Phần thú vị nhất đối với tôi là đưa ra một loại công thức có ý nghĩa để tính toán số lượng người dùng đồng thời mà một ứng dụng có thể hỗ trợ từ các con số được báo cáo bởi ứng dụng kiểm tra căng thẳng.

Đây là một phiếu bầu khác cho JMeter .

JMeter là một công cụ kiểm tra tải nguồn mở, được viết bằng Java. Nó có khả năng kiểm tra một số loại máy chủ khác nhau (ví dụ: web, dịch vụ web, cơ sở dữ liệu, về bất kỳ thứ gì sử dụng các yêu cầu về cơ bản).

Tuy nhiên, nó có một đường cong học tập dốc khi bạn bắt đầu làm các bài kiểm tra phức tạp, nhưng nó cũng đáng. Bạn có thể thức dậy và chạy rất nhanh, và tùy thuộc vào loại thử nghiệm căng thẳng nào bạn muốn làm, điều đó có thể ổn.

Ưu điểm:

• Công cụ mã nguồn mở / miễn phí từ dự án Apache (trợ giúp mua)
• Dễ dàng bắt đầu và dễ sử dụng một khi bạn nắm được các khái niệm cốt lõi. (Tức là, cách tạo yêu cầu, cách tạo xác nhận, cách làm việc với các biến, v.v.).
• Rất có thể mở rộng. Tôi đã chạy thử nghiệm với 11 máy tạo tải trên máy chủ để điều chỉnh gần một triệu lượt truy cập / giờ. Nó dễ dàng hơn nhiều để thiết lập hơn tôi mong đợi.
• Có một cộng đồng tích cực và các tài nguyên tốt để giúp bạn đứng dậy và chạy. Đọc hướng dẫn trước và chơi với nó một lúc.

Nhược điểm:

• Giao diện người dùng được viết bằng Swing. (ừ!)
• JMeter hoạt động bằng cách phân tích văn bản phản hồi được máy chủ trả về. Vì vậy, nếu bạn đang tìm cách xác thực bất kỳ loại hành vi javascript nào, bạn sẽ không gặp may.
• Đường cong học tập là dốc cho những người không lập trình. Nếu bạn quen thuộc với các biểu thức thông thường, bạn đã đi trước trò chơi.
• Có một số lượng lớn những kẻ ngốc ( chèn thám hiểm ) trong diễn đàn hỗ trợ hỏi những câu hỏi ngu ngốc có thể dễ dàng giải quyết nếu họ đưa ra tài liệu ngay cả một cái nhìn lướt qua. ('Làm cách nào để sử dụng JMeter để kiểm tra căng thẳng GUI GUI của tôi' xuất hiện khá thường xuyên).
• Báo cáo 'ra khỏi hộp' để lại nhiều mong muốn, đặc biệt đối với các thử nghiệm lớn hơn. Trong thử nghiệm mà tôi đã đề cập ở trên, cuối cùng tôi đã phải viết một ứng dụng bảng điều khiển nhanh để thực hiện một số chuyển đổi 'xml-logfile' sang 'html'. Tuy nhiên, đó là một vài năm trước, vì vậy có thể điều này sẽ không còn cần thiết nữa.

Tôi đã sử dụng Máy mài . Đó là mã nguồn mở, khá dễ sử dụng và rất cấu hình. Nó dựa trên Java và sử dụng Jython cho các tập lệnh. Chúng tôi đã chạy nó với một ứng dụng web .NET, vì vậy đừng nghĩ đó là công cụ duy nhất của Java (về bản chất, mọi công cụ căng thẳng web không nên được gắn với nền tảng mà nó sử dụng).

Chúng tôi đã làm một số thứ gọn gàng với nó ... chúng tôi là một ứng dụng viễn thông dựa trên web, vì vậy một cách sử dụng tuyệt vời mà tôi thiết lập là bắt chước quay số qua ứng dụng web của chúng tôi, sau đó sử dụng một công cụ trả lời tự động mà chúng tôi có (về cơ bản là hướng dẫn ứng dụng từ Microsoft để kết nối với máy chủ RTC LCS của họ ... đó là những gì Microsoft Office Communicator kết nối với trên mạng cục bộ ... sau đó được sửa đổi để chỉ nhận cuộc gọi tự động). Điều này sau đó cho phép chúng tôi sử dụng công cụ này thay vì một công cụ điện thoại đắt tiền có tên The Hammer (hoặc một cái gì đó tương tự).

Dù sao, chúng tôi cũng đã sử dụng công cụ này để xem ứng dụng của chúng tôi hoạt động như thế nào dưới tải trọng cao và nó rất hiệu quả trong việc tìm ra các nút thắt cổ chai. Công cụ này được xây dựng trong báo cáo để hiển thị thời gian yêu cầu, nhưng chúng tôi không bao giờ sử dụng nó. Nhật ký cũng có thể lưu trữ tất cả các phản hồi và ghi chú, hoặc ghi nhật ký tùy chỉnh.

Tôi đánh giá cao công cụ này, rất hữu ích cho giá ... nhưng tôi sẽ thực hiện một số thiết lập tùy chỉnh với nó (nó có proxy để ghi tập lệnh, nhưng nó có thể cần tùy chỉnh để chụp một cái gì đó như phiên ... Tôi biết Tôi đã phải tùy chỉnh nó để sử dụng một phiên duy nhất cho mỗi luồng).

Một chút muộn để bữa tiệc này. Tôi đồng ý rằng Pylot là công cụ mã nguồn mở tốt nhất hiện có. Nó đơn giản để sử dụng và được tích cực làm việc bởi một anh chàng tuyệt vời ( Corey Goldberg ). Là người sáng lập OpenQA , tôi cũng rất vui khi Pylot hiện được liệt kê trên trang chủ của chúng tôi và sử dụng một số cơ sở hạ tầng của chúng tôi (cụ thể là các diễn đàn).

Tuy nhiên, gần đây tôi cũng quyết định rằng toàn bộ khái niệm kiểm tra tải là thiếu sót: mô phỏng lưu lượng HTTP, với các ứng dụng phức tạp như chúng đã trở thành, là một nỗi đau ở mông. Đó là lý do tại sao tôi tạo ra công cụ thương mại BrowserMob. Đây là dịch vụ kiểm tra tải bên ngoài sử dụng Selenium để kiểm soát các trình duyệt web thực khi phát lại tải.

Cách tiếp cận rõ ràng đòi hỏi một tấn phần cứng hơn các kỹ thuật kiểm tra tải trọng bình thường, nhưng phần cứng thực sự là khá rẻ khi bạn đang sử dụng điện toán đám mây. Và một tác dụng phụ tốt đẹp của việc này là các kịch bản là nhiều dễ dàng hơn thử tải bình thường. Bạn không phải thực hiện bất kỳ kết hợp regex nâng cao nào (như JMeter yêu cầu) để trích xuất cookie, trạng thái phiên .NET, tham số yêu cầu Ajax, v.v. Vì bạn đang sử dụng trình duyệt thực, họ chỉ cần làm những gì họ phải làm.

Xin lỗi vì đã ngang nhiên đưa ra một sản phẩm thương mại, nhưng hy vọng khái niệm này thú vị với một số người và ít nhất khiến họ nghĩ về một số cách mới để đối phó với thử nghiệm tải khi bạn có quyền truy cập vào một loạt phần cứng bổ sung!

Tôi đã sử dụng JMeter . Bên cạnh việc kiểm tra máy chủ web, bạn cũng có thể kiểm tra phụ trợ cơ sở dữ liệu, dịch vụ nhắn tin và máy chủ email.

ab , bao vây , tsung , httperf , chà đạp , Pylot, yêu cầu-log-phân tích , perftools

Để sử dụng đơn giản, tôi sử dụng ab (điểm chuẩn apache) và bao vây, sau này là cần thiết vì ab không hỗ trợ cookie và sẽ tạo các phiên vô tận từ trang web động.

cả hai đều đơn giản để bắt đầu:

ab -c n -t 30 url

siege -b -c n -t 30s url

bao vây có thể chạy với nhiều url hơn.

phiên bản bao vây cuối cùng bật verbose trong siegerc, thật khó chịu. bạn chỉ có thể vô hiệu hóa nó bằng cách chỉnh sửa tập tin đó ( /usr/local/etc/siegerc).

Đối với dịch vụ dựa trên web, hãy xem loader.io .

Tóm lược:

loader.io là một dịch vụ kiểm tra tải miễn phí cho phép bạn nhấn mạnh kiểm tra ứng dụng web / apis của mình với hàng ngàn kết nối đồng thời.

Họ cũng có một API .

Vì câu hỏi này vẫn còn mở, tôi cũng có thể cân nhắc.

Tin tốt là trong khoảng 5 năm trở lại đây, các công cụ Nguồn mở đã thực sự trưởng thành và cất cánh trong không gian, tin xấu là có rất nhiều trong số chúng ở ngoài đó.

Đây là suy nghĩ của tôi: -

Jmeter vs Máy mài

Jmeter được điều khiển từ một đặc tả kiểu XML, được xây dựng thông qua GUI.

Máy mài sử dụng tập lệnh Jython trong khung công tác Java đa luồng, do đó, định hướng nhiều hơn cho các lập trình viên.

Cả hai công cụ sẽ xử lý HTTP và HTTPS và có trình ghi proxy để giúp bạn bắt đầu. Cả hai công cụ đều sử dụng mô hình Bộ điều khiển để điều khiển nhiều tác nhân thử nghiệm nên khả năng mở rộng không phải là vấn đề (được cấp quyền truy cập vào Đám mây).

Cái nào tốt hơn:-

Một cuộc gọi khó khăn khi đường cong học tập dốc cả hai công cụ khi bạn nhận được các yêu cầu về kịch bản phức tạp hơn để viết lại url, tương quan, cung cấp dữ liệu duy nhất cho mỗi Người dùng ảo và mô phỏng Người dùng lần đầu hoặc trả lại Người dùng (bằng cách thao tác Tiêu đề HTTP).

Điều đó nói rằng tôi sẽ bắt đầu với Jmeter vì công cụ này có lượng người theo dõi rất lớn và có nhiều ví dụ và hướng dẫn trên web để sử dụng công cụ này. Nếu và khi bạn đến một 'khối đường', đó là điều bạn không thể 'dễ dàng' thực hiện với Jmeter thì hãy xem Máy mài. Tin tốt là cả hai công cụ này đều có cùng một yêu cầu Java và giải pháp 'trộn và kết hợp' không nằm ngoài câu hỏi đó.

Một cái gì đó mới để thêm - Các trình duyệt không đầu chạy nhiều phiên bản của Selenium WebDriver.

Đây là một cách tiếp cận tương đối mới vì nó phụ thuộc vào sự sẵn có của các tài nguyên hiện có thể được cung cấp từ Đám mây. Với cách tiếp cận này, tập lệnh Selenium (WebDriver) được lấy và chạy trong trình duyệt không đầu (tức là WebDriver = New HtmlUnitDriver ()) trong nhiều luồng.

Từ kinh nghiệm, khoảng 25 trường hợp 'trình duyệt không đầu' có thể được thực thi từ Trường hợp nhỏ Amazon M1.

Điều này có nghĩa là tất cả các vấn đề tương quan, viết lại url biến mất khi bạn tái sử dụng các tập lệnh kiểm tra chức năng của mình để trở thành tập lệnh kiểm tra hiệu năng.

Khả năng mở rộng bị tổn hại vì sẽ cần nhiều VM hơn để điều khiển tải, so với trình điều khiển HTTP như Máy mài hoặc Jmeter. Điều đó nói rằng, nếu bạn đang muốn lái 500 Người dùng ảo thì với 20 Trường hợp nhỏ trên Amazon (6 xu mỗi giờ) với chi phí chỉ 1,20 đô la mỗi giờ mang lại cho bạn tải rất gần với Trải nghiệm người dùng thực.

Ngoài ra, có một khung cào cào tinh khiết mã nguồn mở tuyệt vời được phân phối và mở rộng sử dụng greenlets . Thật tuyệt vời khi mô phỏng số lượng lớn người dùng đồng thời.

Gần đây chúng tôi đã bắt đầu sử dụng Gatling để thử tải. Tôi rất khuyên bạn nên dùng thử công cụ này để thử tải. Chúng tôi đã sử dụng SOASTA và JMETER trong quá khứ. Lý do chính của chúng tôi để xem xét Gatling là sau:

• Ghi âm để ghi lại kịch bản
• Sử dụng Akka và Netty cho hiệu năng tốt hơn so với mô hình Jmeter Threading
• DSL Scala có thể bảo trì rất nhiều so với Jmeter XML
• Dễ dàng viết các bài kiểm tra, đừng sợ nếu đó là scala.
• Báo cáo

Để tôi cho bạn ví dụ đơn giản để viết mã bằng Mã Gatling:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Tuy nhiên bạn có thể làm cho nó phức tạp nhất có thể. Một trong những tính năng nổi bật của Gatling là báo cáo rất chi tiết.

Dưới đây là một số liên kết:
Gatling
Gatling Tutorial

Gần đây tôi đã nói về nó, bạn có thể xem qua cuộc nói chuyện tại đây:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Đây là một câu hỏi cũ, nhưng tôi nghĩ các giải pháp mới hơn đáng được đề cập. Thanh toán LoadImpact: http://www.loadimpact.com .

Tôi đã thử WebLoad, đây là một công cụ khá gọn gàng. Nó đi kèm và kiểm tra tập lệnh IDE cho phép bạn ghi lại hành động của người dùng trên một trang web. Nó cũng vẽ một biểu đồ khi nó thực hiện kiểm tra căng thẳng trên máy chủ web của bạn. Hãy thử nó, tôi đánh giá cao nó.

Thử tất cả các đề cập ở đây, tôi thấy curl-loader là tốt nhất cho mục đích của tôi. giao diện rất dễ dàng, giám sát thời gian thực, số liệu thống kê hữu ích, từ đó tôi xây dựng các biểu đồ hiệu suất. Tất cả các tính năng của libcurl được bao gồm.

Blaze mét có phần mở rộng chrome để ghi phiên và xuất chúng sang JMeter (hiện yêu cầu đăng nhập). Bạn cũng có tùy chọn trả tiền cho họ để chạy nó trên cụm máy chủ JMeter của họ (giá của họ có vẻ tốt hơn nhiều so với LoadImpact mà tôi vừa ngừng sử dụng):

• Tiện ích mở rộng BlazeMeter Chrome
• Blog nhập về nó

Tôi không có bất kỳ liên kết nào với họ, tôi chỉ thích giao diện của dịch vụ của họ, mặc dù tôi chưa sử dụng phiên bản trả phí.

Bạn đã hỏi câu hỏi này gần một năm trước và tôi không biết liệu bạn có còn tìm kiếm một cách khác để đánh giá trang web của mình không. Tuy nhiên vì câu hỏi này vẫn chưa được đánh dấu là đã được giải quyết, tôi muốn đề xuất dịch vụ web miễn phí LoadImpact (btw. Không liên kết). Chỉ cần có liên kết này thông qua twitter và muốn chia sẻ tìm thấy này. Họ tạo ra một tổng quan tốt hợp lý và thêm một vài đô la bạn sẽ có được "chế độ tác động đầy đủ". Điều này nghe có vẻ lạ, nhưng chúc may mắn đẩy và hãm dịch vụ của bạn :)

Tôi thấy IBM Page Chi tiết cũng là một công cụ thú vị để làm việc.

Tôi đã sử dụng openSTA .

Điều này cho phép một phiên với một trang web được ghi lại và sau đó phát lại thông qua ngôn ngữ kịch bản tương đối đơn giản.

Bạn có thể dễ dàng kiểm tra các dịch vụ web và viết các tập lệnh của riêng bạn.

Nó cho phép bạn đặt các tập lệnh cùng nhau trong một thử nghiệm theo bất kỳ cách nào bạn muốn và định cấu hình số lần lặp, số lượng người dùng trong mỗi lần lặp, thời gian tăng dần để giới thiệu mỗi người dùng mới và độ trễ giữa mỗi lần lặp. Các xét nghiệm cũng có thể được lên lịch trong tương lai.

Đó là nguồn mở và miễn phí.

Nó tạo ra một số báo cáo có thể được lưu vào bảng tính. Sau đó chúng tôi sử dụng bảng xoay để dễ dàng phân tích và vẽ biểu đồ kết quả.

Chúng tôi sử dụng công cụ Microsoft đã đề cập - Công cụ căng thẳng ứng dụng web của Microsoft. Nó là công cụ đơn giản nhất mà tôi đã sử dụng. Nó bị hạn chế theo nhiều cách, bao gồm chỉ có thể đạt được cổng 80 trong các thử nghiệm được tạo thủ công. Nhưng, nó dễ sử dụng có nghĩa là nó thực sự được sử dụng.

Chúng tôi bổ sung tải từ công cụ này bằng các công cụ khác bao gồm OpenSTA và các con nhện kiểm tra liên kết.

JMeter có vẻ tốt từ đánh giá ban đầu của tôi, tôi hy vọng sẽ đưa nó vào sự tích hợp liên tục của chúng tôi trong tương lai. Nhưng, JMeter phức tạp và không tầm thường để tung ra.

Tôi khuyên bạn nên mở một câu hỏi khác liên quan đến việc diễn giải kết quả của công cụ căng thẳng MS.

Phiên bản thử nghiệm Visual Studio 2010 (2008 cũng tốt). Đây là một công cụ thực sự dễ dàng và mạnh mẽ để tạo các bài kiểm tra web / tải.

Phần thưởng với công cụ này khi sử dụng đối với các máy chủ Windows là bạn có được quyền truy cập tích hợp vào tất cả các thống kê máy chủ perfmon trong báo cáo của mình. Thực sự hữu ích.

Phần thưởng khác là với dự án Visual Studio, bạn có thể tích hợp "Phiên hiệu suất" sẽ lập hồ sơ thực thi mã của trang web của bạn.

Nếu bạn đang phục vụ các trang web từ máy chủ windows, đây là công cụ tốt nhất hiện có.

Tuy nhiên, có một giấy phép riêng biệt và đắt tiền để sử dụng một số máy để tải thử nghiệm ứng dụng.

Chúng tôi đã phát triển một quy trình coi tải trọng và đo lường hiệu suất là mối quan tâm hàng đầu - như bạn nói, để nó đến cuối dự án có xu hướng dẫn đến sự thất vọng ...

Vì vậy, trong quá trình phát triển, chúng tôi bao gồm thử nghiệm đa người dùng rất cơ bản (sử dụng selen), kiểm tra sự điên rồ cơ bản như quản lý phiên bị hỏng, các vấn đề tương tranh rõ ràng và các vấn đề tranh chấp tài nguyên rõ ràng. Các dự án không tầm thường bao gồm điều này trong quá trình tích hợp liên tục, vì vậy chúng tôi nhận được phản hồi rất thường xuyên.

Đối với các dự án không có yêu cầu hiệu suất cao, chúng tôi bao gồm thử nghiệm hiệu suất cơ bản trong thử nghiệm của chúng tôi; thông thường, chúng tôi viết kịch bản các bài kiểm tra bằng BadBoy và nhập chúng vào JMeter, thay thế các chi tiết đăng nhập và những thứ cụ thể theo chủ đề khác. Sau đó, chúng tôi đưa những thứ này lên đến mức mà máy chủ đang xử lý 100 yêu cầu mỗi giây; nếu thời gian phản hồi ít hơn 1 giây, điều đó thường là đủ. Chúng tôi khởi động và tiếp tục với cuộc sống của chúng tôi.

Đối với các dự án có yêu cầu hiệu năng cao, chúng tôi vẫn sử dụng BadBoy và JMeter, nhưng đặt nhiều năng lượng để hiểu các nút thắt trên máy chủ trên giàn thử nghiệm của chúng tôi (thông thường là máy chủ cơ sở dữ liệu và cơ sở dữ liệu). Có một công cụ tốt để phân tích nhật ký sự kiện của Microsoft giúp ích rất nhiều cho việc này. Chúng tôi thường tìm thấy các nút thắt bất ngờ, mà chúng tôi tối ưu hóa nếu có thể; cung cấp cho chúng tôi một ứng dụng nhanh nhất có thể trên "1 máy chủ web, 1 máy chủ cơ sở dữ liệu". Sau đó, chúng tôi thường triển khai đến cơ sở hạ tầng mục tiêu của mình và sử dụng một trong các dịch vụ "Jmeter trên đám mây" để chạy lại các thử nghiệm ở quy mô.

Một lần nữa, báo cáo PAL giúp phân tích những gì đã xảy ra trong các thử nghiệm - bạn thường thấy các nút thắt rất khác nhau trên môi trường sản xuất.

Điều quan trọng là đảm bảo bạn không chỉ chạy các bài kiểm tra căng thẳng mà còn thu thập thông tin bạn cần để hiểu hiệu suất của ứng dụng.

Có rất nhiều công cụ tốt được đề cập ở đây. Tôi tự hỏi nếu các công cụ là một câu trả lời cho câu hỏi: "Làm thế nào để bạn căng thẳng kiểm tra một ứng dụng web?" Các công cụ không thực sự cung cấp một phương pháp để nhấn mạnh một ứng dụng Web. Đây là những gì tôi biết:

Kiểm tra căng thẳng cho thấy một ứng dụng Web thất bại như thế nào trong khi phục vụ các phản hồi cho số lượng người dùng ngày càng tăng. Kiểm tra căng thẳng cho thấy ứng dụng Web hoạt động như thế nào trong khi nó không thành công. Hầu hết các ứng dụng Web hiện nay - đặc biệt là các ứng dụng Web Xã hội / Di động - là tích hợp các dịch vụ. Ví dụ: khi Facebook ngừng hoạt động vào tháng 5 năm 2011, bạn không thể đăng nhập vào ứng dụng Web của Pepsi.com. Ứng dụng không hoàn toàn thất bại, chỉ một phần lớn chức năng thông thường của nó trở nên không khả dụng với người dùng.

Kiểm tra hiệu suất cho thấy khả năng của ứng dụng Web để duy trì thời gian phản hồi độc lập với số lượng người dùng đồng thời sử dụng ứng dụng. Ví dụ: một ứng dụng xử lý 10 giao dịch mỗi giây với 10 người dùng đồng thời sẽ xử lý 20 giao dịch mỗi giây tại 20 người dùng. Nếu ứng dụng xử lý ít hơn 20 giao dịch mỗi giây, thời gian phản hồi sẽ tăng lên và ứng dụng không thể đạt được khả năng mở rộng tuyến tính.

Ngoài ra, trong ví dụ trên, số lượng giao dịch mỗi giây chỉ nên là các hoạt động thành công của trường hợp / quy trình sử dụng thử nghiệm. Thất bại thường xảy ra trong thời gian ngắn hơn và sẽ làm cho phép đo TPS quá lạc quan. Thất bại rất quan trọng đối với một bài kiểm tra căng thẳng và hiệu suất vì chúng cũng tạo ra tải trên ứng dụng.

Tôi đã viết lên phương pháp PushToTest trong Hướng dẫn sử dụng TestMaker tại http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker có hai loại: Phiên bản cộng đồng mã nguồn mở (GPL) và TestMaker Enterprise (thương mại với sự hỗ trợ chuyên nghiệp tuyệt vời.)

-Frank

Hãy xem LoadBooster ( https://www.loadbooster.com ). Nó sử dụng PhantomJS / CasperJs trình duyệt không có kịch bản để kiểm tra các trang web. Phantomjs sẽ phân tích cú pháp và kết xuất mọi trang, thực thi kịch bản phía máy khách. Cách tiếp cận trình duyệt không đầu dễ dàng hơn để viết các kịch bản thử nghiệm để hỗ trợ ứng dụng AJAX nặng Web 2.0 phức tạp, điều hướng trình duyệt, nhấp chuột và nhấn phím vào trình duyệt hoặc đợi cho đến khi một phần tử tồn tại trong DOM. LoadBooster cũng hỗ trợ tập lệnh HTML selenium.

Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho LoadBooster.

Hãy thử ZebraTester dễ sử dụng hơn jMeter. Tôi đã sử dụng jMeter trong một thời gian dài nhưng tổng thời gian thiết lập cho một bài kiểm tra tải luôn là một vấn đề. Mặc dù ZebraTester không phải là nguồn mở, thời gian mà tôi đã lưu trong sáu tháng qua bù cho nó. Họ cũng có một cổng thông tin SaaS có thể được sử dụng để chạy nhanh các thử nghiệm bằng cách sử dụng các trình tạo tải của họ.

Một lưu ý nữa, đối với ứng dụng web của chúng tôi, tôi thấy rằng chúng tôi có vấn đề về hiệu năng rất lớn do sự tranh chấp giữa các luồng trên ổ khóa ... vì vậy đạo đức là phải suy nghĩ rất kỹ về sơ đồ khóa. Chúng tôi cuối cùng đã có các luồng công nhân để điều tiết quá nhiều yêu cầu bằng cách sử dụng trình xử lý http không đồng bộ, nếu không ứng dụng sẽ bị quá tải và bị sập và cháy. Nó có nghĩa là một lượng tồn đọng lớn có thể chồng chất, nhưng ít nhất trang web sẽ ở lại.

Hãy xem TestComplete .

Tôi thứ hai gợi ý opensta. Tôi chỉ nói thêm rằng nó cho phép bạn làm mọi thứ để giám sát máy chủ mà bạn đang kiểm tra bằng cách sử dụng SMTP. Chúng tôi theo dõi tải bộ xử lý, bộ nhớ đã sử dụng, tạm biệt đã gửi, v.v ... Nhược điểm duy nhất là nếu bạn tìm thấy thứ gì đó bị lỗi và muốn sửa, nó phụ thuộc vào một số thư viện nguồn mở không còn theo kịp, do đó, việc biên dịch phiên bản của nguồn khó hơn so với hầu hết các OSS.

Tôi đã chơi với JMeter. Một người nghĩ rằng nó không thể không kiểm tra là ASP.NET Webforms. Khung nhìn đã phá vỡ các bài kiểm tra của tôi. Tôi không chắc chắn tại sao, nhưng có một số công cụ hiện có mà không xử lý viewstate đúng. Dự án hiện tại của tôi là ASP.NET MVC và JMeter hoạt động tốt với nó.

Tôi đã có kết quả tốt với FunkLoad :

• dễ dàng tương tác người dùng kịch bản
• báo cáo là rõ ràng
• có thể theo dõi tải máy chủ

Có nguy cơ bị buộc tội tự quảng cáo không biết xấu hổ, tôi muốn chỉ ra rằng trong hành trình tìm kiếm một công cụ kiểm tra tải miễn phí, tôi đã đi đến bài viết này: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

Hoặc là tôi không thể có được thông lượng mà tôi muốn, hoặc tôi không thể có được sự linh hoạt mà tôi muốn. VÀ tôi muốn dễ dàng tổng hợp kết quả của nhiều máy chủ tạo thử nghiệm tải trong phân tích thử nghiệm bài.

Tôi đã thử mọi công cụ trong danh sách và với sự thất vọng của tôi thấy rằng không ai trong số họ hoàn toàn làm những gì tôi muốn có thể làm. Vì vậy, tôi đã xây dựng một và đang chia sẻ nó.

Đây là: http://sourceforge.net/projects/loadmonger

Tái bút: Không có bình luận nào về tên của những người quen thuộc với tiếng lóng đô thị. Tôi đã không nhưng bây giờ hơi trần tục hơn.

Tôi cũng bình chọn cho jMeter và tôi muốn thêm một số trích dẫn vào câu trả lời @PeterBernier.

Câu hỏi chính mà các câu trả lời kiểm tra tải là ứng dụng web của tôi có thể hỗ trợ bao nhiêu người dùng? Để có được câu trả lời thích hợp, kiểm tra tải phải thể hiện mức độ sử dụng ứng dụng thực, càng gần càng tốt .

Hãy ghi nhớ, jMeter có nhiều khối xây dựng Bộ điều khiển logic , Cấu phần cấu hình , Bộ xử lý trước , Trình nghe , ... có thể giúp bạn trong việc này.

Bạn có thể bắt chước tình huống trong thế giới thực với jMeter, ví dụ bạn có thể:

1. Cấu hình JMeter để hoạt động như trình duyệt thực bằng cách cấu hình ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Cấu hình JMeter để tạo ra yêu cầu người dùng (bằng cách định nghĩa number of users per second, ramp-up time, scheduling, ...)
3. Định cấu hình nhiều máy khách có jMeter trên chúng, để thực hiện kiểm tra tải phân tán.
4. Quá trình đáp ứng để tìm xem máy chủ có phản hồi chính xác trong quá trình kiểm tra hay không. (Ví dụ assertphản hồi để tìm một văn bản trong đó)

Xin vui lòng xem xét:

• Thật dễ dàng để bắt đầu một thử nghiệm ứng dụng web thực sự với jMeter trong vài phút. Các jMeter có một công cụ rất dễ dàng ghi lại kịch bản thử nghiệm của bạn (biết là HTTP(S) Test Script Recorder).
• jMeter có rất nhiều plugin tại http://jmeter-plugins.org .
• Giao diện người dùng jMeter dựa trên swing và đã có những thay đổi tốt trong jMeter 3.2. Mặt khác, vui lòng xem xét rằng JMeter GUI chỉ nên được sử dụng để kiểm tra và gỡ lỗi. Nó không phải là thực hành tốt để sử dụng nó trong chế độ GUI cho thử nghiệm thực tế. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-USE-jmeter-gui . Định cấu hình và kiểm tra kịch bản của bạn và chạy nó ở chế độ không gui.
• Có rất nhiều công cụ hiển thị báo cáo trong jMeter (Được biết là listeners) nhưng không có nghĩa là phải bật trong khi thử nghiệm. Bạn phải chạy thử nghiệm và tạo báo cáo ( .jtltệp). Sau đó, bạn phải sử dụng các công cụ này để phân tích kết quả. Vui lòng xem tại https://www.blazemeter.com/blog/jmeter-listpers-part-1-basic-display-formats hoặc https://www.tutorialspoint.com/jmeter/jmeter_listpers.htmlm .

Các https://www.blazemeter.com/jmeter có thông tin rất tốt và thiết thực để giúp đỡ bạn cấu hình môi trường thử nghiệm của bạn.