Flame
Two
Scaling UP...
Basics
Before we dig into specific "scalability" with FlameTwo, we can choose some basic modern-day server strategies. In the day of FlameThrower, a single server and internet connection were expected to run an entire site - HTML and other assets, alongside CGI scripts. Today, a simple $5/mo "nanode" running your favorite linux distro with Apache and PHP can immediately take the load off your FlameTwo machine. As with all things Linode/Akamai, these basic webserver nodes are scalable as large as you want to invest. The linode VM's also have their own IP connectivity, which is also easily scalable based on your needs and budget.
Round-Robin DNS was once useful to spread load across multiple CGI machines, but this strategy is less beneficial these days. Now it's more common to see a small number of caching servers retaining DNS entries instead of repeatedly resolving them. Later there's some discussion of using PHP to create similar round-robin functionality with SSI and URL's.
For the rest of this case study, let's assume a hosted solution (like the nanode) for basic HTML and PHP, and FlameTwo machine(s) hosted at the home or office.
So, back to FlameTwo in particular.
For this case study, I used a SuperCard project that modifies draw text on a card that also contains draw graphics, exports the card to a PNG variable and returns the PNG to the browser. My goal was to roughly compare this type of graphics creation to what is available with PHP/IMagick or PHP/GD on Linux. All three performed similarly responsive in a single web page, but the pursuit was to discover options for scaling up. These comparisons are intended to be relative, without spending too much time evaluating CPU speed or OS etc. The rendered PNG's have a text item revealing the "ticks" for FlameTwo, and Unix Time for the PHP items. This allows some basic start-to-finish duration comparisons. As these images are created into variables, we already skip any HDD or SSD overhead.
Test 1 - Multiple projects
For this basic setup, we scale by using multiple projects with a single CPU and FlameTwo instance. This setup uses the built-in routing capabilities in FlameTwo and the F2Route value to direct 8 incoming page requests to different projects, which all display on the same web page. PHP/GD wins easily, and renders all 8 images near simultaneously. PHP/IMagick and FlameTwo both render the 8 images in groups, around 20 ticks start to finish.
Test 2 - Multiple FlameTwo's
In Test 2 we still have multiple projects but spread them across multiple FlameTwo standalones on a single CPU. This setup uses unique URL's to 8 FlameTwo standalones, each with a unique version of the SuperCard project. While there is a slight improvement over Test 1, we are still leveraging a single Apache server and a single instance of AAEB.
Test 3 - Ram Disk
Test 3 is similar in concept to Test 2, however we use a RAM Disk. All the FlameTwo standalones and the respective projects are moved to the Ram Disk. The CPU in question already has an SSD with 500+ MB/s of performance, but the RAM disk is roughly six times faster. Another incremental improvement is observed.
Test 4 - VM time
In Test 4 we consider VM's. We will use a more modern CPU (iMac Pro, 10 core) running Ventura and VirtualBox, and a Tiger Server VM. All previous tests were observably faster. Due to the version of VBox and the use of Ventura, the VM was only acting as a single-core MAC. The addition of the RAM disk was only barely a visible improvement since the Mac's boot volume is a relatively fast 3000MB/s SSD. Newer MacOS versions were not notably better than the Tiger Server, but do require more resources and RAM. Earlier versions of VBox do permit guest MacOS VM's to use more cores, however reverting to earlier MacOS versions on the host offsets any possible gains.
Test 5 - more VM's
In Test 5 we use multiple VM's. Proceeding to further leverage the iMac Pro, I used 8 virtual machines, each setup as in Test 1. At this point, FlameTwo consistently matched the PHP/GD functionality, serving all 8 graphics near simultaneously. This shows the advantage that can be gained with separate Apache servers and separate AAEB instances. Likely, a similar performance benefit could be had with 8 individual i7 2012 Mac Mini systems, which would not be limited to a single CPU core as is the case with the VMs. These 2012 machines are quite inexpensive, as is the cost of maxxing the RAM, but avoid the slow i5 versions.
Test 6 - Multiple Everything
Continuing with the multiple VM's from test 5, each of these 8 Tiger Server instances can also run multiple FlameTwo engines with their own SC projects. To the extent there is sufficient RAM available, even the virtual disks for the VM's can run from RAM. In this ScreenShot, there are 8 VM's on the same iMac Pro, and each of the VM's has 12 instances of FlameTwo. One CPU, 96 FlameTwo engines, each having the capability to host multiple CGI projects. In this scenario, the network bandwidth of your outgoing connectivity is likely more limiting than FlameTwo or the Tiger Server VM's. If substantial CPU-heavy scripts are involved, then merely adding servers and/or VM's on your LAN can also assist scaling up.
misc
One note for port forwarding. Most NAT routers allow forwarding your public IP to a private IP. This only helps for single Apache server instances and doesn't address all the tests we've just done. What can be useful however, is to craft URL's with unique port numbers, then set up your port forwarding to target specific LAN IP addresses back to their normal port 80. It is also trivial to use SSI/PHP to create your own round-robin URL's on the fly for these external port numbers. This allows a single external HTML resource to target your multiple internal FlameTwo resources strategically, without having multiple similar HTML pages for load sharing on the HTML server. This is also useful when you need to take a particular FlameTwo instance offline for admin or maintenance work - just tell your PHP script to exclude a particular port number from its random pool.