anh ơi của em bị lỗi như này anh ạ, event em thấy có rồi mà phải load lại mới có tin nhắn anh ạ

1. Pool size là số connection tối đa cho 1 pool, giống như số ghế trong lớp học, nhưng bạn không nhất thiết lúc nào cũng xếp đầy ghế.

2. Hình như bạn nói là không fair, chứ trên bài mình đâu có nói là không fair nhỉ? Nếu không fair thì giống như so sánh 1 CPU và 3 CPUs ấy.

3. Bạn có chắc chắn là 5 connection là đã ổn định, lỡ như user truy cập tăng đột ngột thì sao, 5 connection có đủ không?

   3.1 Tạo luôn 5 connection từ đầu? chưa thấy ai làm vậy vì keep connection alive rất tốn tài nguyên, server còn cần resource để làm việc khác.

   3.2 Bản chất của max pool size là giới hạn tối đa connection, còn idle connection là giữ lại các connection đã connect trước đó mà ko cần connect lại tới DB (handshake cho tốn thời gian)

=> Dùng pool để tiết kiệm resource, và sử dụng lại connection để tăng performance cao hơn. Mời bạn đọc kĩ lại object pool design pattern

Chào bạn. Mình muốn hỏi b một số câu như sau:

• Ví dụ bạn init pool size = 10 và start ứng dụng thì ứng dụng đã tạo connection đến database chưa?
• Benmark b test benmark như kia k fair đối với trường hợp singleton connection và pool? B có thể chỉ ra chỗ k fair ở đâu k?

=> Sau khi b trả lời đc 2 câu trên mình muốn đặt cho b 1 bài toán như sau: Ví dụ ứng dụng của b cần 5 connection đến database là hoạt động ổn định. Mình có 2 trường hợp sau:

1. Khi start app mình khởi tạo luôn 5 connection trực tiếp đến database luôn.
2. Mình dùng pool như bạn cấu hình init = 5

=> B có thể phản biện lí do b dùng pool thay vì khởi tạo trực tiếp 5 connection đến database luôn không? Mục đích chính là để làm gi, giải quyết vấn đề gi?

Cảm ơn bro ♥️

@systemdesign.vn Sau khi nhận được tín hiệu giá thị trường. hệ thống sẽ quét ra toàn bộ lệnh điều kiện thỏa mãn tiêu chi giá và kích hoạt lệnh thật. Việc kích hoạt lệnh thật là xử lí song song và k cần care đến thứ tự. Mọi thứ diễn biến khá nhanh nên latecy giữa các lệnh là k đáng kể.

Còn về redis là bác đang focus vào việc nó bị lỗi. Nhưng về mặt thực tế tỉ lệ chết của nó rất nhỏ hoặc k chết. ví dụ 1 năm bác chết redis 1-2 lần thì nó là tỉ lệ nhỏ và việc trade off tốc độ là rất cần thiết. Việc đo lường nó thì cần monitor, alert, tính toán tốc độ tăng trưởng.

Hay quá bác

Cảm ơn anh đã chia sẻ. Em đã hiểu hơn về CNN rồi ^^.

cách dễ nhất là bạn dùng Gitbash nhé, nó cho ta thao tác với các command và kết quả như Linux

@haha8x được bạn ạ, bạn chỉ cần viết Dockerfile để build image cho code app của bạn thôi.

Còn các thành phần khác như db (mysql), redis, nginx thì dùng sẵn image của người ta nhé, họ đã build rất tối ưu rồi

@Ryuga vậy bạn nợ mình 1 chầu cafe nhé

sao lại ko thể đến được folder đó là sao hả e?

E đang dùng OS gì? win? linux???

Chắc vẫn sẽ mở được chứ. Nếu trên Linux thì e đi từ / xem nhé.

E muốn hỏi có cách nào mà vẫn ở tài khoản máy host để chạy các file ở trong folder docker-non-root ở trên host khi cả folder đó đổi hết quyền sang cho user mytestuser được không a

Nếu e là root thì e chắc chắn đi đến user nào cũng được, từ đó tuỳ vào từng folder của từng user chạy docker compose up sẽ được non-root của user tương ứng (đảm bảo là các files/folders của từng user nằm dưới quyền của user đó)

sorry bạn mình ko để ý comment.

Khi bạn pull mà Docker ko thấy image ở máy bạn thì nó sẽ gọi lên Dockerhub để tìm, như ảnh của bạn thì khả năng nó còn chưa gọi tới Dockerhub .

Bạn bị lỗi ở tên image, tên Docker image ko có khoảng trắng nhé bạn

cái đó khả năng lỗi của Gitlab nhé bạn, bạn thử lại sau 1 thời gian (vài tiếng hoặc 1 ngày) là đc thôi, mình vừa thử chạy lại file yaml như của bạn thì oke

khá dễ hiểu

Hi @Sudhakar , sorry I missed your comment.

It's hard when reading your code, when it's not formatted correctly, it should be in Markdown, better if you can give exact code.

I'm not clear when you mentioned about 3 branches, but from your code I see only development. ButI think the simplest and clear way is to have a tag for each of a branch. Something like this

image: docker:19

services:
  - docker:dind

stages:
  - build

before_script:
  - docker version
  - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

build:
  stage: build
  only:
    refs:
      - develop
      - staging
      - prod
  script:
    # $CI_COMMIT_REF_NAME is branch name
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME .
    - docker push $CI_REGISTRY_IMAGE:CI_COMMIT_REF_NAME

Bài viết rất hay và bổ ích. Cám ơn đã bổ sung kiến thức mình còn thiếu.

bài viết hay và sâu sắc, bình dân dễ hiểu.

@NamNhiNhanh Em đọc bài viết của bác chưa đề cập tới vấn đề thứ tự. Ví dụ, 2 lệnh SL cùng score 24, value sẽ được sắp xếp theo string. Trong bài viết bác chưa đề cập tới ID lệnh đảm bảo thứ tự về mặt thời gian hay random?

Redis backup bất đồng bộ --> có thể bị mất dữ liệu. Với một hệ thống tài chính, bác ko nên trade off giữa tốc độ với tính đúng đắn.

Em đã làm được và thành công. Cảm ơn chủ shop *chụt

Đúng như bác nói để đánh giá hiệu quả của cả hệ thống thì cần dựa vào test (integration test, smoke test, performance test) sau khi implement

Nhưng bài viết tập trung vào bước phân tích thiết kế dựa vào yêu cầu (trước khi implement)