• Feedback

  • Opalstack vs. Webfaction Performance

In the process of moving my sites over to Opalstack, I ran a few performance (Apache Bench) tests on the sites running on each server.

I made sure to run the apache bench tests both locally (so as to compare processing time and ignore network overheads) as well as on the corresponding server. I ran for one Wordpress site and one PHP website.

The results showed that Opalstack's server (Frankfurt, Opal6) was approximately 10-40% faster at processing the requests than the Webfaction server (UK, Web566).

Comparing like for like:


These were only very brief tests, so I'd be interested to see any of Opalstack's own benchmarking, and if anybody else has data - especially for Postgres databases.

I was pleasantly surprised by the speed improvements. Here's to hoping the Opalstack shared servers don't become sluggish as more users get added to them 😄

    pjrobertson Our shared servers are absolute beasts, and we're working very carefully to avoid overloading.

    We've definitely seen a few scaling issues on our first fleet of shared servers with the influx of new customers ❤️ over the past few weeks, but we've taken some immediate steps to mitigate that. We're also using that info to refine a lot of different things like our PHP deployment options, the managed database configuration, per-user system resource limits, etc so things will get better where they need to 🙂

      Thanks for the insights Sean. Looking forward to seeing what's to come (and hoping it comes soon, before Webfaction closes!).

      I've started deploying a few more of my resource-heavy apps over to Opalstack, and I do note that PHP (and possible postgres?) is struggling somewhat. I've sent you a ticket about it.

      I have a Wordpress server on Webfaction which is able to serve 20-30 simultaneous requests to dynamic content (that hit the database) out of the box, which I'm very impressed with. I hope we can see something else achievable on Opalstack soon, this post has me a little worried!

      • sean replied to this.

        pjrobertson we've seen some impressive results when switching a standard WP install over to our PHP-FPM+Nginx stack. If you'd like to try that please email support to let us know the shell user and app and we'll flip the necessary bits on the backend.

            sean Alright, I'll give it a test! Will most likely be later on this week when I get round to migrating my WP site.

            On the topic of simultaneous requests, do you have a max conn limit for a single user to the shared maria/postgres databases? I think Webfaction was around 20-30 (hence why my wordpress site on WF topped out at about 20-30 requests).

            Edit: I've just done some testing and it looks like the shared Mariadb instance has a limit of 30 connections. Anything above that and I start getting errors.

            • sean replied to this.

                pjrobertson Yes, we're using a limit of 30 connections here, it seems to be the optimal setting to manage DB resources on shared hosting.

                If the limit seems to be causing problems for you then:

                • Use caching where you can to limit your DB hits
                • Close DB connections when you are done with them
                • Reuse DB connections when you can
                • Last resort: use a private MariaDB instance with the settings you need.

                  Thanks Sean, those options are all already employed on the site, the site is just hitting its limits in terms of dynamic content being served.

                  A few more tests today on TTFB comparing the same Wordpress site on Webfaction (Singapore) and on Opalstack (Frankfurt). Tests run at 03:10 UTC. This time around, the Webfaction server massively outperformed the Opalstack server, being about 55% quicker.

                  Webfaction:
Connect: 0.000 TTFB: 0.649 Total time: 0.703 
Connect: 0.000 TTFB: 0.505 Total time: 0.550 
Connect: 0.000 TTFB: 0.445 Total time: 0.487 

Opalstack:
Connect: 0.000 TTFB: 1.151 Total time: 1.184 
Connect: 0.000 TTFB: 1.057 Total time: 1.092 
Connect: 0.000 TTFB: 1.104 Total time: 1.137

                  (all connections are local, from the same server to avoid network speed noise)

                  Command used:

                  SITES="a.b.c.d w.x.y.z"
for site in $SITES
do
  echo "$site"
  for i in 1 2 3
  do
  curl -o /dev/null -s -k -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" --header "Host: example.com" https://$site/XXX
  done
done
                  • sean replied to this.

                    pjrobertson I think we can tweak some gzip settings on your sites that might help, shoot a message to support if you'd like us to try that.

                        sean Thanks Sean! Switching over to Nginx+PHP-FPM as you mentioned in this post certainly seemed to help improve performance.

                        Here are the latest performance numbers:

                        Opalstack:
Connect: 0.000 TTFB: 0.262 Total time: 0.264 Length: 34639 
Connect: 0.000 TTFB: 0.211 Total time: 0.213 Length: 34639 
Connect: 0.000 TTFB: 0.229 Total time: 0.232 Length: 34639 

Webfaction:
Connect: 0.000 TTFB: 0.417 Total time: 0.453 Length: 34637 
Connect: 0.000 TTFB: 0.418 Total time: 0.457 Length: 34637 
Connect: 0.000 TTFB: 0.444 Total time: 0.479 Length: 34637

                        Note that here I'm testing TTFB (server response time) from the server itself, and not file download time, so enabling GZIP won't make a different to these numbers. I appreciate all the work you and the team are doing. I feel like Opalstack really is going the extra mile to help out its users. Thanks!

                        Still, I think work needs to be done to improve PHP out of the box. I think it's unreasonable to expect most users to be as nerdy about TTFB as me, and to file a ticket to switch over to Nginx+PHP-FPM. The previous results were for webfaction out of the box. Looking forward to seeing if Opalstack can tweak the default PHP performance!

                            Mastodon