Thằng DNN cho phép người dùng có thể viết riêng Cache Provider của mình, thằng aspnet cũng thế, chúng ta có thể viết thoải mái. Cache hỗ trợ tăng tốc website (cái này thì rõ rồi).
Theo mô hình chúng ta thường làm web theo mô hình sau :
Data SQL -> Html (trong trang ASPX)
Nếu có cache mô hình sẽ như sau
Data SQL -> Cache -> Html
nếu trong cache tồn tại giá trị rồi thì không cần kết nối vào SQL nữa, vì thông thường để load 1 trang chúng ta dùng tương đối nhiều connection (> 3 connection). Với những đồng chí code không tối ưu số connection có thể lên đến 20 hoặc 50 conn. Tốc độ load trang sẽ rất rùa. Nếu đọc từ cache thì tốc độ load trang sẽ cải tiến hơn nhiều.
Các vấn đề cần giải quyết với cache:
- Cache manager phải tồn tại trong suốt thời gian website chạy (không thì load ra bằng niềm tin). Để tồn tại trong suốt thời gian chạy thì chỉ có biến HttpApplication là active (là sống - alive)
- Hỗ trợ các hàm cơ bản : insert, remove, clear ...
- Hỗ trợ các kiểu dữ liệu khác nhau (, nảy sinh nhiều vấn đề với thằng này)
Vấn đề kiểu dữ liệu (datatype)
Chúng ta biết rằng các kiểu dữ liệu do chúng ta định nghĩa là liên thiên. Các kiểu dữ liệu thường thấy của chúng ta là :
- UserInfo (n trường dữ liệu : Fullname, Email, Address ...)
- PostInfo (m trường : Username, PostedDate, ...)
Vấn đề đặt ra là các biến này có lưu được vào Cache không ? Xin thưa là ông Microsft (viết ASP.NET) chẳng hiểu các kiểu dữ liệu mà các bác định nghĩa nó thế nào đâu. Nên cái Cache Provider (default) của Microsoft chỉ thực sự cache các biến kiểu dữ liệu cơ bản (int, float, long, string...), tức là MS Cache default provider sẽ lưu các biến kiểu dữ liệu cơ bản (int, float, long, string...) vào đâu đó trên disk, còn các kiểu dữ liệu UserInfo, PostInfo ... (do bạn định nghĩa) nó bó tay chẳng lưu nổi vào disk đâu. Bởi vì hệ thống đek làm thế nào mà serialize được (cái này dùng để lưu ra disk). Nên kết luận đưa ra là :
Nếu Cache các kiểu dữ liệu do người dùng định nghĩa thì thực tế là không cache.
Tức là không tồn tại mô hình này :
- Data SQL -> Cache -> Html
Nó chỉ thực hiện cái này
- Data SQL -> Html
Cái này em tìm ra do thực nghiệm (debug) tại function connection vào SQL sau khi đã đặt cache, trong mỗi lần load trang, lần nào em cũng thấy cái query vào DB thực hiện, tức là chả cache keo được cái gì nếu chúng ta cố cache Custom Class Definition. Nhục nhục! Nên nếu bác nào cache thì cache các biến cơ bản thôi nhé.
Vấn đề Live long (sử dụng HttpApplicationState)
Cái cache manager phải sống đủ dài, chứ không thì hệ thống đọc = niềm tin, lại phải connect vào DB tốc độ trang lại rùa. Vấn đề chính ở đây là nếu lưu vào ApplicationState thì 1 biến của bạn thực tế có độ lớn bao nhiêu và kiểu dữ liệu là gì? thực tế cache xong thì hệ thống có chạy nhanh hơn không ? Nó chiếm bao nhiêu RAM ? vì thực tế ApplicationState là lưu trong RAM.
Dùng ApplicationState có 1 cái dở nếu lưu nhiều quá mà IIS Application Pool của bạn được phân bé quá (sảy ra khi thuê host sinh viên giá rẻ) thì bạn sẽ bị lỗi :
Server too bussy
Chẳng làm được việc gì khác. Cho nên mình đã cố tự làm 1 cái serialize cho các loại DataType + code thêm Cache Provider Manager để làm cái việc write các Custom Class ra file text. Nhưng cũng chẳng ăn thua vì lỗi Server too bussy.
Như vậy hệ thống của Microsoft viết Cache giúp chúng ta 1 số chức năng :
- Tránh tràn Application Pool
- Chỉ serialize (ghi ra file) những biến tương đối nhỏ. Tối ưu hóa về bộ nhớ, nếu tràn MS Cache cho phép tự động xóa 1 số biến. Cái này giúp các hệ thống của MS không bị treo hay phát sinh những lỗi kỳ quặc.
Các hệ thống tự viết được cái nhanh thì lại ngốn RAM nhiều, không có khả năng triển khai một cách linh động.
