BenchmarkXPRT Blog banner

Category: Performance benchmarking

The WebXPRT 4 tech press feedback survey

Justin Greene
By Justin Greene
on May 6, 2021

Device reviews in publications such as AnandTech, Notebookcheck, and PCMag, among many others, often feature WebXPRT test results, and we appreciate the many members of the tech press that use WebXPRT. As we move forward with the WebXPRT 4 development process, we’re especially interested in learning what longtime users would like to see in a new version of the benchmark.  

In previous posts, we’ve asked people to weigh in on the potential addition of a WebAssembly workload or a battery life test. We’d also like to ask experienced testers some other test-related questions. To that end, this week we’ll be sending a WebXPRT 4 survey directly to members of the tech press who frequently publish WebXPRT test results.

Regardless of whether you are a member of the tech press, we invite you to participate by sending your answers to any or all the questions below to benchmarkxprtsupport@principledtechnologies.com. We ask you to do so by the end of May.

  • Do you think WebXPRT 3’s selection of workload scenarios is representative of modern web tasks?
  • How do you think WebXPRT compares to other common browser-based benchmarks, such as JetStream, Speedometer, and Octane?
  • Are there web technologies that you’d like us to include in additional workloads?
  • Are you happy with the WebXPRT 3 user interface? If not, what UI changes would you like to see?
  • Are there any aspects of WebXPRT 2015 that we changed in WebXPRT 3 that you’d like to see us change back?
  • Have you ever experienced significant connection issues when testing with WebXPRT?
  • Given the array of workloads, do you think the WebXPRT runtime is reasonable? Would you mind if the average runtime were a bit longer?
  • Are there any other aspects of WebXPRT 3 that you’d like to see us change?

If you’d like to discuss any topics that we did not cover in the questions above, please feel free to include additional comments in your response. We look forward to hearing your thoughts!

Justin

Posted in Battery life, benchmark, Benchmarking, BenchmarkXPRT, Browser-based benchmarks, Collaborative benchmark development, Cross-platform benchmarks, Future of performance evaluation, Performance benchmarking, WebAssembly, WebXPRT, WebXPRT 2015, WebXPRT 3, webxprt 4, What makes a good benchmark? | Tagged , , , , , , , , , , , |

WebXPRT passes the 750,000-run milestone!

Justin Greene
By Justin Greene
on April 29, 2021

We’re excited to see that users have successfully completed over 750,000 WebXPRT runs! If you’ve run WebXPRT in any of the more than 654 cities and 68 countries from which we’ve received complete test data—including newcomers Belize, Cambodia, Croatia, and Pakistan—we’re grateful for your help. We could not have reached this milestone without you!

As the chart below illustrates, WebXPRT use has grown steadily over the years. We now record, on average, almost twice as many WebXPRT runs in one month as we recorded in the entirety of our first year. In addition, with over 82,000 runs to date in 2021, there are no signs that growth is slowing.

Developing a new benchmark is never easy, and the obstacles multiply when you attempt to create a cross-platform benchmark, such as WebXPRT, that will run on a wide variety of devices. Establishing trust with the benchmarking community is another challenge. Transparency, consistency, and technical competency on our part are critical factors in building that trust, but the people who take time out of their busy schedules to run the benchmark for the first time also play a role. We thank all of the manufacturers, OEM labs, and members of the tech press who decided to give WebXPRT a try, and we look forward to your input as we continue to improve WebXPRT in the years to come. 

If you have any questions or comments about WebXPRT, we’d love to hear from you!

Justin

Posted in benchmark, Benchmark metrics, Benchmarking, BenchmarkXPRT, Browser-based benchmarks, Performance benchmarking, WebXPRT, WebXPRT 2013, WebXPRT 3, webxprt 4, What makes a good benchmark? | Tagged , , , , , , |

Default requirements for CloudXPRT results submissions

Justin Greene
By Justin Greene
on April 22, 2021

