Learn about WebAssembly and how to get it working with high-scale apps with some help from Gloo Edge.<\/b>
\nJoin the DZone community and get the full member experience. WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. At Solo.io, we are very excited about Web Assembly as a way to extend our Envoy Proxy-based API Gateway ( Gloo Edge) and the most popular Service Mesh ( Istio). We recently made it very easy to use WebAssembly with Gloo Edge and Gloo Mesh. This is the last blog post of a series about Gloo Edge scalability. In the first blog post, Envoy at Scale with Gloo Edge, we performed benchmarks to determine how Gloo Edge was able to scale in terms of Requests Per Second (RPS.) We also provided information about the throughput one can expect based on the number of CPUs allocated to the gateway-proxy (Envoy) pod. In the second blog post, Security at Scale with Gloo Edge, we measured the impact of enabling different security features, including HTTPS, JWT, API keys, and WAF. In this blog post, we\u2019ll measure the impact of deploying a Web Assembly (Wasm) filter to modify the request or response headers or body. We know based on my previous tests that we could get close to 90,000 RPS with standard HTTP requests when we don\u2019t set any CPU limits on the gateway-proxy pod. In the following tests, we\u2019ll compare the impact with a limit configured to eight CPUs and without a limit. With a limit of eight CPUs, we could get more than 16,000 RPS with standard HTTP requests. To be able to create a regex filter, we need to pick a language that includes a regex package and can be compiled in Wasm format. When we started to work on this filter, we wanted to use AssemblyScript, but there was no regex support at that time. (There is now a community module.) So, we decided to use TinyGo, but when we started to test my filter, we discovered that it was always crashing due to out-of-memory issues. We opened an issue on the TinyGo repository which has now been fixed. Long story short, the filter is now ready and stable. We can easily deploy this filter on Gloo Edge or Istio (using Gloo Mesh) and we can pass some information about the operation we want to execute using the format `Action&&Match&&Replacement`. For example, if we want to replace the value foo by the value bar in the response body, we\u2019ll use the option ResponseBody&&foo&&bar. The tag of the Wasm filter is `webassemblyhub.io\/djannot\/tinygo-regexp:0.1`. The echoenv Docker image we use as a backend in our test is based on the Gin Golang Web Framework, so the response body contains the word GIN. Here is the response body we get before we deploy the filter: It\u2019s easy to deploy a Wasm filter on Gloo Edge. We simply need to modify the gateway-proxy gateway as follows: We set my filter to replace GIN by TONIC. Here is the response body we get after deploying the filter: We can now launch the benchmark and check the results on Grafana. Here is the result without a limit. As we can see, we still get really good performance with my WASM filter. The throughput is more 50,000 RPS. Here is the result with a limit of eight CPUs: The impact is a little bit higher when we set a CPU limit, but the throughput is more than 7,000 RPS. In the remaining tests, we\u2019ll always set a limit of eight CPUs. Here are the headers we currently get: We\u2019re now configuring my Wasm filter to replace utf-8 by ascii in the response headers. Here is what we get after we apply the new parameters: We can now launch the benchmark and check the results on Grafana. Here is the result with a limit of eight CPUs: The impact is higher, but the performance is still good. The throughput is higher than 3,500 RPS. We modify the test plan to send POST requests with the data username=foo: And we\u2019re now configuring the Wasm filter to replace foo by bar in the request body. We can now launch the benchmark and check the results on Grafana. Here is the result with a limit of eight CPUs: The throughput is more than 7,000 RPS, similar to the throughput we were getting when modifying the response body. We add the following section to the test plan: This way, we tell JMeter to add a Key header with the value foo. And we\u2019re now configuring the Wasm filter to replace foo by bar in the request headers. We can now launch the benchmark and check the results on Grafana. Here is the result with a limit of eight CPUs: The impact is higher, but we still get around 2,000 RPS. Then we probably don\u2019t want to have the performance hit for other routes. There\u2019s a simple workaround for that. First, we create a Gloo Edge Gateway object where the Wasm filter will be applied: Note that this gateway is bound to localhost and to a different port. We can see that this Gateway reference a wasm VirtualService. Here is how we defined it: Next, we need an Upstream which corresponds to localhost:8082: Finally, we can create a VirtualService referenced by the gateway-proxy gateway with some routes configured to use the Wasm Upstream: Now, only the routes configured to send the traffic to the Wasm Upstream will have the Wasm filter applied. Note that there is a Pull Request ( http: add composite filter allowing dynamic filter selection) in Envoy which will make it possible for us to improve the user experience with Wasm and Gloo Edge in the future. Gloo Mesh makes it easy to deploy Wasm filters on Istio. Many familiar with Istio know about the Bookinfo demo application. If we send a request from the productpage service to the reviews service, we get the following response headers: To deploy my Wasm filter on the v1 version of the reviews service in cluster1, we can simply create the custom resource (CRD) below: Now, if we send a request from the productpage service to the reviews service, we get the following response headers: Easy. The data we obtained when limiting the amount of CPU used by the gateway-proxy (Envoy) pod is the most useful. It can be used to determine the throughput we\u2019ll get with eight CPUs depending on the transformation we want to perform with a Wasm filter. Here is a table that summarizes the results: Keep in mind that 1,000 RPS means more than 86 million requests a day! Opinions expressed by DZone contributors are their own.<\/p>\n