Published on Sep 16, 2020

Puma vs Unicorn, Which is Better?

Trong các app server được sử dụng cho ứng dụng Rails thì có lẽ Puma, Unicorn và Passenger là những cái tên được nhắc đến nhiều nhất. Tuy nhiên do Passenger là một app server có tính phí nên ngày hôm nay chúng ta sẽ chỉ nói về Puma và Unicorn, cùng với đó, chúng ta sẽ đi tìm câu trả lời cho câu hỏi đâu mới là app server mạnh mẽ hơn.

Process, Thread

Trước khi đi vào chủ đề chính, mình sẽ nhắc lại một số khái niệm cơ bản cho những ai chưa biết hoặc đã quên. Nếu như bạn đã hiểu rõ về process và thread thì có thể bỏ qua phần này và chuyển đến phần tiếp theo nhé.

Process

Mỗi khi mở máy tính lên, việc đầu tiên các bạn làm là gì ? Với mình thì là bật Google Chrome lên. Nhưng có những hôm, do vội quá nên mình đã click vào Chrome tới 2 lần. Kết quả là đã có 2 cửa sổ Chrome được mở ra. Mỗi cửa sổ Chrome như vậy chính là một process đang chạy trong máy tính của mình.

Như vậy có thể hiểu một process là một tiến trình đang chạy trong hệ thống. Cùng một thời điểm có thể có một hay nhiều tiến trình chạy song song, tuy nhiên chúng độc lập với nhau và không chia sẻ bộ nhớ với nhau.

Thread

Trở lại ví dụ khi bạn mở Chrome lên, bây giờ trên một cửa sổ trình duyệt, bạn bật thêm các tab mới. Một tab xem Youtube còn tab kia để lướt Facebook. Mỗi tab lúc này sẽ chính là một thread. Vậy có thể nói rằng, một thread luôn nằm trong một process nào đó. Trong một process có thể có nhiều thread chạy cùng nhau, chúng có thể chia sẻ bộ nhớ với nhau. Điều này có thể hiểu đơn giản là khi bạn có một ứng dụng chạy nhiều thread, trong ứng dụng đó bạn lưu một biến global, lúc này ở tất cả các thread, bạn đều có thể chỉnh sửa biến global này mà không gặp bất cứ khó khăn nào cả.

Unicorn

Được xây dựng dựa trên kiến trúc multi-process và single-thread. Với mỗi request đến, Unicorn sẽ xử lý nó trên một thread trong một process duy nhất. Khi ứng dụng của chúng ta được khởi tạo, nó sẽ đồng thời được fork ra nhiều process khác nhau. Vậy điều gì sẽ xảy ra nếu như có request thứ 7 đến trong khi chúng ta chỉ có 6 process và tất cả trong số chúng đều đang bận? Câu trả lời là request thứ 7 đó sẽ phải đợi, đúng hơn là nó sẽ được đẩy vào queue cho đến khi một process nào đó đã xử lý công việc của nó. Nếu như hết thời gian đợi mà vẫn không có process nào tiếp nhận, request đó sẽ bị timeout - điều mà chúng ta cũng thường hay gặp.

Puma

Khác với Unicorn, Puma hỗ trợ multi-process và multi-thread. Điều này có nghĩa là mỗi một request sẽ được xử lý trên một thread và trên một process có thể có nhiều thread chạy cùng nhau. Nghe xong điều này liệu chúng ta có thể nói rằng Puma có khả năng xử lý được nhiều request hơn Unicorn trong cùng một khoảng thời hay không? Điều này là không thể chắc chắn được. Puma hỗ trợ multi-thread, tuy nhiên trong quá trình làm việc, nó không hoàn toàn được chạy multi-thread. Lý do là vì hiện nay MRI đang là trình thông dịch phổ biến nhất của Ruby. Nó dựa trên cơ chế Global Virtual Machine Lock (tên gọi cũ là Global Interpreter Lock/GLI), theo đó, tại một thời điểm chỉ cho phép chạy một thread, trong khi một process chỉ được thực thi trên một CPU duy nhất (mỗi một process chỉ được xử lý trên một core).

