Chúng tôi hiện đang làm việc với một yêu cầu rằng phản hồi đầu tiên từ máy chủ web phải đến dưới 200ms ở Anh. Hiện tại có dưới 2 máy chủ web chuyên dụng dưới bộ cân bằng tải và máy chủ 1 db, chúng tôi sẽ đạt tốc độ 800ms.

Trang web tại thời điểm này có ít hơn 5 khách hàng, 2 sản phẩm, 4 danh mục, không có lối vào trang web tại thời điểm này, nó là phong cách miễn phí và hình ảnh miễn phí.

Nó cũng đang được chạy trên nginx với Varnish.

Bất cứ ai có thể cho tôi lời khuyên về các thiết lập máy chủ web? Tại sao chúng ta đến chậm? Bạn có thể đề nghị gì để tối ưu hóa điều này? Cần nhanh hơn 400%!

Tôi sẽ cắn.

Đó là phản hồi đầu tiên từ máy chủ web phải đến dưới 200ms tại Vương quốc Anh
Hiện tại không có giao diện nào cho trang web, đây là phong cách miễn phí và không có hình ảnh.

Bạn sẽ không đạt được những con số đó mà không có sự trợ giúp của Varnish hoặc FPC (hoặc cả hai). Tôi chắc chắn sẽ hy vọng rằng con số đó cũng không phải bao gồm nội dung tĩnh (bất cứ khi nào bạn quyết định thêm nó) - vì gần như không thể đạt được (thiếu rất ít hoặc không có hình ảnh / js / css).

Chúng tôi đang đến ở 800ms
Nó cũng đang được chạy trên Nginx với Varnish

Bạn đã cấu hình sai Varnish.

Cài đặt Varnish được cấu hình đúng sẽ cung cấp thời gian tải trang <100ms (chúng tôi thấy gần hơn với <10ms).

Trong thực tế, đối với Magento, bạn sẽ mong đợi được thấy một cái gì đó như thế này,

