Thời gian qua mình đã viết một số bài căn bản về phần mềm server OpenLiteSpeed. Tất cả chỗ đó mới chỉ là phần đầu tiên của quá trình mình di dời từ dịch vụ hosting miễn phí sang server riêng mà thôi.

Nhưng sau khi trải qua được phần đầu tiên ấy, mọi chuyện trở nên rất đơn giản với mình: Cài đặt MariaDB, di chuyển WordPress cùng với database (cơ sở dữ liệu), thiết lập lại các plugin cache và bảo vệ cho WordPress. Thế là xong, các bạn đã và đang chứng kiến blog Noisy Stream này được phục vụ bởi OpenLiteSpeed.

Gần đây mình bổ sung thêm hai thứ: Một là Redis làm cache cho database, hai là CDN làm chuyển bớt việc phục vụ nội dung từ server ra ngoài. Và mình cũng đã sử dụng công cụ MySQLTuner với khả năng đưa ra các gợi ý tinh chỉnh MySQL/MariaDB.

Toàn bộ các việc trên là một thử nghiệm rất hay trong quá trình cài đặt một web server chạy nhanh.

Ở bài viết này, mình sẽ giới thiệu một cách khái quát về quá trình cài đặt một web server như vậy. Mình chia ra làm mấy phần chính:

1. Xác định cấu hình server
2. Xác định mã nguồn cần sử dụng
3. Lựa chọn phần mềm tối ưu cho phục vụ nội dung
4. Lựa chọn phần mềm làm bộ đệm (cache)
5. Giám sát và tinh chỉnh

Nào, chúng ta cùng đi vào chi tiết cụ thể.

---

1. Xác định cấu hình server

Server là một cái máy tính có vai trò phục vụ (serve) dịch vụ. Vì nó thực hiện phục vụ nên nó phải quản lý hoạt động phục vụ đó. Chúng ta chạy một website trên một server riêng, có nghĩa là chúng ta sử dụng một máy tính riêng để phục vụ website đó.

Ban đầu, lúc mới tạo dựng một website, hầu hết mọi người đều dựa theo cảm tính hoặc số liệu thị trường mà dự đoán lượng người quan tâm đến website hằng ngày hoặc hằng tháng. Nhưng ở một server riêng, con số đó không có nhiều ý nghĩa. Vậy chúng ta sẽ quan tâm đến lượng người online cùng lúc tại các website chạy trên cùng một server hay sao?

Gần đúng.

Cụ thể, chúng ta quan tâm đến số người (chính xác là số client/máy khách) tương tác cùng lúc với server. Ít khi con số này lớn bằng số người online như ở trên. Nếu các bạn đã chạy website một thời gian, các bạn có thể biết được con số tương tác đó qua một công cụ theo dõi và thống kê (như Google Analytics chẳng hạn). Nhưng đối với một website mới, chẳng có cách nào hỗ trợ dự đoán được con số đó. Khi ấy, có thể lấy một con số khoảng 50 client cùng tương tác với server.

Ngoài ra, chúng ta căn cứ vào nội dung chính mà server cần phục vụ.

• Nếu hầu hết là nội dung hiếm khi thay đổi (“nội dung tĩnh”), thì server không cần tốn nhiều sức để phục vụ. Nhưng khi các bạn bổ sung thêm một chức năng tìm kiếm nội dung và chính website sẽ thực hiện việc này (không nhờ đến dịch vụ tìm kiếm bên ngoài), thì nên dôi ra một phần CPU và RAM ít hay nhiều tuỳ vào tần suất tìm kiếm.
• Nếu có sẵn một lượng lớn nội dung, hoặc có một phần đáng kể nội dung thường xuyên thay đổi (“nội dung động”) ở nhiều đường link khác nhau, thì server phải dành một phần đáng kể CPU và RAM cho việc lấy dữ liệu và sinh (generate) trang. Điển hình là wiki (encyclopedia – bách khoa toàn thư), trang tổng hợp thông tin về sản phẩm, diễn dàn (forum), trang thương mại điện tử hoặc mạng xã hội.

Nếu số client tương tác thấp và server chủ yếu phục vụ nội dung tĩnh, thì một server nhỏ với CPU một nhân và 512MB RAM sẽ đủ để đáp ứng. Sau một thời gian vận hành, dù chúng ta đã tối ưu phần mềm trên server và cả mã nguồn, mà vẫn gặp tình trạng “kẹt” tài nguyên, thì chúng ta mới cần nâng cấp cấu hình lên, hoặc di chuyển sang một server có cấu hình cao hơn. Điều này có thể thực hiện dễ dàng tại nhiều nhà cung cấp server.

