Cloud

The pace of progress with AI model architectures is staggering, driven by breakthrough inventions such as Transformer, and by rapid growth in high-quality training data. In generative AI, for instance, large language models (LLMs) have been growing in size by as much as 10x per year. Organizations are deploying these AI models in their products and services, driving the exponential growth in demand for AI-accelerated computing for AI training and inference, to reliably and efficiently serve AI models to users across the world.

The latest MLPerf™ 3.1 Inference results1 showcase how Google’s systems breakthroughs enable our customers to keep pace with the ever-growing compute demands of the latest AI models. Google Cloud inference systems deliver between a factor of 2-4x performance improvement and more than a factor of 2x cost-efficiency improvement over existing offerings. At Google Cloud, we are proud to be the only cloud provider to offer a wide range of high-performance, cost-efficient, and scalable AI inference offerings powered by both NVIDIA GPUs and Google Cloud’s purpose-built Tensor Processor Units (TPUs).

GPU-accelerated AI inference on Google Cloud

Google Cloud and NVIDIA continue to partner to help bring the most advanced GPU-accelerated inference platform to our customers. In addition to the A2 VM powered by NVIDIA’s A100 GPU, we recently launched the G2 VM, the cloud industry’s first and only offering powered by the NVIDIA L4 Tensor Core GPU. In addition, our next-generation A3 VMs, powered by the H100 GPU, are in private preview and will be generally available in the next month. Google Cloud is the only cloud provider to offer all three of these NVIDIA-powered AI accelerators. 

With the superb MLPerf™ 3.1 Inference Closed results of the H100 GPU, the A3 VM delivers between 1.7x-3.9x relative performance improvement over the A2 VM for demanding inference workloads. The Google Cloud G2 VM powered by the L4 GPU, meanwhile, is a great choice for customers looking to optimize inference cost-efficiency. NVIDIA’s MLPerf™ 3.1 results for the L4 GPU speak to G2’s strengths:  up to 1.8x improvement in performance per dollar than a comparable public cloud inference offering. Google Cloud customers such as Bending Spoons are using G2 VMs to deploy new AI-powered experiences for their end users.

We derived our performance per dollar metrics, which we use throughout this blog post, from the results of MLPerf™ v3.1 Inference Closed. All prices are current at the time of publication. Performance per dollar is not an official MLPerf™ metric and is not verified by MLCommons® Association.

Cost-efficient AI inference at scale using Cloud TPUs

The new Cloud TPU v5e, announced at Google Cloud Next, enables high-performance and cost-effective inference for a broad range AI workloads, including the latest state-of-the-art LLMs and generative AI models. Designed to be efficient, scalable, and versatile, Cloud TPU v5e delivers high-throughput and low-latency inference performance. Each TPU v5e chip provides up to 393 trillion int8 operations per second (TOPS), allowing fast predictions for the most complex models.

Our high-speed inter-chip interconnect (ICI) allows Cloud TPU v5e to scale out to the largest models with multiple TPUs working in tight unison. Our MLPerf™ 3.1 inference results use four TPU v5e chips to run the 6-billion-parameter GPT-J LLM benchmark. TPU v5e delivers 2.7x higher performance per dollar compared to TPU v4:

Similarly to the G2 performance per dollar metrics, we derived the performance per dollar metrics for the TPU3 from the results of MLPerf™ v3.1 Inference Closed. All prices are current at the time of publication. Performance per dollar is not an official MLPerf™ metric and is not verified by MLCommons® Association2.

The 2.7x gain in performance per dollar is possible thanks to an optimized inference software stack that takes full advantage of the powerful TPU v5e hardware, allowing it to match the QPS of the Cloud TPU v4 system on the GPT-J LLM benchmark. The inference stack uses SAX, a system created by Google DeepMind for high-performance AI inference, and XLA, Google’s AI compiler. Key optimizations include:

XLA optimizations and fusions of Transformer operators 

Post-training weight quantization with int8 precision

High-performance sharding across the 2×2 topology using GSPMD

Bucketized execution of batches of prefix computation and decoding in SAX

Dynamic batching in SAX

