Kinh nghiệm thực tế trong việc mở rộng và điều chỉnh hiệu suất

Trang web tôi đang làm việc được cho là sẽ có tỷ lệ truy cập lớn ngay sau khi ra mắt . Khách hàng đang nói về khả năng khoảng 2500 lượt truy cập mỗi giây trong một ngày hoặc lâu hơn.

Bỏ qua thực tế rằng tỷ lệ trúng này có lẽ là sự lạc quan của khách hàng và ngoài việc có được các máy chủ lớn nhất có thể, cách tốt nhất mà Drupal nên được cấu hình để hỗ trợ tỷ lệ trúng lớn.

Tôi đã đọc Thu nhỏ cơ sở hạ tầng drupal.org , blog hiệu suất Drupal , Thực tiễn tốt nhất để nhân rộng Drupal và nhiều trang khác, nhưng điều tôi đang tìm kiếm là kinh nghiệm thực sự khi làm việc này, những gì hoạt động, những gì không và những gì chờ đợi.

Câu trả lời của Markdorison về cơ bản là phương pháp được chấp nhận để tấn công vấn đề này. Tôi sẽ đưa nó thêm một chút nữa.

Khi bạn có Pressflow cho D6 hoặc Drupal cho D7, Memcached và Varnish đều hoạt động tốt với nhau, bạn sẽ cần tùy chỉnh mã tệp VCL của mình . Có những cái miễn phí có sẵn để tạo điểm bắt đầu nhưng bạn luôn cần chơi với chúng.

Để làm cho Varnish hoạt động tối ưu, hãy đảm bảo bạn khởi động nó bằng -s malloc xG thay vì mặc định của tệp -s / path / to / file. Ngoài ra với Varnish có các mục tĩnh Varnish cache miễn là bạn có thể.

Nếu bạn có nhiều máy chủ web, hãy xóa ETag khỏi tiêu đề được gửi tới Varnish trong VCL. Tôi cũng loại bỏ Hết hạn và chỉ đơn giản dựa vào Tuổi và tuổi tối đa trong các tiêu đề để đưa trình duyệt quay lại trang web.

Phiên bản 1.5 (kể từ ngày 3 tháng 3 năm 2011) vẫn là phiên bản nhanh nhất của mô-đun Memcached từ Drupal.org. Tôi thường triển khai nó bằng cách sử dụng một thùng trên mỗi máy chủ để giảm lưu lượng tcp cho các kết nối đến nhiều thùng ở quy mô lớn)

Định cấu hình bộ đệm trong "Hiệu suất" thành bên ngoài và đặt tuổi tối đa sẽ gửi các tiêu đề chính xác đến proxy lưu trữ như Varnish.

Nếu bạn không thể có được một số trang nhất định để lưu trữ đúng cách trong Varnish, hãy kiểm tra các bài đăng trên blog trên web để biết chi tiết cách kiểm tra các yêu cầu. Dưới đây là một bài viết ví dụ tôi đã viết cách đây một thời gian: Điều gì đang ngăn chặn Varnish và Drupal Pressflow khỏi lưu trữ lượt xem trang người dùng ẩn danh

Bạn nên chọn InnoDB (hoặc một trong những tên khác từ các nhà cung cấp khác như XtraDB) cho MySQL và di chuyển tất cả các bảng vào đó. Sau đó kiểm tra bài đăng trên blog này để được tư vấn điều chỉnh cơ bản http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Có một vùng đệm lớn là cơ bản quan trọng. Khi tải thử nghiệm, trang web bật nhật ký truy vấn chậm. Ban đầu, bạn có thể muốn truy vấn bắt lâu hơn 50msec sau đó điều chỉnh các truy vấn và lặp đi lặp lại giảm thời gian chụp nhật ký chậm cho đến khi bạn có hầu hết các truy vấn đang chạy bằng chỉ mục và thực hiện khá nhanh.

Những điều cơ bản khác liên quan đến việc có APC trong PHP. Nếu bạn dùng CGI nhanh thay vì mod_php, hãy dành thời gian cố gắng tạo bộ đệm APC được chia sẻ trên các phiên bản php bằng cách định cấu hình tập lệnh bao bọc tốt. Ngoài ra, hãy đảm bảo rằng bộ đệm APC nằm trong tệp ánh xạ bộ nhớ để nén mọi bit cuối cùng ra khỏi PHP.