Còn vấn đề về ổ đĩa nữa. Hiện tại, giá thành ổ đĩa SSD (solid state drive – ổ thể rắn) tuy vẫn còn cao, nhưng đang có chiều hướng giảm xuống. SSD lại nhanh hơn ổ đĩa cứng (hard disk drive – HDD). Đã có nhiều nhà cung cấp server đưa ra các cấu hình giá rẻ sử dụng ổ đĩa SSD, mọi người nên tận dụng ngay các cấu hình đó. Dung lượng ổ đĩa cần chọn phụ thuộc vào nhu cầu chứa dữ liệu lớn đến đâu. Dữ liệu sẽ được lưu trên ổ đĩa của server bao gồm dữ liệu sẵn có (nội dung tĩnh, mã nguồn, database) và cache. Ngoài ra, công nghệ RAID kết nối các ổ đĩa là một điểm cộng về độ an toàn và tốc độ.

---

2. Xác định mã nguồn cần sử dụng

Hiện nay có ba hướng chính chọn mã nguồn.

2.1. Tĩnh hoàn toàn

Tĩnh hoàn toàn trên server. Nội dung website bắt đầu được phục vụ từ các file HTML. Việc thay đổi linh hoạt nội dung được thực hiện bởi các đoạn mã JavaScript được nhúng hoặc liên kết từ file HTML. Ví dụ, có một trang HTML chỉ thay đổi giá trị bộ đếm số lượt xem, ngay đến cả việc đếm lượt xem cũng được thực hiện bởi dịch vụ bên ngoài.

Đây là hướng tiếp cận đầu tiên, xuất hiện từ rất lâu rồi. Tuy nhiên, trong vài năm trở lại đây, hướng này đang phổ biến trở lại. Vì sao?

• Nhu cầu ngày càng lớn của các quản trị viên (administrator) về tốc độ, an toàn thông tin và đặc biệt là tính dễ dùng. Các trang web lớn đang phục vụ cho khách truy cập từ nhiều vùng lãnh thổ lớn và quốc gia khác nhau.
• Các dịch vụ điện toán đám mây cung cấp các dịch vụ nhỏ (microservice) chuyên biệt cho từng thành phần và nhiệm vụ cụ thể. Hiện tại có ba dịch vụ lớn là Google Cloud Platform, Amazon Web Services, Microsoft Azure. Các dịch vụ này cung cấp microservice chuyên dùng cho lưu trữ và phục vụ nội dung tĩnh rất ổn định.

Có nhiều cách phổ biến tạo trang HTML:

• Tự viết thủ công. Cách này dành cho những người am hiểu về lập trình.
• Sử dụng chương trình chuyên thiết kế trang web trên máy tính: Adobe Dreamweaver, Adobe Muse…
• Sử dụng “trình tạo trang web” (site builder): RVsitebuilder, SitePad…
• Sử dụng “trình sinh trang tĩnh” (static site generator): Jekyll, Hugo, MkDocs, Octopress…
• Sử dụng chức năng tạo trang tĩnh trong các hệ quản trị nội dung (content management system – CMS).

Server được phục vụ loại nội dung tĩnh, chẳng cần có database (hay dữ liệu được tổ chức tương tự) dành cho việc sinh trang HTML một cách tự động và phục vụ trang đó cho client. Tuy nhiên khi các bạn chọn hướng này, nếu sử dụng một server riêng để phục vụ thì hơi bị phí, do đã có microservice riêng cho nội dung tĩnh rồi.

2.2. Tự phát triển mã nguồn phục vụ nội dung động

Đối với hướng này, các bạn sử dụng một số ngôn ngữ lập trình để viết mã nguồn sinh ra trang HTML cuối cùng. Server sẽ chạy trực tiếp bộ dịch cho các ngôn ngữ đó. Hiện tại, ngôn ngữ PHP (PHP: Hypertext Preprocessor) được sử dụng rất rộng rãi. Trong thời gian gần đây, sự xuất hiện và phổ biến dần dần của một phần mềm server tên là Node.js đã giúp cho ngôn ngữ JavaScript có thể được dịch trên server chứ không chỉ tại trình duyệt phía client. Đối với server sử dụng hệ điều hành Windows, hiện tại có ASP.NET được khuyên dùng và được Microsoft hỗ trợ khá kịp thời.

Để góp phần làm cho server chạy nhanh hơn, thì mã nguồn cũng phải hoạt động nhanh chóng. Vì thế, việc tối ưu mã nguồn rất quan trọng. Công việc đó gồm mấy việc nhỏ sau:

• Giảm số thao tác được thực hiện bởi một đoạn mã.
• Ưu tiên sử dụng các hàm và cú pháp cần thời gian xử lý ngắn hơn và tốn ít tài nguyên hơn.

2.3. Sử dụng hệ quản trị nội dung (CMS) có sẵn

Hiện tại có hằng hà sa số các CMS cho mọi người lựa chọn.

