Di chuyển một ứng dụng PHP từ MySQL sang DB2 - Phần 3: Chuyển đổi mã PHP của bạn

húng trông giống như một sơ đồ 
trường hợp sử dụng. Sự khác biệt so với một mô hình trường hợp sử dụng tĩnh là các bài kiểm 
thử thường được lưu trữ theo một định dạng bảng tính cùng với các ảnh chụp màn hình và các 
bảng có các hàng có thể cập nhật được, ở đó một người kiểm thử có thể nhập một loạt các bước 
cụ thể hay các bước riêng lẻ cho dù có thành công hoặc thất bại. Bảng 1 cho thấy một ví dụ về 
định dạng của trường hợp kiểm thử chấp nhận bởi người dùng để xác minh xem việc tạo nhiệm 
vụ đó đã làm việc như đã mong đợi chưa. 
Bảng 1. Bài kiểm thử chấp nhận bởi người dùng mẫu 
 Test Expected result Passed? 
1. Tạo một 
nhiệm vụ mới 
1.1 Đăng nhập vào hệ 
thống. Trang chào đón được hiển thị. Có 
1.2 Mở trang nhiệm vụ 
mới. Tải biểu mẫu nhiệm vụ mới. Có 
1.3 Điền vào biểu mẫu 
và lưu trữ. 
Hiển thị thông báo thành công và liên kết 
của ID duy nhất của nhiệm vụ. Có 
2. Phê duyệt 
nhiệm vụ 
2.1 Log into the 
system. Trang chào đón được hiển thị. Có 
2.2 Đăng nhập vào hệ 
thống. Danh sách các tải công việc. Có 
2.3 Định vị danh sách 
các nhiệm vụ. Hiển thị thông báo thành công và gửi email. Không 
Hãy ghi nhớ rằng điều cực kỳ quan trọng là những người kiểm thử của bạn dành đủ thời gian để 
thực hiện các bài kiểm thử chấp nhận bởi người dùng và ghi lại bất kỳ vấn đề nào. Nếu họ chỉ 
đọc lướt các bài kiểm thử, họ có thể bỏ sót các lỗi. Cũng với lý do tương tự, điều quan trọng là 
lập sổ ghi ai đã kiểm thử vào lúc nào và các kết quả họ đã báo cáo là gì để thực thi trách nhiệm 
giải trình. 
Bài kiểm thử đơn vị và sửa lỗi 
Bước này đòi hỏi phân tích có hệ thống các vấn đề do những người kiểm thử chấp nhận bởi 
người dùng báo cáo. Khi nhận được các bài kiểm thử chấp nhận bởi người dùng từ những người 
kiểm thử, cần giao cho cá nhân các nhà phát triển những vấn đề đã được báo cáo để xác nhận và 
sửa chữa. Ví dụ, bài kiểm thử 2.3 trong Bảng 1 sẽ được quy như là một lỗi mới. 
Khi bạn di trú hệ thống theo cách lặp nhiều lần, các nhà phát triển cần so sánh chức năng đã di 
trú vào DB2 với hệ thống nguồn MySQL ban đầu để đảm bảo rằng các đơn vị công việc cụ thể 
được thực hiện như mong đợi. Với các bài kiểm thử chấp nhận bởi người dùng, sẽ rất có giá trị 
nếu tự động hóa quá trình này bằng cách sử dụng một khung công tác kiểm thử đơn vị, ví dụ như 
PHPUnit. Vì cơ sở mã ví dụ không được phân chia đúng thành mã MVC, thích hợp với dễ kiểm 
thử theo chương trình, nên bài kiểm thử đơn vị tự động hóa hoặc hệ thống tích hợp liên tục 
không được sử dụng. 
Chụp một ảnh để dùng làm vạch chuẩn 
Sau khi phần chính của các trường hợp sử dụng đã hoàn thành, bước cuối cùng trước khi bắt đầu 
một vòng lặp kiểm thử mới là chụp ảnh hiện trạng hệ thống làm một bản sao lưu và một vạch 
chuẩn để tham chiếu lại khi kiểm tra xác nhận hoạt động và hiệu năng. Một lần nữa, mỗi khi các 
vòng lặp thay đổi đạt đến một mốc ổn định, điều quan trọng là chụp ảnh các bản sao lưu. Ảnh 
này có thể là dạng tệp truyền thống và các bản sao lưu SQL hoặc có thể là dạng các ảnh hoàn 
chỉnh của hệ điều hành. Điều rất quan trọng nữa là duy trì các điểm lưu trữ này trong trường hợp 
có một lỗi trong tương lai hoặc để sử dụng làm một vạch chuẩn so sánh. 
Về đầu trang 
Bước 4: Giải quyết nút nghẽn cổ chai và xác nhận dựa vào vạch chuẩn chức năng 
Một khi tập hoàn chỉnh các bài kiểm thử chấp nhận bởi người dùng đã được các bên liên quan 
của bạn ký duyệt, đây là lúc để cải thiện hiệu năng của hệ thống. Bước này đòi hỏi hoàn thành 
các bước sau đây: 
 Xác nhận các bài kiểm thử chấp nhận bởi người dùng (UAT) là vạch chuẩn. 
 Sử dụng các công cụ để sửa chữa các vấn đề hiệu năng trong DB2. 
 Xác định vị trí và giải quyết các nút nghẽn cổ chai trong hệ điều hành. 