Tôi sẽ khuyên bạn nên bắt đầu với Pressflow (nếu sử dụng Drupal 6), Memcache , Varnish và một số dạng Mạng phân phối nội dung (CDN) như Akamai. Kết quả cuối cùng sẽ là càng ít trong số những người dùng đó thực sự có thể đánh vào máy chủ gốc của bạn.

Nếu bạn có các phần của trang mà bạn không thể lưu vào bộ đệm cho người dùng không ẩn danh (những thứ dành riêng cho người dùng đó, "Chào mừng người dùng X", v.v.), bạn có thể khám phá các tùy chọn để điền vào các phần của trang như không đồng bộ cuộc gọi lại hoặc cạnh bên bao gồm.

Nếu bạn có một nhóm người dùng nội bộ nhỏ hơn (chẳng hạn như một nhóm biên tập viên) cần có thể xem phiên bản chưa được quản lý của trang web, tôi khuyên bạn nên hiển thị phiên bản không được quản lý của trang web của mình tại một URL khác (được bảo vệ đằng sau VPN hoặc tương đương nếu có thể).

2500 lượt truy cập mỗi giây trong một ngày - nếu bằng cách "nhấn", bạn có nghĩa là "trang được phân phối" thì đó là 216 triệu trang mỗi ngày. Hãy để tôi nói với bạn điều này: bạn không có 216 triệu trang mỗi ngày. Tôi yêu những khách hàng này ...

Điều đó nói rằng, dữ liệu giao thông thô không nói lên điều gì. Mặc dù lời khuyên trong chủ đề này là âm thanh về Varnish / CDN nếu tất cả những gì bạn có là lưu lượng truy cập ẩn danh nhưng nếu bạn đã đăng nhập lưu lượng, bạn đang phải đối mặt với một thách thức. Nhưng trước khi dành một lượng thời gian và nỗ lực vô duyên để giải quyết vấn đề, hãy chắc chắn rằng bạn có vấn đề. 2500 lượt truy cập mỗi giây, bing nhận được ít hơn thế, bạn nhận ra điều đó, phải không?

• Phía máy chủ

  • Cài đặt Varnish cho các trang bộ nhớ đệm cho người dùng ẩn danh.
  • Cài đặt hệ thống bộ đệm liên tục (Memcached, APC, Memcache).
  • Sử dụng CDN như Akamai để phục vụ các tệp tĩnh (JavaScript, CSS, hình ảnh).

• Mặt mã

  • Sử dụng Pressflow, nó cho phép Varnish phục vụ trang được lưu trong bộ nhớ cache cho người dùng ẩn danh.
  • Làm sạch bảng giám sát của Drupal. Mỗi khi một lỗi watchdog được ghi lại, nó sẽ tiêu tốn tài nguyên CPU trên máy chủ web và máy chủ cơ sở dữ liệu. Nó cũng làm tăng thời gian tải đáng kể.
  • Thực hiện các chiến lược bộ đệm tĩnh và liên tục cho đến khi nhật ký truy vấn chậm xuất hiện.
  • Tránh các lỗi PHP xảy ra trong các vòng lặp foreach lồng nhau bằng mọi giá.
  • Gỡ cài đặt các mô-đun không sử dụng.
  • Bật bộ nhớ đệm cho các khối và khung nhìn lõi Drupal.

• Cơ sở dữ liệu

  • Hãy chắc chắn rằng các bảng được lập chỉ mục đúng để tìm kiếm nhanh hơn.
  • Không lưu trữ các bản ghi không cần thiết, cơ sở dữ liệu 100 nút sẽ luôn được truy cập nhanh hơn cơ sở dữ liệu 3 triệu nút.

Tôi cũng sẽ nghe podcast Lullabot này về cách họ thiết lập trang web Grammys.com cho một vụ nổ giao thông trong suốt một tuần. Đó là một lời giải thích giáo dục khá.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Mặc dù rất khó để dự đoán các mẫu, nếu bạn có một ý tưởng công bằng về các mức lưu lượng. Tải thử nghiệm giải pháp của bạn. Có một loạt các tùy chọn khác nhau và sẽ không thể dự đoán được cho đến khi bạn có lưu lượng truy cập trực tiếp, nhưng nếu bạn tải thử nghiệm càng nhiều càng tốt, ít nhất bạn sẽ có một mức độ tin cậy hợp lý rằng thiết lập của bạn có thể xử lý lưu lượng.

Tất cả các điều chỉnh trên thế giới sẽ không giúp đỡ nếu bạn không kiểm tra nó trước.

Đây là một bài trình bày tại DC SF về cách nhà kinh tế đã làm nó. http://sf2010.drupal.org/conference/simes/performance-testing-economist-online-USE-grinder

