Hosting Drupal: Máy Chủ Nào Thực Sự Chạy Tốt

Hosting Drupal là nơi phần lớn tiếng xấu “Drupal chậm” bắt đầu, và gần như lúc nào nó cũng là một quyết định mua sắm chứ không phải vấn đề phần mềm. Website được dựng tử tế, rồi lên sóng trên một gói có giá dành cho trang giới thiệu gồm vài tệp PHP. Kết quả là một hệ quản trị nội dung với luồng dựng trang nghiêm túc phải chạy trong giới hạn bộ nhớ mà nó không đổi được, trên bộ nhớ đệm mã lệnh mà nó không kiểm soát được, và không có shell để chạy công cụ của chính nó.

Phép so sánh mà mọi người ngầm đặt ra là với WordPress, và đó là phép so sánh sai. WordPress chạy tạm ổn trên gần như mọi thứ vì thị phần của nó buộc các nhà cung cấp hosting phải làm cho nó chạy tạm ổn trên gần như mọi thứ. Drupal thì giả định có PHP đời mới, cơ sở dữ liệu đời mới, một backend cache thật, một dòng lệnh, và một quy trình triển khai coi mã nguồn là sản phẩm build chứ không phải thư mục để sửa trực tiếp.

Drupal thực sự cần gì ở một máy chủ? Một phiên bản PHP không thấp hơn mức sàn của bản phát hành bạn dùng, một MySQL, MariaDB hoặc PostgreSQL đời mới, trên thực tế là 256MB bộ nhớ PHP, OPcache, quyền truy cập shell cho Composer và Drush, một mục cron thật, và một bộ nhớ đệm đối tượng bên ngoài khi đã có người dùng đăng nhập. Hosting dùng chung giá rẻ trượt ba đến bốn điều trong số đó cùng lúc.

Drupal thực sự đòi hỏi gì ở một máy chủ

Danh sách yêu cầu chính thức thì ngắn, cụ thể và công khai, vậy mà gần như không ai đọc nó trước khi mua. Nó cũng khác nhau theo phiên bản, và điều đó đang rất quan trọng, vì hai mức sàn sẽ dịch chuyển vào tháng 12 năm 2026.

Mức sàn phiên bản PHP là không thương lượng

Drupal 11 yêu cầu tối thiểu PHP 8.3 và hỗ trợ 8.3, 8.4, 8.5. Drupal 10 yêu cầu 8.1 và hỗ trợ tới 8.4, còn Drupal 12 nâng mức sàn lên PHP 8.5. Những con số này lấy từ tài liệu yêu cầu PHP của chính Drupal, và đó là bản danh sách duy nhất đáng tin.

Điều này nặng hơn vẻ ngoài của nó, vì bản thân các nhánh PHP cũng hết hạn. Trang phiên bản được hỗ trợ của php.net đặt mốc kết thúc hỗ trợ bảo mật của PHP 8.2 vào ngày 31 tháng 12 năm 2026, 8.3 đến 31 tháng 12 năm 2027 và 8.4 đến 31 tháng 12 năm 2028. PHP 8.1 thì đã qua mốc đó. Một nhà cung cấp quảng cáo “có sẵn PHP 8.1 và 8.2” đang bán cho bạn một nền tảng hiện không còn bản vá, hoặc sẽ hết bản vá trong vài tháng nữa.

Hai mốc thời gian va vào nhau. Drupal 10 kết thúc vòng đời vào ngày 9 tháng 12 năm 2026 và theo lịch phát hành lõi, Drupal 12 ra mắt ngay trong tuần đó. Nếu nhà cung cấp không phục vụ được PHP 8.3 trở lên, sau thời điểm ấy bạn không thể chạy một Drupal còn được hỗ trợ. Bài viết về chi phí, lựa chọn và thời hạn khi di chuyển Drupal nói rõ điều đó có nghĩa gì nếu bạn vẫn đang ở bản 10.

Các hệ cơ sở dữ liệu và mức tối thiểu thật của chúng

Theo yêu cầu máy chủ cơ sở dữ liệu, Drupal 11 cần MariaDB 10.6 trở lên, MySQL 8.0 trở lên, PostgreSQL 16 trở lên, hoặc SQLite 3.45 trở lên. Drupal 10 dễ tính hơn nhiều với MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 và SQLite 3.26, và đó chính là lý do một lần nâng cấp đôi khi kéo theo cả một lần nâng cấp cơ sở dữ liệu mà khách hàng không hề lường trước.

