Tôi có thể xử lý bao nhiêu yêu cầu trong Laravel?

Tôi đã xây dựng một số trang web tin tức trực tiếp một hoặc hai năm trước. Chúng tôi đã có khoảng 10. 000 người dùng trực tuyến cùng một lúc, tiêu thụ các bài báo của chúng tôi [những bài báo đó được đẩy đến tất cả người dùng ngay lập tức]. Tôi đã học được rất nhiều trong thời gian đó. Đây là một dự án lớn, ngay cả các tệp tĩnh [chủ yếu là hình ảnh] cũng trở thành một vấn đề. Lighttpd/Nginx vừa bị lỗi ở cấu hình tiêu chuẩn. Nói về băng thông 3-5Gbit/s tại đây

Cập nhật lần cuối 8 tháng trước

Xin chào, tôi không nghĩ rằng bạn sẽ tìm thấy bất kỳ khung công tác php nào có thể xử lý loại tải đó mà không được lưu trong bộ nhớ cache, nhưng Laravel chắc chắn sẽ không có hiệu suất kém hơn Wordpress

Thông thường, bạn sẽ muốn bộ đệm càng gần người dùng càng tốt, điều đó có nghĩa là

• Sử dụng CDN càng nhiều càng tốt. Một số trang web [như etsy. com] thực sự trỏ tên miền chính của họ tới CDN của họ
• Sử dụng một cái gì đó như Varnish cho mọi thứ khác. Ngay cả nội dung mới thường có thể được lưu vào bộ nhớ cache trong ít nhất vài giây
• Phương sách cuối cùng là lưu trữ các yêu cầu db

Tôi làm việc trên một mạng trang web có tải trọng tương tự và chúng tôi sử dụng Laravel mà không gặp bất kỳ sự cố nào về hiệu suất

Cập nhật lần cuối 8 tháng trước

Cảm ơn, tôi sẽ xuất bản kinh nghiệm của tôi ở đây. Dự án đã được bắt đầu

Cập nhật lần cuối 8 tháng trước

Cảm ơn trước, sẽ rất tuyệt nếu bạn chia sẻ một số thông tin chuyên sâu về tối ưu hóa và các quyết định mà bạn sẽ đưa ra trong quá trình này. Chúc may mắn. ;]

Cập nhật lần cuối 8 tháng trước

Dự án có hoạt động không?

Cũng cần lưu ý rằng khi ai đó trả lời tin nhắn, điều đó có thể sẽ kích hoạt một nhóm tin nhắn mới tới số đó [và webhook]. Vì vậy, một tin nhắn có thể tạo tối đa hơn 4 bản ghi

Bạn không cần phải suy nghĩ nhiều để nhận ra điều này sẽ không mở rộng quy mô cho lắm. Chúng tôi đã có rất nhiều vấn đề rất nhanh

1. Tải lên danh sách sẽ không bao giờ hoạt động chính xác. Chúng rất lớn và thường thì các công việc sẽ hết thời gian chờ liên tục cho đến khi hàng đợi bỏ chúng
2. Tạo một liên hệ phức tạp và chuyên sâu. tìm nạp dữ liệu địa lý khá tốn kém và có một số truy vấn khác liên quan. Tạo một liên hệ duy nhất liên quan đến việc nhấn vào nhiều vị trí của ứng dụng
3. Khi nhiều chiến dịch bắt đầu chạy, hệ thống sẽ ngừng hoạt động vì chúng tôi nhận được quá nhiều yêu cầu. Vì là đồng bộ nên máy chủ của chúng tôi sẽ mất một lúc để phản hồi, các yêu cầu sẽ chồng chất và sau đó mọi thứ sẽ bùng nổ
4. Mongo hoạt động rất tốt cho đến khi chúng tôi có vài triệu bản ghi trong mỗi bộ sưu tập. Sao chép dữ liệu từ bộ sưu tập này sang bộ sưu tập khác cực kỳ tốn kém --- mỗi bộ trong số chúng có các thuộc tính duy nhất và việc tái cấu trúc là không khả thi
5. Đẩy các tính năng, bản sửa lỗi và cải tiến là rất khó. Không có bài kiểm tra nào cho đến khi tôi tham gia và thậm chí sau đó chúng tôi không có bộ phần mềm mạnh mẽ. Xếp hàng xuống là nỗi lo số 1
6. Hàng đợi gửi thực sự được xử lý bởi một tập lệnh được viết bằng Go. Về cơ bản, nó tiếp tục đọc từ các lượt gửi đi đang chờ xử lý và gửi tin nhắn, nhưng nó khá cơ bản --- không có giao diện người dùng nào mà chúng tôi có thể kiểm tra và việc thêm các nhà cung cấp dịch vụ gửi mới rất khó khăn vì tập lệnh đó cũng phải được thay đổi