Over the past few weeks, we’ve received questions about whether we require specific test configuration settings for official CloudXPRT results submissions. Currently, testers have the option to edit up to 12 configuration options for the web microservices workload and three configuration options for the data analytics workload. Not all configuration options have an impact on testing and results, but a few of them can drastically affect key results metrics and how long it takes to complete a test. Because new CloudXPRT testers may not anticipate those outcomes, and so many configuration permutations are possible, we’ve come up with a set of requirements for all future results submissions to our site. Please note that testers are still free to adjust all available configuration options—and define service level agreement (SLA) settings—as they see fit for their own purposes. The requirements below apply only to results testers want to submit for publication consideration on our site, and to any resulting comparisons.


Web microservices results submission requirement

Starting with the May results submission cycle, all web microservices results submissions must have the workload.cpurequestsvalue, which lets the user designate the number of CPU cores the workload assigns to each pod, set to 4. Currently, the benchmark supports values of 1, 2, and 4, with the default value of 4. While 1 and 2 CPU cores per pod may be more appropriate for relatively low-end systems or configurations with few vCPUs, a value of 4 is appropriate for most datacenter processors, and it often enables CSP instances to operate within the benchmark’s max default 95th percentile latency SLA of 3,000 milliseconds.

In future CloudXPRT releases, we may remove the option to change the workload.cpurequests value from the config.json file and simply fix the value in the benchmark’s code to promote test predictability and reasonable comparisons. For more information about configuration options for the web microservices workload, please consult the Overview of the CloudXPRT Web Microservices Workload white paper.


Data analytics results submission requirement

Starting with the May results submission cycle, all data analytics results submissions must have the best reported performance (throughput_jobs/min) correspond to a 95th percentile SLA latency of 90 seconds or less. We have received submissions where the throughput was extremely high, but the 95th percentile SLA latency was up to 10 times the 90 seconds that we recommend in CloudXPRT documentation. High latency values may be acceptable for the unique purposes of individual testers, but they do not provide a good basis for comparison between clusters under test. For more information about configuration options with the data analytics workload, please consult the Overview of the CloudXPRT Data Analytics Workload white paper.

We will update CloudXPRT documentation to make sure that testers know to use the default configuration settings if they plan to submit results for publication. If you have any questions about CloudXPRT or the CloudXPRT results submission process, please let us know.

Justin

Posted in BenchmarkXPRT, Cloud, CloudXPRT, Clusters, data analytics, Datacenter, IaaS, microservices, Performance benchmarking, results, results submission, Servers, web microservices, White papers | Tagged , , , , , , , , |

Considering WebAssembly for WebXPRT 4

Justin Greene
By Justin Greene
on March 25, 2021

Earlier this month, we discussed a few of our ideas for possible changes in WebXPRT 4, including new web technologies that may work well in a browser benchmark. Today, we’re going to focus on one of those technologies, WebAssembly, in more detail.

WebAssembly (WASM) is a binary instruction format that works across all modern browsers. WASM provides a sandboxed environment that operates at native speeds and takes advantage of common hardware specs across platforms. WASM’s capabilities offer web developers a great deal of flexibility for running complex client applications in the browser. That level of flexibility may enable workload scenario options for WebXPRT 4 such as gaming, video editing, VR, virtual machines, and image recognition. We’re excited about those possibilities, but it remains to be seen which WASM use cases will meet the criteria we look for when considering new WebXPRT workloads, such as relevancy to real life, consistency and replicability, and the broadest-possible level of cross-browser support.

One WASM workload that we’re investigating is a web-based machine learning workload with TensorFlow for JavaScript (TensorFlow.js). TensorFlow.js offers pre-trained models for a wide variety of tasks, including image classification, object detection, sentence encoding, and natural language processing. TensorFlow.js originally used WebGL technology on the back end, but now it’s possible to run the workload using WASM. We could also use this technology to enhance one of WebXPRT’s existing AI-themed workloads, such as Organize Album using AI or Encrypt Notes and OCR Scan.

We’re can’t yet say that a WASM workload will definitely appear in WebXPRT 4, but the technology is promising. Do you have any experience with WASM, or ideas for WASM workloads? There’s still time for you to help shape the future of WebXPRT 4, so let us know what you think!