Hai chi tiết hay bị bỏ qua. Trên MySQL và MariaDB, storage engine bắt buộc phải là InnoDB, vì Drupal dựa vào giao dịch và khóa ở mức dòng. Trên PostgreSQL, tiện ích mở rộng pg_trgm phải được tạo trên cơ sở dữ liệu của Drupal trước khi cài đặt, và một dịch vụ cơ sở dữ liệu quản trị sẵn không cho bạn chạy CREATE EXTENSION là không dùng được.

SQLite thật sự được hỗ trợ và rất ổn cho môi trường phát triển cục bộ, nhưng nó không phải câu trả lời cho môi trường sản xuất một khi nhiều biên tập viên cùng lưu nội dung, vì mức trần chạm phải đầu tiên là khả năng ghi đồng thời.

Bộ nhớ, tiện ích mở rộng và máy chủ web

Mức tối thiểu ghi trong tài liệu là 64MB bộ nhớ PHP, và dưới mức đó Drupal sẽ cảnh báo. Cũng trang đó ghi rằng 128MB hoặc 256MB là mức thường thấy trên môi trường sản xuất, còn các cài đặt nhiều media thì cần hơn. Trên thực tế hãy coi 256MB là con số làm việc và chuẩn bị nâng thêm cho dòng lệnh, vì thứ ngốn bộ nhớ là Composer và các lần di chuyển dữ liệu lớn, chứ không phải việc phục vụ trang.

Danh sách tiện ích mở rộng không có gì lạ nhưng vẫn đáng kiểm tra: PDO kèm driver cơ sở dữ liệu, XML, JSON, mbstring, cURL, OpenSSL cho HTTPS đi ra, và GD hoặc ImageMagick để tạo ảnh dẫn xuất. Drupal 12 thêm Argon2 cho việc băm mật khẩu, tức là thêm một thứ nữa mà một bản dựng PHP quá cũ sẽ không có.

Về máy chủ web, Drupal hỗ trợ Apache 2.4.7 trở lên và Nginx 1.1 trở lên, đồng thời không hỗ trợ Microsoft IIS kể từ Drupal 11.0.0. Apache cần mod_rewrite cho URL sạch và AllowOverride All để tệp .htaccess đi kèm có hiệu lực. Điểm cuối này hay gài bẫy người ta: một phần quy tắc bảo vệ của Drupal chỉ tồn tại trong .htaccess, nên khi triển khai bằng Nginx bạn phải chép lại chúng thủ công vào cấu hình máy chủ. Đó là một bước quen thuộc nhưng cũng thường bị bỏ qua, và là một trong những thứ đầu tiên chúng tôi soi khi làm kiểm định an ninh máy chủ.

Vì sao hosting dùng chung không kham nổi Drupal

Hosting dùng chung không phải hosting tệ. Nó được tối ưu cho một dạng ứng dụng khác, và Drupal vỡ trước những ràng buộc đó ở bốn chỗ hoàn toàn đoán được.

Không có shell thì không có Composer và Drush

Drupal hiện đại là một dự án Composer. Lõi, các module cộng đồng và toàn bộ phụ thuộc PHP của chúng đều do Composer giải quyết, và một khi Composer đã quản lý một module thì nó phải quản lý cả lõi. Trộn Composer với việc sửa tệp thủ công chính là con đường dẫn tới một website không còn cập nhật được nữa.

Một bảng điều khiển kèm trình quản lý tệp không làm được việc đó. Một trình FTP cũng vậy. Không có SSH thì bạn mất luôn Drush, trong khi việc dựng lại cache, nhập cấu hình, chạy cập nhật cơ sở dữ liệu và đặt lại mật khẩu người dùng đều được thực hiện bằng Drush. Một website mà bạn không chạy được drush cr là website mà mọi bước khắc phục đều biến thành một phiếu hỗ trợ.

Những giới hạn bạn không thấy, càng không đổi được

Tài khoản dùng chung cho bạn một memory_limit do người khác đặt, thường là 128MB và đôi khi thấp hơn, không có cách nào nâng lên cho đúng một lần di chuyển cần tới 512MB.