While these results showcase inference performance in four-chip configurations, TPU v5e scales seamlessly via our ICI from 1 chip to 256 chips, enabling the platform to flexibly support a range of inference and training requirements. As shown below, a 256-chip 16×16 TPU v5e topology supports inference for up to 2 trillion parameter models. With our newly available multi-slice training and multi-host inference software, Cloud TPU v5e can further scale to multiple 256-chip pods, enabling customers to leverage the same technology used internally by Google to meet the requirements of the largest and most complex model training and serving systems.

Accelerating your AI innovation at scale

With a full range of high-performance, cost-efficient AI inference choices powered by GPUs and TPUs, Google Cloud is uniquely positioned to empower organizations to accelerate their AI workloads at scale: 

“Our team is a huge fan of Google Cloud’s AI infrastructure solution and we use Google Cloud G2 GPU VMs for the ‘AI Filter’ feature in our AI photography app, Remini, including for the latest filters – ‘Barbie and Ken.’ Using G2 VMs has allowed us to considerably lower latency times for processing by up to 15 seconds per task. Google Cloud has also been instrumental in helping us seamlessly scale up to 32,000 GPUs at peak times like when our Remini app soared into the No. 1 overall position on the U.S. App Store and down to a daily average of 2,000 GPUs.” — Luca Ferrari, CEO and Co-Founder, Bending Spoons

“Cloud TPU v5e consistently delivered up to 4X greater performance per dollar than comparable solutions in the market for running inference on our production model. The Google Cloud software stack is optimized for peak performance and efficiency, taking full advantage of the TPU v5e hardware that was purpose-built for accelerating the most advanced AI and ML models. This powerful and versatile combination of hardware and software dramatically accelerated our time-to-solution: instead of spending weeks hand-tuning custom kernels, within hours we optimized our model to meet and exceed our inference performance targets.” — Domenic Donato, VP of Technology, AssemblyAI

“YouTube is using the TPU v5e platform to serve recommendations on YouTube’s Homepage and WatchNext to billions of users. TPU v5e delivers up to 2.5x more queries for the same cost compared to the previous generation.” — Todd Beaupré, Director of Product Management, YouTube

To get started with Google Cloud GPUs and TPUs, reach out to your Google Cloud account manager or contact Google Cloud sales.

1. MLPerf™ v3.1 Inference Closed, multiple benchmarks as shown, Offline, 99%. Retrieved September 11th, 2023 from mlcommons.org. Results 3.1-0106, 3.1-0107, 3.1-0120, 3.1-0143. Performance per dollar is not an MLPerf metric.TPU v4 results are Unverified: not verified by MLCommons Association. The MLPerf™ name and logo are trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.orgfor more information.
2. To derive performance per dollar for the Oracle BM GPU v2.8, we divided the QPS that Oracle submitted for the A100 results by $32.00, the publicly available server price per hour (US$). The Oracle system used 8 chips. To derive G2 performance per dollar, we divided the QPS from the L4 result by $0.85, the publicly available on-demand price per chip-hour (US$) for g2-standard-8 (a comparable Google instance type with a publicly available price point) in the us-central1 region. The L4 system used 1 chip.
3. To derive TPU v5e performance per dollar, we divided the QPS by the number of chips (4) used multiplied by $1.20, which is the publicly available on-demand price per chip-hour (US$) for TPU v5e in the us-west4 region. To derive TPU v4 performance per dollar, we divided the QPS (internal Google Cloud results, not verified by MLCommons Association) by the number of chips multiplied by $3.22, the publicly available on-demand price per chip-hour (US$) for TPU v4 in the us-central2 region.

Imagine that you’re a Java developer who has just joined a new company, and you’re tasked with creating a small Java service. In a DevOps model, the shared responsibility between Development and Operations teams might mean that you’ll not only be expected to write Java code, but also operations code like build pipelines and monitoring instrumentation. Plus, your new company uses a different cloud platform than the one you learned in your old job.

Suddenly, you’re drowning in YAML files, and building that small Java service becomes a big challenge. You’re faced with a slew of decisions: how should I structure my code? Which tool do I use for continuous delivery?

