2013-09-04 46 views
18

Tôi có cá thể Đám mây SQL có kích thước D0. Khi tôi chạy một đơn giảnGoogle Cloud SQL chậm

select * from table 

có khoảng 500 hàng, phải mất trung bình 100 mili giây để thực thi (như được báo cáo bởi SQL Prompt). Trong khi đó trên phiên bản địa phương của tôi về MySQL 5.5, nó chỉ mất 1 ms. Máy dev của tôi có bộ xử lý lõi kép Intel Core i7 2.9GHz và bộ nhớ 1600MHz 8GB. Tôi đã đọc trong một FAQ hiệu suất của db phụ thuộc vào kích thước - trường hợp lớn hơn có nhiều RAM và CPU.

Điều này có hợp lý để mong đợi các vấn đề về hiệu suất được giải quyết với kích thước mẫu lớn hơn không? Hay tôi còn thiếu cái gì khác ở đây?

+0

đó là dịch vụ đám mây. bạn ** CÓ ** để cho phép độ trễ mạng. DB nhanh nhất trong vũ trụ sẽ vẫn chậm nếu đường ống dẫn đến nó chỉ là một vài lon lon và một chuỗi với những người la hét 1 và 0 trong đó. –

+1

làm cho nó 1000, 10000 hàng và kiểm tra xem nó có quy mô tuyến tính hay không. nếu nó có bạn có một vấn đề. nhưng tôi không nghĩ rằng nó sẽ, vì không đổi trên không (độ trễ mạng). – mnagel

+1

Tôi tin rằng, SQL Prompt báo cáo thời gian thực hiện truy vấn thực tế, không phải truy vấn SQL + độ trễ mạng. Với độ trễ khoảng 400 mili giây, theo báo cáo của Chrome Dev Tools. – andriys

Trả lời

2
  1. Bạn đang kết nối với phiên bản Cloud SQL của mình từ đâu?
  2. Kích thước cấp sẽ có ảnh hưởng lớn đến hiệu suất. Bạn có thể thay đổi tầng của cá thể tạm thời để kiểm tra nó.
+0

1. Tôi đang kết nối từ SQL Prompt https://developers.google.com/cloud-sql/docs/sql_prompt trong trình duyệt. 2. Tôi sẽ thử thay đổi kích thước tầng và đăng kết quả. – andriys

+5

Tôi chuyển sang trường hợp D32 (bản lớn nhất) và phải mất 30 mili giây để truy vấn một bảng có hai bản ghi. Truy vấn bảng với 500 bản ghi mất 75 ms. Tôi nghĩ nó không hợp lý. Amazon RDS thực hiện tất cả các hoạt động này trong vòng chưa đầy 1 ms. Bạn có bất kỳ ý tưởng tại sao nó có thể được? – andriys

+0

Bằng chứng: http://grab.by/q044 – andriys

3

EDIT: ngày 10 tháng 4 năm 2016

GAE hiện nay cung cấp thế hệ thứ hai đám mây mysql mà ngay cả một tầng cơ bản như 'db-g1-nhỏ' thực hiện càng nhanh càng tốt một tầng D8 trong cũ cung cấp đám mây SQL . Nó cũng rẻ hơn đáng kể. Điều này có vẻ là một cột mốc quan trọng và không có lý do gì để nghỉ ngơi để hack và giải pháp nữa.

Bạn có thể tham khảo giá Cloud SQL nhưng chi phí tối thiểu gần đúng là khoảng $ 20 mỗi tháng.

ORIGINAL POST

Google chỉ quy định VM trên một hộp chậm đối với các tầng D0. Bạn có thể chọn D4 nhưng RAM không phải là vấn đề chính nhiều như bộ vi xử lý (họ không đề cập đến các GHz).

Độ trễ mạng không phải là vấn đề. Ví dụ: 0,05 dưới đây là thời gian thực hiện truy vấn trên máy chủ. Bất kỳ số lượng thời gian nào sau đó có thể được chi tiêu trong việc truyền dữ liệu.

mysql> select * from tracking limit 5; 
+--------------------------------+-----------+-----------+ 
| id        | scan_date | status | 
+--------------------------------+-----------+-----------+ 
| 420006929400111899561510697350 | NULL  | Delivered | 
| 420010859400111899561989496058 | NULL  | Delivered | 
| 420019849400111899561989496331 | NULL  | Delivered | 
| 420100109400111899561903290311 | NULL  | Delivered | 
| 420100319400111899561944407020 | NULL  | Delivered | 
+--------------------------------+-----------+-----------+ 
5 rows in set (0.05 sec) 

Edit: Tháng 3 năm 2016

Đối với một số ứng dụng tôi không còn sử dụng đám mây SQL và sử dụng một cụm MySql cơ bản tổ chức từ xa thay vì kể từ GAE mở kết nối ổ cắm ngoài. Nghe có vẻ điên khùng? Không theo các con số - gửi một truy vấn và lấy lại dữ liệu qua kết nối socket này nhanh hơn so với D3 đồng vị trí.

4

Lượt xem là nguyên nhân gây ra hiệu suất kém. Google chạy hương vị riêng của công cụ MySQL được tối ưu hóa theo cách có thể làm tổn thương lượt xem. Nếu bạn có nhiều người tham gia hoặc/và đoàn thể mong đợi lượt xem chạy chậm.

Tuy nhiên, đã gần một năm kể từ khi tôi đăng câu hỏi này và mọi thứ có thể đã thay đổi. Tôi đã không xem lại các lượt xem kể từ khi chúng tôi chuyển khỏi sử dụng chúng.

+0

Mọi thứ không thay đổi. Có vẻ như 200ms là thời gian phản hồi trung bình, mặc dù nó không phải là xấu. –

2

Chúng tôi cũng gặp vấn đề tương tự. Với phiên bản D16, một trang diễn đàn trang web đơn giản sẽ mất> 10 giây để tải. Tôi vừa nói chuyện với một kỹ sư hỗ trợ kỹ thuật của GoogleCloud, người đã xác nhận rằng CloudSQL chưa thực sự sẵn sàng cho "hiệu suất" (tính đến mùa hè 2015), và anh ấy khuyên nên viết lại mọi thứ để sử dụng DataStore ...Vì vậy, nếu bạn có các trang tạo hàng chục truy vấn SQL nhỏ và tập dữ liệu quá lớn để vừa với bộ nhớ cache thì CloudSQL không phải là giải pháp khả thi ngay bây giờ.

+0

Điều này đến như một cú sốc, đã phát triển hệ thống lỗ hổng của chúng tôi trong nhiều tháng để sử dụng cloudSQL. Tại sao bạn nói như mùa hè .. nó đã có hiệu suất tốt hơn hoặc nó đã bắt đầu tụt hậu so với các nhà cung cấp khác kể từ đó? Datastore không phù hợp với nhu cầu của chúng tôi. Bất kỳ đề xuất? – cfl

+0

Tôi cũng thuộc Hỗ trợ nền tảng đám mây và trường hợp cụ thể này dường như là một đề xuất cụ thể về trường hợp sử dụng, chứ không phải là tuyên bố toàn cầu về chăn "Datatsore> Cloud SQL". – Nick

+0

Bạn có thực sự thực hiện hàng tá cuộc gọi trên mỗi lần tải trang không? Điều đó có vẻ là một kế hoạch tổng thể không lý tưởng trong mọi trường hợp. – bwawok

Các vấn đề liên quan