Như tít ạ, e mới cào được mớ dữ liệu này, khoảng hơn 300k bài viết thôi (trong hình là ~540k nhưng một số bị lỗi e chưa xóa), kèm theo tag ,danh mục, tác giả, hình ảnh(lấy link trực tiếp), bình luận trên site, etc.. E dùng vps vultr gói HF 6$ để cào thì khá ổn nhưng khi kết nối site với database thì chắc mấy bác cũng biết chuyện gì rồi đó. Site thì e chưa public chỉ mới vào test thử thôi thì thấy ngoài trang index lấy bài viết rất nhanh (vì e đã index những thứ cần thiết) ngoại trừ thêm mấy cái kiểu order BY thì hơi chậm có khi mất 10s mới truy vấn xong để cache, cái này chắc chắn là do vps yếu rồi ko bàn và kể cả phần bài viết thì mysql truy xuất cũng rất nhanh kể cả chưa cache. Bài viết gồm cả hình ảnh, danh mục, thẻ tag ...etc, nhưng khi bấm ngược vào mỗi cái con trên để hiện bài viết liên quan thì lại rất chậm mặc dù dữ liệu liên quan đến nó không nhiều. Tool cào với web e dùng hết bằng laravel, do e tự học (chắc được tầm tháng à) nên nhiều cái cũng chưa rõ cách xử lý ra sao, theo mấy bác e có nên nâng VPS lên không hay là tối ưu lại code cho tiết kiệm. Tiện thể mấy bác cho hỏi có gói vps của bên nào chạy ngon mà rẻ hơn gói vultr HF 2cpu giá 24$ xíu không?, e định nâng lên gói 24$ để public site nhưng thấy hơi phí phí
Mình xài con 5$ của Vultr chạy 5 site, mỗi site trung bình 500k post vẫn phà phà. Thớt kiểm tra lại và tối ưu lại index của db và các câu query chậm, sau đó cache data lại (Dùng Memcache hoặc Redis) là host hiện tại chạy vô tư. Ngoài ra, thằng Laravel thấy bà con cứ theo trào lưu đua nhau xài nó chứ mình thấy kiến trúc nó khá rườm rà và performance thì thuộc dạng kém so với nhiều framework khác.
Pro quá e ah. 5 site mà mỗi site trung bình 500k post, vẫn chạy ngon thì quá đỉnh. Visit mỗi site ổn ko e.
thanks bác đã chia sẻ nhưng mà 5 site kia của bác dùng wp hay code tay hay dùng 1 framework nào đó ?? và để host trên một con vps 5$ kia thì khó tin quá ạ. E có dùng redis để cache đó chứ nhưng mà ý e là nếu page đó chưa được cache thì người truy cập trang đó đầu tiên phải chờ rất là lâu, có khi bỏ đi trước khi trang load xong! Bác có cách nào để khi truy vấn where hoặc/và orderby nhiều lần trong một query mà vẫn nhanh ko hoặc index những gì ko? orderby hay where tầm trên 1 lần trong 1 query là nó chậm hẵn. Về Laravel thì e thấy nó cũng ổn mà, cấu trúc của nó phức tạp nên chắc chắn ko nhanh bằng FW khác nhưng được cái rất dễ dùng và rất nhiều cái được build sẵn rất tỉ mỉ như là eloquent với paginate chẳng hạn,đặc biệt là cái artisan command với hàng đợi queue - 2 cái này kết hợp để cào thì best. Với e search google FW php phổ biến thì nó ra thằng này nên theo từ đầu luôn.
B code kiểu gì mà load lần đầu quá lâu đến nỗi user không đợi được mà phải bỏ đi vậy. ??? B muốn bỏ 10 site lên vps 5$ của vultr cũng đc chứ nói gì đến 5 con
Tư vấn performance mà không biết site hoặc không biết code đang sử dụng như thế nào thì như thầy bói xem voi thôi. Tốt nhất em nên viết chi tiết hơn, code như thế nào, cấu trúc db ra sao ...
Hem phải anh, tại em nghèo quá nên cố gắng tận dụng á . Visit thì site nhiều nhất 4k UV, site ít nhất vài chục, tổng tầm 6-7K Ở đây mình chọn theo sự phù hợp thôi cụ. Đa phần các site auto business logic và technical ở mức đơn giản nên ko cần phải sử dụng fw quá mạnh, nhiều chức năng. Và vì đơn giản nên cũng ko cần thiết phải có một cộng đồng mạnh nhất để support. Mình đã thử triển khai 2 bộ code cho site auto có chức năng giống nhau, 1 của Laravel và 1 của CakePHP. Sau khi test thử vài tháng thì mình bỏ luôn bộ Laravel vì nó chậm hơn hẳn CakePHP, khi gặp vấn đề trục trặc xử lý cũng tốn thời gian hơn CakePHP nhiều. 5 site mình dùng CakePHP nhé bạn. Chẳng chém gió với bạn làm gì, 500k là mới chỉ tính post thôi, nếu tính cả relation và râu ria thì nó còn nhiều hơn nữa. Đầu tiên bạn phải tối ưu query rồi mới tính đến chuyện cache. Để tối ưu query bạn explain từng câu bạn xài ra xem câu nào chậm thì khắc phục nó. Đánh index thì đơn giản, về cơ bản là dựa trên các field condition và order mà đánh, chi tiết ntn thì bạn google một phát ra cả đống mình ko cần đề cập ở đây. Sau khi tối ưu rồi bạn bật sql slow log trên server lên, config cho nó log những query nào chạy > 10s thì xử tiếp cho đến khi nào hết thì thôi. Có 1 điều nên bạn nên lưu ý: nhiều người hay lý tưởng hóa, thích 1 db design đẹp đẽ, relation hoành tráng nhưng đời ko như là mơ. Để đảm bảo performance nhiều lúc phải chấp nhận dư thừa dữ liệu, bỏ cả relation để đánh đổi lấy tốc độ. Bạn xài Redis rồi nhưng việc có xài cache với xài hiệu quả nó là 2 vấn đề khác nhau. Cái này cần phải có kinh nghiệm, không phải cứ tống tất cả vào cache là tốt. Với 1 con vps tài nguyên hạn hẹp như con 5$ của Vultr thì phải tính toán cache nào xài memory, cache nào xài disk, kích thước cache tối đa là bao nhiêu, vấn đề cân bằng giữa cache để giảm tải server mà vẫn đảm bảo content mới luôn được load... blah blah blah. Mình ko phải chê Laravel vì thực tế nó rất mạnh, hiện tại nó đang là fw số 1 của PHP. Tuy nhiên như đã nói ở trên, cái mình ưu tiên hàng đầu là sự phù hợp. Súng đại bác tuy to và mạnh thật đấy nhưng để bắn chim sẻ thì sao bằng súng hơi . Còn xét về chức năng thì mọi thứ Laravel làm được fw PHP khác cũng làm được bạn nhé.
Chi phí cho server lúc nào cũng là chi phí rẻ nhất, nếu site bạn nhanh, traffic có thể tăng lên và doanh thu có thể sẽ cao hơn. Vì vậy ko nên tiết kiệm quá cho khoản server Mình có dùng cloud server của bên này https://www.hetzner.com/cloud Giá cực rẻ và dùng cũng ổn định. Bạn có thể tham khảo
Oh anh xài Hetzner mấy năm mà ko để ý nó có cloud luôn Vãi thật. Nhìn giá có vẻ rẻ hơn Vultr nhưng ko biết performance thế nào em?
thanks mấy bác đã gợi ý, e khắc phục được query chậm rồi, nguyên nhân là do e tưởng index là index từng cột đơn lẻ xài trong câu orderby query thôi, hóa ra là phải chọn cả 3 cột rồi index mới được, mới test lại thấy nhanh rồi các bác. sẵn tiện cho e hỏi khi mà mình public á là vào google search console add site đúng k? rồi có submit luôn sitemap lên luôn không ?
Public là khi bạn đưa site bạn lên server., có thể truy cập đc bằng domain và không chặn bot của gg or bing. Còn việc add site vào gsc hay submit sitemap chỉ là thủ tục nên làm hoặc phải làm theo quan điểm từng người thôi