OPcache mới là vấn đề lớn hơn. Nó lưu bytecode đã biên dịch sẵn trong bộ nhớ chia sẻ để PHP khỏi phân tích lại tệp ở mỗi yêu cầu, và trên máy chủ dùng chung, vùng bộ nhớ đó được chia cho hàng trăm tài khoản. Drupal có hàng nghìn tệp PHP, nên nó là một người thuê nặng ký trong cái vùng đang bị tranh giành ấy, và nó bị đẩy ra. Triệu chứng là một website nhanh trong một phút sau khi có người ghé thăm rồi chậm trở lại sau một giờ.

Rồi tới những thứ hoàn toàn vắng mặt: không Redis, không Memcached, không quyền điều chỉnh trình quản lý tiến trình PHP, và không cách nào chạy một tiến trình xử lý hàng đợi lâu dài.

Cron không bao giờ thực sự chạy

Module Automated Cron của Drupal mặc định chạy ba giờ một lần và được kích hoạt bởi chính người dùng ghé thăm website. Trên một website đông khách, điều đó nghĩa là thỉnh thoảng có một khách phải trả giá cho việc lập chỉ mục tìm kiếm bằng thời gian tải trang của mình. Trên một website vắng, nó nghĩa là cron gần như không chạy, nên chỉ mục tìm kiếm cũ đi, bảng nhật ký không bao giờ được dọn và các bản vá bảo mật sẵn có không bao giờ được kiểm tra.

Tài liệu khuyến nghị kích hoạt cron từ bên ngoài, vì cách đó luôn chạy đúng lịch và tốn ít tài nguyên hơn. Việc đó cần một mục crontab thật, thứ mà hạng rẻ nhất không có.

Các lớp cache và lớp nào khách của bạn thực sự chạm tới

Drupal có nhiều lớp cache hơn phần lớn mọi người hình dung, và các lớp đó không thay thế nhau. Chúng xếp chồng lên nhau, mỗi lớp đỡ lấy phần mà lớp phía trên không giữ được.

OPcache nằm hoàn toàn bên dưới Drupal

OPcache không phải tính năng của Drupal. Nó lưu bytecode PHP đã biên dịch ở tầng trình thông dịch, nên nó có tác dụng với mọi yêu cầu, bất kể lớp cache nào của Drupal có trúng hay không. Sai ở đây thì không thứ gì bên trên bù lại được, vì mọi yêu cầu đều phải trả giá biên dịch lại framework trước khi tới được router. Hãy cấp bộ nhớ chia sẻ dư dả và tắt kiểm tra dấu thời gian trên môi trường sản xuất, nơi tập tệp chỉ thay đổi khi triển khai.

Internal Page Cache và Dynamic Page Cache

Internal Page Cache là một module lõi, bật sẵn, và chỉ phục vụ khách ẩn danh. Nó giả định mọi khách ẩn danh đều thấy cùng một trang, lưu toàn bộ phản hồi ở lần yêu cầu đầu tiên rồi dùng lại. Với một website marketing không cá nhân hóa, đây là lớp làm gần như toàn bộ công việc.

Dynamic Page Cache cũng thuộc lõi và cũng bật sẵn, nhưng nó cache cho tất cả mọi người, kể cả người dùng đã đăng nhập. Cách làm là để hệ thống dựng trang biến những phần thực sự riêng tư thành placeholder rồi cache mọi thứ xung quanh chúng. Đó là lý do một trang Drupal ở trạng thái đăng nhập vẫn có thể được cache phần lớn: chỉ menu người dùng và vài block là thực sự động.

BigPipe và render cache

Bên dưới cả hai là render cache, nơi lưu từng block, từng trường, kết quả của Views và kết quả dựng thực thể. Một trang trượt page cache thường vẫn được ghép lại chủ yếu từ các lần trúng render cache chứ không phải dựng lại từ cơ sở dữ liệu.

Phần còn lại do BigPipe lo. Nó có trong lõi từ Drupal 8.1, ổn định từ 8.3 và nằm trong hồ sơ cài đặt chuẩn từ 8.5. Thay vì chờ mọi placeholder được giải quyết, nó đẩy ngay phần trang có thể cache rồi truyền các mảnh cá nhân hóa tới sau. Nó không cần cấu hình, và nó giúp người dùng đã đăng nhập nhiều hơn hẳn so với khách ẩn danh.

