Xoogler в облаке здесь. У меня очень низкий уровень сервиса qps, который обслуживает HTML плюс дополнительные ресурсы. Таким образом, он обычно бездействует, а затем получает что-то в порядке 20 запросов в течение 5 с с параллелизмом значительно ниже 10, где предел параллелизма равен 80. Я наблюдаю, что клиенты регулярно получают 429 с из Cloud Run, обычно после периодов бездействия службы, даже если Экземпляр все еще работает (так что это не проблема холодного запуска). Это может быть либо по первому запросу, но часто где-то в середине последовательности (т. Е. Значки, css не загружаются).
Экземпляр является параллельным, отзывчивым и может легко справиться с нагрузкой, но Cloud Run не позволяет этого. Другие экземпляры также не запускаются, хотя мы даже не достигли максимума 2. Это говорит о том, что Cloud Run по некоторым причинам оценивает> 2 необходимых экземпляра?
Вот типичная последовательность запросов, отредактированная из журналов. :
... 20 min idle ...
I 2020-03-27T18:21:27.619317Z GET 307 288 B 5 ms
I 2020-03-27T18:21:27.706580Z GET 302 0 B 0 ms
I 2020-03-27T18:21:27.760271Z GET 200 5.83 KiB 5 ms
I 2020-03-27T18:21:27.838066Z GET 200 1.89 KiB 4 ms
I 2020-03-27T18:21:27.882751Z GET 200 1.05 KiB 4 ms
I 2020-03-27T18:21:27.886743Z GET 200 582 B 3 ms
I 2020-03-27T18:21:27.893060Z GET 200 533 B 4 ms
I 2020-03-27T18:21:27.897352Z GET 200 5.35 KiB 4 ms
I 2020-03-27T18:21:27.899086Z GET 200 11.38 KiB 6 ms
I 2020-03-27T18:21:27.905967Z GET 200 22.48 KiB 13 ms
I 2020-03-27T18:21:27.906113Z GET 200 592 B 13 ms
I 2020-03-27T18:21:27.907967Z GET 200 35.08 KiB 14 ms
...500ms...
I 2020-03-27T18:21:28.434846Z GET 200 2.76 MiB 50 ms
I 2020-03-27T18:21:28.465552Z GET 200 2.29 MiB 67 ms <= up to here all resources served from image
...2500ms...
I 2020-03-27T18:21:31.086943Z GET 200 2.95 KiB 706 ms <= IO-bound, talking to backend api
...1600ms...
W 2020-03-27T18:21:32.674973Z GET 429 14 B 0 ms <= !!!
W 2020-03-27T18:21:32.675864Z GET 429 14 B 0 ms <= !!!
W 2020-03-27T18:21:32.676292Z GET 429 14 B 0 ms <= !!!
I 2020-03-27T18:21:32.684265Z GET 200 547 B 6 ms
I 2020-03-27T18:21:32.686695Z GET 200 504 B 9 ms
I 2020-03-27T18:21:32.690580Z GET 200 486 B 12 ms
Возможно, что последняя группа запросов - это 6 параллельных запросов. Почему трое будут лишены, а трое обслужены? Служба под нагрузкой. Пара перезагрузок обычно решает проблему.
Мне действительно кажется, что алгоритм сильно переоценивает требуемые ресурсы после периода бездействия. Я счастлив попробовать большие максимальные экземпляры (теперь перераспределенные до 10), но что-то действительно не так с оценками в нижней части спектра. Если «2» в качестве параметра параллелизма ниже того, что поддерживает платформа, gcloud, вероятно, в первую очередь, вероятно, должен установить более высокий минимум.
Это несколько печально, поскольку это влияет на людей, просто «пробующих» Cloud Run и они обнаруживают периодические ошибки (частично отображаемые страницы, ...), которые даже фиксируются на клиенте (4xx), который, конечно, не виноват.
Рад предоставить больше данных.
Конфигурация :
template:
metadata:
...
annotations:
...
autoscaling.knative.dev/maxScale: '2'
spec:
timeoutSeconds: 900
...
containerConcurrency: 80
containers:
...
resources:
limits:
cpu: 1000m
memory: 244Mi