WordPress là CMS phổ biến nhất và được hỗ trợ bởi một cộng đồng cực kì đông đảo. CMS này được sử dụng để tạo blog, trang giới thiệu sản phẩm/dịch vụ và các trang tin tức là chủ yếu. Thông qua plugin mở rộng thì các bạn còn có thể tạo diễn đàn và trang bán hàng nữa.

Ngoài WordPress, có một số CMS phổ biến khác như Joomla, Drupal, Moodle, Magento, Opencart, PrestaShop…

Hầu hết các CMS đều hoạt động trên nền ngôn ngữ PHP, và sử dụng cơ sở dữ liệu MySQL để lưu nội dung trang web cùng với các thiết lập. Một số CMS khác sử dụng ngôn ngữ và cơ sở dữ liệu khác. Cá biệt, có một số CMS như Grav hay HTMLy chẳng hạn, sử dụng trực tiếp các file văn bản để lưu nội dung trang web cùng với điều chỉnh.

---

3. Lựa chọn phần mềm tối ưu cho phục vụ nội dung

Các bạn đã chọn được server và mã nguồn các bạn muốn sử dụng để triển khai website. Các bạn đã biết mã nguồn được chọn sử dụng ngôn ngữ nào và hệ quản trị cơ sở dữ liệu nào. Giờ chúng ta đi vào lựa chọn cài đặt bộ dịch, hệ quản trị cơ sở dữ liệu cùng với một số phần mềm khác để thực hiện việc phục vụ nội dung ra bên ngoài.

Phần này giới thiệu một số chương trình phần mềm được sử dụng nhiều, và các chương trình tối ưu hơn có thể thay thế.

3.1. Web server

Hả? Giờ chúng ta lại gặp khái niệm web server đối với phần mềm nữa sao? Mình không hiểu tại sao người ta đã dùng từ đó để chỉ máy tính thực hiện phục vụ nội dung web, giờ lại dùng từ đó để chỉ một số chương trình trên server trực tiếp thực hiện việc đó.

3.1.1. Apache và hạn chế của nó

Apache ra đời vào năm 1995. Đó là một trong những web server lâu đời nhất, và nó đang được sử dụng phổ biến nhất.

Nó có sẵn nhiều module, và có nhiều module khác được phát triển cho nó. Nó cũng cung cấp nhiều điều chỉnh linh hoạt. Đặc biệt, file .htaccess chính là một file thiết lập của Apache tại cấp độ thư mục, với ưu điểm nổi bật là được áp dụng ngay sau khi chỉnh sửa. Vì thế, nó được sử dụng bởi đại đa số các dịch vụ hosting chia sẻ. Một số mã nguồn còn phụ thuộc lớn vào .htaccess, thể hiện qua hai việc: Một là kèm sẵn file .htaccess, hai là sản sinh và thay đổi file .htaccess trong quá trình vận hành.

Apache tồn tại một số vấn đề về tốc độ xử lý. Không có nhiều người sử dụng Apache thực hiện tắt và loại bỏ các module không sử dụng đến, dẫn đến lãng phí CPU. Ngoài ra, việc sử dụng file .htaccess ở nhiều cấp thư mục khác nhau cũng làm trễ việc xử lý nội dung tĩnh.

Apache đang chầm chậm thay đổi để níu kéo vị trí số một về độ phổ biến.

Để đáp ứng nhu cầu của những kẻ đam mê tốc độ, trước hết Apache cho phép tắt các module không sử dụng đến. Thậm chí chúng ta có thể bỏ qua hết các file .htaccess bằng cách chỉnh các thiết lập AllowOverride và AllowOverrideList (trong file thiết lập virtual host) về giá trị None. Từ bản 2.4, Apache bổ sung một MPM (multi-processing module, module đa xử lý) mang tên event, có cơ chế hoạt động hướng sự kiện (event-driven) giống như nhiều web server cạnh tranh. Từ bản 2.4.17, Apache chính thức hỗ trợ giao thức tiên tiến HTTP/2. Tuy nhiên, những sự cố gắng thay đổi đó còn phải được cải tiến thêm nhiều trong thời gian tới, nhằm đáp ứng nhu cầu ngày một cao của những “thợ đua” chuyên nghiệp.

Tất nhiên, vẫn có những “tay đua” rất giỏi, thực hiện giám sát và tối ưu Apache một cách thường xuyên, nhằm đảm bảo nó chạy một cách trơn tru và nhanh chóng. Nhưng khi số lượng khách thực hiện tương tác với server tăng nhiều lên, thì việc tinh chỉnh Apache trở nên quá khó…

Ở ngoài kia đang có một số phần mềm server ra đời sau Apache và hội đủ điều kiện thế chỗ nó trong việc phục vụ nội dung. Trong thời thế bây giờ, chỉ có mấy điều sau khiến các bạn buộc phải gắn bó với Apache:

• Mã nguồn mà các bạn lựa chọn hiện đang phụ thuộc quá lớn vào .htaccess, đến mức gặp lỗi khi các bạn chuyển sang sử dụng web server khác với Apache.
• Các bạn muốn sử dụng một module hiện đang được phát triển cho Apache, chứ không phải là cho web server mà các bạn muốn và thích sử dụng.

Nếu các bạn bị vướng bất kì điều nào ở trên, hãy cài đặt một trong các web server sẽ được giới thiệu tiếp theo đây, để nó làm proxy tiền tuyến cho Apache. (Chú ý là cả Apache lẫn proxy đều phải được tinh chỉnh sau khi cài đặt.)

Nếu các bạn không vướng phải hai điều trên thì thật tuyệt vời! Các bạn hãy chuyển đổi sang một web server khác.

Đặc biệt là khi các bạn chỉ vướng điều đầu tiên, thì có một trong số các phần mềm sau đây có thể thay thế được Apache.

3.1.2. NGINX

Hãy để ý một chút: NGINX nghĩa là “engine X”. Vì vậy phiên âm tiếng Việt của cái tên này sẽ là en-din-ích-xì. Mình thấy vài người Việt chưa biết đến cái nghĩa này, thành ra đọc tên hay bị sai! Cách phát âm mình được nghe nhiều nhất là nghinh-x, nghin-x…

Năm 2004, Igor Sysoev (người Nga) công bố chương trình phần mềm này. Nó giải quyết vấn đề C10K, tức là phục vụ cho 10000 kết nối trong cùng một thời điểm. (Hiện nay, một số website lớn còn phải tiếp nhận đến hàng triệu kết nối cùng lúc!)

Thời điểm đó, NGINX mới chỉ thực hiện vai trò của một proxy tiền tuyến (đứng phía trước) cho các web server khác. Tuy nhiên nó đã (và đang) được ca ngợi về tốc độ xử lý yêu cầu rất cao, đặc biệt là với các yêu cầu phục vụ nội dung tĩnh. Về sau, NGINX được phát triển thành một web server đầy đủ.

NGINX nhẹ RAM và tận dụng tốt CPU đa nhân. Nó cũng có nhiều điều chỉnh linh hoạt, cũng có sẵn nhiều module, và ngày càng nhiều module ngoài được phát triển cho nó. Và NGINX không sử dụng .htaccess như ở Apache.

Ở NGINX, mọi thiết lập đều được tập trung tại file nginx.conf, hoặc được liên kết móc xích từ file nginx.conf thông qua các lệnh include đặt trong các file thiết lập. Các thiết lập được chia thành từng khối, trong đó mở đầu khối có đúng một từ khoá và được nối tiếp bởi dấu {, kết thúc khối là dấu }. Và để áp dụng thiết lập, người sử dụng phải khởi động lại NGINX. Có vẻ điều này được lấy cảm hứng từ ngôn ngữ C/C++ thì phải.

Ví dụ, trong file nginx.conf có một dòng include chứa đường dẫn đến thư mục chứa các file thiết lập virtual host. Trong một file bên trong thư mục đó, có thể có một lệnh include nữa kèm theo đường dẫn đến file thiết lập cụ thể về kết nối SSL. Khi NGINX được khởi động lại, nó sẽ tiến hành biên dịch thiết lập từ file nginx.conf trước. Cứ khi nào dịch đến lệnh include thì NGINX thay dòng lệnh đó bằng nội dung của file (hoặc toàn bộ các file trong thư mục) tại đường dẫn được chỉ định qua lệnh.

Khi NGINX thực hiện vai trò của một proxy server, module cache riêng của nó có thể linh hoạt lưu tạm (cache) nội dung HTML được sinh ra. Trên một trang web chính thức của NGINX đã có hai hướng dẫn cài đặt cache, trong đó có một hướng dẫn cơ bản và một hướng dẫn về microcache.

NGINX cũng đã hỗ trợ giao thức HTTP/2 từ phiên bản 1.9.5, và việc bổ sung HTTP/2 vào một virtual host có sẵn SSL là cực kì đơn giản. Mở file thiết lập virtual host lên và tìm khối lệnh server tương ứng với tên miền (domain) hoặc subdomain có SSL. Sau đó bổ sung từ khoá http2 vào dòng lệnh listen, ngay bên cạnh từ khoá ssl.

Sự thành công của NGINX đã khuyến khích rất nhiều các web server khác được tối ưu nhiều hơn cho tốc độ. Một số web server còn sử dụng cấu trúc file thiết lập gần giống với NGINX: LiteSpeed, Caddy…

3.1.3. LiteSpeed

