Di chuyển ứng dụng PHP từ MySQL sang DB2 Phần 4: Triển khai ứng dụng của bạn

Di chuyển ứng dụng PHP từ MySQL sang DB2 Phần 4: Triển khai ứng dụng của bạn Giới thiệu về triển khai Bài này trình bày bốn bước chính để triển khai và hỗ trợ ứng dụng và cơ sở dữ liệu một khi nó đã sẵn sàng cho sản xuất. Nếu cần, hãy tham khảo Phần 1 của loạt bài này để xem lịch trình các bước ấy trong quá trình di trú tổng thể trước khi tiến hành triển khai. Bước 1: Tạo một môi trường sản xuất mới  Xác định cấu trúc liên kết sản xuất và chiến lược triển khai.  Cấu hình các máy chủ dữ liệu DB2 chính và bản sao sản xuất.  Cấu hình máy chủ ứng dụng PHP sản xuất. Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng  Thực hiện hay cập nhật cơ chế báo cáo lỗi PHP.  Xác định các giá trị thích hợp cho các tính năng tự trị trong DB2.  Xác nhận các giá trị thiết lập sao lưu dự phòng và sao chép cơ sở dữ liệu. Bước 3: Triển khai ứng dụng đã cập nhật  Lập lịch biểu một ngày triển khai để giảm thiểu ảnh hưởng đến công việc kinh doanh.  Bắt giữ lại các bản sao lưu ảnh của hệ thống hiện có và hệ thống mới.  Triển khai dữ liệu DB2.  Triển khai mã PHP.  Giám sát hệ thống mới. Bước 4: Xử lý hỗ trợ liên tục  Đáp ứng hoặc tránh các vấn đề hiệu năng.  Cấu hình lại khi kích cỡ của dữ liệu và luồng công việc phát triển thêm. Về đầu trang Hiểu một nghiên cứu sâu ví dụ về cấu trúc liên kết triển khai PTT hiện có Nhắc nhở Nếu cần, hãy tự mình tìm hiểu phần Tài nguyên có thể có ích trong việc di trú của bạn. Các tài nguyên sau có thể đặc biệt có ích cho bước này:  Chương 9 và 10 trong ấn phẩm Redbooks® của IBM Hướng dẫn chuyển đổi MySQL sang DB2 (MySQL to DB2 Conversion Guide).  Bài "Danh sách nên xem: Quản trị cơ sở dữ liệu của DB2 cho Linux, UNIX và Windows" trên developerWorks.  Loạt bài "Sử dụng các kỹ năng về MySQL để tìm hiểu DB2 Express" trên developerWorks.  Sách trắng "Các hướng dẫn thực hành tốt nhất: Các chiến lược giảm chi phí với DB2" trên developerWorks . Một tùy chọn khác là sử dụng đám mây cho quá trình di trú. Bạn có thể sử dụng các ảnh máy Amazon (AMI) Linux và DB2 của Amazon EC2 hoặc đăng ký dùng SmartCloud của IBM (trước đây được biết đến với tên gọi Phát triển và thử nghiệm trên Đám mây IBM) (xem Tài nguyên). Để có được cấu trúc liên kết triển khai ví dụ trong bài này, hệ thống sản xuất PTT (Project Tracking Tool - Công cụ dò vết dự án) có một máy Linux chạy máy chủ web Apache được biên dịch từ mã nguồn với phần mở rộng mod_php được xây dựng và được nạp như một mô-đun động, một máy Linux chạy cơ sở dữ liệu chủ MySQL và một máy Linux thứ ba chạy ;một cơ sở dữ liệu MySQL sao chép cho các phân tích và các truy vấn đặc biệt. Ứng dụng PTT được sử dụng cho các chức năng khác nhau để hỗ trợ luồng công việc thông tin được công bố trên trang web của IBM. Hơn 4.000 người dùng trên toàn thế giới truy cập và sửa đổi cơ sở dữ liệu MySQL thông qua mặt trước của trang web PHP. Tại bất kỳ thời điểm nào cũng có vài trăm người dùng đang hoạt động đồng thời trên hệ thống. Cấu trúc liên kết đơn giản này được hiển thị trong Hình 1. Hình 1. Cấu trúc liên kết máy chủ và phần mềm ban đầu Phần lớn người dùng truy cập cơ sở dữ liệu chủ thông qua mặt trước của Apache và PHP. Một ít người dùng kết nối trực tiếp đến cơ sở dữ liệu sao chép để chạy các truy vấn SQL đặc biệt hoặc sử dụng Hyperion Brio để tạo ra các báo cáo. Trong ví dụ triển khai, vẫn duy trì cách bố trí ba máy chủ giống nhau, nhưng các hệ thống MySQL chính và bản sao đã được thay thế bằng các cá thể của DB2. Cấu hình Apache và PHP được biên dịch từ nguồn đã được thay thế bằng các phiên bản đóng gói nhị phân của Apache và PHP (Zend Server với các phần mở rộng DB2). Bài này mô tả các yếu tố cần xem xét khi lựa chọn một cấu trúc liên kết PHP và DB2, các bước cần thiết để di chuyển mã vào sản xuất càng trôi chảy càng tốt và cách duy trì một hệ thống ổn định sau khi triển khai. Về đầu trang Chuẩn bị các tài sản triển khai Để chuẩn bị triển khai các ứng dụng đã cập nhật, hãy bảo đảm rằng một bản sao ổn định của cơ sở dữ liệu và mã đã sẵn sàng cho sản xuất. Bạn sẽ đạt tới điểm này sau một số lần lặp lại quá trình di trú và chuyển đổi được mô tả trong Phần 2 và Phần 3 của loạt bài này, xem phần Tài nguyên. Ngoài sự ổn định, hãy chắc chắn rằng chức năng của ứng dụng nói chung đã được các đại diện của các bên liên quan chấp thuận. Bản sao ổn định và được phê duyệt của dữ liệu và cấu trúc cơ sở dữ liệu DB2 được di trú Tùy thuộc vào việc liệu môi trường sản xuất của bạn có cùng một nền tảng như hệ thống phát triển của bạn hay không, ví dụ nếu cả hai đều là các hệ thống Linux 64-bit, bạn có thể dùng một trong hai cách tiếp cận để di chuyển dữ liệu của mình vào sản xuất. Nếu chúng có cùng một nền tảng, chỉ cần sao lưu cơ sở dữ liệu trên hệ thống phát triển của bạn và phục hồi nó như một bản sao mới của cơ sở dữ liệu trong sản xuất. Trái lại, nếu chúng là các nền tảng khác nhau, bạn sẽ cần tính đến tập hợp các kịch bản lệnh của ngôn ngữ định nghĩa dữ liệu (DDL) để tạo ra cấu trúc cơ sở dữ liệu, bao gồm các đối tượng như khóa và các ràng buộc giá trị được phép, các chỉ mục và các thiết lập cấu hình. Tập hợp này cũng sẽ bao gồm các kịch bản lệnh nhập khẩu thường dùng để di chuyển dữ liệu đã di trú vào hệ thống DB2 mới. Bản sao ổn định và được phê duyệt của mã PHP đã chuyển đổi và các tệp tĩnh khác Bản sao này bao gồm mã PHP đã chuyển đổi và tất cả các tệp JavaScript, CSS và hình ảnh cần thiết khác để tạo ra ứng dụng web. Bản sao này cũng bao gồm các kịch bản lệnh vỏ (shell) được lập lịch biểu và được gọi thông qua các công việc dựa theo lịch biểu thời gian (cron) để xử lý các thông báo định kỳ và bảo trì thường xuyên, chẳng hạn như việc thực hiện các quy tắc lưu giữ dữ liệu hàng đêm. Dữ liệu đúng thời điểm Trong hầu hết các trường hợp, hệ thống sản xuất MySQL của bạn sẽ tiếp tục tạo ra các dữ liệu mới khi bạn tiến hành các bước trong Phần 2 và 3 của loạt bài này, xem phần Tài nguyên. Nhiều khả năng bạn sẽ cần nhập khẩu dữ liệu mới nhất này vào bản sao ổn định của mình để di chuyển vào sản xuất như trong Bước 2 của Phần 2. Xem Liệt kê 3 trong bài đó để thấy cách di chuyển chỉ dữ liệu đã thay đổi kể từ khi xuất khẩu ban đầu. Hãy chắc chắn tham khảo các quyết định về cấu hình của bạn và các bài học rút ra từ các bước ở trên trong loạt bài này để bạn có thể bảo đảm hệ thống sản xuất được cấu hình đúng khi bạn triển khai. Hãy xem xét việc lưu một ảnh chụp nhanh của cả hai hệ thống hiện có và hệ thống mới như là các ảnh máy ảo trước khi triển khai tại các điểm mốc quan trọng để dùng làm các bản sao lưu dự phòng và làm các vạch chuẩn để so sánh việc cải thiện mã tiếp theo. Nếu bạn muốn bắt giữ lại một hình ảnh của một cấu hình máy tính vật lý, bạn có thể làm việc này bằng VMware vCenter Converter (Bộ chuyển đổi vCenter của Vmware) miễn phí. Có một sự thay thế khác là xem xét dùng đám mây cho những thay đổi thực hành như vậy. Bạn có thể sử dụng các Ảnh máy Amazon (AMI) DB2 của Amazon EC2 hoặc bạn có thể đăng ký dùng SmartCloud của IBM (trước đây được gọi là Phát triển và thử nghiệm trên Đám mây của IBM). Với các máy ảo, bạn sẽ có thể không phải mua sắm phần cứng máy chủ và cài đặt một hệ điều hành và DB2, để tiết kiệm thời gian, đẩy nhanh quá trình di trú và mang lại cho bạn sự tự tin hơn để trải nghiệm với cấu hình phù hợp nhất cho nhu cầu của bạn. Có thể tìm thấy các liên kết đến tất cả những sản phẩm này trong phần Tài nguyên. Về đầu trang Bước 1: Tạo một môi trường sản xuất mới Vì bạn đã di trú dữ liệu và mã trong Phần 2 và 3 của loạt bài này, hãy xem phần Tài nguyên, bạn đã nắm bắt được các lưu ý về cấu hình để biểu thị kiểu tài nguyên mà ứng dụng của bạn sẽ cần có trong sản xuất. Bây giờ ứng dụng này đã được thử nghiệm và được kiểm tra, bạn đã sẵn sàng để xác nhận môi trường có sẵn cho sản xuất cần thiết để chạy nó. Trong nghiên cứu sâu này, ứng dụng triển khai sản xuất được chuẩn bị trên các máy chủ vật lý mới (mặc dù các máy ảo cũng là một tùy chọn), chứ không phải cấu hình lại các máy chủ hiện có để lưu trữ trên đó hệ thống dựa vào MySQL đã thấy ở trên trong Hình 1. Bước này liên quan đến các bước con sau đây.  Xác định chiến lược sản xuất.  Cấu hình các máy chủ dữ liệu DB2 chính và bản sao.  Cấu hình máy chủ ứng dụng PHP. Xác định chiến lược sản xuất Trong ví dụ này, một cơ sở dữ liệu DB2 mới và một bản sao được cài đặt và dữ liệu được di trú lên cả hai máy chủ Linux 64-bit. Cả hai máy chủ MySQL chính và bản sao cũ hơn có bốn lõi xử lý (3,0 GHz) và 8 GB bộ nhớ RAM. Hai máy chủ DB2 mới có 8 lõi xử lý (2,5 GHz) và 16 GB RAM. Các thông số kỹ thuật mạnh hơn phản ánh tuổi tác của máy tính chứ không phải là một yêu cầu tiên quyết để có phần cứng tốt hơn cho DB2. Các kinh nghiệm di trú, chuyển đổi và thử nghiệm của bạn từ các phần trước của loạt bài này, xem phần Tài nguyên, sẽ giúp bạn phối hợp đúng các tài nguyên cho tải công việc của mình. Các cách tiếp cận triển khai Bạn sẽ cần trả lời những câu hỏi quan trọng sau đây khi bạn chuẩn bị triển khai ứng dụng mới được cập nhật của mình vào sản xuất.  Bạn có bắt đầu với một cấu hình mới hay là bạn thay thế phần mềm trên hệ thống hiện có và sử dụng lại phần cứng ? Nói cách khác, bạn có cài đặt DB2 và gỡ bỏ cài đặt MySQL như là một phần trong cùng một hoạt động triển khai không?  Bạn có triển khai nâng cấp cơ sở dữ liệu và nâng cấp phiên bản PHP cùng một lúc hay là bạn triển khai mỗi thành phần ở một giai đoạn riêng biệt? Đó là, nâng cấp môi trường PHP lên Zend Server trong khi vẫn sử dụng MySQL, sau đó thay thế MySQL bằng DB2? Không phải lúc nào cũng có một câu trả lời rõ ràng. Trong ví dụ này, việc bắt đầu từ các thành phần mới được cài đặt và triển khai cấu trúc liên kết hoàn chỉnh có ít rủi ro hơn vì nói chung mọi thứ đã được thử nghiệm và vì bạn có thể dễ dàng quay trở lại hệ thống cũ trong lúc triển khai nếu có vấn đề. Quyết định có nên thay đổi môi trường sản xuất hiện tại của bạn hay bắt đầu bằng các máy tính mới hay không Dựa trên những quan sát từ việc thử nghiệm ứng dụng và việc hiểu các đặc tính hiệu năng của nó trong Phần 2 và Phần 3 của loạt bài này, xem phần Tài nguyên, phần cứng của bản chính và bản sao MySQL hiện có (hoặc tương tự) có thể đã đủ cho hệ thống mới dựa trên DB2. Tuy nhiên, do hệ thống hiện có đã nhiều hơn ba tuổi rồi, nên trường hợp thử nghiệm này đã bắt đầu với phần cứng mới để vừa mạnh hơn lại vừa tiết kiệm năng lượng hơn. Bạn có thể muốn đánh giá xem đây có phải là lúc để mua sắm phần cứng mới không hoặc nếu không thì có phải là lúc để nâng cấp hệ thống của bạn để đáp ứng tốt nhất với tải công việc cơ sở dữ liệu và ứng dụng của bạn không, dựa trên bất kỳ sự nghẽn cổ chai nào mà bạn thấy trong quá trình di trú và chuyển đổi. Quyết định xem có nên thay thế toàn bộ hệ thống sản xuất hay là nâng cấp trong nhiều giai đoạn Một vấn đề cần xem xét khác đối với quá trình triển khai của bạn là quyết định xem bạn sẽ xây dựng một hệ thống hoàn toàn mới tách biệt khỏi bất kỳ các máy chủ sản xuất hiện tại nào của bạn hay là bạn sẽ thay thế các phần mềm trên các máy chủ vật lý hay các máy chủ ảo hiện tại của bạn. Một hệ quả tất yếu của quyết định này là liệu bạn sẽ chuyển hoàn toàn dữ liệu đồng bộ từ hệ thống cũ sang hệ thống mới cùng một lúc không hay là bạn sẽ thay thế dần dần một số thành phần. Ví dụ, một tùy chọn đã được xem xét là thay thế một bản xây dựng tùy chỉnh của Apache và PHP bằng các phiên bản đóng gói trước khi chuyển đổi từ MySQL sang DB2. Cuối cùng, đã quyết định là thay thế tất cả các thành phần đã được thử nghiệm tích hợp cùng một lúc, chứ không phải là thực hiện các thay đổi cơ sở hạ tầng dần dần từng bước theo các giai đoạn. Cuối cùng, hệ thống mới dựa trên DB2 phản chiếu cấu trúc liên kết triển khai MySQL hiện có, nhưng nó được xây dựng tách khỏi hệ thống trung gian và hệ thống sản xuất hiện có. Khi đã đến thời gian bật nguồn cho hệ thống mới, lưu lượng đã được chuyển hướng đến các máy chủ web mặt trước mới. Điều này cũng có nghĩa là việc triển khai có thể quay lại hệ thống cũ bằng cách đảo ngược chuyển hướng. Lúc đầu, đã lập kế hoạch để chỉ thay thế các cá thể MySQL bằng các cơ sở dữ liệu DB2, nhưng trường hợp sử dụng này đã tận dụng lợi thế của quá trình di trú để đồng thời nâng cấp phiên bản đã biên dịch tùy chỉnh của Apache và PHP bằng các phiên bản đóng gói và dễ bảo trì. Cấu hình các máy chủ dữ liệu DB2 chính và bản sao Hãy cài đặt phiên bản 9.7.2 của DB2 Enterprise (Doanh nghiệp DB2) lên hai máy chủ Linux doanh nghiệp Red Hat 64-bit giống hệt nhau. Như đã lưu ý trong ô đóng khung bên cạnh đầu tiên trong bài này, các bài báo trên developerWorks là "Quản trị cơ sở dữ liệu DB2 cho Linux, UNIX và Windows" và "Sử dụng các kỹ năng MySQL để tìm hiểu DB2 Express: Các nhiệm vụ quản trị và các nhiệm vụ cơ bản của DB2 so với MySQL" đưa ra một tổng quan rất hay về các nhiệm vụ cài đặt và cấu hình then chốt và có thể tìm thấy các bài này trong phần Tài nguyên. Cấu hình máy chủ ứng dụng PHP Tiếp theo, hãy cài đặt Apache và Server Zend lên máy chủ ứng dụng. Máy chủ này có thể chia sẻ các đặc tả tương tự như hai máy chủ cơ sở dữ liệu. Trên máy chủ sản xuất trước đó, Apache đã được biên dịch từ mã nguồn và PHP được xây dựng để được chạy như là một mô-đun được chia sẻ động. Đối với hệ thống sản xuất mới, Server Zend đã được sử dụng để thay thế và tiện ích quản lý gói của hệ điều hành được phép xử lý gói và các bản nâng cấp Apache (http). Người ta đã chọn cách này vì những lý do sau đây.  Zend Server là một bản phân phối nhị phân của PHP để tự động cấu hình máy chủ web Apache. Nó được hỗ trợ và đã được thử nghiệm trên các bản phân phối Linux mức doanh nghiệp. Việc cài đặt và bảo trì rất dễ dàng theo một định dạng gói để có thể được quản lý bằng công cụ yum trên Red Hat Linux.  Zend Server bao gồm các trình điều khiển DB2 và cung cấp một giao diện dựa vào Giao diện người dùng đồ họa (GUI) để cấu hình các phần mở rộng cần thiết.  Zend Server cung cấp chức năng giám sát, ghi nhật ký và cảnh báo để mang lại sự hiểu biết tốt hơn về cách hệ thống đang hoạt động. Bài báo "Tạo ra một môi trường phát triển PHP trên đám mây" của Daniel Krook trên developerWorks cung cấp thêm chi tiết về cách cài đặt và cấu hình DB2 với Zend Server (xem phần Tài nguyên). Bài này đã đi theo một quá trình giống hệt. Hình 2 cho thấy hệ thống sau khi đã thay thế MySQL bằng DB2 và hệ thống đã nâng cấp lên Zend Server. Miếng ghép còn thiếu cuối cùng là cài đặt phần mềm Cognos Business Intelligence của IBM dựa trên web, để thay thế cho công cụ Hyperion Brio di sản chạy trên máy tính để bàn, đã được cấu hình để tạo ra các phân tích từ cơ sở dữ liệu DB2 mới. Bạn có thể tìm hiểu thêm về cách cài đặt Cognos bằng cách tham khảo các liên kết đến các sản phẩm trong phần Tài nguyên. Hình 2. Cấu trúc liên kết máy chủ và phần mềm mới Về đầu trang Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng Nếu bạn đang di trú từ một hệ thống sản xuất hoàn thiện, bạn có thể có một cơ chế báo cáo lỗi đang tồn tại. Trong trường hợp này, do có sử dụng tầng trừu tượng của cơ sở dữ liệu PDO trong PHP, nên vẫn có thể tiếp tục sử dụng hệ thống hiện có để thông báo cho các quản trị viên biết các vấn đề trong mã. Ở mức cơ sở dữ liệu, DB2 Health Monitor (Bộ theo dõi sức khỏe của DB2) được sử dụng để đưa ra các cảnh báo dựa vào lúc các ngưỡng cụ thể đã đạt đến hay vượt quá giới hạn quy định. Bước này liên quan đến các bước con sau đây.  Cấu hình cơ chế báo cáo lỗi PHP  Xác định các thiết lập bảo trì DB2  Xác nhận các thiết lập sao lưu dự phòng và sao chép DB2 Ngoài các hiểu biết sâu hơn do mã báo cáo lỗi tùy chỉnh cung cấp, trường hợp sử dụng này cũng được hưởng lợi từ việc theo dõi và phân tích chi tiết mịn hơn nhờ việc chuyển đổi sang Zend Server. Cấu hình cơ chế báo cáo lỗi PHP Dù bạn phát triển và thử nghiệm cẩn thận đến mấy đi nữa, thì bạn vẫn có cơ hội phát sinh các lỗi không lường trước được trong sản xuất. Ứng dụng này đã luôn kết hợp một tính năng gỡ lỗi tự động hiệu quả. Nếu ứng dụng web gặp một lỗi, nó sẽ thu thập tất cả các thông tin về bối cảnh lỗi và gửi một email đến những người phụ trách phát triển để họ có thể ngay lập tức nhận biết và sửa chữa lỗi. Điều này đặc biệt có ích với một ứng dụng vừa được di trú sang DB2. Bạn có thể tính đến các mã trạng thái và các mã lỗi SQL của DB2 chi tiết để giúp một nhà phát triển trong việc gỡ lỗi. Trường hợp sử dụng này dựa vào cơ chế báo cáo lỗi của ứng dụng được hiển thị ở trên trong Hình 2 và nhờ vào việc thiết lập các ngưỡng với cơ sở dữ liệu để nó gửi các thông báo cơ sở dữ liệu cụ thể. Trong trường hợp các ngưỡng này đã bị vượt qua, DB2 Health Monitor sẽ gửi đi các thông báo email để cho biết có một vấn đề tiềm ẩn. Việc thu nhận thông tin về lỗi và hiệu năng kịp thời là rất quan trọng. Ứng dụng này đã thực hiện hai loại thông báo email sau đây trong mã PHP dùng cho mục đích này.  Gửi email cho nhóm bảo trì khi xuất hiện bất kỳ các lỗi SQL nào.  Gửi email cho nhóm bảo trì khi chạy bất kỳ trang nào kéo dài hơn 60 giây. Để bắt giữ lỗi SQL, một lớp truy cập cơ sở dữ liệu đã được triển khai thực hiện để cung cấp một loạt các phương thức thi hành tất cả truy vấn ứng dụng. Tất cả câu lệnh SQL đã được định tuyến qua lớp này và các phương thức của nó, sao cho có thể thực hiện các câu lệnh SQL bên trong một khối try/catch. Khi xuất hiện các lỗi, lớp này có thể thu thập thông tin dò vết đầy đủ và gửi thông tin đó cho nhóm bảo trì. Trong các email như vậy có các thông tin sau đây: mã lỗi và thông báo lỗi từ DB2, câu lệnh SQL được thi hành, dò vết ngăn xếp PHP và tài khoản người dùng cuối đã gọi hoạt động đó. Với thông tin này, nhóm bảo trì có thể cô lập các lỗi và giải quyết vấn đề. Liệt kê 1 cho thấy một đoạn mã của lớp truy cập cơ sở dữ liệu PHP, nơi câu lệnh SQL được thực hiện trong một giao dịch PDO và để bắt giữ bất kỳ các vấn đề nào qua một PDOException. Liệt kê 1. Mã PHP ví dụ mẫu để bẫy và báo cáo các lỗi cơ sở dữ liệu khi sử dụng PDOException <?php // Database query or update specified by the application. // $query = ... Database::beginTransaction(); try { $res = Database::getRawResource()->prepare($query); Database::$affectedRows = 0; foreach ($data as $itemData) { Database::$queryCount++; if (!$res->execute($itemData)) { throw new PDOException("Could not execute query: $query"); } Database::$affectedRows += $res->rowCount(); $res->closeCursor(); } } catch (PDOException $e) { Database::rollback(); $error = new error("Database error: " . $e->getMessage(), 0, $query); if (true == Config::get('DB', 'DIE')) { // Captures full trace error info and sends notification. $error->nicedie(); return $error; } } Database::commit(); Trong trường hợp thực hiện không tốt mã và các truy vấn, kịch bản lệnh này bắt giữ lại thời gian thực hiện với mỗi trang. Kịch bản lệnh ghi lại thời gian bắt đầu trước khi thực hiện logic nghiệp vụ chính và ghi nhận thời gian kết thúc sau khi nội dung chính được hiển thị, rồi đánh giá toàn bộ giao dịch đã mất bao lâu. Nếu giao dịch kéo dài hơn 60 giây, thì kịch bản lệnh này sẽ gửi ra thông báo email cùng với dò vết ngăn xếp PHP, các tham số được gửi cùng với yêu cầu HTTP, thông tin trình duyệt và tài khoản người dùng cuối đã gọi hoạt động này. Liệt kê 2 cho thấy kịch bản lệnh PHP có sử dụng hằng số ngưỡng cấu hình (60 giây) và gửi một thông báo đến địa chỉ email của quản trị viên đã định Liệt kê 2. Mã PHP ví dụ mẫu để bắt giữ lại thời gian thực hiện kịch bản lệnh <?php // This static function returns the current UNIX timestamp as microseconds. function getmicrotime() { list($usec, $sec) = explode(" ", microtime()); return ((float) $usec