Vậy nên trên một website được cấu hình tốt, khách ẩn danh chạm vào Internal Page Cache, hoặc CDN đứng trước nó, và gần như không đụng tới phần còn lại. Biên tập viên đang đăng nhập thì chạm vào Dynamic Page Cache, render cache và BigPipe ở mọi yêu cầu, và đó là lý do lưu lượng đã đăng nhập tốn kém hơn nhiều.

Bộ nhớ đệm đối tượng bên ngoài

Mọi lớp phía trên đều cần một chỗ để lưu các mục của mình. Mặc định chỗ đó là cơ sở dữ liệu, trong các bảng cache, nghĩa là việc đọc cache tranh tài nguyên với truy vấn nội dung trên cùng một máy chủ.

Module Redis chuyển các backend cache, lock, flood và hàng đợi sang Redis hoặc một kho tương thích như Valkey, dùng tiện ích PhpRedis, tiện ích Relay hoặc thư viện thuần PHP là Predis. Memcached là lựa chọn tương đương. Với một website ẩn danh nhỏ, điều này thay đổi rất ít. Với một website có người dùng đăng nhập, đây thường là cải thiện lớn nhất còn sẵn có, vì nó lấy tải ghi ồn ào nhất ra khỏi cơ sở dữ liệu và làm cho việc khóa trở nên rẻ.

Proxy ngược và CDN đứng trước Drupal

Một proxy ngược như Varnish hay Nginx, hoặc một CDN, trả lời yêu cầu trước khi PHP kịp tham gia. Với lưu lượng ẩn danh, đây là khác biệt giữa việc trả trang trong vài mili giây và trả trang trong vài trăm mili giây. Đây cũng là lớp mà người ta sợ nhất, vì một bản cache cũ trên trang tin hay cửa hàng là một thất bại ai cũng nhìn thấy.

Thẻ cache là thứ làm CDN trở nên an toàn

Câu trả lời của Drupal là thẻ cache. Thẻ cache mô tả các phụ thuộc dữ liệu, viết dưới dạng chuỗi như node:5, user:3 hay node_list. Mỗi mục được cache đều ghi lại nó phụ thuộc vào những thẻ nào, nên khi bạn sửa node 5 thì mọi mảnh, mọi trang và mọi view từng tham chiếu tới nó đều bị vô hiệu hóa, dù chúng xuất hiện ở đâu.

Điều quan trọng là Drupal có thể công bố các thẻ đó ra bên ngoài. Các module cộng đồng phát chúng dưới dạng header Surrogate-Key cho Fastly hoặc header Cache-Tag cho Cloudflare, và CDN sẽ xóa theo thẻ khi Drupal ra hiệu. Điều đó biến CDN từ một canh bạc theo thời gian thành một bộ nhớ đệm hướng sự kiện: bạn có thể đặt thời gian sống rất dài, vì một lần sửa sẽ xóa đúng những URL bị ảnh hưởng trong vài giây.

Hãy để ý ngân sách header. Tài liệu xóa cache theo thẻ của Cloudflare giới hạn tổng header Cache-Tag ở mức 16KB sau tên trường, tức khoảng 1.000 thẻ duy nhất, tối đa 1.024 ký tự cho mỗi thẻ trong một lệnh gọi API và 100 thẻ cho mỗi lần xóa từ bảng điều khiển. Một view Drupal liệt kê nhiều thực thể có thể sinh ra nhiều thẻ hơn thế rất nhiều, nên một trang liệt kê tất cả sẽ âm thầm làm tràn header nếu module không được cấu hình để cắt bớt hoặc băm chúng.

Chọn hosting Drupal: bốn hạng, nói thẳng

Có bốn lựa chọn thật sự, và hạng đúng được quyết định bởi việc bạn có lưu lượng đã đăng nhập hay không, và có ai vận hành máy chủ hay không. Các khoảng dưới đây là mức khách hàng ở Anh thường trả theo kinh nghiệm của chúng tôi, chưa gồm VAT, mang tính tham khảo chứ không phải báo giá của nhà cung cấp nào.

Hosting dùng chung

