DEV Community: Thomas Cross

Is GCP internal network slower than AWS?

Thomas Cross — Fri, 25 Sep 2020 13:18:28 +0000

I am working on a side project that intends to provide tracking of application performance at the function level called Criterion.dev. The Criterion API uses a PostgreSQL database and Actix Web for the web service.

I am very happy with the performance, but still, some random thought came to mind that made me question the numbers.

GCP Infrastructure

Compute Engine: E2-small
Cloud SQL: PostgreSQL 1v shared CPU .6GB
API request wait time: 84ms

AWS Infrastructure

EC2: t2.micro
RDS: db.t2.micro
API request wait time: 42ms

I started the service on GCP, so I logged into that instance and then into the SQL server and ran some queries by hand. The same queries that the service executes actually take less than 2ms. This convinced me that the network was the bulk of the request wait time.

So I copied my project over to AWS made a new subdomain and connected the SPA to it - The request time was 40ms less.

Have you ever seen this before? Could it be due to the shared/free instance tiers I am experimenting with?

How to choose a language on Google App Engine if performance matters

Thomas Cross — Fri, 26 Jun 2020 18:03:03 +0000

So you may know one programming language really well, you are a polyglot, or you may be learning your first right now. Kudos to you no matter which camp you are in!

This post is going to focus on app engine standard second generation in particular, and the languages I would personally consider for my projects. There are a few more that I could add to this post, just comment on this and let me know if that interests you and I can add them - more on that later.

These graphs are centered around Django 3 - this framework is very popular but it may not be the best framework for you if performance is a priority.

build time - the time it takes to build a docker image with cloud build.
start up time - the time it takes for a server to start and accept requests.
request time - the time it takes for the framework to respond to a "hello world" request.

Request time is important because you can kind of place a constant K value on the time it takes to process a request; possibly even apply some time factor to every request. Start up time is important because it is the time a client will have to wait if there is no server available to process the request. For this reason, if your app has a large influx of traffic, I suggest choosing a framework with low start up times. Build time is more of an awareness statistic - a nice to know. CI/CD processes become concerned with this, but unit and integration tests and other processes tend to take longer than build time.

Here is the data shown without build time as a consideration

This graph makes it pretty easy to pick a framework because you can weigh the relative start and request times. I wish there was something Google could do for Java/Spring, that start up time inhibits scaling abilities quite a bit.

I am curious how Laravel and Express fit in. Let me know if you are as well and I will update this blog with those added to the charts!

Scale to 1000 concurrent users on a raspberry pi 4

Thomas Cross — Thu, 25 Jun 2020 04:08:36 +0000

I have been investigating rust web frameworks and have to say this one is my favorite. Not just because of its performance, but the features, design choice, and ecosystem.

Actix web is a web framework that uses the actor model to perform HTTP requests. It has middlewares, SSL, HTTP/2, and many "extras".

My main reason for looking into this is because I think Rust can facilitate a future of fast, safe, concurrent software. Coming from php, python, Java, ... the barrier to learning was really to learn Rust(a non object oriented language). I've always wanted to write bare metal web services, but would prefer not to use C++ because of the mistakes we can make.

The results impressed me so much that I decided to publish them here and provide the source code for you as a sort of kicking off point.

This test is a lot like my other one except the redis pool is async via deadpool and obviously actix.

All this service does is use a thread pool in the HTTP handler to get a value from redis and print out some hello world type message. This implementation is more than a 10X improvement in concurrency and 2X in latency compared to the aforementioned warp test. In fact, I noticed redis may have been slowing the benchmark down because it needed so much CPU.

tcross@spongebob:~$ siege -c1000 -r 50 -H  'Content-Type: application/json' 'http://192.168.1.2:8080/tcross/1/index.html'
** SIEGE 4.0.4
** Preparing 1000 concurrent users for battle.
The server is now under siege...
Transactions:              50000 hits
Availability:             100.00 %
Elapsed time:              26.41 secs
Data transferred:           6.68 MB
Response time:              0.52 secs
Transaction rate:        1893.22 trans/sec
Throughput:             0.25 MB/sec
Concurrency:              990.76
Successful transactions:       50000
Failed transactions:               0
Longest transaction:            1.66
Shortest transaction:           0.00

I hope you enjoyed reading this, find me on any channel and ask questions! Here is the source!

My First Rust Web Service (And Other Firsts)

Thomas Cross — Thu, 25 Jun 2020 00:03:30 +0000

Many Firsts
Rust is Different
Warp
Raspberry PI 4 Benchmark