Có một công ty tên là LiteSpeed Technologies công bố phần mềm LiteSpeed vào ngày 1/7/2003. LiteSpeed là kẻ thay thế hoàn toàn cho Apache, khi ngay cả file .htaccess cũng được nó hỗ trợ. Nó đã được sử dụng bởi một số dịch vụ hosting chia sẻ, có tốc độ xử lý website cao hơn nhiều so với Apache.

Khác với mọi web server khác cần phải được chỉnh sửa trực tiếp file thiết lập, LiteSpeed sử dụng một trang web thiết lập riêng có giao diện rất thân thiện. Đối với ngôn ngữ PHP, LiteSpeed sử dụng bộ dịch riêng (LiteSpeed PHP – LSPHP) có cơ chế hoạt động hướng sự kiện và nhỉnh hơn về tốc độ so với PHP-FPM.

Hơn nữa, trên khía cạnh an ninh, LiteSpeed chống chịu DDOS rất tốt, lại còn hỗ trợ sẵn ModSecurity cùng với các thiết lập tối ưu. (ModSecurity vốn là một module an ninh được phát triển cho Apache, và trong vài năm trở lại đây là NGINX.)

Nếu người dùng trả tiền sử dụng LiteSpeed thì sẽ được tận hưởng thêm nhiều cải tiến nữa:

• Nâng cao giới hạn số kết nối được phục vụ cùng lúc. Bản miễn phí (Standard Edition) chỉ hỗ trợ đến 150 kết nối.
• Loại bỏ giới hạn tối đa 5 virtual host được phép sử dụng.
• Sử dụng module cache riêng (LiteSpeed cache) có phương thức hoạt động giống Varnish. Nó có thể áp dụng linh hoạt cho cả nội dung tĩnh lẫn nội dung động, với hiệu năng rất cao. Module này cũng dễ thiết lập hơn Varnish.
• Edge Side Includes, cho phép chèn nội dung tĩnh một cách linh hoạt từ nhiều nguồn khác nhau vào trong một trang tĩnh. Điều này cho phép một trang có thể được xử lý cache theo từng phần nhỏ, làm tăng hiệu quả sử dụng cache.
• Hỗ trợ sớm giao thức QUIC được đề xuất và phát triển bởi Google. Hiện chính giao thức này đang trong giai đoạn thử nghiệm.

OpenLiteSpeed mà mình sử dụng trong thời gian vừa qua chính là “người em” mã nguồn mở (open source) của LiteSpeed. Các bạn có thể sử dụng OpenLiteSpeed thoải mái, điều chỉnh số kết nối tuỳ ý, lập bao nhiêu virtual host cũng được, và sử dụng module cache. Tuy nhiên khả năng sử dụng file .htaccess sẽ bị hạn chế: Chỉ có các lệnh rewrite trong đó thực sự được áp dụng.

Các bạn hãy đọc thêm series về OpenLiteSpeed do mình viết để nắm được cơ bản cách cài đặt phần mềm này nhé. Riêng phần cài đặt module cache, mình dự tính sẽ không viết hướng dẫn cài đặt nữa, vì đã có vài trang tiếng Việt khác viết tốt rồi.

3.1.4. H2O

H2O (“HTTP/2 Optimized”) là một web server mã nguồn mở, được công ty DeNA (Nhật Bản) phát hành vào năm 2014. Nó được viết bằng ngôn ngữ Ruby và được chạy bởi bộ thông dịch mruby. Đứng đầu dự án H2O là kĩ sư Kazuho Oku.

H2O chú trọng vào tốc độ phục vụ nội dung trên giao thức HTTP/2. Nó cũng có khả năng phòng chống DDOS với các điều chỉnh nhận diện và phản ứng cơ bản.

Hiện tại Kazuho Oku đang tiến hành thử nghiệm công khai giao thức QUIC trên H2O, như ở LiteSpeed đang làm.

3.1.5. Caddy

Caddy cũng là một web server mã nguồn mở, được kĩ sư Matthew Holt (Matt Holt) ra mắt vào tháng Tư năm 2015, chạy trên nền tảng ngôn ngữ Go. Các cá nhân có thể sử dụng Caddy hoàn toàn miễn phí. Các công ty muốn sử dụng phần mềm này thì cần trả tiền để có được sự hỗ trợ thông qua công ty Light Code Labs.

Caddy nổi bật ở file thiết lập Caddyfile đơn giản hơn so với mọi web server khác từ trước đến nay. Caddy tự động yêu cầu cấp chứng chỉ SSL từ Let’s Encrypt và kích hoạt giao thức an toàn TLS đã được tối ưu sẵn. Caddy cũng ưa thích việc trao đổi dữ liệu qua hai giao thức HTTP/2 và QUIC.