Không hợp với bất kỳ ai chạy Drupal trong môi trường sản xuất. Nó trượt cùng lúc ở quyền truy cập shell, bộ nhớ, cache mã lệnh, cache đối tượng và cron. Nếu ngân sách thật sự chỉ tới đây, một máy ảo tự quản nhỏ với giá tương đương là cách tiêu tiền tốt hơn.

VPS hoặc máy ảo cloud tự quản

Khoảng GBP 20 đến GBP 120 mỗi tháng mua được một máy có toàn quyền root, và mức này hợp với đại đa số website Drupal. Bạn chọn phiên bản PHP, cấp phát OPcache, cài Redis, đặt crontab và cấu hình Nginx cho đúng. Thứ bạn không có là người làm những việc đó, vá lỗi, giám sát hay khôi phục lúc hai giờ sáng. Hạng này đúng khi bạn đã có lập trình viên hoặc một agency theo hợp đồng, và chi phí thật nằm ở hợp đồng chứ không ở máy ảo.

Nền tảng chuyên biệt quản trị sẵn cho Drupal

Hosting Drupal quản trị sẵn bắt đầu quanh mức GBP 40 mỗi tháng cho một website nhỏ và tăng nhanh theo lưu lượng, số môi trường và mức hỗ trợ. Thứ bạn mua là một nền tảng đã đúng sẵn, cộng với triển khai dựa trên Git, môi trường staging, sao lưu và một người hiểu Drupal nhấc máy. Nó đáng tiền khi lựa chọn còn lại là không có ai, và không đáng tiền khi bạn trả giá nền tảng cho một trang giới thiệu có 4.000 lượt truy cập mỗi tháng.

Hạ tầng tùy chỉnh đầy đủ

Cơ sở dữ liệu tách riêng, các node cache chuyên dụng, máy chủ ứng dụng sau một bộ cân bằng tải, lưu trữ đối tượng cho tệp. Cấu hình này bắt đầu hợp lý từ khoảng GBP 400 mỗi tháng trở lên, và chỉ khi lưu lượng đã đăng nhập, các tích hợp hoặc yêu cầu tuân thủ làm cho các hạng quản trị sẵn trở nên gò bó. Đây là hạng mạnh nhất và cũng đòi hỏi nhất, vì giờ bạn tự lo vá lỗi, giám sát và khôi phục sau thảm họa. Bài hướng dẫn phát triển web với Drupal nói về nguồn gốc của độ phức tạp đó ở phía ứng dụng.

Triển khai: bạn không sửa tệp trên máy chủ

Vì Composer giải quyết toàn bộ cây phụ thuộc, mã nguồn trên máy chủ là đầu ra chứ không phải nơi làm việc. Sửa tại chỗ một tệp module nghĩa là lần composer update kế tiếp sẽ ghi đè lên nó, và nghĩa là mã chạy thật của bạn không còn khớp với bất cứ thứ gì trong Git.

Một quy trình phát hành tỉnh táo sẽ dựng sản phẩm ở nơi khác. Hãy chạy composer install từ tệp composer.lock đã commit trong CI, để bản dựng có thể tái lập và máy chủ chạy thật không cần Composer, không cần bộ nhớ PHP để giải phụ thuộc, cũng không cần quyền ghi vào vendor. Chuyển kết quả lên, chạy cập nhật cơ sở dữ liệu, nhập cấu hình, dựng lại cache. Quay lui chỉ là trỏ về sản phẩm của lần trước.

Điều đó cũng lặng lẽ trả lời câu hỏi về hosting. Một nhà cung cấp mong bạn sửa tệp qua FTP là không tương thích với cách Drupal được bảo trì, bất kể bảng thông số của họ ghi gì.

Đồng bộ cấu hình nằm ở đâu

Drupal giữ cấu hình đang hoạt động trong cơ sở dữ liệu và xuất nó ra các tệp YAML, đó là cách các kiểu nội dung, trường, view và thiết lập di chuyển giữa các môi trường. Tài liệu quản lý cấu hình giải thích rằng UUID của site phải trùng nhau giữa nguồn và đích, và đó là lý do thường gặp khiến lần nhập đầu tiên thất bại.

