You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/ruby-on-rails/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ cascade:
7
7
8
8
minutes_to_complete: 40
9
9
10
-
who_is_this_for: This learning path is intended for software developers deploying and optimizing Ruby on Rails workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
10
+
who_is_this_for: This is an introductory topic intended for software developers deploying and optimizing Ruby on Rails workloads on LinuxArm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
11
11
12
12
learning_objectives:
13
13
- Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
## Baseline Setup for Ruby on Rails with PostgreSQL
10
-
This section covers the installation and configuration of **PostgreSQL** and a **Rails application** on a SUSE Arm-based GCP VM. It includes setting up PostgreSQL, creating a Rails app, configuring the database, and starting the Rails server.
10
+
This section sets up PostgreSQL and connects it with a Ruby on Rails application on a SUSE Arm64 Google Cloud C4A virtual machine. You’ll install PostgreSQL, configure it for Rails, create a database user, and verify that Rails can connect and serve requests successfully.
11
11
12
12
### Install and Configure PostgreSQL
13
-
PostgreSQL is used with Ruby on Rails as a robust, production-ready relational database that reliably stores and manages application data.
13
+
PostgreSQL is a robust, production-grade relational database that integrates seamlessly with Ruby on Rails.
If the Active state reads running, your PostgreSQL service is operational and ready for configuration.
27
47
28
-
This command creates a new PostgreSQL role (user) named `gcpuser` with **superuser privileges**.
48
+
### Create a Database Role for Rails
49
+
Next, create a dedicated PostgreSQL role (user) that Rails will use to connect to the database.
29
50
30
51
```console
31
-
sudo -u postgres createuser --superuser gcpuser
52
+
sudo -u postgres psql -c "CREATE USER gcpuser WITH SUPERUSER PASSWORD 'your_password';"
32
53
```
33
-
-`sudo -u postgres` → Runs the command as the `postgres` user (default PostgreSQL superuser).
34
-
-`createuser --superuser gcpuser` → Creates a PostgreSQL role named `gcpuser` with full admin privileges.
35
-
- Can create databases
36
-
- Can create other roles/users
37
-
- Can grant privileges
54
+
This command:
55
+
56
+
Executes under the default PostgreSQL superuser account (postgres).
57
+
Creates a new PostgreSQL role called gcpuser.
58
+
Assigns superuser privileges, allowing the user to create databases, manage roles, and execute administrative tasks.
59
+
60
+
This user will serve as the Rails database owner and be referenced in the Rails configuration file (config/database.yml) later.
38
61
39
-
This role will be used by Rails to connect to the PostgreSQL database.
62
+
### Set Environment variables
63
+
64
+
Before creating your Rails application, export environment variables so Rails and the `pg gem` can authenticate automatically with PostgreSQL.
65
+
66
+
```console
67
+
export PGUSER=gcpuser
68
+
export PGPASSWORD=your_password
69
+
export PGHOST=localhost
70
+
```
71
+
72
+
PGUSER → Specifies the PostgreSQL user that Rails will connect as.
73
+
PGPASSWORD → Stores the password for that user in memory (temporary for this session).
74
+
PGHOST → Points to the PostgreSQL host (in this case, the local VM).
40
75
41
76
### Create a Rails App with PostgreSQL
42
-
Creates a new Rails application configured to use PostgreSQL as its database.
77
+
Now, generate a new Rails application configured to use PostgreSQL as its default database adapter:
43
78
44
79
```console
45
80
rails new db_test_rubyapp -d postgresql
46
81
cd db_test_rubyapp
47
82
bundle install
48
83
```
49
-
- Creates a new Rails application called `db_test_app`.
50
-
-`d postgresql` → Tells Rails to use PostgreSQL as the database instead of the default SQLite.
51
-
-`bundle install` ensures all required gems are installed.
84
+
-rails new db_test_rubyapp → Creates a new Rails application named db_test_rubyapp.
85
+
-`d postgresql` → Instructs Rails to use PostgreSQL instead of the default SQLite database.
86
+
- bundle install → Installs all gem dependencies defined in the Gemfile, including the pg gem that connects Rails to PostgreSQL.
52
87
53
88
{{% notice Note %}}
54
89
Check `config/database.yml` to ensure the `username` and `password` match your PostgreSQL role `(gcpuser)`.
55
90
{{% /notice %}}
56
91
57
92
### Verify and Update Database Configuration
58
-
Open the Rails database configuration file:
93
+
Rails uses the `config/database.yml` file to define how it connects to databases in different environments (development, test, and production).
94
+
It's important to verify that these credentials align with the PostgreSQL role you created earlier.
95
+
96
+
Open the file with your preferred text editor:
59
97
60
98
```console
61
-
nano config/database.yml
99
+
sudo vi config/database.yml
62
100
```
63
-
Find the `default`: and `development`: sections.
64
-
Ensure the username matches the PostgreSQL user you created (gcpuser):
101
+
Locate the default and development sections, and make sure they match the PostgreSQL user and password you configured.
65
102
66
-
You should see output similar to:
103
+
Your configuration file should have the following fields set:
67
104
```output
68
105
default: &default
69
106
adapter: postgresql
70
107
encoding: unicode
71
108
username: gcpuser
72
-
password:
109
+
password: your_password
73
110
host: localhost
74
111
pool: 5
75
112
76
113
development:
77
114
<<: *default
78
115
```
116
+
117
+
### Change the Authentication Method
118
+
By default, PostgreSQL on many Linux distributions (including SUSE) uses the ident authentication method for local connections. This method maps Linux system usernames directly to PostgreSQL roles. While convenient for local access, it prevents password-based authentication, which is necessary for Rails and most application connections.
119
+
120
+
To allow Rails to connect using a username and password, change the authentication method in PostgreSQL’s configuration file `pg_hba.conf` from ident to md5.
121
+
122
+
Open your configuration file
123
+
```console
124
+
sudo vi /var/lib/pgsql/data/pg_hba.conf
125
+
```
126
+
The file location `/var/lib/pgsql/data/pg_hba.conf` is the default data directory path for PostgreSQL on SUSE Linux.
127
+
128
+
Find lines like the following in the file:
129
+
130
+
```output
131
+
# IPv4 local connections:
132
+
host all all 127.0.0.1/32 ident
133
+
# IPv6 local connections:
134
+
host all all ::1/128 ident
135
+
```
136
+
Modify both lines to use md5, which enables password-based authentication:
137
+
138
+
```output
139
+
# IPv4 local connections:
140
+
host all all 127.0.0.1/32 md5
141
+
# IPv6 local connections:
142
+
host all all ::1/128 md5
143
+
```
144
+
After saving the file, restart the PostgreSQL service to apply the new authentication settings:
145
+
146
+
```console
147
+
sudo systemctl restart postgresql
148
+
```
149
+
150
+
Verify the change:
151
+
```console
152
+
sudo systemctl status postgresql
153
+
```
154
+
The service should show as active (running).
155
+
79
156
### Create and Initialize the Database
80
-
Initializes and creates the development and test databases for your Rails app using PostgreSQL.
157
+
Once PostgreSQL is configured and Rails can authenticate, you can create your application’s development and test databases.
158
+
This step verifies that Rails is correctly connected to PostgreSQL and that the pg gem is working on your Arm64 environment.
81
159
160
+
Run the following command from inside your Rails app directory:
82
161
```console
83
162
rails db:create
84
163
```
@@ -87,22 +166,26 @@ You should see output similar to:
87
166
Created database 'db_test_rubyapp_development'
88
167
Created database 'db_test_rubyapp_test'
89
168
```
90
-
This means Rails successfullyconnected to PostgreSQL and created both dev and test databases.
169
+
This output confirms that Rails successfully. It connected to the PostgreSQL service using the credentials from `config/database.yml`and created two new databases — one for development and one for testing.
91
170
92
171
### Generate a Scaffold for Testing
93
-
A database and Scaffold are required to create the actual PostgreSQL database for your Rails app and quickly generate the model, controller, views, and migrations for your data.
94
-
Let’s create a small test model and table — for example, a simple Task tracker:
172
+
To verify your Ruby on Rails and PostgreSQL integration, you’ll create a small scaffold application.
173
+
A scaffold is a Rails generator that automatically builds a model, controller, views, and database migration, allowing you to test CRUD (Create, Read, Update, Delete) operations quickly.
174
+
175
+
For this example, you’ll create a simple Task Tracker app that manages tasks with titles and due dates.
176
+
Run the following command inside your Rails project directory:
This verifies the basic functionality of the Ruby/Rails installation before proceeding to the benchmarking.
310
+
With port 3000 reachable and the welcome page loading, your Rails stack on SUSE Arm64 (C4A Axion) is verified end-to-end and you can proceed to benchmarking.
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/ruby-on-rails/benchmarking.md
+20-27Lines changed: 20 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,25 +7,25 @@ layout: learningpathall
7
7
---
8
8
9
9
10
-
## Ruby on Rails Benchmarking with built-in Benchmark
11
-
This section benchmarks Ruby on Rails using Ruby’s built-in `Benchmark` library to measure execution time for database inserts, queries, and CPU computations on GCP SUSE VMs, providing insights into performance metrics and bottlenecks.
10
+
## Ruby on Rails Benchmarking
11
+
In this section you will benchmark Ruby on Rails using Ruby’s built-in `Benchmark` library to measure execution time for database inserts, queries, and CPU computations on GCP SUSE VMs, providing insights into performance metrics and bottlenecks.
12
12
13
13
### Go into your Rails app folder
14
-
You need to navigate into the folder of your Rails application. This is where Rails expects your application code, models, and database configurations to be located. All commands related to your app should be run from this folder.
14
+
Navigate into the folder of your Rails application. This is where Rails expects your application code, models, and database configurations to be located. All commands related to your app should be run from this folder.
15
15
16
16
```console
17
17
cd ~/db_test_rubyapp
18
18
````
19
19
20
-
### Create the benchmark file inside the app
21
-
We create a new Ruby file named `benchmark.rb` where we will write code to measure performance.
20
+
### Create the benchmark
21
+
Now create a new Ruby file named `benchmark.rb` where you will write code to measure performance.
22
22
23
23
```console
24
-
nano benchmark.rb
24
+
vi benchmark.rb
25
25
```
26
26
27
27
### Benchmark code for measuring Rails app performance
28
-
Below mentioned code (`benchmark.rb` file) measures database inserts, queries, and CPU computations in your Rails application using Ruby’s Benchmark library.
28
+
Copy the code below into `benchmark.rb`. It measures database inserts, queries, and CPU computations in your Rails application using Ruby’s Benchmark library.
29
29
30
30
```ruby
31
31
require'benchmark'
@@ -62,21 +62,21 @@ end
62
62
This code gives you a basic understanding of how your Rails app performs under different types of workloads.
63
63
64
64
### Run the benchmark inside Rails
65
-
Now that your benchmark file is ready, run it **within the Rails environment** using the following command:
65
+
Now that your benchmark file is ready, run it within the Rails environment using the following command:
66
66
67
67
```console
68
68
rails runner benchmark.rb
69
69
```
70
-
-`rails runner` runs any Ruby script in the context of your Rails application.
70
+
`rails runner` runs any Ruby script in the context of your Rails application.
71
71
72
-
-It automatically loads your **Rails environment**, including:
72
+
It automatically loads your Rails environment, including:
73
73
- All models (like `Task`)
74
74
- Database connections
75
75
- Configuration and dependencies
76
76
77
-
-This ensures that your benchmark can interact with the **PostgreSQL database** through ActiveRecord, rather than running as a plain Ruby script.
77
+
This ensures that your benchmark can interact with the PostgreSQL database through ActiveRecord, rather than running as a plain Ruby script.
-**total** → `user + system` (sum of CPU processing time).
93
93
-**real** → The **wall-clock time** (actual elapsed time, includes waiting for DB, I/O, etc).
94
94
95
-
### Benchmark summary on x86_64
96
-
To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE:
97
-
98
-
| Task | user (sec) | system (sec) | total (sec) | real (sec) |
### Ruby/Rails performance benchmarking comparison on Arm64 and x86_64
106
+
### Key Takeaways
107
+
108
+
When you look the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
116
109
117
-
When you compare the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
110
+
Rails on Arm64 performs consistently: Ruby and PostgreSQL are both natively optimized for Arm, providing stable, predictable latency.
111
+
Database I/O remains the main optimization target: Techniques such as query caching, connection pooling, and async queries can improve DB-heavy performance.
112
+
Compute-bound tasks scale well: Axion’s Arm cores and Ruby’s YJIT show excellent CPU utilization for non-I/O workloads.
118
113
119
-
-**Database operations are the main bottleneck:** DB Insert and DB Query take the most time.
120
-
-**DB Query has the highest latency:** It is the slowest operation at 3.39 seconds.
121
-
-**Core computation is fast:** Pure Ruby/Rails calculations complete quickly at 0.41 seconds.
114
+
Ruby on Rails runs efficiently on Google Cloud’s Axion-based C4A Arm64 instances.
0 commit comments