The reality of the DevOps model is that it often introduces cognitive overhead that is unsustainable for developers, raising the barriers to onboarding, slowing productivity, and causing burnout.

Platform Engineering is the practice of building useful abstractions and self-service infrastructure within an organization, to unify scattered tools and accelerate developer productivity. Platform Engineering aims to mitigate the cognitive overload caused by a shared-responsibility model that’s gone too far, by smoothing the day-to-day developer experience.

So what kind of abstractions and self-service infrastructure would best serve developers? This brings us to the idea of a Golden Path.

What is a Golden Path?

The Cloud Native Computing Foundation defines a Golden Path as a “templated composition of well-integrated code and capabilities for rapid project development.”  Simply put, it is a self-service template for common tasks.

Imagine that instead of fending for yourself amidst a sea of tools and infrastructure, you are provided with a Java Spring Boot Golden Path Template on your first day at work. This is a source code repository containing:

A getting-started tutorial 

Skeleton source code  

Dependency management 

CI/CD pipeline template 

Cloud infrastructure-as-code template

Kubernetes YAML files 

Policy guardrails

Logging and monitoring instrumentation 

Reference documentation  

This Golden Path not only helps you onboard to the Java recommended practices within your new organization, but also provides a forkable repo template to get building fast.

Now imagine that your new company provides multiple Golden Path templates, each serving common tasks, from “React Web Frontend” to “Machine Learning with Python.” No developer is left in the dark to fend for themselves; Golden Paths light the way.

Who is a Golden Path for?

Golden Paths can benefit multiple personas within your organization. They help application developers onboard and get building faster by providing a clear pathway to supported tooling— less bespoke infrastructure code to maintain later. If multiple application teams build on the same golden path, they have a common foundation that aids information-sharing, inspires the creation of shared tools, and improves agility and mobility across the org.

That same consistency makes it easier for Site Reliability Engineers (SREs) to monitor a portfolio of production services. For instance, if most services at the company use the same metrics exporters and labels, this can accelerate debugging during an outage.

Golden Paths also provide Security Administrators with a clear means to implement policy guardrails. For instance, if the Security team has new requirements on firewall rules, they can work with the Platform team to update the Golden Path templates.

Lastly, Golden Paths can help the entire organization by optimizing costs. For instance, a Golden Path for a Kubernetes-based service can create a Namespace in a GKE Autopilot cluster, instead of creating a large, dedicated GKE cluster where most capacity goes unused. This allows infrastructure-level optimizations to be defined and abstracted away.

This is an incomplete list of people who can benefit from a set of Golden Paths. From Developers and Machine Learning Engineers, to Testers and FinOps, common abstractions and easy self-service can benefit everyone.

Golden Path Principles

No two Golden Paths will look the same— that’s okay! However, Golden Paths often share a common set of principles:

Provide a single, clear, opinionated method to accomplish a specific task.

Reduce the cognitive load on the target audience using abstraction and getting-started documentation.

Integrate with existing internal developer platforms. A Golden Path should work on top of the abstracted infrastructure managed by the platform team: for instance, if a developer creates a new service with a Golden Path, that should spawn a new software catalog entry.  Another example: if a Golden Path repo contains a Kubernetes Deployment template, that Deployment should be applied to a platform team-managed GKE cluster and namespace.

Light the complete path from development to production. This might include instructions for local development, a templated CI/CD pipeline, and infrastructure as code templates for staging and production. 

Be self-service. Any developer in the organization should be able to discover and use the Golden Paths — no ticketing system required.

Provide a transparent abstraction without hiding the underlying infrastructure. Under a DevOps shared responsibility model, developers will eventually need to understand the full stack of their own services to maintain, optimize, and debug them.

Address your organization’s specific needs. Is your organization primarily dealing with “brownfield” migrations, with few new “greenfield” services? Consider building Golden Paths for supported migration paths.

Allow for flexibility to support the requirements of multiple audiences. For instance, a Golden Path could support a SQL database like Spanner by default, but make it easy to swap in a NoSQL database like Firestore.

Be optional. A developer should not be forced to adopt a Golden Path if it does not fulfill their needs.

