Bạn đang bước vào một thế giới tối ưu hóa rộng lớn ở đây và chắc chắn không có một kích thước nào phù hợp với mọi phương pháp.
Xác định hiệu suất
Bạn có nghĩa là thời gian tải trang cho một người dùng, hoặc tổng dung lượng / tổng đồng thời? Hai là rất khác nhau rõ ràng - và không liên quan chặt chẽ. Hoàn toàn có thể có một cửa hàng nhanh với khả năng hạn chế; hoặc một cửa hàng chậm với nhiều công suất.
Vì vậy, khi giải quyết một trong hai loại hiệu suất:
- Thời gian tải trang cảm nhận của một người dùng
- Tổng công suất / đồng thời
Bạn phải giải quyết từng vấn đề một cách độc lập bằng các giải pháp riêng - đặc biệt là mỗi giải pháp đều có những điểm nghẽn riêng.
Hãy đưa ra giả định rằng bạn đang ở với một máy chủ có thẩm quyền đã cấu hình tối ưu các khía cạnh khác của máy chủ cho cửa hàng của bạn.
Thời gian tải trang cảm nhận của một người dùng
Có phải MySQL là nút cổ chai
số Không trực tiếp. Đó là tất cả về độ trễ, trong phần lớn các trường hợp khi kiểm tra thời gian tải trang - chỉ bộ nhớ cache sẽ bị tấn công. Vì vậy, chìa khóa ở đây là để giảm thiểu độ trễ.
- Điều chỉnh kích thước bộ đệm của MySQL một cách thích hợp (không có câu trả lời đúng, chúng tôi điều chỉnh các cài đặt hoàn toàn khác nhau, hàng tháng, trên mỗi cửa hàng)
- Giảm độ trễ mạng. Đối với khung 64 byte; 51,2 Lời đề nghị cho 10Mb / giây, 5,12 Chuyển đổi cho 100Mb / giây và 4,096 Lát cho 1Gb / giây. Điều này giúp cải thiện 20% chỉ bằng cách chuyển từ 100Mbps sang 1Gbps. s1
- Tăng dung lượng mạng. Bạn sẽ ngạc nhiên khi nhiều megabyte mỗi giây được trao đổi giữa máy chủ Web và DB, thường vượt quá 10MB / s - vì vậy cần tối thiểu 100Mb / giây s1 . Hoặc, chỉ cần di chuyển máy chủ DB cục bộ.
- Sử dụng SOLR. Các công cụ bên ngoài đôi khi phù hợp hơn, chắc chắn SOLR nhanh hơn cho các danh mục LARGER (và tôi nhấn mạnh, các danh mục lớn hơn ). Ngay cả SOLR không được điều chỉnh sẽ tạo ra điều hướng lớp và kết quả tìm kiếm nhanh hơn MySQL có thể.
Nhưng những thay đổi này sẽ có tác động phân đoạn như vậy đối với thời gian tải trang - nơi mà nút cổ chai thực sự ở nơi khác.
- Điều chỉnh ứng dụng. Magento có một số lỗi khá lớn với cách nó xây dựng các bộ sưu tập và lưu trữ chúng; chúng tôi đã gặp một số vấn đề về mã lõi lớn có thể làm tê liệt hiệu năng. Trong một số trường hợp, chỉ cần xóa màn hình đếm sản phẩm trên kết quả điều hướng được xếp lớp đã cạo 2 giây khi tải một bộ sưu tập lớn.
- Xem lại nhật ký chậm của MySQL. Kiểm tra các truy vấn chậm và thêm các chỉ mục khi cần thiết. Sự khác biệt giữa việc chạy một truy vấn phức tạp có nhiều phép nối có và không có chỉ mục thích hợp có thể là hàng chục giây .
Ứng dụng này là nút cổ chai. Không phải phần mềm. Vì vậy, chỉ cần cải thiện mã lõi hoặc làm cho mẫu của bạn bớt nặng hơn sẽ có hiệu quả rõ rệt hơn về hiệu suất so với BẤT K change thay đổi cấu hình MySQL nào.
Chúng ta sẽ không bận tâm điều gì
- Thay đổi công cụ lưu trữ. MariaDB và Percona chia sẻ cùng một công cụ InnoDB - Percona XtraDB. Họ có thể được coi là một và giống nhau. Về mặt thời gian thực hiện truy vấn duy nhất - hiệu suất sẽ phản ánh chính xác một bản dựng vanilla MySQL. Điều này đi vào chơi dưới tải / đồng thời.
- Chạy một nô lệ MySQL. Điều này sẽ không cải thiện hiệu suất trừ khi nô lệ được đặt gần hơn về mặt vật lý (từ góc độ mạng) hoặc nô lệ có phần cứng tốt hơn so với máy chủ. Điều này đi vào chơi dưới tải / đồng thời.
- Chạy một máy chủ DB bên ngoài. Đây là lời khuyên tồi tệ nhất mà chúng tôi thấy nhiều lần được đưa ra bởi nhiều máy chủ / cơ quan. Cho đến khi bạn đạt được mức trần về phần cứng / tài nguyên hoặc bạn đã có nhiều máy chủ web (đọc: tính sẵn sàng cao), MySQL trên máy cục bộ cho cửa hàng Magento là Ý tưởng hay. Nó cắt bỏ tất cả các chi phí và độ trễ mạng. Ngay cả mạng 100Gb / giây (vâng, một trăm gigabit mỗi giây) sẽ không so sánh với ổ cắm unix cục bộ về khối lượng thô, thông lượng và độ trễ.
s1 Chỉ dành cho máy chủ cơ sở dữ liệu riêng biệt. Không áp dụng cho các máy chủ DB cục bộ.
Tổng công suất / đồng thời
Có phải MySQL là nút cổ chai
Có lẽ. Nhưng chỉ khi bạn đóng đinh hiệu năng và năng lực PHP của bạn đến mức MySQL làm mọi thứ chậm lại. Nếu bạn có Varnish và FPC được cấu hình đúng cách (đừng để chúng tôi bắt đầu với bao nhiêu lần thử thất bại mà chúng tôi đã thấy) - thì MySQL sẽ trở thành một nút cổ chai.
Vì vậy, ngoài các sửa đổi trên.
- Thay đổi công cụ MySQL. XtraDB có thể vượt trội khi tải và không hiển thị lợi ích thực sự trên bản phân phối MySQL chứng khoán.
- Luôn cập nhật với MySQL. 5.5 thực hiện tốt hơn 5.0 dưới tải.
- Thay đổi trình điều khiển PHP MySQL. PHP 5.3 và mới hơn có trình điều khiển MySQL gốc, nhưng trong một số trường hợp, chúng tôi đã tìm thấy PHP 5.2 với trình điều khiển riêng để vượt trội hơn MySQLND cho Magento. Tự kiểm tra
- Thay đổi công cụ tìm kiếm. Chuyển tìm kiếm ra SOLR / Sphinx (hoặc thậm chí một số dịch vụ bên ngoài của bên thứ 3) thực sự có thể giảm bớt gánh nặng của tải không giao dịch (ví dụ: mọi người không đặt hàng)
- Thay đổi lớp điều hướng động cơ. Một lần nữa, SOLR là một công cụ tuyệt vời để điều hướng theo lớp và do tính chất không khóa của nó nhanh hơn nhiều so với MySQL.
- Thêm một nô lệ MySQL. Điều này giúp tải trình duyệt (không giao dịch), nhưng sẽ không giúp bạn xử lý nhiều đơn hàng hơn mỗi giờ - vì nó phụ thuộc vào Master để xử lý và sao chép dữ liệu này
Chúng ta sẽ không bận tâm điều gì
- Sư phụ sư phụ. Do điểm bão hòa phần cứng khá cao của thiết lập Master / Slave (vượt quá 1000 đơn hàng mỗi giờ) - chúng tôi chưa bao giờ thấy yêu cầu sử dụng Master / Master trong sản xuất. Chúng tôi đã thực hiện thử nghiệm rộng rãi, nhưng chưa bao giờ thấy nó có lợi thế từ góc độ hiệu suất và với các rủi ro và vấn đề cố hữu của Master / Master, đơn giản là nó không đáng.
Đọc so với khả năng mở rộng
Đoạn cuối thực sự dẫn đến một lĩnh vực chính là khả năng mở rộng đọc và viết. Đọc tỷ lệ có thể được thực hiện khá vô hạn mà không có quá nhiều phức tạp với việc thêm ngày càng nhiều nô lệ.
Với tỷ lệ Đọc trên Writes của Magento là khoảng 0,1% - việc xem xét việc viết không nên quan tâm nhiều. Đó là lý do tại sao tôi không bận tâm đến việc đề cập đến MySQL Cluster và các tính năng thông minh của nó như tự động tắt (tách bảng thành các máy riêng biệt).
Phần cứng, phần cứng, phần cứng
Phần cứng dễ dàng là câu trả lời nhanh nhất khi nói đến cải tiến, vì vậy tôi đã cố tình không đề cập đến nó ở trên trong cả hai kịch bản.
Nhưng tất cả các thay đổi phần mềm trên thế giới sẽ không tạo ra bất kỳ sự khác biệt nào nếu phần cứng cơ bản của bạn không đủ. Điều đó có nghĩa là ...
- Công tắc chất lượng thấp với bộ đệm hạn chế
- Liên kết mạng quá bão hòa
- Máy chủ địa lý xa
- QoS / CoS mạng kém
- Tổng dung lượng RAM có hạn
- RAM băng thông bộ nhớ thấp
- Hệ thống con IOPs thấp
- Bộ điều khiển RAID phần mềm
- CPU tốc độ xung nhịp thấp
- Chipset băng thông thấp
- Ảo hóa phần cứng (hầu hết tất cả các loại ngoài Ảo hóa cấp hạt nhân)
Ngày nay, có một mức trần thực sự cao về mức độ bạn thực sự có thể mở rộng quy mô trên phần cứng. Hãy bỏ qua huyền thoại về quy mô vô hạn "trong đám mây" vì phần cứng đám mây có xu hướng khá tầm thường. Ví dụ, các mô hình hàng đầu của Amazon chỉ là 12 lõi @ 3,3 GHz. Nhưng bên ngoài điều này, có một số máy chủ rất mạnh có sẵn - máy chủ hàng đầu của chúng tôi có 160 lõi và 2TB (vâng, Terabyte) RAM. Chúng tôi chưa thấy ai vượt quá khả năng đó.
Vì vậy, bạn đã có một phạm vi rộng cho tỷ lệ dọc, thậm chí trước khi bạn cần xem xét tỷ lệ ngang.
Mục tiêu luôn chuyển động
Điều đáng nói của nó là trong quá trình theo đuổi hiệu suất, nút cổ chai sẽ luôn luôn di chuyển.
Đối với một cửa hàng Magento chứng khoán.
Bật bộ nhớ cache trên. PHP là nút cổ chai
Thêm bộ đệm phụ trợ. PHP là nút cổ chai
Thêm bộ đệm toàn trang ở cấp ứng dụng. PHP là nút cổ chai
Thêm bộ đệm phía trước cấp máy chủ (ví dụ: Varnish). MySQL là nút cổ chai
Thêm một công cụ điều hướng tìm kiếm / lớp thay thế (ví dụ: SOLR / Sphinx). PHP là nút cổ chai
Thêm nhiều máy chủ ứng dụng. MySQL là nút cổ chai
Thêm một nô lệ MySQL. Bộ đệm
phía trước là nút cổ chai Thêm nhiều máy chủ bộ đệm phía trước. PHP là nút cổ chai
Thêm nhiều máy chủ ứng dụng. SOLR / Sphinx là nút cổ chai
Etcetera.
Nó khá nhiều trở thành một trường hợp rửa lặp lại. Nhưng điều dễ hiểu là MySQL chắc chắn không phải là cổng đầu tiên để tối ưu hóa - và thực sự chỉ phát huy tác dụng khi MySQL tiêu thụ nhiều CPU hơn theo tỷ lệ với PHP - và điều này CHỈ xảy ra khi cả FPC và Varnish đang sử dụng và (các) máy chủ hoàn toàn xử lý các đơn đặt hàng và không có gì khác (vì mọi thứ khác đều nằm trong bộ đệm).
Đừng thay đổi một cách mù quáng
Đơn giản chỉ cần thêm một nô lệ MySQL bởi vì bạn đọc chúng tôi nói ở trên rằng nó sẽ giúp ích, có thể khiến bạn mất hiệu suất và độ tin cậy ở mức rất lớn. Mạng bị tắc nghẽn, máy chủ nô lệ thông số thấp hoặc thậm chí cài đặt không phù hợp có thể gây ra sự cố sao chép có thể khiến cửa hàng của bạn chậm hơn so với trước - hoặc gây ra sự cố đồng bộ hóa giữa Master và Slave.
Để đưa mọi thứ vào quan điểm - một số ví dụ thực tế.
Ví dụ 1 - 300 đơn hàng mỗi giờ
Chúng tôi đã sử dụng phần cứng sau đây để phục vụ 300 đơn hàng mỗi giờ ; và chỉ tại điểm tới hạn đó - sau đó chúng tôi cảm thấy cần phải thêm một máy chủ MySQL chuyên dụng và một nô lệ MySQL cục bộ.
1
CPU máy chủ : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k SSD IOP / s
RAID: RAID phần cứng 10
Phiên bản Magento: Magento EE
Hệ điều hành: MageStack
Trong toàn bộ thời gian, trung bình tải vẫn dưới 3.00.
Ví dụ 2 - 180 đơn hàng mỗi giờ
Chỉ hai ngày trước, một khách hàng mới của chúng tôi dễ dàng tăng vọt lưu lượng truy cập lớn. Xử lý 180 đơn hàng mỗi giờ với một máy chủ và Magento Community Edition .
1
CPU máy chủ : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k SSD IOP / s
RAID: RAID phần cứng 10
Phiên bản Magento: Magento CE
OS: MageStack
Trang web: Wellgosh.com
Trong toàn bộ thời gian, trung bình tải vẫn dưới 6,00. Tải trọng cao hơn trong kịch bản này và điều đó đã giảm xuống một vài yếu tố.
- Không có điều chỉnh phía cửa hàng nào được thực hiện như trong ví dụ 1
- Việc thiếu một FPC cấp ứng dụng
Và với sự chính xác của điều này, chúng tôi vẫn có số liệu thống kê chi tiết để đưa ra một số phản hồi bằng các biểu đồ. Chúng kể một câu chuyện tuyệt vời về cách phân phối tải giữa các thành phần chính của kiến trúc Magento riêng biệt (bộ cân bằng tải, máy chủ web, máy chủ db, v.v. - sử dụng MageStack ).
Vì vậy, từ trước ra sau ... ngày bạn muốn xem là lúc 12:00 sáng ngày 22 tháng 2.
Gói tường lửa
Giao thông mờ
Giao thông Nginx
Tải MySQL
Tải CPU
Và quan trọng nhất là phân phối tải
Hình ảnh này thực sự nói lên tất cả. Và đó là MySQL chắc chắn không phải là một gánh nặng - ít nhất là chưa. Vì vậy, lời khuyên của chúng tôi, tập trung vào mối quan tâm hiệu suất của bạn ở nơi khác, trừ khi bạn đang xử lý hơn vài nghìn đơn hàng mỗi giờ.
Và tóm lại
Thực hiện thay đổi hiệu suất không phải là "một kích thước phù hợp với tất cả". Đó là một trường hợp phân tích các tắc nghẽn hiện tại của bạn và thực hiện các thay đổi / điều chỉnh tinh tế cho phù hợp với cửa hàng và cơ sở hạ tầng của bạn.
Nhưng hiệu quả sang một bên, có những lợi ích khác khi sử dụng Percona
Chúng tôi sử dụng Percona XtraDB, gần như độc quyền. Chúng tôi chạy các bản dựng được biên dịch tùy chỉnh của MySQL mà chúng tôi đã phát triển riêng cho Magento và đã tham khảo Percona trong quá trình này. Nhưng đó không chỉ là hiệu suất ảnh hưởng đến sự lựa chọn này.
- Bộ công cụ Percona
- pt-truy vấn-tiêu hóa
- xtrabackup
- v.v.
- Tần số phát hành Percona
- Hỗ trợ tư vấn của Percona
- Khởi động lại bộ đệm ấm với bảo quản hồ bơi InnoDB
Và nhiều hơn nữa. Vì vậy, sử dụng nó trên MySQL có những lợi thế khác ngoài hiệu năng. Trong thực tế - MySQL là và luôn là mối quan tâm tối thiểu của chúng tôi trong việc theo đuổi hiệu suất và sự ổn định.
Các bản phân phối: wellgosh.com , sonassi.com , iebmedia.com .