Xác nhận các bài kiểm thử UAT vạch chuẩn 
Với bước chuẩn bị này, điều quan trọng cần nhắc lại là bạn cần có một khung nhìn rõ ràng về 
chức năng hệ thống đã xác nhận sao cho bạn biết liệu có bất kỳ yêu cầu cải tiến phi chức năng 
nào không, ví dụ như các cải tiến hiệu năng, có ảnh hưởng tốt hoặc phải đánh đổi bằng các yêu 
cầu chức năng đã thống nhất. Bước này nên diễn ra sau khi kiểm tra xác nhận chức năng vì hai lý 
do. Đầu tiên, nó đảm bảo rằng bạn có một vạch chuẩn chức năng đã được ký duyệt, đã được biết 
rõ trước khi thực hiện bất kỳ các thay đổi phi chức năng nào. Thứ hai, nó giúp bạn tránh các cạm 
bẫy của việc tối ưu hóa vội vàng trong việc di trú của bạn. Bạn có thể biết rằng một truy vấn 
hoặc cách tiếp cận nào đó nhanh hơn trong một trường hợp, nhưng bạn không nên áp dụng một 
cách mù quáng một sự thay đổi trên toàn bộ cơ sở mã, đặc biệt là khi không có dấu hiệu nào cho 
thấy có một vấn đề hiệu năng. 
Lấy ví dụ, một lịch sử các bài kiểm thử chấp nhận bởi người dùng đã được lưu giữ để xác nhận 
liệu có gì đó đã được kiểm thử và thành công trước đó chưa để dùng kiểm tra các vấn đề hồi quy 
nếu chúng xuất hiện sau này. 
Sử dụng các công cụ để sửa chữa các vấn đề hiệu năng trong DB2 
Những mối hiểm họa của việc tối ưu hóa vội vàng 
Có khả năng bạn đã nghe nói về nhận xét của Donald Knuth vào năm 1974 rằng "việc tối ưu hóa 
vội vàng là gốc rễ của mọi tội lỗi". Một ví dụ về các cạm bẫy của vấn đề này xuất phát từ kinh 
nghiệm của một trong những tác giả của loạt bài này (chúng tôi không nêu rõ tên người phạm 
lỗi!). Khi ông đã biết rằng các chuỗi ký tự dùng dấu nháy đơn thực hiện tốt hơn so với các chuỗi 
ký tự dùng dấu nháy kép (do thực tế là các biến nội suy không bị thay thế khi được bọc trong các 
dấu nháy đơn), ông đã quyết định có lẽ thật tốt để thay thế tất cả các dấu nháy kép bằng các dấu 
nháy đơn. Ông đã không có lý do nào để nghĩ rằng ứng dụng này đã đang có các vấn đề hiệu 
năng, nên ông đã thực hiện những gì ông nghĩ là tìm kiếm và thay thế cẩn thận hơn. Thật không 
may, ông đã bỏ sót một hoặc hai chuỗi nội suy và đưa vào một lỗi rất khó phát hiện, đã gây ra 
các vấn đề toàn vẹn dữ liệu trong tương lai. Tuy nhiên, chúng tôi đã tha lỗi cho ông. 
Việc kiểm thử của bạn vào thời điểm này nên tập trung chủ yếu vào những gì DB2 có thể sửa 
chữa tự động cho bạn, vì DB2 là sự thay đổi lớn nhất mà bạn đưa vào. Khi bạn thay đổi mã, bài 
kiểm thử đơn vị và thực hiện kiểm thử chấp nhận bởi người dùng (UAT), bạn nên xác định các 
nút nghẽn cổ chai và thực hiện các thay đổi khi cần. Một triết lý quan trọng cần làm theo là chỉ 
thay đổi những điều đã biết là có vấn đề thông qua bài kiểm thử đơn vị và việc kiểm tra UAT còn 
hơn là thực hiện các giả định về các nguồn tiềm năng của các vấn đề hiệu năng. Sau khi thực 
hiện điều này, bạn có thể cung cấp những gì đã được thay đổi và ghi lại nó để các ứng dụng 
tương lai chống lại các lỗi sau này. 
Có một sự cân bằng mong manh giữa việc tối ưu hóa vội vàng và áp dụng các bản sửa lỗi trên 
diện rộng dựa vào một danh sách các hướng dẫn thực hành tốt nhất. Đây sẽ là một quá trình lặp 
lại trong suốt vòng đời của ứng dụng. Xem phần bên về các mối hiểm họa của việc tối ưu hóa vội 
vàng. 
Một kỹ thuật mà bạn có thể thấy có ích là thực hiện một hàm, giám sát các kịch bản lệnh chạy 
quá 60 giây và gửi một báo cáo lỗi, như đã được thực hiện cho ứng dụng ví dụ PTT. Một ví dụ 
của hàm này được mô tả trong phần 4 của loạt bài này. 
Dựa vào thông tin có sẵn trong báo cáo đó, bạn có thể phát hiện ra là liệu có vấn đề phát sinh ra 
từ một kết quả của việc thực hiện PHP chậm hay một truy vấn chậm không. Với các vấn đề về 
PHP, một trình gỡ lỗi như trình gỡ lỗi có sẵn trong Zend Studio hoặc Eclipse PDT có thể giúp 
bạn định vị các vấn đề. Với các vấn đề truy vấn, bạn có thể sử dụng IBM Data Studio để định vị 
các vấn đề và đề xuất sửa chữa. Hình 2 cho thấy một ví dụ của biểu đồ kế hoạch truy cập cho 
một truy vấn cụ thể. 
Hình 2. Tinh chỉnh một truy vấn trong IBM Data Studio 
Định vị và giải quyết các nút nghẽn cổ chai trong hệ điều hành 
Nếu bạn đã chắc DB2 và PHP không phải là nguồn gốc của các vấn đề hiệu năng của ứng dụng 
của bạn, thì bạn nên định vị lặp lại nhiều lần các nút nghẽn cổ chai khác bằng cách sử dụng các 
hướng dẫn thực hành tốt nhất về thử - và - đúng được mô tả trong "Các mẫu PHP mức doanh 
nghiệp của Zend" của John Coggeshall (xem phần Tài nguyên). Tóm lại, bạn có thể bắt đầu xem 
xét ba nguồn gốc phổ biến của các nút nghẽn cổ chai của ứng dụng để xem xem bạn có thể giải 
quyết bất kỳ các vấn đề hiệu năng nào không thông qua việc nâng cấp phần cứng đơn giản hoặc 
bằng cách điều chỉnh các tài nguyên được phân phối cho một máy ảo: 
 CPU 
 Bộ nhớ 
 Đĩa 