Golden Path Practices

We’ve covered the who, what, and why of Golden Paths. Now let’s discuss when and how. 

When to build Golden Paths?

Building and maintaining a Golden Path has a cost. You might work in a small organization with few services; in this case, the cost of building a Golden Path may exceed the benefits. We recommend creating your first Golden Paths if you have several services that look similar — think similar frameworks running on similar infrastructure.

We also recommend taking a look at the day-to-day friction of a typical developer in the org. Industry-specific regulations or complex, heterogeneous infrastructure environments are both cases where abstractions provided by a Golden Path could benefit developers and your business— even if the Golden Path is serving only a few teams. 

How to choose a Path?

Let’s say your organization has fifty dev teams working across four programming languages. How can you choose what Golden Paths to build first?

To start, work with the teams to identify common patterns. Perhaps your front-end developers are using both Flutter and React. Maybe you should build two frontend web Golden Path templates: one for Flutter, and one for React. Only have time to build one? Perhaps choose the simpler architecture, or identify a team with the excitement and bandwidth to co-develop and test-drive the first Golden Path.

Who builds and maintains?

Golden Path templates are technical artifacts that need to be built, documented, and maintained. We recommend that each template is co-developed by at least two people/teams, spanning both the platform team and at least one stakeholder team. 

Why co-develop? First, to ensure that the platform team can build consistency across multiple Golden Paths— for instance, to ensure all Golden Paths in the org use the same infrastructure as code stack. Second, to ensure that the stakeholder teams have a say in what goes into the template. Involving application development teams from the beginning can increase the likelihood that the Golden Path template is adopted.

Long-term maintenance and iteration of Golden Path templates will vary depending on your organization’s velocity, total number of Golden Paths supported, and the overall adoption of the Golden Path. One route could be for the platform team to own the maintenance and version control of all Golden Path templates, but accept contributions from other teams.

Overall, adopting a shared responsibility model for Golden Paths highlights the best of DevOps culture, where communication, shared learning, and high cooperation are rewarded and benefit everyone involved.

Measuring success and iterating

Let’s say you’ve identified, designed, built, and released your first Golden Path templates. How can you determine whether they’re successful? 

First, it’s important to identify what success looks like in your organization. Is it improved developer satisfaction? More releases per quarter? Try looking at your internal platform as a product: what does the success of that product look like? 

Some metrics might be easy to measure: for instance, the number of new services that have adopted the golden paths. Set KPIs and quantitative goals; build dashboards to track Golden Path adoption within your organization.

Other metrics are harder to measure. How do you measure developer autonomy? Or reduced coordination costs between teams? Here, qualitative measurements like internal developer surveys can help. Establish support channels to gather feedback from the users of your Golden Paths, and don’t be afraid to iterate if the first implementation misses the mark.

As your quantitative and qualitative measurements come together, use the feedback to build a roadmap and release schedule to share with dev teams. You may even want to market and promote your platform with newsletters or lunch and learn sessions to raise awareness of your latest Golden Path features.

Light the way!

This post gave a high-level introduction to Golden Paths, exploring how self-service abstractions can boost engineering velocity and collaboration across teams. Hopefully this post inspires you to think about what kind of Golden Paths you’d like to use or build within your organization.

Not sure where to start? Check out the Google Cloud Terraform Blueprints page for example bundles of Google Cloud infrastructure as code. Still wrapping your head around Platform Engineering as a whole? Check out this blog post from Google’s Alex McWilliam on Platform Engineering pitfalls, and the CNCF Whitepaper on Platform Engineering.

Background

With the increasing popularity of AI-generated content (AIGC), open-source projects based on text-to-image AI models such as MidJourney and Stable Diffusion have emerged. Stable Diffusion is a diffusion model that generates realistic images based on given text inputs. In this GitHub repository, we provide three different solutions for deploying Stable Diffusion quickly on Google Cloud Vertex AI, Google Kubernetes Engine (GKE), and Agones-based platforms, respectively, to ensure stable service delivery through elastic infrastructure. This article will focus on the Stable Diffusion model on GKE and improve launch times by up to 4x.

Problem statement