Ngày càng nhiều module (plugin) hữu ích và thú vị được phát triển cho Caddy. Trong đó có plugin dịch file văn bản Markdown sang nội dung HTML để hỗ trợ phục vụ nội dung website, và hai plugin tạo giao diện quản lý website dựa trên hai trình tạo trang tĩnh phổ biến là Jekyll và Hugo.

3.1.6. Node.js

Node.js không đơn thuần chỉ là một web server. Nó là cả một nền tảng (framework) lớn dành cho server. Nó dựa trên engine V8 của Google, để đọc và thực thi chương trình từ các file JavaScript. Engine V8 cũng đang được trình duyệt Chrome/Chromium sử dụng để dịch và thực thi mã JavaScript ở phía client.

Node.js tận dụng các ưu điểm của ngôn ngữ JavaScript trong việc vận hành server. Người sử dụng có thể mở rộng Node.js bằng cách cài đặt các phần mềm và gói thư viện bổ sung thông qua hệ thống NPM (Node Package Manager).

Nếu các bạn thông thạo ngôn ngữ JavaScript thì Node.js là một phần mềm server rất đáng để thử. Có một số thứ liên quan đến nó:

• Ghost là một CMS khá mới, ra mắt chính thức vào tháng 10 năm 2013, sử dụng JavaScript (được dịch và chạy bởi Node.js) và MySQL. Ghost khuyên dùng NGINX để phục vụ nội dung ra ngoài và kích hoạt SSL.
• MEAN stack, gồm có MongoDB (một hệ quản trị cơ sở dữ liệu phi SQL), Express.js, AngularJS và chính Node.js. Stack này đặc sệt JavaScript, và hiện đang là một đối thủ đáng gờm của hai stack phổ biến là LAMP (Linux – Apache – MySQL – PHP) và LEMP (Linux – NGINX – MySQL – PHP).

3.2. Bộ dịch ngôn ngữ

Một bộ dịch ngôn ngữ là một chương trình dịch một ngôn ngữ lập trình cụ thể sang mã máy. Sở dĩ có cái đó là vì mã máy được thiết kế tối ưu cho CPU (và GPU). Mã máy chỉ bao gồm các hướng dẫn cụ thể cho các bộ phận bên trong CPU, chứ không phải là các thao tác nhỏ hay được con người sử dụng để yêu cầu hoặc hướng dẫn cho nhau!

Các bạn sử dụng mã nguồn viết bằng ngôn ngữ gì, thì các bạn sẽ cài đặt bộ dịch cho ngôn ngữ đó. Hiểu một cách nôm na rằng, muốn sử dụng ngôn ngữ gì trên server thì cài ngôn ngữ đó vào. Bởi vì hầu như chỉ có duy nhất một bộ dịch dành cho từng ngôn ngữ một.

Thế nhưng, đối với ngôn ngữ PHP, chúng ta có rất nhiều lựa chọn khác nhau về bộ dịch, chưa kể đến phiên bản bộ dịch tương ứng với từng phiên bản của PHP. Cho đến thời điểm hiện tại, đây là ba lựa chọn tối ưu nhất về tốc độ cũng như tiết kiệm tài nguyên:

• PHP: FastCGI Process Manager (PHP-FPM).
• HipHop Virtual Machine (HHVM). Chú ý rằng, cái này không hoàn toàn tương thích với mọi lệnh trong PHP.
• LiteSpeed PHP (LSPHP). Bộ dịch này chỉ có thể được sử dụng bởi LiteSpeed và OpenLiteSpeed.

Ngoài ra, các bộ dịch dành cho ngôn ngữ PHP phiên bản 7 có cơ chế hoạt động hoàn toàn mới, nhanh và hiệu quả hơn nhiều so với trước đây.

3.3. Hệ quản trị cơ sở dữ liệu

Tương tự như mục 3.2, mã nguồn hoạt động với cơ sở dữ liệu nào thì các bạn sẽ cài hệ quản trị cho cơ sở dữ liệu đó.

Đối với cơ sở dữ liệu MySQL cũng vậy, cơ bản là các bạn sẽ tìm đến MySQL Server để cài đặt và quản lí cơ sở dữ liệu này. Tuy nhiên, trong cuộc đua về tốc độ, chúng ta không nên sử dụng MySQL Server.

Hiện tại, dự án MySQL đang được quản lí bởi Oracle. Nhiều người không hài lòng với cách Oracle quản lý dự án này, nên một số nhóm đã fork (sao chép và cải biên) dự án MySQL thành các hệ quản trị riêng tương thích với cơ sở dữ liệu MySQL. Trong số đó, có một nhóm đứng đầu bởi cha đẻ của MySQL (Michael “Monty” Widenius) đã phát triển nên MariaDB vào khoảng đầu năm 2009. MariaDB đang được đóng góp xây dựng tích cực bởi một cộng đồng đông đảo, được giám sát bởi Tập đoàn MariaDB. Monty hiện đang là giám đốc công nghệ (CTO) tại tập đoàn này.