Trên thực tế, điều này có nghĩa cấu hình chính là mã. Nó được commit, được review và được triển khai cùng phần còn lại, còn bước nhập chạy như một phần của lần phát hành thay vì được bấm tay trong giao diện quản trị sau đó. Hosting phải hỗ trợ được điều đó: bạn cần một nơi để chạy lệnh nhập, và một môi trường nơi một lần nhập lỗi có thể được quay lui thay vì nằm nửa vời trên bản chạy thật.

Tệp, media và sao lưu

Drupal có hai hệ tệp và khác biệt giữa chúng là thứ chịu lực. Hệ công khai nằm dưới thư mục gốc web và được máy chủ web phục vụ trực tiếp. Hệ riêng tư nằm ngoài thư mục gốc web, và mọi yêu cầu tới một tệp riêng tư đều đi qua Drupal để quyền truy cập được kiểm tra.

Vì thế tệp riêng tư đắt hơn tệp công khai rất nhiều, vì mỗi lượt tải về đều khởi động PHP. Một website phục vụ các tài liệu riêng tư dung lượng lớn cần khoảng dự phòng mà một máy chủ tệp tĩnh không cần tới.

Chuyển media sang lưu trữ đối tượng

Một khi tệp nằm trên máy chủ ứng dụng, việc mở rộng theo chiều ngang và dựng lại đều trở nên khổ sở, và mỗi bản sao lưu đều phải cõng theo toàn bộ thư viện media. Chuyển hệ tệp công khai sang lưu trữ đối tượng tương thích S3 sẽ tách hai thứ đó ra, cho phép CDN phục vụ media trực tiếp, và biến máy chủ ứng dụng thành thứ thực sự có thể vứt đi.

Diễn tập khôi phục chứng minh điều sao lưu không chứng minh được

Một bản sao lưu chứng minh rằng tệp tồn tại. Một lần diễn tập khôi phục chứng minh rằng tệp đó đầy đủ, rằng cơ sở dữ liệu và các tệp thuộc cùng một thời điểm, rằng thông tin đăng nhập của bạn vẫn dùng được, và rằng bạn biết việc đó mất bao lâu. Đó là bốn kiểu hỏng khác nhau và không kiểu nào lộ ra từ một dấu tích xanh trong bảng điều khiển.

Hãy thử với đồng hồ bấm giờ thật ít nhất hai lần mỗi năm và ghi lại con số. Nếu khôi phục mất sáu tiếng mà ngưỡng chịu đựng của bạn là một tiếng thì vấn đề nằm ở kiến trúc, không nằm ở bản sao lưu. Thời gian khôi phục là một yêu cầu về hosting, và nó thuộc về bản đặc tả chứ không phải về lúc đang xử lý sự cố.

Tính đúng quy mô cho một máy chủ Drupal

Lượt xem trang là đơn vị sai. Một website có 200.000 lượt xem ẩn danh mỗi tháng nằm sau một CDN có thể thoải mái trên một máy nhỏ, trong khi một website có 8.000 lượt xem lại có thể chật vật nếu phần lớn trong số đó là người đã đăng nhập.

Lưu lượng đã đăng nhập mới là yếu tố quyết định

Yêu cầu ẩn danh có thể được page cache hoặc CDN trả lời mà không chạm tới PHP. Yêu cầu đã đăng nhập thì không. Mỗi yêu cầu như vậy đều chạy luồng dựng trang, kiểm tra quyền trên từng thực thể, giải các placeholder và ghi dữ liệu phiên. Câu hỏi thực tế không phải bạn có bao nhiêu lượt truy cập, mà là bạn có bao nhiêu người dùng đăng nhập cùng lúc và những người đó được phép nhìn thấy gì.

Biên tập viên là trường hợp cực đoan. Màn hình quản trị nội dung nằm trong nhóm trang nặng nhất của Drupal và theo định nghĩa là không thể cache, nên một website có mười hai biên tập viên làm việc cùng lúc có một yêu cầu đồng thời thật sự mà lưu lượng công khai của nó không hề gợi ý.

Views, taxonomy và công việc hàng đợi

Ngoài lưu lượng đã đăng nhập, các nguồn tốn kém đáng tin cậy là những view lớn với nhiều bộ lọc và quan hệ, vốn sinh ra các phép join đắt đỏ; các cây taxonomy sâu, nơi phân cấp thuật ngữ bị duyệt lại ở mỗi lần dựng; và công việc cron hay hàng đợi như lập chỉ mục tìm kiếm, nhập feed và tạo ảnh dẫn xuất.