The container image of Stable Diffusion is quite large, reaching approximately 10-20GB, which slows down the image pulling process during container startup and consequently affects the launch time. In scenarios that require rapid scaling, launching new container replicas may take more than 10 minutes, significantly impacting user experience.

During the launch of the container, we can see following events in chronological order:

Triggering Cluster Autoscaler for scaling + Node startup and Pod scheduling: 225 seconds

Image pull startup: 4 seconds

Image pulling: 5 minutes 23 seconds

Pod startup: 1 second

sd-webui serving: more than 2 minutes

After analyzing this time series, we can see that the slow startup of the Stable Diffusion WebUI running in the container is primarily due to the heavy dependencies of the entire runtime, resulting in a large container image size and prolonged time for image pulling and pod initialization. 

Therefore, we consider optimizing the startup time from the following three aspects:

Optimizing the Dockerfile: Selecting the appropriate base image and minimizing the installation of runtime dependencies to reduce the image size.

Separating the base environment from the runtime dependencies: Accelerating the creation of the runtime environment through PD disk images.

Leveraging GKE Image Streaming: Optimizing image loading time by utilizing GKE Image Streaming and utilizing Cluster Autoscaler to enhance elastic scaling and resizing speed.

This article focuses on introducing a solution to optimize the startup time of the Stable Diffusion WebUI container by separating the base environment from the runtime dependencies and leveraging high-performance disk image.

Optimizing the Dockerfile

First of all, here’s a reference Dockerfile based on the official installation instructions for the Stable Diffusion WebUI:

https://github.com/nonokangwei/Stable-Diffusion-on-GCP/blob/main/Stable-Diffusion-UI-Agones/sd-webui/Dockerfile

In the initial building container image for the Stable Diffusion, we found that besides the base image NVIDIA runtime, there were also numerous installed libraries, dependencies and extensions

In terms of optimizing the Dockerfile, after analyzing the Dockerfile, we found that the nvidia runtime occupies approximately 2GB, while the PyTorch library is a very large package, taking up around 5GB. Additionally, Stable Diffusion and its extensions also occupy some space. 

Therefore, following the principle of minimal viable environment, we can remove unnecessary dependencies from the environment. 

We can use the NVIDIA runtime as the base image and separate the PyTorch library, Stable Diffusion libraries, and extensions from the original image, storing them separately in the file system. Below is the original Dockerfile snippet,

After moving out Pytorch libraries and Stable diffusion, we only retained the NVIDIA runtime in the base image, here is the new Dockerfile.

Using PD disks images to store libraries 

PD Disk images are the cornerstone of instance deployment in Google Cloud. Often referred to as templates or bootstrap disks, these virtual images contain the baseline operative system, and all the application software and configuration your instance will have upon first boot.  The idea here is to store all the runtime libraries and extensions in a disk image, which in this case has a size of 6.77GB. The advantage of using a disk image is that it can support up to 1000 disk recoveries simultaneously, making it suitable for scenarios involving large-scale scaling and resizing.

We use a DaemonSet to mount the disk when GKE nodes start. 

The specific steps are as follows:

As described in previous sections, in order to speed up initial launch for better performance, we’re trying to mount a persistent disk to GKE nodes to place runtime libraries for stable diffusion.

Leveraging GKE Image Streaming and Cluster Autoscaler

In addition, as mentioned earlier, we have also enabled GKE Image Streaming to accelerate the image pulling and loading process. GKE Image Streaming works by using network mounting to attach the container’s data layer to containerd and supporting it with multiple cache layers on the network, memory, and disk. Once we have prepared the Image Streaming mount, your containers transition from the ImagePulling state to Running in a matter of seconds, regardless of the container size. This effectively parallelizes the application startup with the data transfer of the required data from the container image. As a result, you can experience faster container startup times and faster automatic scaling.