Một lựa chọn khác cũng quản lí cơ sở dữ liệu MySQL, đó là Percona Server for MySQL (gọi tắt là Percona). Nó được công ty Percona phát triển và ra mắt vào năm 2006. Percona hướng đến các doanh nghiệp mong muốn tăng tốc độ truy vấn cơ sở dữ liệu.

Các bạn có lựa chọn MariaDB hay Percona thì cũng tốt cả. Điều các bạn cần quan tâm là storage engine (engine lưu trữ) được sử dụng tại các bảng trong cơ sở dữ liệu.

• Đối với website nhỏ, không có lượng truy cập lớn, chúng ta có thể sử dụng MyISAM hoặc tốt hơn là Aria (cải tiến từ MyISAM).
• Đối với website lớn, có lượng truy cập cao:
  • Sử dụng một trong các engine sau: InnoDB, XtraDB, TokuDB.
  • Sử dụng chương trình MySQLTuner để có được các gợi ý tinh chỉnh hệ quản trị. Nên chạy MySQLTuner sau 24 giờ kể từ thời điểm gần đây nhất server được khởi động.

---

4. Lựa chọn phần mềm thực hiện cache

Cache (bộ đệm) là một từ được rất nhiều nhà phát triển “nhai đi nhai lại” trong một cuộc đua tốc độ. Cache xuất hiện trong mọi thiết bị phần cứng cũng như hầu hết các chương trình phần mềm. Việc sử dụng cache sẽ góp phần làm giảm số thao tác xử lí, nghĩa là CPU sẽ được sử dụng tiết kiệm hơn khi có cache.

Trong một server có hai vị trí chính được sử dụng để ghi cache, đó là bộ nhớ RAM và ổ đĩa. Còn về phần mềm cache, hiện tại có thể được chia ra làm mấy loại sau đây.

4.1. Module cache cho phần mềm web server

Hiện tại có hai web server sau có module cache tốt: NGINX, LiteSpeed trả phí (và OpenLiteSpeed).

Trước khi sử dụng module cache, các bạn cần cài đặt proxy cho web server và đặt nó ở phía trước. Proxy sẽ ở vị trí trung gian, giữa client và các thành phần còn lại trong server.

Các bạn có thể sử dụng một phần mềm web server để làm proxy, hoặc tạo mới proxy ngay trên web server hiện tại. Sau đó các bạn kích hoạt và điều chỉnh module cache tại proxy.

4.2. Phần mềm proxy server có chức năng cache

Có một số phần mềm chỉ là proxy server, trong số đó có một số có tính năng cache. Cho đến nay, có ba proxy server như vậy được sử dụng nhiều nhất.

4.2.1. Apache Traffic Server

Đây vốn là một proxy server thương mại được phát triển bởi công ty Inktomi (Mỹ), với cái tên ban đầu là Inktomi Traffic Server. Inktomi được mua lại bởi Yahoo vào năm 2003, và kể từ đó Yahoo sử dụng Traffic Server trên hệ thống web server do hãng quản lý. Tháng 7 năm 2009, Yahoo cung cấp mã nguồn của phần mềm này cho Apache. Đến ngày 21/4/2010, Apache chính thức công bố rộng rãi mã nguồn của Traffic Server.

Apache Traffic Server (ATS) là một proxy server mạnh và có rất nhiều tính năng, vừa có thể cache, vừa có thể bảo vệ cho các thành phần phía sau nó. ATS cũng hỗ trợ SSL và HTTP/2. Nếu các bạn cần nhiều tính năng nhất có thể thì hãy đến với ATS. Nhưng nếu các bạn chỉ cần cache thôi, thì ATS kém hơn Squid và Varnish (và cả module cache của NGINX) về hiệu năng.

4.2.2. Squid

Squid là proxy server mã nguồn mở được ra mắt vào tháng 7 năm 1996. Tính năng của Squid cũng rất đa dạng, gần bằng ATS. Ở Squid có một thiếu sót nhỏ: Mặc dù nó hỗ trợ SSL, nhưng nó chưa hỗ trợ HTTP/2. Bù lại, cache của Squid tốt hơn của ATS đôi chút.

Muốn sử dụng Squid mà lại muốn có HTTP/2? Câu trả lời hay nhất bây giờ là bổ sung NGINX (hoặc Caddy) như là một proxy tiền tuyến cho cả Squid lẫn các thành phần khác.

4.2.3. Varnish

Đã có và ngày càng có nhiều người biết đến phần mềm rất mạnh này. Đây là một proxy server ra mắt vào năm 2006, tập trung vào việc cache qua giao thức HTTP. Nó được sử dụng tại rất nhiều trang web nổi tiếng trên thế giới.