Many Firsts

This blog post is many firsts for me. My first blog post, first post on medium, first time I compiled Rust code on a raspberry pi, first time I benchmarked a web service on raspberry pi, … there is probably even more. So please give me feedback on how I can improve my writing for you!

I realized that a large community of people exist that desire to learn the things I am learning but struggle to break into the technical space. So my goal for my writing is to lower that barrier by providing my experience, source code, and even directly helping over whatever channels work best. Feel free to ask questions here, or twitter, or anything. I hope that you can take my projects and build upon them.

Rust is Different

According to the stack overflow developer survey, Rust has been the most loved language since 2016 (over 4 years today). I have been keeping an eye on the language for some time now, and feel like it is finally in a place I would consider it stable — not mature necessarily — but stable. Stable in the sense that the syntax and community are developed. So after watching many YouTube videos, reading articles, and even testing out various projects I decided to invest more time into the rust ecosystem and I have to admit, it is nice.

For your benefit I should note that my primarily used languages are Python, C, C++, and Java; with python being my most familiar. Admittedly, Rust feels very different to me and I am still learning the fundamentals. I can not say I love the syntax. Rust does not have OOP design paradigms, and surprisingly passing variables was tough to get used to because of the borrow checker.

However, I can say I love the compiler, which uses LLVM as its back end and has clear messaging to explain what is wrong. Rust comes with amazing tools out of the box; such as automatic documentation generator, linter, code formatter, package manager, …. It even has the ability to write tests in the doc strings, and run them without third party libs.

I am in the process of learning rust by completing the rustlings courses. But I am also a hands on learner — hence this experiment.

Warp

A super-easy, composable, web server framework for warp speeds.

I found this web server framework different than others I have used in the past, and I will try a couple more soon. Regardless, I am glad I tried warp, they are on to something with this feature they call “filters”. It allows your routes to be built with a builder pattern.

let register = warp::post()
    .and(warp::path("register"))
    .and(warp::body::json())
    .and(redis_pool.clone())
    .and_then(register);

The above code sample makes a route and registers it to a function called “register” that may be accessed in the following way.

HTTP
POST /register HTTP/1.1
Host: 192.168.1.2:3030
{
    "username": "chmoder",
    "password": "password"
}

The neat takeaway for me here is that you compose what will catch a route and prepare the data for the function that intercepts the request.

Raspberry PI 4 Benchmark

High level talk: This service has two routes “register” and “login”. Register saves a user and password-hash to redis. Login gets the password for the username. This is totally contrived and doesn’t make sense as an application. But it does allow us to see what kind performance we can get from warp with a real-world database.

In this project you will find main.rs, and main-mutex.rs. main-mutex was my first iteration. It used a mutex to share a redis connection among the warp threads. Main.rs gives each handler a r2d2 connection pool for redis. This allowed me to remove a few things from the code and get > 2X performance.

By the way the server was compiled and ran on a raspberry pi 4 and used only 23 Mb of memory.

main-mutex.rs

siege -c100 -r 10 -H  'Content-Type: application/json' 'http://192.168.1.2:3030/login POST { "username": "chmoder","password": "password"}'

The mutex version is not completely utilizing the CPU because only has one process is in “running” state at any given time.

Our concurrency looks good but some transactions had to wait
8.4 seconds.

** SIEGE 4.0.4
** Preparing 100 concurrent users for battle.
The server is now under siege...
Transactions:             1000 hits
Availability:             100.00 %
Elapsed time:             37.55 secs
Data transferred:         0.00 MB
Response time:            3.48 secs
Transaction rate:         26.63 trans/sec
Throughput:               0.00 MB/sec
Concurrency:              92.55
Successful transactions:  1000
Failed transactions:      0
Longest transaction:      8.40
Shortest transaction:     0.04

main.rs

This one passes the connection pool to all the threads, fully utilizing the CPU. This ended up taking 2.19X less time to run and had the same speedup on “Longest transaction”.

** SIEGE 4.0.4
** Preparing 100 concurrent users for battle.
The server is now under siege...
Transactions:              1000 hits
Availability:              100.00 %
Elapsed time:              17.10 secs
Data transferred:          0.00 MB
Response time:             1.57 secs
Transaction rate:          58.48 trans/sec
Throughput:                0.00 MB/sec
Concurrency:               91.82
Successful transactions:   1000
Failed transactions:       0
Longest transaction:       3.58
Shortest transaction:      0.07

Go ahead and check out the repository on GitHub! Let me know what you think and what kind of modifications you were able to do!