Đối với các trang web có lưu lượng truy cập cao, bạn nên sử dụng nhiều máy chủ và cân bằng tải hoặc sử dụng CDN đơn giản. Ngoài ra, điều rất quan trọng là lưu trữ bộ nhớ cache càng nhiều càng tốt để giảm thiểu tải trên các máy chủ web.

Sử dụng Mạng phân phối nội dung ( CDN ) giúp phân bổ tài nguyên trên một số tên miền (ngăn chặn tên miền) giúp giảm tải trên máy chủ web.

Sử dụng CDN giúp với bộ nhớ đệm phân tán và tăng tốc từ xa, cũng giúp giảm thiểu các cuộc tấn công DDoS , do có nhiều điểm cuối. Nó giúp bảo mật, bởi vì nội dung được lưu trữ sẽ khó khai thác hơn.

Nhà cung cấp ví dụ: Nhanh chóng , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Dưới đây là một số gợi ý khác:

• Với CDN, sử dụng các miền vô dụng để các thành phần tĩnh được lưu trữ (như sstatic.net ). Vì một số proxy có thể từ chối lưu trữ các thành phần được yêu cầu với cookie.
• Làm ấm bộ nhớ cache của bạn sau khi xóa bộ nhớ cache (sử dụng wget, Cache Warmer , Drush ECL ).
• Sử dụng giám sát hiệu suất (ví dụ: Relic mới hoặc Yottaa có tích hợp cho Drupal).
• Sử dụng công cụ giám sát cho trang web của bạn (ví dụ: Nagios).
• Cài đặt mô-đun tích hợp tăng tốc HTTP Varnish và Varnish , sau đó định cấu hình nó .
• Varnish + Authcache: Kiểm tra ví dụ VCL này để biết tệp cấu hình Authcache Varnish.
• Xem xét Pound hoặc NGINX trước Varnish. Xem: Tại sao Pound là tuyệt vời trước Varnish .
• NGINX có thể hoạt động như proxy ngược và cân bằng tải, vì vậy nó có thể thay thế Pound và Varnish.
• Hãy xem xét một phiên bản thương mại của Varnish hoặc NGINX để sử dụng các tính năng không có sẵn trong phiên bản nguồn mở "cộng đồng".
• Xem xét bộ cân bằng tải / bộ nhớ đệm để thay thế Varnish và Pound (ví dụ BIG-IP F5 ).
• Sử dụng các công cụ như ab, JMeter cho TTFB , tải và kiểm tra căng thẳng trên ứng dụng web của bạn.

Vì vậy, kiến ​​trúc web của bạn từ quan điểm người dùng có thể trông giống như:

1. Người dùng (bộ nhớ đệm trình duyệt cục bộ).
2. NGINX hoặc Pound + Varnish (cân bằng tải, proxy ngược như trình tăng tốc HTTP).
3. Apache (máy chủ web).
4. PHP-FPM (Trình quản lý quy trình FastCGI của PHP).
5. MariaDB (cơ sở dữ liệu).

Đối với đề xuất tối ưu hóa Drupal, hãy kiểm tra: Làm thế nào để bạn cải thiện hiệu suất của Drupal?

Cho phép hai tiện ích mở rộng:

• Zend OPcache
• wincache

Hiệu suất của bạn sẽ làm việc tốt hơn.

Nếu bạn đang tìm cách xoay Zend OPcache và Wincache trong Microsoft Azure, đầu tiên hãy tạo một tên thư mục ' ini' dưới ' D:\home\site\'. Ngoài ra, tạo 2 tệp, ' .user.ini' và ' settings.ini'

Thêm cấu hình sau vào mỗi tệp:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

cài đặt.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Ngoài ra, thêm Cài đặt ứng dụng cho Ứng dụng web của bạn bằng khóa PHP_INI_SCAN_DIR và giá trị d:\home\site\ini

Sau khi thay đổi PHP_INI_SYSTEM khởi động lại ứng dụng web của bạn. Nếu muốn biết thêm về cấu hình twigging, vui lòng kiểm tra tài liệu của Microsoft .

Sau khi cài đặt ở trên, trang web Drupal (Drupal 8.3) của tôi tải trong vòng 3 giây.

Bạn cũng có thể kiểm tra việc phân phối lại tải trên nhiều máy chủ với sự hỗ trợ của giải pháp cân bằng tải phần mềm hoặc phần cứng / phần mềm. Điều này cũng sẽ nướng trong khả năng chịu lỗi.