Как оптимизировать базу данных Google Cloud SQL (MySQL) для использования с API - PullRequest
0 голосов
/ 07 января 2020

Я создал MySQL базу данных в Google Cloud Platform.

Machine type is db-n1-standard-2 with 2 vCPUs and 7.5 GB Memory. 
Network throughput (MB/s) is 500 of 2000
Storage type: SSD

Disk throughput (MB/s)
Read: 4.8
Write 4.8
IOPS
Read: 300
Write: 300

Availability: High availability

Database Flags:
max_connections: 500

Я создал API с Laravel Lumen и позволил ему работать на Google Cloud Platform в App Engine

runtime: php72
instance_class: F2
automatic_scaling:
    min_instances: 1
    max_instances: 20
    target_cpu_utilization: 0.7
    max_concurrent_requests: 80
    target_throughput_utilization: 0.8

Если я отправлю запрос в мой API с почтальоном, первый ответ потребует 1123 мс. Размер ответа составляет 8,59 КБ.

Если я отправлю тот же запрос с loader.io с 250 клиентами в течение 1 минуты, тест будет прерван, поскольку он достиг порога ошибки. 79,5% частота ошибок, ср. Ср. = 9141 мс

мин / макс. Время ответа: 2081/10376 Количество ответов успешно: 104 Время ожидания ответа: 403

Когда я смотрю на MySQL Ведение журнала ошибок, у меня действительно невозможно много ошибок, подобных этой:

    2020-01-07 16:29:18.670 CET
2020-01-07T15:29:18.670275Z 1507 [Note] Aborted connection 1507 to db: 'mydatabasename' user: 'mydatabaseuser' host: 'cloudsqlproxy~172.217.35.158' (Got an error reading communication packets)

У кого-нибудь есть идея, как мне решить эту проблему?

1 Ответ

0 голосов
/ 14 января 2020

Я немного изучил эту ошибку и нашел несколько полезных руководств по диагностике ошибок этого типа по этой ссылке . Я считаю, что в качестве первого шага нам нужно будет найти реальную причину возникновения ошибки. это сообщение (это может быть вызвано различными причинами в соответствии с общей ссылкой), некоторые предложения, которые я мог бы заметить, повторяя на других сообщениях и на той же ссылке, которой я поделился ранее, следующие:

  • Проверка чтобы убедиться, что значение max_allowed_packet достаточно высокое (это можно изменить с помощью флагов в Cloud SQL).
  • Клиент успешно подключился, но неправильно завершился
  • Клиент проспал дольше, чем определенное wait_timeout или interactive_timeout секунд

Я бы go включил и попытался настроить флаги базы данных, как описано в этой publi c документации на странице Google и проверьте, как меняется поведение.

Пожалуйста, дайте нам знать, если вы найдете что-то полезное при настройке экземпляр.

...