23 Matching Annotations
  1. Aug 2024
    1. This is the most simulative version of a controller. It will try and mimic real user behaviour. It's the recommended version to use when the goal of the load-test is finding out how many concurrently active users the target instance supports.
  2. Feb 2022
  3. May 2021
  4. Mar 2021
  5. Feb 2021
  6. Aug 2020
  7. May 2020
  8. Apr 2020
  9. Mar 2020
    1. I would like to make an appeal to core developers: all design decisions involving involuntary session creation MUST be made with a great caution. In case of a high-load project, avoiding to create a session for non-authenticated users is a vital strategy with a critical influence on application performance. It doesn't really make a big difference, whether you use a database backend, or Redis, or whatever else; eventually, your load would be high enough, and scaling further would not help anymore, so that either network access to the session backend or its “INSERT” performance would become a bottleneck. In my case, it's an application with 20-25 ms response time under a 20000-30000 RPM load. Having to create a session for an each session-less request would be critical enough to decide not to upgrade Django, or to fork and rewrite the corresponding components.
  10. Feb 2020
    1. I had created a bunch of annotations on: https://loadimpact.com/our-beliefs/ https://hyp.is/bYpY5lKoEeqO_HdxChFU0Q/loadimpact.com/our-beliefs/

      But when I click "Visit annotations in context"

      Hypothesis shows an error:

      Annotation unavailable The current URL links to an annotation, but that annotation cannot be found, or you do not have permission to view it.

      How do I edit my existing annotations for the previous URL and update them to reference the new URL instead?

    1. Performance Benchmarking What it is: Testing a system under certain reproducible conditions Why do it: To establish a baseline which can be tested against regularly to ensure a system’s performance remains constant, or validate improvements as a result of change Answers the question: “How is my app performing, and how does that compare with the past?”
    1. Do Browse like a user wouldTake natural pauses that users would take to consume page contentFocus on the most common use cases, rather than all the possible use casesTake note of pages where forms/logins occur, you will likely need to complete some scripting there
    1. We believe load test scripts should be plain code to get all the benefits of version control, as opposed to say unreadable and tool generated XML.

      Saw another comment lamenting the use of ugly/unreasonable XML files:

      https://github.com/flood-io/ruby-jmeter

      Tired of using the JMeter GUI or looking at hairy XML files?

    2. It is also good practice to make sure that your load testing is functionally correct. Both the performance and functional goals can be codified using thresholds and checks (like asserts).
    1. Load Testing Manifesto Simple testing is better than no testingLoad testing should be goal orientedLoad testing by developersDeveloper experience is super importantLoad test in a pre-production environment
    2. You can use it for running tests with a high load (spike, stress, endurance tests) in pre-production and QA environments.