# Performance Testing Published articles for Performance Testing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From hours to minutes: Optimizing Red Hat Developer Hub performance testing with immutable LDAP images DevFeed: [From hours to minutes: Optimizing Red Hat Developer Hub performance testing with immutable LDAP images]() Original publisher: [Read original article]() Author: Shashank Kestwal Published: 2026-09-17T13:16:48Z Content type: article Language: en Sources: [Red Hat](), [Red Hat Developer]() Topics: [Performance Testing](), [LDAP](), [Keycloak](), [CI/CD](), [Concurrency](), [Deployment](), [rbac]() Tags: [ci-cd](), [concurrency](), [deployment](), [keycloak](), [ldap](), [migration](), [performance-testing](), [testing]() ### AI overview This Red Hat developer article describes a performance-testing bottleneck in Red Hat Developer Hub caused by generating users and groups at runtime through the Keycloak Admin REST API and synchronizing them over HTTP. It introduces pre-built LDAP container images as immutable infrastructure to reduce environment setup complexity and improve testing feedback loops. ### Source excerpt At Red Hat, our CI/CD pipelines are the heartbeat of our development process. However, as we scaled the Red Hat Developer Hub performance testing framework, we hit a wall. Our environment setup time was ballooning, turning what should have been a seamless verification step into a long waiting game. For performance engineering in catalog-dependent applications, deployment and catalog population speed directly dictate your feedback loops. The post From hours to minutes: Optimizing Red Hat Developer Hub performance testing with immutable LDAP images appeared first on Red Hat Developer. ## Better context, smarter testing: How to give your AI coding agent direct access to k6 docs DevFeed: [Better context, smarter testing: How to give your AI coding agent direct access to k6 docs]() Original publisher: [Read original article]() Author: İnanç Gümüş Published: 2026-09-12T11:22:06.456390Z Content type: article Language: en Sources: [Grafana Labs blog on Grafana Labs]() Topics: [k6](), [Agent Skill](), [AI Agent](), [Command-line interface](), [coding]() Tags: [agent-skill](), [ai](), [ai-agent](), [ai-coding](), [analytics](), [cli](), [grafana](), [k6](), [logs](), [metrics](), [monitoring](), [observability](), [performance-testing](), [testing](), [traces]() ### AI overview The article introduces k6 x docs, an official k6 2.0 command that provides k6 documentation directly in the terminal. It supports API references, guides, best practices, and examples; works offline after the first lookup; matches documentation to the installed k6 version; and includes an agent skill for AI coding assistants. ### Source excerpt As testing workflows become more AI-assisted, fast access to accurate documentation matters more than ever. Whether you're writing a new load test, troubleshooting an issue, or having an AI agent generate a script for you, you need reliable guidance that keeps pace with the way you work. But most documentation still lives in a browser. Every time you or your agent needs to verify an API or look up a best practice, you're forced to leave your terminal or editor and interrupt your workflow. That's why, in k6 2.0, we introduced k6 x docs, an official k6 command that puts the entire k6 documentation library, including API references, guides, best practices, and examples, directly in your terminal. It works offline after first use, matches the docs to your exact k6 version, and includes a built-in agent skill, so AI coding assistants can look up k6 docs faster and most cost-effectively. The problem: documentation lives in the wrong place Most developers know the feeling. You're writing a k6 script, you need to check the signature for http.post or remember how thresholds work, and suddenly you're in a browser tab, searching, scrolling, clicking through navigation, and losing the context you had in your editor. For AI agents, the problem is worse. When they need to reference k6 APIs, best practices, or examples, they either rely on stale training data, hallucinate a function signature, or burn expensive tokens on a web search that may not return the right version of the docs. k6 x docs solves both problems by making documentation a first-class part of the k6 CLI. It gives agents CLI access to k6 docs that automatically detect the k6 version in use and deliver accurate content without leaving the session or performing web searches. How k6 x docs works The use is simple: type k6 x docs, optionally followed by the topic you want to look up. k6 x docs # See all available topics k6 x docs http # Learn about the k6/http module k6 x docs http get # Look up a specific function k6 ## curl performance DevFeed: [curl performance]() Original publisher: [Read original article]() Author: Daniel Stenberg Published: 2026-08-14T11:20:32Z Content type: opinion Language: en Sources: [Daniel Stenberg]() Topics: [cURL](), [Performance Testing](), [Development](), [Shell](), [Git]() Tags: [curl](), [curl-and-libcurl](), [git](), [performance](), [performance-testing](), [shell-script](), [testing]() ### AI overview This article describes an initial performance-testing effort for curl. It explains the difficulty of obtaining stable results on shared cloud infrastructure and outlines a local shell script that updates curl from git, builds it, runs tests, and records data and logs. ### Source excerpt tldr: the live version is here: https://curl.se/perf/ How fast is "fast" and is it good enough? Does it run as fast now as it did before or was there a regression? What exactly needs to be fast? How fast is it? These are questions that many projects and products face, and in curl we are ... Continue reading curl performance -> ## Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA DevFeed: [Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA]() Original publisher: [Read original article]() Author: Maria Fernanda Romano Silva Published: 2026-05-12T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [telemetry](), [Performance Testing](), [cpu](), [Latency](), [Linux](), [Monitoring](), [IO]() Tags: [cpu](), [kernel](), [kubernetes](), [latency](), [linux](), [metrics](), [monitoring](), [performance](), [performance-testing](), [production](), [resource](), [scale](), [telemetry](), [testing](), [v1]() ### AI overview Kubernetes v1.36 graduates Pressure Stall Information (PSI) metrics to general availability, providing stable visibility into CPU, memory, and I/O resource contention at node, pod, and container levels. The article explains PSI signals, moving averages, and performance validation on high-density workloads to assess production readiness and collection overhead. ### Source excerpt Since its original implementation in the Linux kernel in 2018, Pressure Stall Information (PSI) has provided users with the high-fidelity signals needed to identify resource saturation before it becomes an outage. Unlike traditional utilization metrics, PSI tells the story of tasks stalled and time lost, all in nicely-packaged percentages of time across the CPU, memory, and I/O. With the recent release of Kubernetes v1.36, users across the ecosystem have a stable, reliable interface to observe resource contention at the node, pod, and container levels. In this post, we will dive into the improvements and performance testing that proved its readiness for production. Beyond utilization: why PSI? Monitoring CPU or memory usage alone can be misleading. A node may report XX% (below 100%) CPU utilization while certain tasks are experiencing severe latency due to scheduling delays. PSI fills this gap by providing: Cumulative Totals: Absolute time spent in a stalled state. Moving Averages: 10s, 60s, and 300s windows that allow operators to distinguish between transient spikes and sustained resource tension. Proving stability: performance testing at scale A common concern when graduating telemetry features is the resource overhead required to collect and serve the metrics. To address this, SIG Node conducted extensive performance validation on high-density workloads (80+ pods) across various machine types. Our testing focused on two primary scenarios to isolate the impact of the Kubelet and kernel-level collection respectively: Kernel PSI ON / Kubelet Feature OFF vs Kernel PSI ON / Kubelet Feature ON (Kubelet overhead) Kernel PSI OFF / Kubelet Feature ON vs Kernel PSI ON / Kubelet Feature ON (Kernel overhead) Scenario 1: The Kubelet Overhead First, we looked at the kubelet usage on 4 core machines (Case 1). For these, the Linux kernel was already tracking pressure on both clusters by default(psi=1), but we toggled the KubeletPSI feature gate to see if the Kubelet actively qu ## BigQuery connector for ClickPipes is now in Private Preview DevFeed: [BigQuery connector for ClickPipes is now in Private Preview]() Original publisher: [Read original article]() Author: Marta Paes Published: 2026-01-28T16:38:57Z Content type: news Language: en Sources: [ClickHouse Blog]() Topics: [BigQuery](), [clickhouse](), [migration](), [real-time](), [Performance Testing](), [data-architecture](), [datasets](), [Cloud](), [Replication]() Tags: [architecture](), [bigquery](), [clickhouse](), [cloud](), [data](), [datasets](), [migration](), [open-source](), [performance](), [performance-testing](), [real-time](), [replication]() ### AI overview The article announces a private-preview BigQuery connector for ClickPipes, enabling users to load BigQuery data into ClickHouse Cloud for rapid exploration, prototyping, and performance testing. It presents ClickHouse as a low-latency speed layer alongside BigQuery's batch-processing and warehousing workloads, while describing automated data movement and future continuous-ingestion capabilities. ### Source excerpt Load data from BigQuery into ClickHouse Cloud in a few clicks for fast exploration and prototyping. The connector simplifies data migration for testing ClickHouse's real-time query performance on your BigQuery datasets. ## Why Would you Write Tests before Code? DevFeed: [Why Would you Write Tests before Code?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-02-13T17:42:58Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Software Engineering]() Tags: [development](), [monitoring](), [performance-testing](), [tdd](), [testing](), [unit-testing]() ### AI overview The article explains test-driven development as writing tests before implementation to create refactoring capability early. It distinguishes capability testing, which verifies intended feature behavior, from regression testing, which records unexpected user-replicated behavior, and argues that TDD adoption depends more on a mindset shift toward higher-quality delivery than on additional workshops. ### Source excerpt The Test-Driven Elephant In The Room ## Fix your website's Largest Contentful Paint by optimizing image loading DevFeed: [Fix your website's Largest Contentful Paint by optimizing image loading]() Original publisher: [Read original article]() Author: debugbear Published: 2025-01-13T00:00:00Z Content type: tutorial Language: en Sources: [MDN Blog]() Topics: [Core Web Vitals](), [Website](), [Image](), [Optimization](), [HTML](), [Performance Testing](), [real user monitoring](), [Network](), [browser](), [JavaScript](), [CSS]() Tags: [article](), [browser](), [core-web-vitals](), [css](), [how-to](), [html](), [javascript](), [network](), [optimization](), [performance](), [performance-testing](), [user-experience](), [web]() ### AI overview This tutorial explains how image loading affects Largest Contentful Paint and Core Web Vitals. It covers image discovery through HTML, CSS, and JavaScript, request chains, network waterfalls, browser image-processing stages, and techniques for diagnosing and improving loading performance. ### Source excerpt Learn techniques to improve the Largest Contentful Paint metric, a part of Core Web Vitals, for your website. ## Reliability recommendations when adopting Kubernetes DevFeed: [Reliability recommendations when adopting Kubernetes]() Original publisher: [Read original article]() Author: Andre Newman Published: 2024-09-03T00:00:00Z Content type: tutorial Language: en Sources: [Gremlin Blog]() Topics: [Kubernetes](), [migration](), [configuration](), [Performance Testing](), [Application Development]() Tags: [best-practices](), [configuration](), [containers](), [deployment](), [kubernetes](), [migration](), [performance-testing](), [platform](), [production](), [qa](), [quality-assurance](), [resource](), [scale]() ### AI overview This article presents four reliability strategies for organizations adopting Kubernetes. It emphasizes treating reliability as an ongoing practice through regular reliability testing, configuration scans, failure recovery, scalable and replicated deployments, failover planning, and correctly configured liveness, readiness, and resource settings. ### Source excerpt General reliability best practices when adopting Kubernetes. ## Adding Content with Content Migrations in Craft CMS DevFeed: [Adding Content with Content Migrations in Craft CMS]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2024-05-13T14:27:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Content Management System](), [migration](), [PHP](), [Database](), [Command-line interface](), [Performance Testing](), [Development](), [Git]() Tags: [cli](), [cms](), [content](), [craft](), [create](), [database](), [development](), [environments](), [git](), [insights](), [learn](), [migrations](), [performance-testing](), [php](), [syncs]() ### AI overview A tutorial on using content migrations in Craft CMS 5 to create and seed Entries, Fields, Entry Types, and Sections across environments. It explains how migrations can be version-controlled, run through Craft CLI commands, and rolled back after performance testing or other automated content tasks. ### Source excerpt Learn how to create content migrations in Craft CMS 5 to add content that syncs across environments ## Automating performance tests DevFeed: [Automating performance tests]() Original publisher: [Read original article]() Author: Egor Romanov Published: 2024-02-21T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Performance Testing](), [k6](), [WebSocket](), [Streaming](), [Latency](), [Supabase](), [Replication]() Tags: [http](), [k6](), [latency](), [performance](), [performance-testing](), [replication](), [server](), [streaming](), [testing]() ### AI overview This article explains how Supabase developed an automated performance-testing process for its Realtime service. It covers comparing Realtime versions, testing WebSocket workloads such as database changes, broadcast, and presence, evaluating latency, and selecting k6 for load generation. ### Source excerpt Learn about our story to get to the automated performance testing. ## Spotting Latency Regressions Ahead of Time at Teams Mobile DevFeed: [Spotting Latency Regressions Ahead of Time at Teams Mobile]() Original publisher: [Read original article]() Author: Saumye Srivastava Published: 2024-02-02T18:18:47Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Latency](), [Mobile](), [telemetry](), [Android](), [App](), [Grafana](), [Monitoring](), [dashboards](), [Database]() Tags: [android](), [app-performance](), [dashboards](), [database](), [grafana](), [latency](), [mobile](), [monitoring](), [performance](), [performance-testing](), [telemetry](), [user-experience]() ### AI overview This article describes how the Teams Mobile Android team measures and monitors latency in critical app scenarios using scenario telemetry. It explains how execution time, metadata, device information, status, steps, and correlation IDs are recorded and visualized to detect regressions earlier, while noting that latency graphs alone can make diagnosis and rollout response difficult. ### Source excerpt In the realm of mobile applications, subpar performance not only results in user frustration but also contributes to high user dissatisfaction scores (DSAT), a lower app Net Promoter Score (NPS), and increased uninstallations. Developers continually implement numerous code optimizations in each release, bringing about substantial improvements in App Vitals and critical user scenarios such as application launch, chat loading time, and channel loading time. Our Android codebase sees contributions from over 350 developers on a monthly basis, with a staggering 50+ commits merged into the mainline every day. The pace of innovation remains high, as we introduce more than 20 new features daily to our internal users across the organization and our partners. In this dynamic environment, the need to maintain optimal app performance is paramount, emphasizing the importance of identifying and mitigating latency issues before they have a chance to impact user experience. All code is guilty until proven innocent.-- Uncle BobScenario Measurement & Monitoring We employ a method called scenario telemetry to measure execution time at the beginning and end of critical usage scenarios of our app. The latency telemetry for all usage scenarios is recorded in our database along with user details. The ScenarioContext handle facilitates the transfer of context information related to a user scenario throughout the app, including execution time, metadata, device information, status, steps, and correlation ID. fun onCreate() { val scenarioContext = scenarioManager.startScenario(AppScenarioNames.App.APP_START_WARM_FIRST_DRAW); // do critical work, load screen scenarioManager.stopScenario(scenarioContext); } Creating dashboards at Microsoft is a straightforward process, involving crafting a query on our internal portal that our internal framework executes every minute to chart into graphs. You can send the usage telemetry to your internal or third party Database and host a Grafana instance for ## Keeping Figma fast DevFeed: [Keeping Figma fast]() Original publisher: [Read original article]() Author: Slava Kim; Laurel Woods Published: 2023-08-29T00:00:00Z Content type: article Language: en Sources: [Figma Blog]() Topics: [Figma](), [Performance Testing]() Tags: [dev](), [developers](), [figma](), [performance](), [performance-testing](), [testing]() ### AI overview Figma describes how its performance testing system evolved from a single MacBook running repeated scenarios to a more sophisticated approach built for a larger, more complex product and distributed team. The article discusses granular tests, including simulations with many multiplayer editors, and the need to scale testing as features and releases increased. ### Source excerpt When a laptop crashed in an empty office, we knew it was time to overhaul our performance testing framework. ## Pummelling the Platform-Performance Testing Shopify DevFeed: [Pummelling the Platform-Performance Testing Shopify]() Original publisher: [Read original article]() Author: Chris Inch Published: 2020-12-02T16:53:57Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Performance Testing](), [Shopify](), [systems]() Tags: [events](), [experimentation](), [framework](), [performance](), [performance-testing](), [sales](), [shopify](), [testing]() ### AI overview Shopify describes how it uses large-scale performance testing to prepare its platform for major sales events such as Black Friday Cyber Monday. The article covers load testing, stress testing, and an experimentation and regression framework for identifying bottlenecks and improving capacity over time. ### Source excerpt Insight into the tools Shopify uses to raise confidence in our ability to serve large sales events, as well as the experimentation and regression framework built to ensure that we're getting better, week-over-week, at handling load. ## Measuring the Performance of our OpenStack Cloud DevFeed: [Measuring the Performance of our OpenStack Cloud]() Original publisher: [Read original article]() Author: Target Brands, Inc Published: 2017-06-20T05:00:00Z Content type: article Language: en Sources: [Target]() Topics: [openstack](), [Performance Testing](), [Cloud](), [Hardware](), [HTTP](), [Latency](), [Command-line interface](), [Linux]() Tags: [cli](), [cloudpunch](), [configuration](), [hardware](), [http](), [latency](), [linux](), [openstack](), [performance](), [performance-testing]() ### AI overview This article describes Target's effort to measure performance in its private OpenStack cloud. It evaluates Rally and KloudBuster, finding that Rally focuses on API testing while KloudBuster supports HTTP and storage tests but lacks sufficient extensibility, configuration, and stability. The authors therefore decide to create their own flexible performance framework. ### Source excerpt Here at Target, we run our own private OpenStack cloud and have never been able to accurately measure the performance of our hardware. This lack of measurement prevents the evaluation of performance improvements of new hardware or alternative technologies running as drivers inside OpenStack. It also prevents us from providing a Service Level Agreement (SLA) to our customers. Recently we have been striving to improve our OpenStack service which led us to talk to our consumers directly. One of the major feedback points provided by talking with our consumers was the performance of the OpenStack cloud was lower than expected. Because we have not measured the performance of our cloud in the past, we have been unable to know if new hardware or configuration changes improves consumer-facing performance. With our new OpenStack environment builds we focused on changing this. But first we needed a tool to do the job. Searching for a Tool The first tool we looked at was Rally. Rally does performance testing of an OpenStack cloud. However, Rally focuses on the OpenStack API only. It is mainly used to test functionality (via Tempest) and stability of the API under large amounts of load. Rally does contain a resource to boot an instance and run Linux CLI commands via user data. This was tested as a way to provide the staging of instances to run performance software. However, starting the software on each instance at the same time and collecting the results from said software was difficult and not viable. Because of this, we deemed Rally was not suitable for our needs. The next tool we looked at was KloudBuster. KloudBuster is a tool that does performance testing inside an OpenStack instance. At the time of writing it provides two sets of tests: HTTP and storage. The HTTP test uses a traffic generator to measure requests per second and latency between instances. The storage test uses FIO to measure read/write IOPs and bandwidth. KloudBuster does what we were looking for, measuring ## Open Sourcing Daytona: A Framework For Automated and Application-agnostic Performance Analysis DevFeed: [Open Sourcing Daytona: A Framework For Automated and Application-agnostic Performance Analysis]() Original publisher: [Read original article]() Author: mikesefanov Published: 2017-05-23T16:00:06Z Content type: release Language: en Sources: [Yahoo]() Topics: [Testing](), [benchmarking](), [Framework](), [Open Source](), [Tool](), [ui](), [Command-line interface](), [CI/CD](), [Cloud](), [on-prem]() Tags: [architecture](), [ci-cd](), [cloud](), [cloud-services](), [command-line](), [data](), [framework](), [metrics](), [on-prem](), [open-source](), [performance](), [performance-analysis](), [performance-testing](), [systems-engineering](), [tool](), [ui](), [yahoo](), [yahoo-engineering]() ### AI overview Yahoo presents Daytona as an open-source, application-agnostic framework for automated performance testing and analysis. It provides repeatable test execution, standardized reporting, profiling, a unified interface, command-line script support, scheduling, CI/CD integration, and deployment on-premises or in the cloud. ### Source excerpt By Sapan Panigrahi and Deepesh Mittal Today, we are pleased to offer Daytona, an open-source framework for automated performance testing and analysis, to the community. Daytona is an application-agnostic framework to conduct integrated performance testing and analysis with repeatable test execution, standardized reporting, and built-in profiling support. Daytona gives you the capability to build a customized test harness in a single, unified framework to test and analyze the performance of any application. You'll get easy repeatability, consistent reporting, and the ability to capture trends. Daytona's UI accepts a performance testing script that can run on a command line. This includes websites, databases, networks, or any workload you need to test and tune for performance. You can submit tests to the scheduler queue from the Daytona UI or from your CI/CD tool. You can deploy Daytona as a hosted service in your on-prem environment or on the public cloud of your choice. In fact, you can even host test harnesses for multiple applications with a single centralized service so that developers, architects, and systems engineers from different parts of your organization can work together on a unified view and manage your performance analysis on a continuous basis. Daytona's differentiation lies in its ability to aggregate and present essential aspects of application, system, and hardware performance metrics with a simple and unified user interface. This helps you maintain your focus on performance analysis without changing context across various sources and formats of data. The overall goal of performance analysis is to find ways of maximizing application throughput with minimum hardware resource and the best user experience. Metrics and insights from Daytona help achieve this objective. Prior to Daytona, we created multiple, heterogenous performance tools to meet the specific needs of various applications. This meant that we often stored test results inconsistently, maki ## Performance Testing Serverside Applications DevFeed: [Performance Testing Serverside Applications]() Original publisher: [Read original article]() Author: umer Published: 2016-11-16T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [Performance Testing](), [Testing](), [Back end](), [cpu](), [Database](), [Algorithms](), [Graphs]() Tags: [algorithms](), [backend](), [cpu](), [database](), [graph](), [latency](), [metrics](), [performance-testing](), [testing]() ### AI overview The article explains why teams should begin performance testing server-side applications early in the release cycle. It covers load and soak testing, response times, latency, throughput, resource utilization, capacity planning, and bottleneck detection, and describes a backend service whose CPU-intensive database queries and graph algorithms caused substantially lower-than-expected capacity and higher infrastructure costs. ### Source excerpt Performance testing server-side applications is a crucial process to help understand how the application behaves under load. It helps software teams fine-tune their applications to get the best performance while keeping the infrastructure costs low. Performance testing answers several important questions such as: Is the application ready to handle the traffic that's going to hit it? What do average response times and latencies look like under normal and peak loads? Can the application be scaled out? What are the bottlenecks? (could be CPU, memory, an external service or a database server) How many instances are needed for supporting the estimated traffic (i.e. max RPS)? What type of instances are needed? Does the application requires an instance with higher CPU to Memory ratio? Or does it need an instance type that supports high network utilization? Does the application slowly degrade in performance under load? Is it slowly leaking a resource that eventually crashes it after a few hours or days? A lesson I learned recently is that performance testing should not be an after-thought. Software teams should start performance testing early in the release cycle and not wait until the end to do it. I once worked on a team that built a backend service that passed all unit, integration and end-to-end tests with flying colors. QA engineers didn't find any bugs in the application's logic. However, the performance was just terrible when we ran load tests on it. On a single m4.large instance, the application supported 80% fewer requests than the team had estimated! The main bottleneck was found to be the 2-core CPU that was utilized to its maximum capacity as the application issued several queries to the database and applied complex algorithms to build a graph. Investigations by developers revealed that to reduce the amount of work the CPU was doing, it would require significant design changes. But it was already too late - the deadline was just weeks away. We decided to proceed ## test\_awsy\_lite: Android Mochitest Performance Testing with Perfherder DevFeed: [test\_awsy\_lite: Android Mochitest Performance Testing with Perfherder]() Original publisher: [Read original article]() Author: gbrown-mozilla Published: 2016-01-27T13:39:53Z Content type: article Language: en Sources: [Mozilla Automation]() Topics: [Android](), [Testing](), [Performance Testing](), [Mobile](), [Hardware]() Tags: [android](), [firefox-for-android](), [measurements](), [memory](), [mobile](), [mozilla](), [performance-testing](), [testing]() ### AI overview The article discusses test_awsy_lite.html, an Android-only mochitest-chrome test inspired by areweslimyet.com. It compares the approach with custom harnesses such as Talos, covering local debugging, Perfherder reporting, emulator limitations, runtime constraints, and the use of Resident memory measurements. ### Source excerpt Bug 1233220 added a new Android-only mochitest-chrome test called test_awsy_lite.html. Inspired by https://www.areweslimyet.com/mobile/, test_awsy_lite runs similar code and takes similar ... Continue reading -> ## Investigating L3 Cache Contention in Micro-Benchmarks and Larger Applications DevFeed: [Investigating L3 Cache Contention in Micro-Benchmarks and Larger Applications]() Original publisher: [Read original article]() Author: Michael Barker (noreply@blogger.com) Published: 2014-12-03T01:13:00Z Content type: article Language: en Sources: [Bad Concurrency]() Topics: [Cache](), [Benchmark](), [cpu](), [Performance Testing](), [Concurrency]() Tags: [benchmarks](), [cache](), [cpu](), [performance](), [performance-testing](), [thread]() ### AI overview The article investigates why a LevelDB micro-benchmark reached about 400K operations per second while the same code could not sustain a 160K operations-per-second requirement in an end-to-end environment. It attributes the difference to shared L3 cache contention among concurrent threads in the larger application. ### Source excerpt While preparing for my talk at QCon SF 2014, I wanted to investigate a theory around how micro-benchmarks are not a useful reflection of how software may behave when run as part of a larger application. Specifically due contention in the last-level cache (L3* in current Intel CPUs). Read more " ## Speeding up Rails 4.2 DevFeed: [Speeding up Rails 4.2]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2014-12-01T04:30:19Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [Rails](), [Benchmark](), [Performance Testing](), [Ruby]() Tags: [benchmark](), [performance-testing](), [rails](), [ruby](), [testing]() ### AI overview This article examines Rails 4.2 performance using the Discourse benchmark, a macrobenchmark that loads users and topics and measures performance with Apache Bench. Initial results showed Rails 4.2 running at about half the speed of the earlier setup, prompting efforts to identify and fix the regressions before release. ### Source excerpt Recently Godfrey Chan got Discourse working on Rails Master. It was a rather long task that involved some changes to Discourse internals and some changes to Rails internals. Knowing Rails 4.2 was just around the corner I decided that it seemed like the perfect time to see how performance is. Seeing Rails 4.2 contains the adequate record patches, I was super eager to see how Discourse fared. ###The Discourse benchmark Answering the question of "how fast is Ruby?" or "how fast is Rails?" is something people usually answer with the following set of steps. Upgrade production to a certain version of Rails Look at New Relic reports Depending on how performance is either complain on Twitter and/or Blog or write a few kind words. The trouble is that performance testing after release is the absolute worst time. Code is in production, fixing stuff is tricky, rolling back often impractical. At Discourse I developed the Discourse benchmark. It is a simple script that loads up a few thousand users and topics and then proceeds to measure performance of various hot spots using apache bench. I have found that the results of the benchmark are strikingly similar to real-world performance we see. If the benchmark is faster, it is very likely that it will also be faster in production. We use this benchmark to test Ruby before major Ruby releases. Koichi used this benchmark to help optimise the current GC algorithms in MRI. It is often tempting to look at micro benchmarks when working on performance issues. Micro benchmarks are a great tool, but MUST be followed with bigger macro benchmarks to see the real impact. 1000% speedup for a routine that is called once a day in a background job has significantly less impact than 0.5% improvement to a routine that is called on every web request. ###How was Rails 4.2 Looking? For over a year now, Discourse had the ability to dual boot. This allowed me to quickly run a simple benchmark to see where we were at (arel , rails): % RAILS_MASTER=1 ruby