Nếu tránh được, các tiến trình xử lý hàng đợi không nên chia sẻ tài nguyên máy chủ web với khách truy cập. Trên một website lớn, chúng thuộc về một tiến trình hoặc một máy riêng, để hàng nhập bị dồn không làm chậm giao diện. Đó là một quyết định kiến trúc được đưa ra ngay lúc mua, và cũng là điểm mà các hạng quản trị sẵn thôi vừa vặn còn hạ tầng tùy chỉnh bắt đầu hợp lý.

Ra quyết định cho đúng

Khuôn mẫu lặp lại rất đều. Hosting không nhỏ quá, nó sai hình dạng: không có shell, không có cache đối tượng, một cache mã lệnh do người khác kiểm soát, và một phiên bản PHP sắp rơi khỏi diện hỗ trợ. Chuyển đúng website đó sang một máy được đặc tả đúng với giá tương đương thường thắng mọi nỗ lực tối ưu phía giao diện.

Mecanik đặc tả, xây dựng và bảo trì hạ tầng Drupal như một phần công việc phát triển website, và soi lại các nền tảng sẵn có qua một kiểm định an ninh máy chủ khi mối lo là mức độ phơi nhiễm chứ không phải tốc độ. Nếu bạn cần con người thay vì một nền tảng, bài viết về thuê lập trình viên Drupal nói rõ cần nhìn vào những gì.

Câu hỏi thường gặp

Yêu cầu máy chủ tối thiểu cho Drupal 11 là gì? PHP 8.3 trở lên, và cơ sở dữ liệu là MariaDB 10.6, MySQL 8.0, PostgreSQL 16 hoặc SQLite 3.45. Về phía máy chủ web là Apache 2.4.7 hoặc Nginx 1.1 trở lên, còn Microsoft IIS không được hỗ trợ kể từ Drupal 11.0.0. Drupal cảnh báo khi bộ nhớ PHP dưới 64MB, nhưng 256MB mới là con số thực tế cho môi trường sản xuất.

Drupal có chạy được trên hosting dùng chung không? Nó cài được và vẫn trả về trang, nhưng hosting dùng chung thường trượt ba đến bốn yêu cầu cùng lúc: không có shell cho Composer hay Drush, một giới hạn bộ nhớ PHP bạn không nâng được, không có Redis hay Memcached, và cron chỉ chạy khi tình cờ có khách mở một trang. Chính những điều kiện đó tạo ra tiếng xấu rằng Drupal chậm.

Hosting Drupal nên tốn bao nhiêu tiền? Một website Drupal nhỏ trên một máy tự quản được cấu hình đúng thường nằm trong khoảng GBP 20 đến GBP 120 mỗi tháng trước khi có người quản trị hộ. Các nền tảng Drupal quản trị sẵn thường bắt đầu gần mức GBP 40 và tăng lên hàng trăm bảng theo lưu lượng và số môi trường. Hạ tầng tùy chỉnh bắt đầu hợp lý từ khoảng GBP 400 trở lên. Hạng rẻ nhất hiếm khi là kết quả rẻ nhất.

Drupal có cần Redis không? Không cần với một website ẩn danh nhỏ, nơi Internal Page Cache và cơ sở dữ liệu là đủ. Một khi bạn có người dùng đăng nhập, biên tập viên hoặc khu vực thành viên, một bộ nhớ đệm đối tượng bên ngoài như Redis hay Memcached sẽ đưa việc đọc cache, khóa và hàng đợi ra khỏi cơ sở dữ liệu, và xét trên số tiền bỏ ra thì đó thường là cải thiện lớn nhất có thể mua được.

Đặt CDN trước một website Drupal động có an toàn không? Có, miễn là bạn vô hiệu hóa theo thẻ cache chứ không theo thời gian. Drupal ghi lại các thẻ như node:5 cho mọi thứ mà một phản hồi phụ thuộc vào, và các module dịch chúng thành header Cache-Tag hoặc Surrogate-Key để CDN xóa đúng những trang mà một lần sửa ảnh hưởng tới. Không có vô hiệu hóa theo thẻ, bạn phải chọn giữa trang cũ và một bộ nhớ đệm không bao giờ giúp được gì.