Justin

Posted in benchmark, BenchmarkXPRT, Browser-based benchmarks, Collaborative benchmark development, Cross-platform benchmarks, image processing, Machine learning, Performance benchmarking, TensorFlow, Virtual reality, Web-based testing, WebAssembly, WebGL, WebXPRT, WebXPRT 3 | Tagged , , , , , , , , , |

CrXPRT support through 2022

Justin Greene
By Justin Greene
on March 18, 2021

CrXPRT testers may remember that back around the time that we began the CrXPRT 2 development process, the Chrome team announced that they were phasing out support for Portable Native Client (PNaCL) in favor of WebAssembly (WASM). As a first step, they changed the Chrome OS setting that enabled PNaCL by default. At the time, this caused problems with the Photo Collage workload in CrXPRT 2015, and even though we identified a workaround, details in the Chrome team’s announcement led us to conclude that the workaround might stop working in June 2021. Because of this change, we decided that the best decision would be to remove the workload from CrXPRT 2, and keep existing CrXPRT 2015 testers informed of any changes with the workaround.

In 2020, the Chrome team also announced that they would be phasing out support for Chrome Apps altogether starting in June 2021, and would shift their focus to Chrome extensions. This change would have required us to reassess the viability of CrXPRT in anything like its current form.

We’re happy to report that the Chrome team has extended support for PNaCL and existing Chrome Apps through June 2022. Barring further changes, this means that CrXPRT 2015 (with the workaround) and CrXPRT 2 should continue to serve as reliable Chrome OS evaluation tools for some time.

If you have any questions about CrXPRT 2, please let us know!

Justin

Posted in benchmark, Benchmarking, BenchmarkXPRT, Browser-based benchmarks, Chrome OS, Chromium, CrXPRT, Google Chrome, Performance benchmarking, PNaCL, WebAssembly | Tagged , , , , , , , |

The CloudXPRT v1.1 general release is tomorrow!

Justin Greene
By Justin Greene
on March 11, 2021

We’re happy to announce that CloudXPRT v1.1 will move from beta to general release status tomorrow! The installation packages will be available at the CloudXPRT.com download page and the BenchmarkXPRT GitHub repository. You will find more details about the v1.1 updates in a previous blog post, but the most prominent changes are the consolidation of the five previous installation packages into two packages (one per workload) and added support for Ubuntu 20.04.2 with on-premises testing.

Before you get started with v1.1, please note the following updated system requirements:

  • Ubuntu 20.04.2 or later for on-premises testing
  • Ubuntu 18.04 and 20.04.2 or later for CSP (AWS/Azure/GCP) testing

CloudXPRT is designed to run on high-end servers. Physical nodes or VMs under test must meet the following minimum specifications:

  • 16 logical or virtual CPUs
  • 8 GB of RAM
  • 10 GB of available disk space (50 GB for the data analytics workload)

We have also made significant adjustments to the installation and test configuration instructions in the readmes for both workloads, so please revisit these documents even if you’re familiar with previous test processes.

As we noted during the beta period, we have not observed any significant differences in performance between v1.01 and v1.1, but we haven’t tested every possible test configuration across every platform. If you observe different results when testing the same configuration with v1.01 and v1.1, please send us the details so we can investigate.

If you have any questions about CloudXPRT v1.1, please let us know!

Justin

Posted in Amazon Web Services, benchmark, Benchmarking, BenchmarkXPRT, Cloud, CloudXPRT, Clusters, Cross-platform benchmarks, CSP, data analytics, Datacenter, Google Cloud Platform, Hosted cloud, Hybrid cloud, IaaS, Microsoft Azure, on premises, Performance benchmarking, Server, Ubuntu, web microservices | Tagged , , , , , , , , |

Check out the other XPRTs:

Forgot your password?
© Principled Technologies, Inc. 2024   |   Privacy policy

Cookie Notice: Our website uses cookies to deliver a smooth experience by storing logins and saving user information. By continuing to use our site, you agree with our usage of cookies as our privacy policy outlines.

x