Rõ ràng là ứng dụng được thiết kế rất kém. Tôi không chắc tại sao họ chọn sử dụng 3 bộ sưu tập để gửi tin nhắn, nhưng đó là một vấn đề lớn.
Công ty đã thử thuê một chuyên gia Mongo để thực hiện một số điều kỳ diệu --- Tôi không phải là chuyên gia DB, nhưng tôi nhớ đã có rất nhiều sharding và hóa đơn hàng tháng gần như chạm mốc 5 chữ số.
Điều đó cho phép chúng tôi đạt ~4M/lần gửi mỗi ngày, nhưng vẫn còn rất nhiều vấn đề và dữ liệu phải được dọn dẹp thường xuyên.

Vào khoảng thời gian đó, tôi đã quyết định tham gia *nhiệm vụ hoạt động đen *và xây dựng lại thứ này từ đầu với tư cách là một MVP. Chúng tôi không cần nhiều tính năng [tôi chưa đề cập đến 1/3 trong số đó --- có rất nhiều] cho điều đó --- chỉ cần xác nhận rằng chúng tôi có thể gửi những tin nhắn đó một cách thoải mái.
Tôi không có nhiều kinh nghiệm với microservices và devops nên tôi chỉ quyết định sử dụng những gì tôi biết và bỏ qua những thứ mới mẻ, hấp dẫn.
Tôi đã quyết định sử dụng Laravel, MySQL và Redis. Đó là nó. Không Kubernetes, không Terraform, không microservice, không autoscaling, không.

Lược đồ DB mới trông giống như thế này. ​

​

Một số quy tắc kinh doanh khác tôi đã không đề cập đến

1. Trong tất cả các lần gửi, chúng tôi cần xác minh xem số đó có nhận được tin nhắn từ cùng một công ty trong vòng 24 giờ hay không. Điều đó có nghĩa là một truy vấn bổ sung
2. Chúng tôi cần kiểm tra xem người liên hệ có nhận được tin nhắn vào một thời điểm nhất định hay không --- luật tiếp thị SMS chỉ cho phép người liên hệ nhận tin nhắn trong một khung thời gian nhất định, vì vậy việc kiểm tra múi giờ là cực kỳ quan trọng
3. Trong mỗi câu trả lời gửi đến, chúng tôi cần kiểm tra xem có bất kỳ từ dừng nào --- những từ đó đã được tùy chỉnh, do đó, điều đó cũng có nghĩa là một truy vấn bổ sung. Nếu đúng như vậy, chúng tôi cần chặn số đó cho công ty đó --- một lần nữa, một truy vấn nữa
4. Chúng tôi cũng cần kiểm tra các từ khóa trả lời --- đó là những từ sẽ kích hoạt một thư gửi đi mới. Một lần nữa, truy vấn bổ sung và có thể là toàn bộ quá trình gửi
5. Mỗi chiến dịch được liên kết với một Tài khoản có nhiều Số. Có một phép tính, trong thời gian chạy, để xác định số lượng tin nhắn mà tài khoản đó có thể gửi trong một phút mà không làm cháy số hoặc bị điều chỉnh

Để giải quyết những vấn đề đó, tôi đã nhờ đến hai người bạn thân nhất của mình. Hàng đợi và Redis. Để xử lý các hàng đợi, tôi đã sử dụng Laravel Horizon đã được thử nghiệm thực tế và dễ sử dụng

Ứng dụng mới trông như thế này

1. Mỗi thư được lưu trữ trong bảng messages, với một khóa ngoại trỏ đến chiến dịch mà nó thuộc về và trường gửi_tại dấu thời gian không thể bỏ qua. Bằng cách đó, thật dễ dàng [và nhanh chóng, có chỉ mục] để kiểm tra các thư đang chờ và đã gửi
2. Mỗi chiến dịch có một cột trạng thái xác định điều gì sẽ xảy ra. đang chờ xử lý, đã hủy, bị tạm dừng, đang chạy và đã hoàn thành. Đang chờ xử lý có nghĩa là các tin nhắn vẫn đang được thêm vào bảng
3. Không có gì được xử lý đồng bộ --- mọi thứ được đưa vào hàng đợi. Từ webhook đến nhập danh sách đến tạo liên hệ đến gửi tin nhắn
4. Khi một danh sách được nhập, nó được xử lý theo lô 10.000 --- điều đó cho phép các công việc được xử lý khá nhanh mà chúng tôi không phải lo lắng về thời gian chờ
5. Khi một chiến dịch được tạo, các thông báo được tạo theo lô 10.000 --- khi đợt cuối cùng được tạo, trạng thái chiến dịch sẽ thay đổi thành bị tạm dừng
6. Bạn có nhớ nội dung dữ liệu địa lý không? . Hãy tưởng tượng hàng trăm triệu liên hệ được nhập bởi các công ty khác nhau hàng ngày.
   Điều đó đã được hoãn lại cho Redis --- thường thì một số số sẽ chia sẻ một số bản ghi mà chúng tôi sẽ sử dụng để tìm nạp dữ liệu địa lý và việc lưu những dữ liệu đó vào bộ nhớ cache giúp mọi thứ nhanh hơn nhiều.