Nếu như vậy thì Puma có khác gì so với Unicron đâu? Tất nhiên là có khác, nhưng trước hết có một vài thứ mà chúng ta cần phải làm rõ. Đó là trong một request, server cần phải thực hiện 2 nhiệm vụ đó là: Hoạt động liên quan đến I/O (read/write file, database queries, api call…) và các tác vụ khác do CPU xử lý. Trong đó thời gian giành cho I/O chiếm phần lớn thời gian của một request. Mặc dù MRI chỉ cho phép chạy một thread trên một core tại một thời điểm do, nhưng trong thời gian thực hiện các tác vụ I/O tốn thời gian, nó có thể switch sang các thread khác để xử lý trước những tác vụ cần đến CPU. Chính vì điều này mà Puma vượt qua Unicorn trong hầu hết các bài kiểm tra Benchmark. Chi tiết hơn về các bài kiểm tra này, các bạn có thể xem thêm tại đây và đây nữa.

Hiện nay, với các trình thông dịch mới như jRuby hay Rubinius, chúng có thể cho phép chạy nhiều thread đồng thời, điều này sẽ giúp cho Ruby có thể chạy multi-thread một cách đúng nghĩa, khi đó hiệu quả mà Puma mang lại sẽ được thể hiện nhiều hơn nữa.

Conclusion

Vừa rồi là một số tìm hiểu của mình về Puma và Unicorn, nó cũng phần nêu lên được một số ưu điểm của Puma để khiến nó trở thành app server mặc định cho Rails. Tuy vậy việc lựa chọn app server nào còn tùy thuộc vào mục đích cũng như cấu hình máy chủ. Không phải cứ chạy nhiều process và nhiều thread là tốt vì nếu không sử dụng đúng, nó còn có thể gây lãng phí tài nguyên hệ thống. Một số điều mà chúng ta cần lưu ý khi lựa chọn sẽ có bao nhiêu process và bao nhiêu thread được chạy trên máy chủ của mình là:

• Mỗi một process sẽ cần một lượng RAM nhất định (với Rails app là từ 300 - 400 MB), do đó phải đảm bảo là server có đủ RAM.
• Quyết định có bao nhiêu thread sẽ được chạy trong một process phải dựa vào CPU, CPU phải đủ mạnh để chạy ứng dụng và phải đủ để xử lý các tác vụ khác nữa.

Nếu như bạn đang phân vân về việc lựa chọn app server nào cho ứng dụng của mình thì hi vọng bài viết này sẽ phần nào giúp bạn có được câu trả lời cho riêng mình.

Multithread

Read more

AWS CDK

Overview And Key Techniques In CDK