Khi một khách hàng chưa đăng nhập ...
Tức là. Chưa tạo một phiên duy nhất (add-to-cart / wishlist, đăng nhập, v.v.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Khi một khách hàng đăng nhập ...
Tức là. Đã tạo một phiên duy nhất (đăng nhập, các mục trong giỏ hàng, v.v.). Tại thời điểm này, Varnish có thể sẽ tắt. Và nếu bạn đã chọn sử dụng ESI - tùy thuộc vào các cuộc gọi ngược, nó có thể duy trì thời gian tải trang tương tự như bộ đệm FPC (do tổng phí bootstrap) - hoặc thực sự tăng thời gian tải trang ngoài việc không bị chặn.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Đây không phải là trường hợp điều chỉnh Varnish - đó là trường hợp - "bạn hoàn toàn không lưu trữ bất cứ thứ gì" .

Các tập tin cấu hình máy chủ Magento lý tưởng

Không có một, tốt, không hoàn toàn.

Chúng tôi vận hành hơn 400 máy chủ, tất cả các cửa hàng Magento hoàn toàn - với quy mô và công suất khác nhau. Và rất hiếm khi các tệp cấu hình chúng ta có trên một - sẽ khớp với các tệp khác. Đó là bởi vì không phải tất cả các doanh nghiệp đều giống nhau.

Nút cổ chai có thể hình thành do nhiều lý do khác nhau:

1. Số lượng đồng thời của khách truy cập cao, với các phiên hoạt động
2. Nạn nhân của các bot 'xấu' thu thập dữ liệu, tạo ra tải cần thiết, không thể định giá
3. Tỷ lệ cao của các lượt truy cập điều hướng lớp
4. Số lượng truy vấn tìm kiếm cao
5. Khối lượng giao dịch lớn mỗi giờ
6. Mẫu kém
7. Quá nhiều phần mở rộng của bên thứ 3 quá chậm / cồng kềnh
8. Các liên kết trong nước lỗi thời dẫn đến tỷ lệ truy cập 404 cao
9. Dung lượng giao diện mạng ở mức giới hạn
10. Danh mục lớn / phức tạp (rất nhiều sản phẩm / danh mục / thuộc tính)

Vì vậy, với các cửa hàng trên toàn phổ này, mỗi cửa hàng có một cách tiếp cận khác nhau để có hiệu suất tối ưu hơn.

Để giải quyết các vấn đề nêu trên; chúng tôi sẽ cố tình tránh chỉ nêu "phần cứng nhiều hơn / tốt hơn"

1. Sử dụng FPC vượt quá Varnish
2. Lọc ra / chặn các bot xấu ở rìa mạng - hoặc chuyển hướng tất cả các yêu cầu đến Varnish bất kể trạng thái cookie / URL
3. Thay đổi điều hướng lớp chứng khoán thành SOLR, làm cho bộ lọc điều hướng lớp phụ thuộc
4. Thay đổi tìm kiếm chứng khoán thành SOLR
5. Phân phối tải MySQL trên cấu hình Master / Slave - chỉ thực hiện việc này khi bạn đã đảm bảo tải duyệt được Varnish / FPC hấp thụ
6. Xây dựng lại mẫu
7. Tước chúng ra
8. Theo dõi nhật ký truy cập liên tục và viết lại URL tại Nginx / Varnish trước khi giao hàng. Nếu thực hiện nó ở cấp Nginx - đảm bảo Varnish đang lưu trữ bộ chuyển hướng 301/302.
9. Tách nội dung tĩnh thành CDN hoặc cải thiện kết nối
10. Thêm phần cứng nữa (tốt, chúng tôi đã phải nói điều đó tại một số điểm)

Vì vậy, với suy nghĩ này - bạn sẽ thấy có lẽ sẽ không có tệp cấu hình Nginx, tệp cấu hình nhóm fcgi PHP, tệp cấu hình MySQL hoặc tệp cấu hình Varnish sẽ giống nhau. Cặp đôi với phần cứng tự thay đổi; bộ nhớ khả dụng, hiệu năng I / O (HDD và Mạng) và CPU - và bạn sẽ thấy có những biến thể tinh tế dẫn đến hiệu suất đạt được 400% mà bạn mong muốn - nhưng không ai có thể trả lời nhanh chóng trên mạng.

Bạn có thể sao chép + dán giấy trắng Magento được Peer 1 tài trợ trên peformance (chúng tôi không khuyến nghị); hy vọng rằng các cài đặt không vượt quá bộ nhớ khả dụng, giới hạn luồng, trạng thái TCP / IP, dung lượng I / O của bạn và dẫn đến hiệu suất thấp hơn so với cấu hình vanilla Apache / mod_php.

Vì vậy, hãy tiếp tục.

Ngăn xếp máy chủ Magento lý tưởng

Điều này có nhiều khả năng giúp bạn gần gũi hơn với thực tế. Một ví dụ điển hình để chứng minh điều này là cho thấy hệ điều hành Magento chuyên dụng được cấu hình như thế nào, MageStack

Lấy các thành phần phụ riêng biệt và bạn đã có một danh sách các phần mềm tối ưu / tối ưu nhất, khi được cấu hình đúng cách , để chạy một cửa hàng Magento. Đáng chú ý:

Tường lửa, bộ lọc DOS, Load Balancer, Varnish, Nginx, PHP, Redis, Memcached, MySQL

Vì vậy, khi bạn hỏi:

Thiết lập máy chủ Magento tốt nhất là gì?

Mục tiêu của bạn chính xác là gì?

1. Tính sẵn sàng cao
2. độ tin cậy
3. Đơn giản về quản trị
4. Hiệu suất
5. Khả năng mở rộng

Đủ bài giảng, chúng ta sẽ làm như thế nào

Để phản chiếu một phần các câu trả lời đưa ra trên lỗi máy chủ xuống một tĩnh mạch tương tự. Bạn đã có 3 máy chủ theo ý của bạn - vì vậy trước tiên hãy định hướng chúng một cách tối ưu nhất có thể. Chúng tôi sẽ tránh một giải pháp khả dụng cao vì nó vượt xa phạm vi của câu trả lời này.

Các thành phần phụ cần thiết cho cấu hình nhiều máy chủ là:

• Bức tường lửa
• Cân bằng tải
• Máy chủ web
• Máy chủ MySQL
• Lưu trữ chung

Vì vậy, chúng tôi sẽ đa mục đích một số hệ thống. Tuân thủ PCI-DSS quyết định vai trò của từng máy chủ. Vì vậy, với 5 vai trò và 3 máy chủ - bạn sẽ vi phạm ngay lập tức. MageStack làm tròn điều này bằng cách sử dụng ảo hóa - bạn có thể làm tương tự.

Máy chủ 1: Tải cân bằng + Máy chủ web Máy
chủ 2: Máy chủ web Máy
chủ 3: Máy chủ cơ sở dữ liệu

Không có độ trễ thấp và băng thông mạng đáng kể (> 1Gb / giây, <125 Cv), thay vì có bộ nhớ chung - tốt hơn hết là bạn chỉ lưu trữ thư mục gốc lưu trữ trên mỗi máy và sao chép dữ liệu, trong thời gian thực sử dụng ionotifyhoặc mất hiệu lực một croncông việc. Một lần nữa, chúng tôi sẽ tránh các hệ thống tệp mạng như NFS hoặc các thiết bị khối được sao chép như Gluster hoặc DRBD - vì cần phải điều chỉnh băng thông rộng và băng thông mạng tốt.

Varnish cần ngồi càng gần phía trước càng tốt. Nhưng Varnish không thể giải mã SSL. Vì vậy, kết hợp nó với một bộ kết thúc SSL; Nginx, Pound, Stunnel, Stud, v.v ... Bộ cân bằng tải tích hợp trong Varnish không tuyệt vời - nhưng sẽ phù hợp cho 2 máy chủ được thiết lập.

Nginx + PHP-FPM vẫn ổn, nhưng đừng uống quá nhiều chất hỗ trợ kool của Nginx. Nó sẽ thực hiện gần như giống hệt với cấu hình Apache / mod_php truyền thống, đây là một số cách đọc tốt về lý do tại sao không sử dụng Nginx . Nginx là tốt, nguyên vẹn rất tốt, nhưng chắc chắn nó không phải là nút cổ chai của một cửa hàng Magento - và do sự phức tạp và thiếu hỗ trợ Magento bản địa của nó. Hầu hết các quản trị viên hệ thống mới làm quen sẽ được hưởng lợi từ việc sử dụng Apache / mod_php hơn bất kỳ thứ gì khác. Điều này có vẻ giống như một đề xuất cổ xưa về việc sử dụng PHP-FPM - nhưng các thử nghiệm hiệu suất của chúng tôi đã cho thấy hiệu suất chỉ nhanh hơn ~ 7% với giải pháp Nginx - khi được định cấu hình đúng. Điều chỉnh và kinh nghiệm cần thiết cho một thiết lập Nginx / PHP-FPM hiệu suất cao, đáng tin cậy là khá lớn để giúp nó vượt trội hơn Apache / mod_php. Bất cứ điều gì bạn chọn để sử dụng, là cuộc gọi của bạn.

Máy chủ cơ sở dữ liệu rất đơn giản, MySQL. Nhưng như đã đề cập trước đó, nếu bạn có một trang web chuyển đổi cao, nên sử dụng cấu hình Master / Slave. Cho dù bạn nên làm theo phương pháp này có thể được xác định bằng cách đọc bài viết này .

Sau đó, bộ đệm back-end ngoại vi của bạn, Memcached và Redis. Trên các cửa hàng nhỏ hơn, lưu trữ phiên trong một phiên bản Memcache và bộ đệm phụ trợ nhanh trong một phiên bản khác sẽ mang lại lợi ích hiệu suất tốt. Chúng tôi không ủng hộ việc lưu trữ các thẻ bộ nhớ cache trong một phụ trợ chậm - vì nó gây ra nhiều vấn đề hơn nó mang lại. Vì vậy, với thiết lập Memcached, bạn sẽ phải bỏ qua việc gắn thẻ bộ nhớ cache . Thay vào đó, chúng tôi sử dụng một cấu hình như thế này .

Redis không có nguồn gốc từ Magento, nhưng với phần mở rộng từ Colin Mollenhour - một giải pháp tốt hơn Memcache, hỗ trợ thẻ bộ nhớ cache, lưu trữ phiên và thậm chí lưu trữ bộ nhớ cache liên tục - nó không hoàn toàn biến động như Memcache . Nhưng nó có nhược điểm của nó. Chúng tôi đã tìm thấy trên các cửa hàng sản xuất quy mô lớn (> 500 đơn hàng / giờ,> 30 nghìn đơn vị / giờ) rằng bộ đệm (và thẻ) có thể lấp đầy rất nhanh và một khi điểm bão hòa đã bị tấn công, cơ chế LRU không thành công ( mặc dù cài đặt khác nhau) và gây ra một tắc nghẽn lớn ngay lập tức. Vì vậy, nó là khôn ngoan để thường xuyên cắt tỉa hồ sơ cũ bằng tay.

Vậy phần cứng nào nên được sử dụng để làm gì?

Máy chủ web: CPU nhanh nhất, hầu hết các lõi CPU, tỷ lệ 2GB RAM / Core
DB máy chủ: CPU nhanh, I / O đĩa nhanh nhất, hầu hết RAM

Vì vậy, khi đa mục đích cho 3 máy của bạn, bố cục tốt nhất sẽ là:

Máy chủ 1: Kẻ hủy diệt SSL -> Véc ni -> Nginx / Apache>
Máy chủ PHP 2: Nginx / Apache> PHP, Redis, (Slave MySQL)
Máy chủ 3: MySQL

Theo cấu hình cụ thể của từng ứng dụng. Vâng, đó là tùy thuộc vào thông số kỹ thuật phần cứng của bạn, độ phức tạp của cửa hàng, loại và tính chất của khách truy cập và lượng khách truy cập tuyệt đối.

Bạn đang trên một con đường tuyệt vời với cấu hình cụm đó. Tôi khuyên bạn nên thêm một máy chủ bộ nhớ cache dành riêng cho Redis; chọn một cái có sức mạnh CPU cao và nhiều RAM (~ 64 GB).

Dưới đây là danh sách đầy đủ các cấu hình tôi đã sử dụng cho cụm LEMP cân bằng, có khả năng chịu lỗi, phân tán và tải trọng cao. Nó bao gồm app/etc/local.xml, core_config_databảng và cấu hình cho MySQL, php-fpm, nginx và Redis. Tất cả chạy Ubuntu 12.04 LTS 64-bit. Các cấu hình bao gồm rất nhiều tối ưu hóa mà không có nhược điểm.

Điểm nổi bật

• Quản trị viên: 46
• Thể loại: 2.450 (lớn nhất có 2.400 sản phẩm)
• Thực thể sản phẩm: 101.000
• Combo sản phẩm: 484
• Quan hệ sản phẩm: 54.000
• Trong kho và các sản phẩm có thể cấu hình được kích hoạt: 10.100
• Khối CMS: 3.100
• Trang CMS: 1.400

Giao thông tháng 8 năm 2013:

• 40 triệu lượt xem trang hàng tháng
• 2,3 triệu khách truy cập
• 46.000 thanh toán hàng tháng
• 89% du khách đến từ Hoa Kỳ

Máy chủ web

Có 10 máy chủ phía sau tường lửa phần cứng dự phòng, rất sẵn có và cân bằng tải phần cứng. Hầu hết các tài sản tĩnh được giảm tải cho CDN.

• thời gian phản hồi trung bình trên toàn trang web: 282 ms
• Phản hồi FPC trung bình: 48 ms
• tải trung bình: 0,6 đến 1 (trong các thử nghiệm, hiệu suất giảm 35% khi tải trung bình đạt ~ 5.0)
• CPU Intel Xeon kép E3-1230 V2 @ 3.30GHz (mỗi lõi 4 lõi)
• RAM 32 GB DDR3 1333 MHz

Mô-đun

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = mô hình
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMothy.git --branch = sản xuất
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Máy chủ lưu trữ

Có hai máy chủ đang chạy Redis trong cấu hình chính-phụ với chuyển đổi dự phòng tự động. Ba trường hợp Redis (phiên, phụ trợ và FPC) được sử dụng để tăng thông lượng và cung cấp tinh chỉnh các hành vi kiên trì.

• 3.000 lệnh mỗi giây
• Thời gian phản hồi trung bình 0,7 ms
• tải trung bình từ 1 đến 1,5
• CPU Quad Intel Xeon E5-2620 0 @ 2.00GHz (mỗi lõi 6 lõi)
• Bộ nhớ RAM DDR3 1333 MHz được đệm 128 GB
• Đĩa cơ, RAID 1, bộ điều khiển phần cứng

Máy chủ cơ sở dữ liệu

Có hai máy chủ đang chạy MySQL 5.6.11 trong cấu hình chính-phụ với chuyển đổi dự phòng ấm.

• 1.500 lệnh mỗi giây
• Thời gian phản hồi trung bình 1,1 ms
• tải trung bình 0,1 (chính) và 0,4 (nô lệ)
• CPU Quad Intel Xeon E7- 2860 @ 2.27GHz (mỗi lõi 10)
• Bộ nhớ RAM DDR3 1333 MHz được đệm 128 GB
• SSD, RAID 1 + 0, bộ điều khiển phần cứng
• MySQL 5.6.11 với tcmalloc

Một mẹo máy chủ khác phải có cho Magento là cài đặt PHP 5.4 hoặc 5.5 với OPcache . PHP 5.4 nhanh hơn nhiều so với 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Tôi muốn thêm một mẹo quan trọng khác là cải thiện tốc độ trang magento khi không được lưu trong bộ nhớ cache và không được bật theo mặc định (thời gian tải trang của giỏ hàng thay đổi từ 6sc thành 1,5sc).

Kích hoạt bộ đệm truy vấn mysql trong /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type cho phép nó, kích thước bộ đệm là giá trị được sử dụng bởi bộ đệm trong bộ nhớ và giới hạn bộ đệm là kích thước tối đa của kết quả truy vấn vào bộ đệm

Với cấu hình hiện tại của chúng tôi, chúng tôi sẽ nhận được phản hồi ban đầu trong 400 ms và tài liệu hoàn tất sau 2 giây (sử dụng kết nối tiêu chuẩn 5mbps). Kích thước trang chủ của chúng tôi là 1mb.

Thiết lập của chúng tôi dựa trên AWS như sau: Chúng tôi có một phiên bản ec2 với bộ cân bằng tải được kết nối với cơ sở dữ liệu RDS (có chuyển đổi dự phòng). Chúng tôi cũng đã triển khai bộ đệm toàn bộ trang với phụ trợ bộ nhớ cache redis cho cả lưu trữ bộ đệm và lưu trữ phiên.

Trung bình chúng tôi có 300 - 400 khách truy cập mỗi ngày nhưng với tính năng lưu lại bộ nhớ cache được kích hoạt, chúng tôi đã sử dụng tài nguyên ec2 tối thiểu trong khi duy trì tốc độ và giảm chi phí.

Lý do chúng tôi có bộ cân bằng tải là vì ec2 được thiết lập để tự động khởi động một phiên bản mới nếu trong trường hợp hiếm hoi chúng tôi có các lưu lượng truy cập mà thiết lập hiện tại không thể xử lý.