Периодический сбой канала связи с Cloud SQL

Я использую jmeter для стресс-тестирования веб-службы GAE, которая использует CloudSQL, и я получаю прерывистые исключения сбоя канала связи.

Я пытался использовать прямые соединения и пул соединений, и я вижу исключения в любом сценарии. Исключения увеличиваются по мере увеличения количества запросов в секунду.

Обратите внимание, что мы используем самый высокий уровень облачного SQL, D32, и тесты намного меньше максимальных 3200 подключений.

Вот трассировка стека для справки:

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at sun.reflect.GeneratedConstructorAccessor48.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:33)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1117)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:350)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2413)
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2450)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2235)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:818)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
at sun.reflect.GeneratedConstructorAccessor46.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:33)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:404)
at com.mysql.jdbc.GoogleNonRegisteringDriver$JdbcWrapper.getInstance(GoogleNonRegisteringDriver.java:276)
at com.mysql.jdbc.GoogleNonRegisteringDriver.connect(GoogleNonRegisteringDriver.java:246)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)

Обновление: я изменил настройки пула соединений на maxActive = 5 и maxIdle = 5, и исключения прерывистой связи исчезли. Обратите внимание, что я пробовал commons dbcp и tomcat dbcp. Теперь я вижу следующие исключения в журналах:

Вызвано: java.sql.SQLException: java.lang.SecurityException: невозможно получить доступ к collectPerformanceMetrics

Вызвано: java.sql.SQLException: java.lang.SecurityException: невозможно получить доступ к includeThreadDumpInDeadlockExceptions

Вызвано: java.sql.SQLException: java.lang.SecurityException: невозможно получить доступ к nullNamePatternMatchesAll


google-cloud-sql google-app-engine jmeter
person Albert Chu    schedule 27.02.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Из https://cloud.google.com/appengine/docs/java/cloud-sql/#Java_Size_and_access_limits

«Каждый экземпляр App Engine не может иметь более 12 одновременных подключений к экземпляру Google Cloud SQL».

Можно подробнее о тестовой установке? Сколько запросов jmeter отправляет на appengine и сколько соединений открывает экземпляр приложения для каждого из этих запросов?

person Community    schedule 28.02.2014
comment
СПАСИБО! Я не смог найти ограничение в 12 одновременных запросов в текущей документации App Engine, но, похоже, это правда. У меня было максимальное количество подключений к движку приложения, равное 35, и, по-видимому, 35 пользовательских подключений имели возможность использовать более 12 подключений к базе данных. Я сократил количество подключений к движку приложения до 12, и хотя количество экземпляров движка приложения увеличилось, я больше не вижу эту ошибку. - person Chris Fremgen; 04.08.2016

arrow_upward
0
arrow_downward

Всем, кто ищет, почему вы можете получить «com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: сбой канала связи» при соединении.

Убедитесь, что ваш IP разрешен, если вы звоните с тестового сервера!

Я тестировал в доме друзей, и эта бесполезная ошибка продолжала появляться.

person Andreas Rudolph    schedule 20.04.2016