Dimitrios Kechagias

If you are using Cloud VMs you might want to check out a CPU performance and price comparison across 7 providers, 44 VM families.

The main benchmark suite used was the Perl-based (Benchmark::DKbench). If you want to try it out yourself, on a machine with docker just run:

docker run -it --rm dkechag/dkbench

I recently refactored the multi-core benchmarking framework I've been using for my Perl CPU benchmark suite (Benchmark::DKbench) and released it as a separate module: Benchmark::MCE.

Why spin it out? Because the harness can do more: it can be used to write custom benchmark suites of any type, generate massively parallel workloads for stress testing, or run throughput benchmarks against services and APIs.

The exact scenario that prompted me was a comparison of Cloud SQL database instances. We wanted to see how a 16-CPU Enterprise Plus instance would compare to a 24-CPU Enterprise instance under heavy load. One way to do that is to write one or more functions that run randomized, typical/heavy queries (e.g. random searches for SpareRoom ads in our case), then use Benchmark::MCE to time them running on dozens of parallel MCE workers to simulate high load:

use Benchmark::MCE;

suite_run({
  threads => 64,   # Parallel workers
  scale   => 100,  # Workload multiplier (x times to call code)
  bench   => {
    Name1 => sub { ...code1... },
    ...
});

This is the simplified syntax, but since it was part of a benchmark suite I've been developing for a while now, there are many more features (verifying correctness, iterating stats, single/multi-core scaling etc).

I started using DEV at the suggestion of Perl Weekly, and I was quite pleased with it - until I discovered that links to dev.to are effectively "shadowbanned" on several major platforms (Reddit, Hacker News, etc.). Posts containing DEV URLs would simply not be shown to users, making it impossible to share content effectively.

To work around this, I thought I would need a way to publish my DEV articles on my own domain so I could freely share them. There are some DEV tutorials out there that explain how to consume the API using frontend frameworks like React, however I don't enjoy frontend at all and I did not want to spend much time on that.

My solution was to get a simple Perl script that builds static versions of the articles, along with an index page. A Perl 5 script will run anywhere, including an old shared linux hosting account I still keep on IONOS, and I really like the speed of static sites.

I thought this is an ideal task to start with ChatGPT. Indeed, after 10-15 mins in a few prompts I had a sort-of working solution without having to open up the API documentation, nor writing any CSS. I then spent an hour or two fixing bugs, refactoring some of the ancient-looking code and tweaking / adding features (e.g. tag index pages) - tasks that I enjoy.

Here is the result. You can find the Perl script and assets in this repo.

It will run on pretty much any Perl 5 version (tested down to 5.10) with some basic CPAN modules (LWP::UserAgent, JSON, Path::Tiny).

To use it, check the project out from the repo and specify at least your DEV user name when calling the script:

./dev_to_static.pl -u [username]

# or to also specify a target directory and name your blog:
./dev_to_static.pl -u [username] -t [directory] -title="Blog name"

Try option -h to get more help.

You can run it on your web host, or run locally and copy the resulting directory to your host.

A nightly cron can update the site with new articles.

I am in the process of adding OpenWeatherMap support to Xasteria Weather for iOS and the proxy I built is in Perl. Since there was only an old module on CPAN which did not support the current API and was not easily updatable, I released Weather::OWM. It's a very simple module, similar to two other Weather modules I've released in the past (Weather::WeatherKit…

I gave the talk Maximizing Performance and Cost Efficiency in the Cloud at the Perl and Raku conference this year. Among others, it used data from a benchmarking comparison I did among dozens of VMs on various cloud providers, and I had promised I'd post the full report.

It took me quite a bit longer than expected due to both technical complications and some new releases I wanted to include that enlarged the scope, but here it is now.…