We have enabled the Cluster Autoscaler (CS) feature, which allows the GKE nodes to automatically scale up when there are increasing requests. Cluster Autoscaler triggers and determines the number of nodes needed to handle the additional requests. When the Cluster Autoscaler initiates a new scaling wave and the new GKE nodes are registered in the cluster, the DaemonSet starts working to assist in mounting the disk image that contains the runtime dependencies. The Stable Diffusion Deployment then accesses this disk through the HostPath. Additionally, we have utilized the Optimization Utilization Profile of the Cluster Autoscaler, a profile on GKE CA that prioritizes optimizing utilization over keeping spare resources in the cluster, to reduce the scaling time, save costs, and improve machine utilization.

Final results 

The final startup result is as below:

In chronological order:

Triggering Cluster Autoscaler for scaling: 38 seconds

Node startup and Pod scheduling: 89 seconds

Mounting PVC: 4 seconds

Image pull startup: 10 seconds

Image pulling: 1 second

Pod startup: 1 second

Ability to provide sd-webui service (approximately): 65 seconds

Overall, it took approximately 3 minutes to start a new Stable Diffusion container instance and start serving on a new GKE node. Compared to the previous 12 minutes, it is evident that the significant improvement in startup speed has enhanced the user experience.

Take a look at the full code here: https://github.com/nonokangwei/Stable-Diffusion-on-GCP/tree/main/Stable-Diffusion-UI-Agones/optimizated-init

Considerations 

While the technique described above splits up dependencies so that the container size is smaller and you can load the libraries from PD Disk images, there are some downsides to consider. Packing it all in one container image has its upsides where you can have a single immutable and versioned artifact. Separating the base environment from the run time dependencies means you have multiple artifacts to maintain and update. You can mitigate this by building tooling to manage updating of your PD disk images.

Security is a top priority for all customers on Google Cloud, whether beginner, intermediate, or advanced users. Through our partnership with Acalvio, we are able to offer Active Defense to Google Cloud customers, providing automated deception management and deployment capabilities, with a simple onboarding experience.

Architecture overview

Acalvio’s patented Active Defense platform, built on award-winning autonomous deception technology, can enable organizations to detect, engage, and respond to malicious activity in cloud and on-premises networks, as well as hybrid deployments. ShadowPlex achieves this goal by using decoys of attackable systems or applications, bread crumbs of false credentials and baits using tripwires to misdirect malicious actors. Any interaction with the deception platform generates a high-fidelity alert. Built on Google Cloud, Acalvio’s platform delivers enterprise-scale distributed deception.

Acalvio’s Active Defense has two main components (Figure 1): the ShadowPlex service running on Google Cloud, and the projection sensors deployed in customer workloads, which provide point-of-presence. The centralized ShadowPlex service hosts deceptions and projects them across distributed and hybrid enterprise networks. 

Sensors are lightweight components that are installed in the enterprise network, both on-premises and in cloud workloads, and can enable decoy projection from the ShadowPlex service. ShadowPlex service also supports the work-from-home model by enabling deception across remote computers not directly connected to the enterprise network. It leverages a global sensor deployed in Google Cloud.

How ShadowPlex is built on Google Cloud

For effective Active Defense, deception needs to be enterprise scale and Google Cloud provides the elasticity for ShadowPlex to deploy thousands of deceptions across the customer’s network. Acalvio’s patented Fluid Deception technology provides high decoy density and high interaction, with strict containment. This can allow for safe engagement with attacks, while optimizing resource usage.

ShadowPlex is tightly integrated with Google Cloud Security Command Center (SCC), alerting customers through SCC when deception incidents occur (Figure 2). Additionally, Google Cloud customers will also receive notifications in SCC (Figure 3) to consider adding Active Defense protection for any of their Google Cloud projects not covered by ShadowPlex.

ShadowPlex is also integrated  with Google Cloud Chronicle Security Operations. Customers can configure the deception incidents to be sent to Chronicle and correlated with other alerts. 

Additional Google Cloud services are used by ShadowPlex for internal operations (Figure 4), such as enriching deception incident data by using information from VirusTotal, data management and processing built on Google’s database services, and threat analysis on the GKE platform.

Better together

Acalvio’s deception-based Active Defense is available in the Google Cloud Marketplace. This partnership delivers Active Defense to help customers detect and respond to the latest advanced threats with precision and speed.

