当您事先不知道 URL 是什么时,您将如何对动态网站进行压力测试?

发布于 2024-10-03 10:40:50 字数 620 浏览 0 评论 0原文

这不是有什么压力测试工具的问题。恐怕比这困难得多。 (至少对我来说)

考虑一个论坛或博客的宁静架构,为每个帖子生成随机 ID。

模拟创建这些主题/文章很简单,因为您只需将表单数据发布到端点,例如:/article/topic

但是您如何强调测试对这些文章/主题的评论?这是不同的,因为评论需要属于文章/主题,这意味着您需要这些项目的 ID。但是,如果您所能做的就是发布帖子,并且无法提取这些 ID,那么您将无法创建它们。

我正在创建一个在这方面类似的网站,但我不知道如何对评论的创建进行压力测试。

我有两个想法,它们都非常糟糕:

  1. 用某种工厂提前生成一个庞大的系统,然后冻结它。从那里,我想我必须使用某种浏览器自动化来创建我对所有这些的“评论”。我想自动化会通过记录代理,就像 JMeter 提供的那样。然后,为了运行测试,我重新加载数据库,并重播大量日志文件。
  2. 利用 HTML 页面中提供的动态链接,对整个过程使用浏览器自动化。这里唯一的选择是硒,实际上,我们正在谈论一个巨大的硒网格,这将非常昂贵。可能也很难维护。

据我所知,选项 2 完全不可行,但选项 1 听起来令人难以忍受。我真的希望有人能提出更聪明的建议。

This isn't a question of what stress testing tools are out there. I'm afraid it's a lot harder than that. (At least for me)

Consider a restful architecture for a forum or blog that generates random IDs for each post.

Simulating creating those topics/articles would be simple, because you'd just be posting form data to an endpoint like: /article, or /topic

But how do you then stress test commenting on those articles/topics? This is different, because the comments need to belong to an article/topic, which means that you need the ids of those items. However, if all you can do is issue posts, and you have no way of pulling those ids, you'd be unable to create them.

I'm creating a site that is similar in this regard, and I have no idea how to stress test the creation of the comments.

I have two ideas, and they're both pretty awful:

  1. Generate a massive system ahead of time with some kind of factory, and then freeze it. From there, I figure I'd have to use some kind of browser automation to create my 'comments' on all of this. The automation would I suppose go through a recording proxy, like what JMeter offers. Then, to run the test, I reload the database, and replay the massive log file.
  2. Use browser automation for the whole thing, taking advantage of the dynamic links delivered in the HTML page. The only option here would be Selenium, and really, we're talking a massive selenium grid that would be extremely expensive. Probably very difficult to maintain also.

Option 2 is completely infeasible near as I can tell, but option 1 sounds excruciating. I'm really hoping someone can suggest something more clever.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

清风挽心 2024-10-10 10:40:51

我曾经使用Visual Studio来解决此类问题。 Visual Studio 允许 C# 编码的 Web 测试,可以以编程方式解析返回的 html,并据此采取操作。

我正在对 SharePoint 网站进行负载测试,并需要提前填充信息。我确实创建了一个负载测试,专门用于提前创建“随机”内容页面。我提前用 URL 填充了测试工具数据库,从而可以对加载的页面进行一些控制。

有了可用的“文章”列表和潜在注释列表,就可以编写伪随机数生成器(由于测试工具的异步性质,在存储过程中)以获得可重复的负载测试。这意味着每次运行负载测试时都会以相同的方式填充该站点。

确实需要付出一些努力来创建一种体面的方式来立即填充站点,但是负载测试的相关性的回报是相当好的。

I have used Visual Studio to solve this kind of problem. Visual Studio allows C# coded web tests that can programatically parse the html returned and take action based on that.

I was load testing a SharePoint website and required information to be populated ahead of time. I did create a load test that was specifically for creating "random" pages of content ahead of time. I populated a test harness database with the urls ahead of time, allowing some control over the pages that were loaded.

With a list of "articles" available and a list of potential comments, it is possible to code a pseudo-random number generator (inside a stored procedure because of the asynchronous nature of the test harness) to get a repeatable load test. That meant that the site would be populated in the same way each time the load test was run.

It does take some effort to create a decent way of populating the site off the bat, but the return in the relevance of the load test is quite good.

落墨 2024-10-10 10:40:50

选项 1。

我的意思是,除了实施说明之外,您基本上只是需要一个测试环境。所以,答案是制作一个。以任何方式:

  • 生成它
  • 制作一次并重新加载它
  • 随机化它

无论如何。这是要采用的方法。

你如何进行测试是一个附带问题(单元测试/浏览器/其他,由你决定)。

但您已经到了需要使用真实数据进行测试的地步。所以让它发生吧。

Option 1.

I mean, implementation notes aside, you're basically just asking for a testing environment. So, the answer is to make one. In whatever fashion:

  • Generate it
  • Make it once and reload it
  • Randomise it

Whatever. It's the approach to go with.

How do you your testing is kind of a side issue (unit testing/browser/whatever, up to you).

But you've reached a point where you need to test with real data. So make it happen.

人生百味 2024-10-10 10:40:50

这是一个常见问题。我们通过从服务器响应中提取 URL 的动态部分来处理它。我认为该系统使用 Web 浏览器客户端 - 这意味着这些 URL 是在服务器响应中发送的。如果它们在回复中,那么您就可以获得它们。然而,既然你说“如果你所能做的就是发布帖子,而你无法提取这些ID”,那么也许情况并非如此?那么,您能澄清一下吗?

我们最近为我们的客户进行了大量的 Drupal 系统测试 - 这正是您所描述的问题。我们要么通过在用户浏览到他们想要评论的页面时从页面动态提取 ID 来解决这个问题,要么使用选项 1,或两者的组合。请注意,如果您有方便的负载测试工具,那么内容的生成并不太困难 - 使用该工具来完成。即运行“内容生成”负载测试。除了自动生成有用的数据之外,这还将为您提供一个测试数据库,然后您可以根据需要备份/恢复该数据库以维护您的测试基础设施。现在,您可以在更现实的环境中运行测试 - 一个已经包含大量内容的环境(当然,假设这对于您的目的来说是现实的)。

如果您有兴趣,我很乐意演示我们如何使用我们的软件(Web Performance Load Tester)解决问题。

This is a common problem. We handle it by extracting the dynamic parts of the URLs from the server responses. I presume this system uses web browser client - which implies that those URLs are being sent in the server responses. If they are in the responses, then you CAN get them. However, since you said "if all you can do is issue posts, and you have no way of pulling those ids", then perhaps this is not the case? In that case, can you clarify?

We've recently been doing a lot of testing of Drupal systems for our customers - which has exactly the problem you've described. We either solve it by extracting the IDs dynamically from the page as the user browses to the page they want to comment on, or we use option 1, or a combination of both. Note that if you have a load testing tool handy, then generation of content is not too difficult - use the tool to do it. I.e. run a "content generation" load test. Besides yielding useful data on its own accord, that will give you a test database that you can then backup/restore as needed to maintain your test infrastructure. Now you can run the test on a more realistic environment - one that has lots of content already in it (assuming, of course, that this is realistic for your purposes).

If you are interested, I'd be happy to demo how we solve the problem using our software (Web Performance Load Tester).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文