7. Việc xử lý thư vẫn phức tạp nhưng dễ xử lý hơn. toàn bộ quá trình dựa trên tài khoản thay vì chiến dịch vì chúng tôi cần tôn trọng thông lượng tối đa của từng tài khoản và có thể có một số chiến dịch sử dụng cùng một chiến dịch.
   Có một công việc được lên lịch chạy mỗi phút để tính toán số lượng tin nhắn mà một tài khoản có thể gửi, tìm nạp đúng số lượng tin nhắn đang chờ xử lý theo thứ tự ngẫu nhiên, sau đó gửi một công việc duy nhất cho từng tin nhắn đang chờ xử lý.

​

Bạn có nhớ từ khóa dừng và trả lời không? .
Xác định xem một thư đi có được gửi gần đây không? .

Horizon đang sắp xếp một vài hàng đợi --- một để nhập CSV, một để nhập từng liên hệ, một để gửi công việc tài khoản, một để gửi tin nhắn, một để xử lý webhook, v.v.
Phần cơ sở hạ tầng trông như thế này.

Tôi không thể nhớ hết dung lượng của mỗi máy chủ, nhưng ngoài MySQL và Redis ra, chúng đều khá yếu.
Với ngăn xếp đó, ứng dụng đã quản lý để gửi hơn 10 triệu tin nhắn và hơn 100 triệu công việc được xếp hàng trong khoảng thời gian 12 giờ một cách dễ dàng.
Nó đã vượt qua 1 tỷ bản ghi khá nhanh và nó vẫn mượt mà như bơ. Tôi không nhớ các khoản tài chính, nhưng hóa đơn hàng tháng đã tăng từ 5 chữ số [+ nhà tư vấn DB] xuống dưới một nghìn đô la.

Không tự động tính tỷ lệ, không K8, không có gì --- chỉ là những điều cơ bản và những gì tôi biết tương đối rõ

Một vài suy nghĩ về cơ sở hạ tầng tổng thể.
Việc xử lý các chỉ mục đúng cách trên MySQL đã được đền đáp xứng đáng --- chúng tôi không có bất kỳ bất kỳ trừ khi chúng tôi cần.
Redis được sử dụng rộng rãi và có TTL hào phóng --- ném thêm RAM vào ngăn xếp sẽ rẻ hơn là để hệ thống ngừng hoạt động. Nhìn chung, nó hoạt động khá tốt, nhưng việc xử lý việc vô hiệu hóa bộ đệm đôi khi rất phức tạp.

Việc viết lại cách gửi tin nhắn khiến mọi việc trở nên dễ dàng hơn rất nhiều, vì tôi có thể gói gọn hành vi riêng của từng trình điều khiển vào lớp riêng của chúng và yêu cầu chúng tuân theo hợp đồng.
Điều đó có nghĩa là việc thêm trình điều khiển gửi mới chỉ là tạo một lớp mới, triển khai giao diện và thêm một vài phương thức --- điều đó sẽ làm cho trình điều khiển đó hiển thị trong giao diện người dùng, xử lý webhook và gửi tin nhắn.

Về Laravel Horizon, một điều quan trọng. những công việc cần thiết để trở nên ngu ngốc. ngu thật.
Tôi đã quen với việc chuyển các mô hình làm đối số cho các công việc --- Laravel xử lý điều đó một cách đặc biệt bằng cách giải tuần tự hóa mô hình, chuyển nó đến công việc và sau đó tuần tự hóa nó trên nhân viên xếp hàng. Khi điều đó xảy ra, bản ghi được tìm nạp từ cơ sở dữ liệu. một truy vấn được thực hiện.

Đây chắc chắn là điều mà tôi không muốn, vì vậy các công việc phải càng ngu ngốc càng tốt về những gì liên quan đến cơ sở dữ liệu --- tất cả các đối số cần thiết được chuyển trực tiếp từ công việc của trình xử lý tài khoản, vì vậy vào thời điểm đó .
Không cần chuyển một thể hiện Danh sách cho một công việc nếu tất cả những gì nó cần là list_id --- thay vào đó chỉ cần chuyển int $listId. 😉

Tóm lại, các bài kiểm tra đã tạo ra sự khác biệt lớn. Ứng dụng cũ không có nhiều thứ ngoài những ứng dụng tôi đã viết và nó khá không ổn định. Biết rằng mọi thứ hoạt động như tôi dự định đã cho tôi một chút tâm trí

Nếu tôi làm điều này hôm nay, có lẽ tôi sẽ chọn một số công cụ khác. Chắc chắn là Swoole và Laravel Octane. Có lẽ SingleStore cho cơ sở dữ liệu. Nhưng nhìn chung, tôi hài lòng với những gì tôi đã chọn và nó hoạt động rất tốt, trong khi vẫn còn chỗ để cải thiện và có thể thay đổi một số thứ

Yêu cầu hoạt động như thế nào trong Laravel?

Laravel có chỉ số octan nhanh như thế nào?

Giá trị giới hạn tốc độ mặc định trong Laravel là gì?

Yêu cầu $request trong Laravel là gì?