For customers, it is important to know how Betty Blocks handles high-volume requests to their application. This article aims to answer any questions related to performance of the platform and how we guarantee performance when the app is used at scale.

Performance Statistics (as of Q1 2019)

This chapter includes statistics on which scale the platform currently operates, these statistics were measured in Q1 2019. Please contact support via chat if you need more
recent numbers. 

Note: Every production app is powered by only one codebase, and all apps share all hardware we have.

General Betty Blocks Platform

  • Apps currently running in Production: 5.500

  • Database tables running in Production: 80.500

  • Database fields running in Production: 916.600

  • Back-office views running in Production: 89.600

  • Actions running in Production: 102.000

  • Endpoints running in Production: 96.500

  • Commits made to our codebase: 62.500

Front-end Servers (serving HTML/CSS/JSON/JSON to clients)

  • Average response times in platform or back-office: 150 ms

  • Average response times from GET endpoints: 500 ms

  • Average response times from POST endpoints: 600 ms

  • Average daily requests on our front-end servers: 7.1 million

  • Average yearly request on our front-end servers: 2.6 billion

Application Servers (Actions, Expressions etc)

  • Average calculations per 24 hours: 11.4 million

  • Average calculations per year: 4.2 billion

  • Average calculation time for actions: 1,7 seconds

  • Average time to import large CSV or Excel files: 40 seconds

  • Average time to generate an export file: 8 seconds

  • Average time to mass delete records: 6 seconds

  • Average time to merge changes to production: 30 seconds

  • Average time to create a new application: 10 seconds

Background and Technologies Used

The Betty Blocks platform is 100% cloud-based, that means that building applications happens from within the browser. Also, apps on the platform are not the result of generated code, apps are simply 'configurations' on our platform. With this setup we've removed the need to tie a specific app to a specific piece of hardware/server, all of our production apps share the same hardware. In terms of scaling, this results in the possibility that Betty Blocks could scale up servers at any given moment, for all apps. We have auto-scaling enabled on our infrastructure, so as soon as we detect high load on the infrastructure we automatically add new servers.

Codebase That Allows for High Scalability

For our codebase, we use a mix of Ruby on Rails and the highly scalable language Elixir/Erlang. We are currently in the process of transforming our Ruby codebase to a more Elixir-oriented codebase. For every module we transformed from Ruby to Elixir, we achieved over 200% increase in performance, in some cases we increased it by 500%. On top of that, our Elixir codebase needed just 30% of the current Ruby servers we run.

Elixir is a dynamically-typed functional programming language emphasizing a sweet-spot between programmer productivity and functional purity. Utilizing the underlying Erlang/OTP (created by Ericsson in 1986), it offers massive scalability options benefitting from the same technology that drives high availability, high-throughput telecom and networking infrastructure. By being a functional programming language Elixir (and Erlang) are able to fully utilize modern multi-core processors, maximizing resource utilization on off-the-shelf (i.e. commodity) hardware and virtualized environments. Functional programming language in general benefits from the fact that code written in them is easier to reason with (w.r.t. correctness and completeness). The Elixir environment also offers features as hot code reloading (updates without downtime) and dynamic recompilation (i.e. meta programming).

WhatsApp is one of the most successful users of Elixir, they scaled to almost 1 billion active users with only 50 engineers.

Any questions? Please contact us via chat. Our Elixir engineers would love to answer any questions you might have!

Did this answer your question?