Cập nhập hệ thống cho bibica.net năm 2024

1 số cập nhập cho hệ thống của thèng bibica.net, viết thành 1 bài để có chuyện nói là chính, chứ không có gì để bàn nhiều 😛

Update

1. Đổi sang dùng Oracle location US West
2. Nâng cấp Webinoly v1.17.9 – Nginx v1.26.0 + MariaDB v10.11.7 (MySQL) PHP v7.4.33
3. Nâng cấp WordPress lên v6.5.2
4. Cập nhập tất cả plugins, themes lên phiên bản mới nhất
5. Nâng cấp Artalk lên v2.8.5
6. Nâng cấp Umami lên v2.11.2
7. Tạm ngừng sử dụng Releem
8. Backup sử dụng dịch vụ Cloudflare R2

1. Do mình đang có vài tài khoản Oracle, nên đợt này chuyển hẳn về US West cho tiện quản lý, lý thuyết thì ở Việt Nam, truy cập sẽ chậm hơn so với cụm tại Singapore đó giờ hay dùng, có điều mình nghĩ chắc cũng hiếm ai biết được sự thay đổi nếu không có thông báo này, vì thèng bibica.net gần như cache toàn bộ sang Cloudflare, VPS ở đâu cũng không có sự khác biệt ở phía người dùng

Thực tế vận hành thì mình chỉ cần thêm ~ 20MB RAM cho Artalk là đủ, mà Oracle tài trợ VPS mạnh quá, nên mình cài nhiều thứ râu ria không quá cần thiết vào, khiến RAM chạy bình thường đã ở mức 1.3 GB, xưa chạy tầm 500-700 MB là kịch

Về uptime thì Oracle là bố của các thể loại, mình dùng khoảng 1 năm nay tỷ lệ uptime ở location Singapore là 100%, cụm US West thi thoảng thấy có email bảo trì, nhưng cũng chưa thấy downtime khi nào cả

2. Webinoly mình dùng rất nhiều năm, tổng thể rất tốt, cho tới năm ngoái khi xem lại tính năng backup và restore thì cực kết, nếu bạn không biết thì nó rất tương đồng với chuyện bạn clone server này sang server khác, công đoạn chuyển server rất nhàn, nó hoạt động ở cấp độ server, nên rất nhanh, thực tế mình gần như chẳng phải làm gì, chỉ chạy 1 file bash ghi lại sẵn các thứ là xong

Bạn nào dùng 1 VPS, cài 10-100 trang trên đó thì mới thấy hiệu quả khi backup và restore trên Webinoly, đây là tính năng mà mình rất ít thấy tác giả nào viết (nếu không muốn nói là không ai viết), đa phần ông nào cũng khoe script teo viết tối ưu hiệu năng, chịu tải khỏe, chạy dùng ít tài nguyên …. bla bla bla

Nói ngắn gọn thì siêu hài lòng về Webinoly, nhớ tác giả có nói trong tuần này sẽ lên v1.8, khả năng cao là dùng bản Nginx mới, hỗ trợ http3, mà mình thấy không cần lắm, chạy qua Cloudflare hỗ trợ cả rồi, có lẽ mình sẽ duy trì phiên bản hiện tại rất lâu, vì không thấy có gì cần cập nhập nữa

3-4. Về WordPress, theme, plugins …. thường khi rỗi rãi mình sẽ ngồi xem history, coi bản đó nâng cấp cái gì, cần thì lên, không thì thôi, vì rất dễ gặp lỗi sảng, đợt này tổng nâng cấp nên cho lên mới nhất hết, tạm ngó sơ thì chưa thấy phát sinh lỗi gì

Plugin hiện tại mình muốn gỡ bỏ là Jetpack, lý do là mình chỉ còn dùng duy nhất tính năng Related Posts, cài cả 1 bộ Jetpack vào thì hơi đồ sộ quá, tiếc là vẫn không có cách nào thay thế, đành vẫn phải dùng

5. Về Artalk mình vẫn dùng bản cũ, chạy ổn, và không có ý định nâng cấp, chủ yếu các tính năng mình đề xuất, tác giả vẫn chưa thêm vào, mà quên mất lúc cài lại VPS, mặc định nó sẽ cài bản mới nhất, nên cho lên v2.8.5 luôn

