Data Centers exist all over the world. They’re used to stored all sorts of computer data, including websites and web apps, like MIDAS.
The location of the data center that houses your cloud-hosted MIDAS system can have an impact on the quality of your overall experience.
One of the unavoidable aspects of long-distance internet communications is high latency.
What is latency and why is it important?
The term “latency” describes a measure of delay between two events.
In the context of the internet, latency refers to the amount of time it takes for data to perform a round-trip between two points in a network. In the case of your MIDAS system, these two points are represented by your web browser and the server in a data center which runs your MIDAS system.
The amount of time it takes for a unit of data to travel from the server in the data center to your browser is considered the latency of the network. This is usually measured in milliseconds and expressed as ms. This is also frequently referred to as the response time of a server.
We recently added two new data centers to our network, including one in Europe.
In our testing, we saw lower latency leading to an approximately 30% improvement in page loading times for Europe-based users accessing a MIDAS system in our EU data center vs our East Coast US location.
How does a data center’s location help reduce latency?
Being geographically closer to a data center can have several benefits, including:
Lower Latency: When the distance between a user and a data center is shorter, the time required to transfer data is reduced. This results in lower latency and faster response times.
Improved Performance: Lower latency can result in improved performance for applications and services hosted at the data center, such as faster loading times for websites, smoother streaming, and reduced lag in online gaming.
Increased Reliability: By being geographically closer to a data center, users are less likely to experience network congestion, data loss, and other issues that can affect the reliability of their connections.
Better Compliance: Data centers located in specific regions may be subject to local laws and regulations, such as data privacy and security standards, which can affect their suitability for hosting certain types of data. By being closer to a data center, organizations can more easily ensure compliance with these regulations.
We added new client nodes in a data center in Europe (in Amsterdam, Netherlands), and in a data center on the West Coast of the US (in Seattle, Washington).
These two new data center locations are in addition to our existing nodes residing in our East Coast US data center (in Atlanta, Georgia).
We then looked at the location of each organization with an active cloud-hosted MIDAS service. Those which were geographically closer to either our EU or West Coast US locations were seamlessly migrated to those data center locations.
Naturally, we provided customers with advance notice of proposed migrations, and allowed individual customers to opt-out, or to choose a different data center for their MIDAS system.
Because our cloud-hosted MIDAS systems can now be run out of three different geographic regions (US East, US West, and Europe), we now offer all new cloud-hosted customers a choice of data center where they’d like their MIDAS system to reside.
We’re adding additional new client nodes in Europe (in Amsterdam, Netherlands), and on the West Coast of the US (in Seattle, Washington).
We’ll also be upgrading existing client nodes in our East Coast US data center (in Atlanta, Georgia) too.
We’re adding new data center locations on the West Coast USA and in Europe
Why are we doing this?
As part of our continued commitment to the service we provide, we’re investing in new additional hardware, upgrading older hardware, and expanding our network infrastructure.
What are the benefits?
Our network expansion is designed to further improve the speed and performance of existing cloud-hosted MIDAS systems.
By relocating cloud-hosted customer’s MIDAS systems to data centers which are geographically closer to them, faster communication speed between an end-user’s device and their MIDAS system can be achieved.
As a result, customers should notice that their MIDAS systems will load and respond quicker than before.
For new cloud-hosted customers, going forward our network expansion will also mean that we can offer a choice of data center for where their hosted MIDAS system will reside.
What’s happening and when?
Our network expansion and upgrades are scheduled to take place during February and March 2023. The work is being done in 5 phases, which are outlined below:
Phase 1: (Expected completion: End of February 2023)
The first phase of our network expansion involves provisioning new client nodes in Amsterdam, Netherlands and in Seattle, Washington.
Phase 2: (Expected completion: End of March 2023)
Once the new client nodes are up and running, the second phase involves migrating existing cloud-hosted customer’s MIDAS systems to the new Amsterdam or Seattle nodes where appropriate.
For example, if a customer is geographically closer to one of these new locations than they are to the current East Coast US node where their MIDAS system resides, we’ll move them to a closer node.
Phase 3: (Expected completion: End of March 2023)
Once applicable existing clients have been relocated onto the Amsterdam or Seattle nodes, phase 3 sees a reorganization of existing client nodes located in our East Coast US data center (in Atlanta, Georgia).
We’ll be retiring some older client nodes in this data center after we’ve moved customers to the new West Coast and EU nodes. The remaining East Coast US client nodes will be consolidated, which will mean that some customers may move nodes within the East Coast US data center.
Phase 4: (Expected completion: End of March 2023)
The forth phase of our expansion plan sees an upgrade to the server hardware which runs our main website, blog, and our public demo and private trial systems.
Phase 5: (Expected completion: End of April 2023)
The final phase of our network expansion sees the upgrading of remaining East Coast US client nodes to bring their hardware up to date and in line with the new nodes in the West Coast US and EU data centers.
Will there be any downtime?
We do not envisage any loss of access to our customer’s cloud hosted MIDAS systems during these network upgrades.
However, when we migrate a customer’s MIDAS system to a new node, we’ll temporarily place their system running on the old node into “Maintenance Mode” whilst the migration to the new node is performed.
“Maintenance Mode” essentially puts a MIDAS system into a special “read only” state. So you’ll retain full access to all your booking information, but won’t be able to make any changes.
Once the migration to the new node is complete, your MIDAS system will come out of “Maintenance Mode”, and you can continue using the software again as normal.
We anticipate that any “Maintenance Mode” period will last less than one hour.
We plan to carry out migrations at a time when a customer’s MIDAS system is typically least active (i.e. in the middle of the night)
We’ll also notify the “Primary Contact” we have on record in advance of any server migration and provide an estimated time when their migration will take place.
Can I choose which data center my MIDAS system will reside?
We’ll be contacting all existing cloud-hosted customers by email in advance if their MIDAS system is proposed to be migrated to a different data center. We’ll provide details of the data center we propose to move their MIDAS system to, and an estimate on when their migration will take place.
Customers will have a chance to respond to these emails to request a different data center, or that their cloud-hosted MIDAS system remains in their current data center.
Where can I get updates on the progress of these network upgrades?
We have a dedicated page over on our Service Status site, that we’ll continually update during these network expansion and upgrade works.
What if I have further questions?
If you have any questions or concerns in relation to our network expansion, please don’t hesitate to reach out to us, and we’ll be happy to help!
There are plenty of acronyms and terminology in the world of computer software and technology. You may have come across some of them on our website.
An acronym is a word formed from the first letters of a phrase. For example, “SQL” is an acronym for “Structured Query Language”.
Whenever we use a computer term or acronym on our website that may not be obvious to readers what it means, we endeavor to define it there and then in plain English.
However, sometimes this isn’t enough – ok, great so SQL means “Structured Query Language”… but what does THAT phrase actually mean?!
For some terminology going into too much depth and detail may detract from the context or theme of the actual article in which the terms appears.
The glossary is an alphabetical list of terms and their definitions. When we use technical terminology, jargon, or acronyms on our website, we’ll link to a description in the glossary.
Links to definitions in our glossary will appear with a dotted underline. When you move over a link, the cursor will change to a question mark.
We’ve currently defined close to 50 terms and acronyms and will be adding plenty more in the future.
Oh, and in case you’re wondering what the acronyms SaaS, SPF or SSO mean, click those words in this sentence to view their definitions in our new glossary!
ActivePerl is a way of installing a Perl environment under Windows. Perl is the underlaying programming language that our MIDAS software is written in.
In essence, we felt we could no longer recommend ActivePerl to customers looking to install a self-hosted room booking system on their Windows servers.
Well, ActiveState (the developers of ActivePerl) took notice of our original article and have quickly reached out to us…
ActiveState’s Response
Pete Garcin, Director of Product at ActiveState reached out to us:
“I saw your blog post about revisiting ActivePerl — it was great to see the engagement you had with the platform and the process you went through trying to get your build to work. It’s unfortunate that you ran into issues during that process though!
One of the goals of the platform is to provide a simple, reproducible process for generating builds from an expansive catalog. While it’s not always possible to keep 100% of the catalog building 100% of the time, we do our best to keep critical packages running.
Since the time you attempted your build, DBD::MySql and the maria-db-connector have been fixed (they were transiently broken) and one of our build engineers bumped the timestamp on your project so that now all of your projects for later versions should work. If you use 5.32 or newer, it ships with the mysql client DLL by default! In the future, making any change to a project will move the timestamp forward so that you pick up new changes to the catalog.
Also, you are free to use 5.32.1 or 5.34.0 — as both are now classified as out of beta (website might lag behind slightly). In fact, we highly recommend using one of the newer versions as the build experience is much faster and they also include the mysql DLL.
Also, if you’re distributing to your end users, our CLI provides a super simple way for anyone to set up the environment without needing to distribute a full installer — and they can also receive updates and stay sync’d. For modern versions of Perl (5.32+) you’ll see the instructions on how to install the CLI and the build on the platform dashboard in the Downloads tab.
Again — sorry to hear you had a rough experience creating your build, we’d love for you to try again with the updated projects and always happy to help work through any issues with you! Feel free to reach out any time.“
– Pete Garcin, Director of Product, ActiveState
ActiveState’s CTO, Scott Robertson, also reached out:
“Thanks for the amazing write up, really sorry you had a bad first impression. Even though ultimately we didn’t win you on the first shot I took heart that you’re starting to see the vision to our ambition when you say “We admit, we were actually a little excited – we appeared to have a custom Windows distribution of..”.. That’s the goal!
You’ve noted the number of packages we now support is over 100k! We’re coming pretty close to our goal now of being able to build 100% of CPAN in a secure reproducible way including all native dependencies. Something Strawberry perl can not claim. Unfortunately we’re still experiencing some growing pains going from 500 packages to over 100k and supporting every version the night it’s dropped. Looks like when you tried this project MariaDB updates entered our catalog and were broken. We have since fixed them. The post you found in our community forum was way out of date. We’re working on producing better support materials, but in the meantime know we’re here to help.“
– Scott Robertson, CTO, ActiveState
Analysis
First of all, we have to give credit to ActiveState for reaching out to us so quickly. We certainly weren’t expecting that, but it’s encouraging to see their engagement.
Secondly, it would appear – at first glance – that ActivePerl 5.32 and 5.34 do now successfully build on the ActiveState platform.
So let’s take a look…
Missing stand-alone installers
Here’s what the “Download Builds” tab on the ActiveState platform looks like for our ActivePerl 5.28.3 build:
.exe and .msi Windows installers are available for ActivePerl 5.28.3
Notice that there are two install methods offered; “Download Installer” and “Install via Command Line”.
The “Download Installer” section contains download links for standalone Windows installers for our ActivePerl 5.28.3 build.
The “Install via Command Line” section allows the build to be installed from the command line. This is achieved by using Windows PowerShell and ActiveState’s “State Tool“.
Now, let’s be realistic; the average non-tech savvy user will always prefer a familiar Windows Installer over having to use Windows PowerShell to execute arbitrary commands.
So it’s strange and very disappointing that no stand-alone installers appear to be provided for our 5.32/5.34 builds:
No stand-alone installers for Windows are provided for ActivePerl 5.34
Thinking this may be a glitch, we triggered a re-build of our ActivePerl 5.34 package on the ActiveState platform. This appeared to successfully build, but again no standalone Windows installers were generated.
We questioned this with ActiveState’s CTO who told us:
“Installers vs State tool: It will be State tool only going forward for free versions. The service and command client is meant for developers. Installers are a paid option.“
Scott Robertson, CTO, ActiveState
This is clearly a very recent decision which isn’t made clear on their website. In fact, the automated email notification the platform sent us when the re-building of 5.34 was complete, still asserts that you can “download the installer”:
Email notification from ActiveState indicating that a stand-alone installer is available
Sadly, the lack of any standalone .exe/.msi installers for ActivePerl being made freely available going forward is a major block for us to recommence recommending ActivePerl again to our self-hosted MIDAS customers.
However, we were still curious ourselves as to whether the previous issues with lack of MySQL/MariaDB support had indeed been fixed in this 5.34 build. So we decided to try a test install using Windows PowerShell to install ActivePerl’s “State Tool” and configure our 5.34 build.
Here’s how we got on:
Installing via Windows PowerShell
We opened a Windows command prompt and then pasted in the command ActiveState provided to “Install via Command Line”.
The result was a spiel of console output that would baffle most:
Console output from installing ActivePerl via the command line
…to be honest, we’re not even sure if we understand all of that… and we’re seasoned Perl developers!
Anyway, the console output ended by informing us that we were “Activated”.
So Perl 5.34 was now installed… right?(!)
We weren’t sure. So to test, we created a very simple .pl script that would print the words “Hello World!” in the browser. We saved this file into our test Apache web server’s htdocs folder.
This very simple .pl script contained just two lines:
In Perl, the “shebang” refers to the very first line of any Perl script. It informs the web server as to the whereabouts of the perl installation to use.
On Linux servers, Perl may typically be located at /usr/bin/perl, therefore, the first line of any Perl script (known as the “shebang” line) should read:
#!/usr/bin/perl
On Windows servers, Perl was traditionally located at C:\Perl\bin, C:\Perl64\bin, or C:\Strawberry\perl\bin, and so the shebang could read something like:
#!C:\Strawberry\perl\bin\perl.exe
However, Apache servers support a really cool configuration option called “ScriptInterpreterSource Registry“. What this does is instruct Apache to simply ignore the “shebang” line. Instead, Apache will determine the location of Perl based upon a Windows registry value (which should be set when Perl is installed).
That has the advantage that user’s don’t then need to set/change, or indeed care about the “shebang” line in Perl scripts, they should just work regardless!
So we tried accessing our simple “hello world” Perl script in our browser. This resulted in an Internal Server Error:
Internal Server Error when executing a .pl script
Upon investigation, it would appear that during install of ActivePerl, no registry value was set to allow Apache’s “ScriptInterpreterSource” directive to determine where Perl was located.
So we then had to find the location of the perl.exe executable on our test server and manually update the shebang line of our “hello world” script.
There was no obvious C:\Perl, or C:\Perl64 or even C:\ActivePerl directories present. We had to search the entire C:\ drive on our test server for “perl.exe”, and we eventually found it under:
So the “shebang” line we needed to add to our “hello world” perl script was the instantly forgettable(!): #!C:\users\wdagutilityaccount\appdata\local\activestate\052e8766\bin\perl.exe
Anyway, this at least allowed our hello world script to execute and correctly print “Hello World” to the browser.
Our Server Readiness Tool is a perl script that our customers can freely download and access (via their browser). The tool checks that their server is correctly configured in order to install MIDAS.
As part of these checks, the tool identifies any missing Perl modules which MIDAS requires.
To our surprise, running this tool indicated a number of missing modules, which we thought had been included in our custom ActivePerl build:
Perl modules apparently “missing”
We double-checked back on the ActiveState platform. Sure enough these modules appear to have been successfully included in our build:
DBD::MariaDb and DBD::mysql appear to have been included in the build
So what was going on?
Digging a little deeper in Apache’s error logs revealed the following errors:
Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/DBD/mysql/mysql.dll' for module DBD::mysql: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/DynaLoader.pm line 193.\r: C:/Apache24/htdocs/servercheck.pl
Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/DBD/MariaDB/MariaDB.dll' for module DBD::MariaDB: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/DynaLoader.pm line 193.\r: C:/Apache24/htdocs/servercheck.pl
Can't load 'C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/site/lib/auto/Net/SSLeay/SSLeay.dll' for module Net::SSLeay: load_file:The specified module could not be found at C:/Users/wdagutilityaccount/AppData/Local/activestate/052e8766/lib/DynaLoader.pm line 193.\r: C:/Apache24/htdocs/servercheck.pl
We checked, and verified that “mysql.dll”, “MariaDB.dll” and “SSLeay.dll” files were all present at the locations indicated.
Digging into line 193 of “DynaLoader.pm”, this section of code included the comment “Many dynamic extension loading problems will appear to come from this section of the code … often these errors are actually occurring in the initialisation C code of the extension XS file. Perl reports the error as being in this perl code simply because this was the last perl code it executed“.
So whilst ActivePerl appears to have technically installed the modules as part of the installation process, right now they’re broken and don’t work on Windows under ActivePerl 5.34!
…and the previous “workaround” of grabbing the “libmysql__.dll” file from a Strawberry perl installation and placing that within the ActivePerl installation also didn’t resolve the issue.
Once again, we have a broken and unusable ActivePerl installation.
In conclusion…
ActiveState’s prompt engagement with us is very welcome and demonstrates that there is still at least some interest there with regards to Perl.
However, we’re sad that they still don’t have an up-to-date version of perl for Windows users that works with MySQL/MariaDB.
That disappointment has been further compounded now by the knowledge that ActiveState have made the commercial decision going forward to discontinue being able to build Windows .exe/.msi standalone installers. That is, unless you pay.
This makes ActivePerl a far less attractive option to us.
Why would we want to spend thousands of dollars a year in order to “build” a user-friendly ActivePerl Windows installer for our self-hosted customers to use, when our customers can simply grab and use Strawberry Perl’s Windows installer for free? Plus, in doing so end up with a Perl installation that actually works on Windows!
Even if a tech-savvy customer was willing to go down the route of installing ActivePerl on their Windows server via the command line script – as things stand right now, they would have a broken installation that wasn’t capable of interacting with a MySQL/MariaDB database. Therefore, they wouldn’t be able to install and run a self-hosted MIDAS booking system.
Now, if ActiveState are committed to resolving these issues, then we’d be happy to take another look. However, for us to be won over, ActiveState would also have to reconsider the decision to put standalone Windows installers behind a paywall!
Right now, we can’t see how we can continue to recommend ActivePerl to our Windows-based customers. This is with a heavy heart, as for years we’d been big advocates of ActivePerl.
For any prospective customers who are interested in MIDAS and considering a self-hosted installation in a Windows environment, we recommend installing Strawberry Perl. Alternatively, you could consider our no-hassle cloud-hosted offering instead.
