VWS 1.1.3

VWS 1.1.3 is a big update with many new performance improvements and features.

VBench

Part of Velocity Web Server's growth has been adding tools to make managing a web server easier than ever. VBench, a new benchmarking tool, continues this philosophy. It works much like Apache Benchmark and is designed to be a drop-in replacement for quickly running benchmarks on any operating system, with a single command in VWS.

Much like ApacheBench, VBench sends many concurrent requests to a web server to test how well it handles them. VWS, on average, can handle 180 requests per second on a simple PHP page, whereas Apache is closer to 75 per second (though this is not an official number yet), as I'll need to do more rigorous testing later.

VBench is something I've wanted to make for a long time, and now I have. 

Web Assets

Web Assets are a special type of asset that can be cached by the web server. For example, let's say you host many websites on your web server, and all of these websites use React. Well, rather than specifically copying React to each of these websites, just use the Web Assets tool - firstly install the asset (React) and then on each of the pages requiring React, just write and VWS will provide it for you. And it's quick too. 

Web Asset Bundles

Web Asset Bundles are even more interesting and useful. These combine multiple assets into a single request before sending them to you, reducing the number of requests. Same idea, but instead of the word asset, we use bundle: . It's fast, and it's powerful. 

The most recent benchmarkings

I benchmark VWS frequently using Apache Bench. The command used is ab -n 10000 -c 40 url. I do this for both Apache and VWS and run the same file on the same server. I then get ChatGPT to look at the results from both of them and summarise. Thanks to some real performance improvements, VWS pulls ahead of Apache in all benchmarks carried out. Here's what ChatGPT had to say:

VWS performed slightly better than Apache in this test. Apache handled 2544.69 requests/sec with a mean request time of 15.719 ms, while VWS handled 2670.49 requests/sec with a mean request time of 14.979 ms. Both completed 10,000 requests at concurrency 40 with 0 failed requests.

Latency was also a bit better on VWS. The median request time was 14 ms for VWS versus 15 ms for Apache, and the 99th percentile was 24 ms for VWS versus 36 ms for Apache. That suggests VWS had slightly better tail latency in this run.

Apache showed a lower mean connect time, but VWS showed a lower mean processing time. Apache’s mean connect time was 5 ms versus 8 ms for VWS, but Apache’s mean processing time was 10 ms versus 7 ms for VWS. Overall total mean time still favoured VWS at 15 ms versus 16 ms for Apache.

Apache transferred more total bytes, 4,010,000 versus 3,020,000 for VWS, while both transferred the same HTML payload, 1,310,000 bytes. That suggests Apache was sending more header overhead, while VWS was leaner on the wire.

So the overall finding is that, for this particular internet-facing test at concurrency 40, VWS was competitive with Apache and slightly faster overall, with lower average latency, better tail latency, and no failed requests.

Next steps

I had given up on VWS until last month. But now look at it. It's nearly a fully-fledged web server.

VWS is nearly production-ready. The introduction of benchmarking tools has allowed me to test how well VWS handles multiple requests, and it does pretty well. I have no concerns about VWS being able to deliver what's needed on scale, but I want to get it right.

Additionally, ZPE has been getting a lot of attention over the last four months, with this month and last month focused on the new features in VWS.