AWS Cloud Development Kit (CDK) là một framework mạnh mẽ cho phép sử dụng ngôn ngữ lập trình thông dụng như TypeScript, Python, Go… để định nghĩa và triển khai hạ tầng trên AWS. CDK giúp chúng ta dễ dàng quản lý resources bằng cách chuyển đổi từ mã nguồn sang mô hình hạ tầng dưới dạng CloudFormation. Để tìm hiểu kỹ hơn về CDK bạn có thể đọc qua bài viết IaC With AWS CDK. Dưới đây là tổng hợp các khía cạnh quan trọng khác mà bạn cần nắm vững để sử dụng CDK một cách hiệu quả. Phases CDK hoạt động theo ba phase chính: synth time, deploy time, và runtime. Mỗi phase có vai trò khác nhau trong việc xây dựng và quản lý hạ tầng trên AWS. Synth Time Ở giai đoạn này, CDK tổng hợp (synthesize) mã nguồn của bạn thành một tập hợp các tệp JSON dưới dạng CloudFormation Template. Không có resource nào được tạo trong giai đoạn này, nó chỉ đơn thuần là việc tạo ra mô tả hạ tầng. Khi bạn chạy lệnh cdk synth, CDK sẽ tạo ra template CloudFormation mô tả toàn bộ hạ tầng của bạn. Deploy Time Đây là giai đoạn triển khai (deploy) thực sự. Các template CloudFormation được gửi lên AWS và triển khai resources theo mô tả trong template. Lệnh cdk deploy sẽ triển khai các thay đổi của bạn lên tài khoản AWS. Trong quá trình này, AWS sẽ tạo, cập nhật hoặc xóa resource. Runtime Đây là giai đoạn khi các resource của bạn đang hoạt động trên AWS sau khi đã được triển khai. Các dịch vụ như Lambda, EC2, S3 sẽ hoạt động theo logic đã định nghĩa và bạn có thể bắt đầu tương tác với chúng. Resources Mỗi resource trong AWS được định nghĩa thông qua Construct. Tập hợp nhiều constructs tạo nên một Stack. Ví dụ về construct: new s3.Bucket(this, 's3-bucket', { versioned: false, autoDeleteObjects: true, removalPolicy: cdk.RemovalPolicy.RETAIN, }); Ví dụ về stack: import * as cdk from 'aws-cdk-lib'; import * as s3 from 'aws-cdk-lib/aws-s3'; import * as iam from 'aws-cdk-lib/aws-iam'; import { Construct } from 'constructs'; interface S3Props extends cdk.StackProps { allowPolicies: Array<iam.Policy>; } export class S3Stack extends cdk.Stack { constructor(scope: Construct, id: string, props: S3Props) { super(scope, id, props); const bucket = new s3.Bucket(this, 's3-bucket', { versioned: false, autoDeleteObjects: true, removalPolicy: cdk.RemovalPolicy.RETAIN, }); props.allowPolicies.forEach((policy) => { bucket.grantReadWrite(policy); }); } } Bất cứ resource nào trong CDK sẽ luôn được xác định dựa vào scope và ID. Trong một scope không được phép xuất hiện 2 resources có cùng ID. Khi thay đổi scope hoặc ID của một resource, CDK sẽ xoá resource cũ và replace nó bằng một resource mới. Vì vậy với những resource như S3, RDS, Elasticache… việc thay đổi trên có thể làm mất dữ liệu. Do đó bạn cần quản lý chúng thông qua removalPolicy một cách cẩn thận. Stack References Trong một project CDK, bạn cần nhóm những resources có liên quan vào trong một stack, điều này giúp bạn quản lý resources tốt hơn. Lý tưởng nhất là khi các stacks hoạt động độc lập, sự thay đổi trong stack này không ảnh hưởng đến các stacks khác. Việc có quá nhiều resources trong một stack sẽ phát sinh vấn đề khi deploy. Nếu có bất kỳ lỗi nào xảy ra trong quá trình này thì toàn bộ stack sẽ bị rollback. Đôi khi điều này sẽ làm tốn khá nhiều thời gian của bạn. Nhưng nếu thiết kế một stack có ít resources hơn thì bạn sẽ cần tạo ra nhiều stacks hơn, các stacks cũng sẽ ràng buộc với nhau phức tạp hơn. Vì vậy việc thiết kế stack là rất quan trọng. Trong trường hợp không tránh khỏi việc ràng buộc giữa các stacks, bạn có thể sử dụng những cách dưới đây để truyền thông tin giữa chúng. Sử dụng Properties Đây là cách đơn giản nhất, bạn chỉ cần truyền properties từ stack này sang stack kia thông qua stack props: const vpcStack = new VpcStack(scope, 'vpc-stack', { env: props.env }); const webStack = new WebStack(scope, 'web-stack', { env: props.env, vpc: vpcStack.vpc, }); new S3Stack(scope, 's3-stack', { env: props.env, allowPolicies: [webStack.policy] }); Trong ví dụ trên web-stack nhận vào vpc được tạo từ vpc-stack. Policy được tạo ra trong web-stack sau đó được truyền vào s3-stack để thực hiện grant bucket cho policy này. cdk.CfnOutput và cdk.Fn.importValue Bạn có thể sử dụng cdk.CfnOutput để export thông tin trong một stack. Các stack khác có thể sử dụng cdk.Fn.importValue để import những thông tin cần thiết. Quay lại ví dụ trên, ở vpc-stack sẽ thực hiện export vpcId : import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import { Construct } from 'constructs'; export class VpcStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, 'main-vpc'); new cdk.CfnOutput(this, 'mainVpcId', { value: vpc.vpcId, exportName: 'mainVpcId', }); } } web-stack sẽ import giá trị này vào để sử dụng: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import { Construct } from 'constructs'; export class WebStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpcId = cdk.Fn.importValue('mainVpcId'); const vpc = ec2.Vpc.fromVpcAttributes(this, 'vpc', { availabilityZones: ['ap-northeast-1a', 'ap-northeast-1c'], vpcId: vpcId, }); } } Với cách này, việc chia sẻ thông tin giữa các stack trở nên linh hoạt hơn, bạn không cần phải truyền trực tiếp thông tin từ stack này sang stack kia. Tuy nhiên nó không giải quyết được vấn đề ràng buộc giữa các stack. Nếu không quản lý tốt, bạn có thể gặp phải tình huống hai stacks bị phụ thuộc vào tham số export từ stack còn lại dẫn đến việc lock lẫn nhau. Bạn sẽ không thể thực hiện update hay delete một trong hai stack. Sử dụng SSM Parameter Store SSM Parameter Store được sử dụng để lưu trữ các tham số, như các thông tin cấu hình, secret key. Chúng có thể được truy xuất bằng API hoặc SDK từ các dịch vụ AWS hay các ứng dụng khác. Bạn cũng có thể dùng nó để chia sẻ thông tin giữa các stack nằm trong các dự án cdk khác nhau. Với SSM chúng ta sẽ viết lại vpc-stack như sau: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import { Construct } from 'constructs'; export class VpcStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, 'main-vpc'); new ssm.StringParameter(this, 'main-vpc-id', { parameterName: '/main-vpc/id', stringValue: vpc.vpcId, }); } } Tương tự, web-stack sẽ lockup parameter main-vpc-id để sử dụng: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import { Construct } from 'constructs'; export class WebStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpcId = ssm.StringParameter.valueFromLookup(this, '/main-vpc/id'); const vpc = ec2.Vpc.fromLookup(this, 'vpc', { vpcId }); } } Như vậy web-stack không còn phụ thuộc vào vpc-stack nữa, nó sẽ chỉ phụ thuộc vào parameter store. Cách làm này thích hợp khi có nhiều dự án cùng sử dụng chung một resource ví dụ như RDS, ALB… Lúc này bạn có thể lưu thông tin như ID, ARN của các resources này lên store, dự án khác muốn dùng chỉ cần lookup các thông tin cần thiết để import vào. Conclusion Sử dụng AWS CDK đòi hỏi sự hiểu biết về các phase hoạt động cũng như cách quản lý resource thông qua stack và chia sẻ thông tin giữa các stack với nhau. Bằng cách nắm vững các kỹ thuật này bạn sẽ có thể xây dựng và quản lý hạ tầng trên AWS một cách hiệu quả và tối ưu hơn.

Sep 15, 2024

Vue

SPA With Vue And Rails

Ứng dụng SPA đang ngày càng trở nên phổ biến bởi những ưu điểm mà nó mang lại. Có thể kể đến như tốc độ tải trang nhanh, trải nghiệm mượt mà, tách biệt logic frontend và backend, giúp chuyên môn hoá từng bộ phận trong dự án. Khó khăn khi phát triển ứng dụng SPA nằm ở việc kết nối giữa và đảm bảo tính đồng bộ giữa hai server frontend và backend. Đây là những vấn đề mà bạn không bao giờ gặp ở một ứng dụng SSR. Chưa kể việc tạo ra nhiều server có thể gây lãng phí vì thực tế chỉ có server backend chịu tải chính, server frontend sẽ chỉ lưu các tài nguyên như html, css, js… Có một hướng tiếp cận đơn giản hơn giúp bạn sử dụng SPA cho dự án của mình mà không phải lo lắng đến các vấn đề trên. Bài viết này sẽ giúp bạn thực hiện điều đó với Vue và Rails.

Aug 20, 2024