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/background.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,15 @@ weight: 2
6
6
layout: "learningpathall"
7
7
---
8
8
9
-
## Google Axion C4A Arm instances in Google Cloud
9
+
## Learn about Google Axion C4A Arm instances in Google Cloud
10
10
11
11
Google Axion C4A is a family of Arm-based virtual machines built on Google's custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines offer strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
12
12
13
13
The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud.
14
14
15
15
To learn more about Google Axion, refer to the [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) blog.
16
16
17
-
## Ruby on Rails
17
+
## Learn about Ruby on Rails
18
18
19
19
Ruby on Rails (Rails) is an open-source, server-side web application framework written in Ruby.
-`postgresql-devel` lets you compile the `pg` gem for Rails.
20
+
21
+
This installs two packages:
22
+
-`postgresql-server` - the PostgreSQL database service
23
+
-`postgresql-devel` - development headers needed to compile the `pg` gem that connects Rails to PostgreSQL
24
+
25
+
The development headers are essential because Rails uses the `pg` gem to communicate with PostgreSQL, and this gem needs to be compiled during installation.
21
26
22
27
Start PostgreSQL and enable it to run at boot:
23
28
@@ -41,47 +46,63 @@ The output is similar to:
41
46
```
42
47
If the Active state is running, PostgreSQL is ready.
43
48
44
-
###Create a PostgreSQL user for Rails
49
+
## Create a PostgreSQL user for Rails
45
50
46
51
Create a dedicated PostgreSQL user for your Rails app:
47
52
48
53
```console
49
54
sudo -u postgres psql -c "CREATE USER gcpuser WITH SUPERUSER PASSWORD 'your_password';"
50
55
```
51
-
- This command creates a user named `gcpuser` with superuser privileges.
52
-
53
-
You’ll use this user in your Rails configuration.
56
+
This command creates a user named `gcpuser` with superuser privileges. You’ll use this user in your Rails configuration.
54
57
55
-
###Set environment variables
58
+
## Set environment variables
56
59
57
-
Export environment variables so Rails and the `pg` gem can connect to PostgreSQL:
60
+
Set environment variables for Rails to connect to PostgreSQL:
58
61
59
62
```console
60
63
export PGUSER=gcpuser
61
64
export PGPASSWORD=your_password
62
65
export PGHOST=localhost
63
66
```
64
-
-`PGUSER` sets the PostgreSQL user.
65
-
-`PGPASSWORD` stores the password for this session.
66
-
-`PGHOST` points to the local VM.
67
67
68
-
### Create a new Rails app with PostgreSQL
68
+
These variables tell Rails how to connect to your PostgreSQL database:
69
+
-`PGUSER` - the PostgreSQL username you created
70
+
-`PGPASSWORD` - the password for that user
71
+
-`PGHOST` - tells Rails to connect to the local database server
72
+
73
+
## Create a new Rails app with PostgreSQL
74
+
75
+
Now you'll create a Rails application configured to use PostgreSQL as its database.
69
76
70
-
Generate a new Rails app that uses PostgreSQL:
77
+
Generate a new Rails app:
71
78
72
79
```console
73
80
rails new db_test_rubyapp -d postgresql
81
+
```
82
+
83
+
This command creates a new Rails application named `db_test_rubyapp` with PostgreSQL as the default database adapter.
84
+
85
+
Navigate to your new app directory:
86
+
87
+
```console
74
88
cd db_test_rubyapp
89
+
```
90
+
91
+
Install the required gems:
92
+
93
+
```console
75
94
bundle install
76
95
```
77
-
-`rails new db_test_rubyapp -d postgresql` creates a Rails app using PostgreSQL.
78
-
-`bundle install` installs gem dependencies, including the `pg` gem.
96
+
97
+
The `bundle install` command downloads and installs all the gem dependencies listed in your `Gemfile`, including the `pg` gem that allows Rails to communicate with PostgreSQL.
98
+
99
+
You now have a Rails application ready to connect to your PostgreSQL database.
79
100
80
101
{{% notice Note %}}
81
102
Check `config/database.yml` and make sure `username` and `password` match your PostgreSQL user (`gcpuser`).
82
103
{{% /notice %}}
83
104
84
-
###Update Rails database configuration
105
+
## Update Rails database configuration
85
106
86
107
Open `config/database.yml` and confirm the credentials:
87
108
@@ -103,7 +124,7 @@ development:
103
124
<<: *default
104
125
```
105
126
106
-
###Change the Authentication Method
127
+
## Change the Authentication Method
107
128
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.
108
129
109
130
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.
@@ -142,7 +163,7 @@ sudo systemctl status postgresql
142
163
```
143
164
The service should show as active (running).
144
165
145
-
###Create and Initialize the Database
166
+
## Create and Initialize the Database
146
167
Once PostgreSQL is configured and Rails can authenticate, you can create your application’s development and test databases.
147
168
This step verifies that Rails is correctly connected to PostgreSQL and that the pg gem is working on your Arm64 environment.
148
169
@@ -158,24 +179,25 @@ Created database 'db_test_rubyapp_test'
158
179
```
159
180
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.
160
181
161
-
###Generate a Scaffold for Testing
182
+
## Generate a Scaffold for Testing
162
183
To verify your Ruby on Rails and PostgreSQL integration, you’ll create a small scaffold application.
163
184
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.
164
185
165
186
For this example, you’ll create a simple Task Tracker app that manages tasks with titles and due dates.
187
+
166
188
Run the following command inside your Rails project directory:
![Rails default welcome page displaying Ruby on Rails framework logo with green and red styling, welcome message, and navigation links for About your application environment, getting started guide, and Rails documentation on a clean white background alt-text#center](images/rails-web.png"Ruby/Rails welcome page")
292
313
293
314
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
+52-30Lines changed: 52 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,25 +7,27 @@ layout: learningpathall
7
7
---
8
8
9
9
10
-
## Ruby on Rails Benchmarking
10
+
## Overview
11
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
-
### Go into your Rails app folder
13
+
##Locate the Rails app folder
14
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
21
-
Now create a new Ruby file named `benchmark.rb` where you will write code to measure performance.
20
+
## Create the benchmark file
21
+
22
+
Create a new Ruby file called `benchmark.rb` to measure your Rails application's performance:
22
23
23
24
```console
24
25
vi benchmark.rb
25
26
```
26
27
27
-
### Benchmark code for measuring Rails app performance
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.
28
+
This file will contain the benchmarking code that tests different aspects of your application's performance.
29
+
Copy the following code into `benchmark.rb`. This code measures three different aspects of your Rails application's performance:
-`n = 1000` → Sets the number of iterations for each task. You can increase or decrease this number to simulate heavier or lighter workloads.
57
-
-`Benchmark.bm` → Starts a block to measure performance of different tasks.
58
-
-**DB Insert** → Creates 1,000 new `Task` records in the database. Measures how long it takes to insert data.
59
-
-**DB Query** → Retrieves the 1,000 `Task` records from the database. Measures how long it takes to query data.
60
-
-**Computation** → Performs a simple calculation 1,000 times. Measures pure CPU performance (without database interactions).
57
+
This benchmarking script tests three key areas of your Rails application's performance:
58
+
59
+
- The `require 'benchmark'` statement loads Ruby's built-in benchmarking library, which provides precise timing measurements for code execution.
60
+
- The variable `n = 1000` sets how many times each test runs - you can adjust this number to simulate lighter or heavier workloads depending on your testing needs.
61
+
- The `Benchmark.bm` method creates a benchmarking block that measures and reports the performance of different tasks. Within this block, three different tests run to evaluate your application:
62
+
63
+
- The DB Insert test creates 1,000 new `Task` records in your PostgreSQL database. This measures how efficiently your application can write data, which is crucial for understanding performance during high-volume data entry operations.
64
+
65
+
- The DB Query test retrieves those same `Task` records from the database. This measurement shows how quickly your application can read data, helping you understand performance during data-heavy read operations like report generation or search functionality.
66
+
67
+
- The Computation test performs a mathematical calculation (summing numbers 1 through 10,000) repeatedly without any database interaction. This gives you a baseline for pure CPU performance, showing how your application handles processing-intensive tasks that don't involve external resources.
61
68
62
69
This code gives you a basic understanding of how your Rails app performs under different types of workloads.
The output shows four different timing measurements that help you understand where your application spends its time.
97
+
98
+
- The user time measures how long your Ruby code actually ran on the CPU. This represents the pure processing time for your application logic, calculations, and Ruby operations.
99
+
100
+
- The system time tracks how long your application spent waiting for system-level operations like database queries, file I/O, and network requests. Higher system time usually indicates bottlenecks in external resources.
101
+
102
+
- The total time simply adds user and system time together, giving you the complete CPU processing time your application consumed.
103
+
104
+
- The real time shows the actual wall-clock time that passed from start to finish. This includes everything: CPU processing, waiting for the database to respond, network delays, and any other factors that made your application pause. Real time is often higher than total time because your application might wait for resources that are busy with other tasks.
87
105
88
-
### Benchmark Metrics Explained
106
+
When real time significantly exceeds total time, it typically indicates that your application is spending considerable time waiting for external resources rather than actively processing data.
89
107
90
-
-**user** → Time spent executing your Ruby code (**CPU time in user mode**).
91
-
-**system** → Time spent in **system calls** (I/O, database, kernel interactions).
92
-
-**total** → `user + system` (sum of CPU processing time).
93
-
-**real** → The **wall-clock time** (actual elapsed time, includes waiting for DB, I/O, etc).
108
+
## Benchmark summary on Arm64
94
109
95
-
### Benchmark summary on Arm64
96
-
Results summarized from the your run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
110
+
Here are the performance results from running the benchmark on a `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP with SUSE:
97
111
112
+
| Task | User Time | System Time | Total Time | Real Time |
- Database operations (insert and query) take significantly longer than pure computation, with queries being the slowest operation.
121
+
- System time is minimal across all tasks, indicating efficient system resource usage on Arm64.
122
+
- Real time closely matches total time for most operations, showing minimal waiting for external resources.
123
+
- Computation tasks run very efficiently, demonstrating strong CPU performance on Axion processors.
105
124
106
-
###Key Takeaways
125
+
## Key takeaways
107
126
108
-
When you look the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
127
+
When you analyze the benchmarking results, you'll notice several important patterns on Google Cloud Axion C4A Arm-based instances:
109
128
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.
129
+
- Consistent performance - Ruby and PostgreSQL are both natively optimized for Arm, which provides stable and predictable latency across different workloads.
130
+
- Database optimization opportunities - the results show that database I/O remains the primary bottleneck. You can improve database-heavy performance using techniques such as:
131
+
- Query caching
132
+
- Connection pooling
133
+
- Asynchronous queries
134
+
- Strong compute performance - Axion's Arm cores combined with Ruby's YJIT compiler demonstrate excellent CPU utilization for compute-intensive tasks that don't rely heavily on I/O operations.
113
135
114
-
Ruby on Rails runs efficiently on Google Cloud’s Axion-based C4A Arm64 instances.
136
+
Ruby on Rails runs efficiently on Google Cloud's Axion-based C4A Arm64 instances, making them a solid choice for Rails applications.
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/ruby-on-rails/installation.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
1
---
2
-
title: Install Ruby on Rails
2
+
title: Install Ruby on Rails on SUSE Linux
3
3
weight: 4
4
4
5
5
### FIXED, DO NOT MODIFY
6
6
layout: learningpathall
7
7
---
8
8
9
-
## Install Ruby on Rails on SUSE Linux
9
+
## Overview
10
10
11
11
In this section, you'll install Ruby, Rails, and essential supporting tools on your Google Cloud C4A instance running SUSE Enterprise Linux. The steps ensure your environment is ready to build, deploy, and optimize Ruby on Rails applications on Arm-based infrastructure.
12
12
@@ -17,7 +17,7 @@ Start by updating your system packages to ensure you have the latest security pa
17
17
sudo zypper update
18
18
```
19
19
## Install required dependencies
20
-
Before installing Ruby, install essential development libraries and tools that ensure Ruby compiles and runs correctly on your SUSE Arm64 environment:
20
+
Install essential development libraries and tools that Ruby needs to compile and run properly on your SUSE Arm64 system:
0 commit comments