6. Umami mình cũng không có ý định nâng cấp, lý do cũng tương tự Artalk ở trên, cài mới nó tự kéo bản mới nhất về, ngó sơ thì thấy bản mới hiệu ứng có vẻ mượt hơn so với bản cũ, cũng không quan trọng lắm, vì thi thoảng mình vào ngó xem view các bài viết làm sao là chính, thường mình nhìn dựa vào số comment nhận được nhiều hơn, bài viết có view cao mà không có comment tương tác thì cũng không nghĩa lý gì cả

7. Releem sau khi dùng khoảng nửa năm nay, các con số gần như đã tối ưu, phần vì thèng bibica.net, các trang gần như là trang tĩnh, nên hiệu quả từ tối ưu database thường không quá lớn, nên mình giữ nguyên các giá trị, và tạm ngừng monitor, dành cho bạn nào quan tâm thì cấu hình database bên dưới mình đang duy trì

[mysqld]
thread_cache_size = 32
table_open_cache = 2048
sort_buffer_size = 8M
innodb = force
innodb_stats_on_metadata = OFF
innodb_buffer_pool_instances = 8
innodb_log_buffer_size = 10M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 6
join_buffer_size = 8M
max_allowed_packet = 64M
read_rnd_buffer_size = 16M
read_buffer_size = 2M
bulk_insert_buffer_size = 64M
max_connections = 512
myisam_sort_buffer_size = 128M
explicit_defaults_for_timestamp = 1
open_files_limit = 65535
table_definition_cache = 1024
table_open_cache = 2048
log_bin_trust_function_creators = 1
disable_log_bin
innodb_adaptive_flushing_lwm = 25.000000
innodb_autoextend_increment = 48
query_cache_type = 0
query_cache_size = 0
query_cache_limit = 1048576
query_cache_min_res_unit = 4096
max_heap_table_size = 1040187392 ### Previous value : 1040187392
key_buffer_size = 8388608 ### Previous value : 8388608
tmp_table_size = 1073741824 ### Previous value : 1073741824
innodb_buffer_pool_size = 134217728 ### Previous value : 134217728
innodb_log_file_size = 16777216 ### Previous value : 12582912
innodb_max_dirty_pages_pct = 70.000000 ### Previous value : 70.000000
thread_stack = 524288 ### Previous value : 524288
innodb_buffer_pool_chunk_size = 2097152 ### Previous value : 2097152
transaction_prealloc_size = 8192 ### Previous value : 8192

Bạn nào dùng 1 trang blog WordPress cơ bản có thể dùng theo thông số như thế

8. Trước đây mình hay dùng Google Drive và OneDriver để chứa các backup trong 30 ngày, hoạt động rất ổn định, và khoảng 1 tháng nay, không rõ API của Google nó ngáo ngáo sao đó, thi thoảng chuyển file lên thấy văng lỗi, thi thoảng lại chạy bình thường … quá là bực mình để đi xử lý vấn đề này, nên mình chuyển hết về Cloudflare R2 free 10Gb space cho nhẹ đầu

Bài này mình nói cho dài thôi, thực tế chỉ tạo mới VPS từ Oracle -> tạo tài khoản root -> chạy đoạn bash script để nó restore lại, kiểm tra sơ bộ lại 1 tẹo coi các tính năng chạy bình thường chưa là được

Bug Fixes

Sau khi đổi location VPS thì mình gặp 1 tình huống hơi lạ, ở 1 bài viết, tốc độ load ảnh khá chậm, kiểm tra lại thì không rõ vì lý do gì, ảnh tại bài viết đó luôn bị Cloudflare bypass, lạ là vì Cloudflare mặc định cache ảnh, bypass chỉ xuất hiện khi bạn set thêm các rule tùy chỉnh vào thôi, và câu chuyện càng lạ hơn, là nếu nó bypass ảnh, thì sẽ phải bypass tất cả các ảnh theo domain đó, chứ không phải chỉ duy nhất bài viết đó 😀

Khá là củ chuối, giải pháp đơn giản và hiệu quả nhất là set thêm 1 rule riêng cho domain ảnh tại img.bibica.net, cưỡng bức cache luôn cho lành

Lúc này thì các ảnh tại bài viết bị bypass đã cache lại được bình thường

Lỗi khá kì quặc, mình ghi chú lại nếu ai đó tình cờ gặp vấn đề này có thể xử lý tương tự cũng được 😀