Mặc dù nó cực kì mạnh và linh hoạt ở công việc cache, nhưng lại có một điểm trừ: Nó không hề hỗ trợ SSL, và sẽ không bao giờ hỗ trợ SSL!

Vì thế, nếu các bạn vừa muốn website sử dụng SSL (và HTTP/2), vừa muốn tăng tốc nhờ Varnish, thì các bạn bổ sung NGINX hoặc Caddy làm proxy tiền tuyến.

4.3. Gói mở rộng về cache cho bộ dịch ngôn ngữ

Đối với những ngôn ngữ phổ biến như PHP, Python, Ruby… thì hay có những gói mở rộng (extension) hoặc thư viện (library) có thể thực hiện cache kết quả hoặc mã máy tương ứng với từng đoạn mã nguồn. Hãy chịu khó tìm hiểu và tận dụng bất cứ khi nào có thể.

Đối với ngôn ngữ PHP, hiện tại có hai extension phổ biến thực hiện cache vào bộ nhớ RAM, đó là:

• APC User Cache (APCu): Cache dữ liệu, thường là kết quả xử lý của các đoạn mã PHP.
• Zend OPcache: Cache mã máy (cụ thể là opcode) được bộ dịch PHP dịch ra.

APCu được rút gọn lại từ extension Alternative PHP Cache (APC). APC thực hiện cache cả dữ liệu lẫn mã máy. Nhưng từ phiên bản PHP 5.4, nó luôn gặp khó khăn trong việc cache mã máy. Kể từ PHP 5.5, OPcache trở thành extension mặc định thực hiện cache mã máy, thì APCu xuất hiện thay thế cho APC để hoạt động song song với OPcache.

Ưu điểm của tất cả các extension trên là đều không cần sử dụng nhiều bộ nhớ RAM. Ngoài ra còn có extension Memcached tuy cũng cung cấp khả năng cache tương tự, nhưng thực chất đó là một extension cầu nối giữa PHP và một phần mềm cache độc lập cũng có tên là Memcached.

4.4. Phần mềm cache độc lập

Có một số phần mềm như vậy, mà không phải là proxy server cho bất cứ cái gì cả. Chúng hoạt động trên mô hình client – server, vì thế người ta có thể cài đặt một số cache server chỉ dùng để cache, nhờ vào các phần mềm như vậy.

Hiện tại có hai phần mềm cache độc lập phổ biến là Memcached và Redis. Chúng đều lưu tạm dữ liệu vào bộ nhớ RAM. Memcached hay được sử dụng để cache kết quả từ PHP, còn Redis thì hay được dùng để cache kết quả của các truy vấn cơ sở dữ liệu.

Có một điều kì lạ là, bản thân Redis chính là một hệ quản trị cơ sở dữ liệu phi SQL (NoSQL). Vì vậy, trong một số hoàn cảnh cần thời gian phản hồi cực ngắn, người ta sử dụng luôn Redis để chứa database. Tất nhiên việc đó cần nhiều RAM, tuỳ theo kích thước của database.

4.5. Cơ chế cache của mã nguồn

Mã nguồn cần có các hoạt động cache cụ thể để tiết giảm số thao tác phải thực hiện lại nhiều lần. Trong đó, những nội dung tĩnh (ít thay đổi) thì nên được ghi ra file trên ổ đĩa. Và nếu server được trang bị những phần mềm cache thuộc các mục 4.3 và 4.4, thì mã nguồn cần phối hợp với các phần mềm đó.

---

5. Giám sát và tinh chỉnh thêm

Sau khi các bạn cài đặt và điều chỉnh xong một stack với đầy đủ tiện nghi cho mã nguồn, hãy khởi động website lên và theo dõi thôi!

Trước tiên, chúng ta tiến hành chạy thử và kiểm tra khả năng chịu tải của server. Có rất nhiều phần mềm và dịch vụ giúp chúng ta kiểm tra, trong đó hầu hết đều cần được cài đặt trên một server khác, để server được kiểm tra có cơ hội thể hiện hết khả năng. (Bản thân mình chưa từng thực hiện việc này bao giờ, vì từ trước đến nay mình chỉ dựng và vận hành các trang web nhỏ.)

Sau đó là phần “chạy marathon”. Trong quá trình “chạy”, nên tiến hành định kì (hoặc thỉnh thoảng cần làm) việc đọc các file error log chứa các thông báo lỗi cụ thể. Sau khi đọc qua bài tổng quan này và phân loại được các loại chương trình đang chạy trên server, mình mong các bạn sẽ nhanh chóng tìm ra được vị trí gặp vấn đề, từ đó có thể tự tay điều chỉnh thêm, hoặc thay đổi sang chương trình tối ưu hơn khi cần.

Hãy bắt đầu năm mới 2018 với những server khoẻ mạnh nào! Gaooooooooooooooooh!