Acalvio ShadowPlex service from Google Cloud not only provides Active Defense to Google Cloud workloads, but also extends security to customers’ on-premises infrastructure. Deception across the on-premises networks is deployed and managed from Google Cloud, bringing additional usage to Google Cloud.

As a fully managed relational database service for MySQL, PostgresSQL and SQL Server, Cloud SQL lowers the cost of database ownership in several ways: it makes it easy to set up and operate a highly available database as well as scale with replicas, it provides security, it  automates database upgrades and maintenance, and it manages and monitors your database. It’s also easy to migrate to Cloud SQL using Google Cloud’s Database Migration Service. It’s no surprise then, that more than 95% of Google Cloud’s top 100 customers use Cloud SQL.

Google has now launched  Cloud SQL Enterprise Plus edition for MySQL and PostgreSQL. This new edition has all of the great benefits you get with Enterprise edition, but adds some important capabilities in availability and data protection: a 99.99% availability SLA that is inclusive of maintenance, near-zero-downtime upgrades, and up to 35-day point-in-time recovery capability. 

In addition to all these great new features, Enterprise Plus edition delivers several performance improvements including a data cache feature that allows you to seamlessly scale your workload. In this post we describe the performance results of Cloud SQL Enterprise plus edition on standard database benchmarks to showcase some of the improvements that you can gain when you choose it for your MySQL workloads.

New compute platform and architecture

Enterprise Plus edition gives MySQL users the option to enable a data cache feature, which can dramatically accelerate read performance. The data cache adds local SSD media to the Cloud SQL for MySQL instance, extending the MySQL buffer pool beyond memory to use local SSD. This allows read requests that cannot be serviced from data stored in the instance’s memory to be retrieved from local SSD rather than going out to instance storage, reducing latency and delivering 3x improvement in read throughput for MySQL workloads. The data cache is optional, but when you enable it, an optimal size of local SSD is provisioned on the instance depending upon the number of vCPUs you’ve configured.

Cloud SQL Enterprise Plus edition database instances leverage a different underlying hardware platform than Enterprise Edition, with a higher memory-to-vCPU ratio of 8 GB per vCPU. Even without any tuning, this platform delivers performance benefits when compared to Enterprise edition: the increased memory allows more data to be resident in memory when processing queries, therefore reducing latency associated with doing disk I/O operations during query processing. Cloud SQL Enterprise Plus edition also allows instances with up to 128 vCPU to allow your workloads to scale to higher levels.

With Enterprise Plus edition, we also improved Cloud SQL for MySQL’s write performance using several techniques and optimizations to reduce latency, resulting in up to 2X increased write throughput. This is due to a combination of more efficient log writes and a better CPU, resulting in reduced wait time for committing transactions, and increased throughput. This makes Enterprise Plus edition very well suited to applications with high data-ingestion rates. 

Combined with the read-performance improvements, these changes mean that Cloud SQL Enterprise Plus edition shines on mixed workload performance, as shown in the benchmark results below.

The blue bars represent the results when running on CloudSQL Enterprise Edition and the green bars are the results when running with Enterprise Plus with data cache enabled. Mixed workloads on Enterprise Plus edition show up to 171% improvement when compared to Enterprise edition.

Read-only workloads show an even more dramatic improvement when leveraging Enterprise Plus with data cache. The results of a read-only benchmark above show a 241% increase in queries per second (QPS) on a 32 vCPU instance and a 218% increase on a 64 vCPU instance. 

Go ahead, scale those MySQL applications

With the introduction of Cloud SQL for MySQL Enterprise Plus edition, you now have a great new option for scaling your applications. In this post, we covered the performance benefits using standard database benchmarks. The results demonstrate that the Cloud SQL Enterprise Plus edition offers significant performance improvements when compared to Enterprise edition, and also beats other major public cloud vendors’ comparative services’ MySQL performance. As a result, you can expect significant value in terms of price/performance when running your MySQL database applications with Google Cloud SQL for MySQL Enterprise Plus edition. 

Cloud SQL Enterprise Plus edition is now available in select Google Cloud regions.  To get started, provision an Enterprise Plus edition instance from the Google Cloud console or GCloud API.