Trong khi nhiều công cụ được sử dụng để xác định các nút nghẽn cổ chai trong cuốn sách của 
Zend áp dụng cho các hệ điều hành Linux, thì nhiều kỹ thuật có thể đạt được với các công cụ đặc 
trưng của Windows khi bạn đang phát triển hoặc sau khi bạn triển khai ứng dụng đã cập nhật của 
bạn tới một máy chủ thử nghiệm hay máy chủ tạm và tiếp tục lại sau khi triển khai. 
Về đầu trang 
Bước 5. Đánh giá vạch chuẩn về di trú mã 
Sau một vòng lặp toàn bộ các bước 1 đến 4, mà mỗi bước trong đó lại gồm vài bước chuyển, bạn 
sẽ có một hệ thống cơ sở dữ liệu hoạt động được trên một máy trạm Windows và vài ghi nhớ về 
những gì bạn đã thay đổi và những gì đã có vấn đề. Nếu bạn đã sử dụng các máy ảo, bạn có thể 
chụp một hình ảnh của hệ thống Windows như một ảnh chụp màn hình, vừa để lưu trữ làm một 
điểm ghi lưu thực hiện chức năng và vừa để sử dụng làm một vạch cơ sở để so sánh với các thay 
đổi hiệu năng trong tương lai. Tất nhiên, có một tùy chọn khác là sử dụng một ảnh ảo trong Đám 
mây của IBM hay của Amazon và sử dụng đám mây theo cùng cách. Bạn có thể muốn thử 
nghiệm với vài bản cập nhật mã khác nhau để xem xét những gì làm việc tốt nhất cho môi trường 
của bạn. 
Một khi bạn đã cảm thấy hài lòng với hệ thống trên máy trạm Windows được sử dụng trong các 
bước 1-4, bạn có thể gắn thẻ cho mã đã chuyển đổi của bạn như một phát hành trong hệ thống 
kiểm soát phiên bản của bạn và chuẩn bị cơ sở hạ tầng cho các bước cuối cùng trước khi triển 
khai như mô tả trong phần 4 của loạt bài này.