Сообщений в теме: 14

[necro]

Добрый день.

 

Целевая система при запросах в оракловую базу открывает новое соединение для каждой серии запросов (в 99.9% сессия содержит ровно один запрос, т.е. каждый запрос идет в новой оракловой сессии) ЖМетер же в коробочной версии пытается делать все запросы каждого вузера в одной сессии. Кто посоветует наиболее кошерный способ как его заставить закрывать сессию после получения ответа и открывать новую при отправке сообщения. Шаманства с настройками JDBC конфигов и самплеров не помогли. Подозреваю что нужно курить в сторону пост-реквест экшинов и beans/jsr кода, но инструмент для меня новый (до этого плотно сидел на стеке ALM/PC) и прогресс идет сложно.

 

Леша

 

P.S. подспудный вопрос - целевое приложение использует binded variables в PL\SQL коде и вызов переменных через ":" 

Насколько я понял из курения доков по ораклу использование ":" позволяет "зафиксировать" план исполнения запросов данного типа (т.е. ораклу не придется каждый раз придумывать каким образом данный запрос исполнять, что в свою очередь уменьшит нагрузку на базу. Пропихивание же параметров в тело запроса JDBC Request'ов по моему разумению данную функциональность реализовывать не будет, а значит тестирование не будет валидным. 

 

У кого нить есть идеи какими коробочными средствами можно реализовать поддержку таких запросов? Или как в предыдущем примере уходит в чистую яву в плане логики, а jmeter-у оставить только управление потоками?

[Timbildim]

Я все же предлагаю использовать JSR223 Sampler, но переиспользовать JDBC Connection. Можно посмотреть как JDBC Connection реализован на GitHub.

Если у JSR223 Sampler проставить галку на "Cache compiled script if available", то по идее подгрузка ресурсов будет только один раз.

 

 JDBC Connection.png   54,76К   7 Количество загрузок:

 

 

Либо сделать JSR223 PostProcessor для JDBC Request c таким кодом:

import java.sql.*;
import org.apache.jmeter.protocol.jdbc.config.DataSourceElement;

Connection conn = DataSourceElement.getConnection("jdbcConnection");
conn.close();

* jdbcConnection - название переменной в JDBC Connection.

При следующем запуске JDBC Request, он сам пересоздаст Connection.

Сообщение отредактировал Timbildim: 30 декабря 2019 - 13:40

[necro]

 

Я все же предлагаю использовать JSR223 Sampler, но переиспользовать JDBC Connection. Можно посмотреть как JDBC Connection реализован на GitHub.

Если у JSR223 Sampler проставить галку на "Cache compiled script if available", то по идее подгрузка ресурсов будет только один раз.

 

JDBC Connection.png

 

 

Либо сделать JSR223 PostProcessor для JDBC Request c таким кодом:

import java.sql.*;
import org.apache.jmeter.protocol.jdbc.config.DataSourceElement;

Connection conn = DataSourceElement.getConnection("jdbcConnection");
conn.close();

* jdbcConnection - название переменной в JDBC Connection.

При следующем запуске JDBC Request, он сам пересоздаст Connection.

 

 

Спасибо, работает )))

 

P.S. хотя как-то странно ((

[Timbildim]

P.S. хотя как-то странно ((

 

А в чем странность?
Я это решение полноценно не тестировал, хотелось бы знать в чем подвох?

[necro]

 

 

 

Я все же предлагаю использовать JSR223 Sampler, но переиспользовать JDBC Connection. Можно посмотреть как JDBC Connection реализован на GitHub.

Если у JSR223 Sampler проставить галку на "Cache compiled script if available", то по идее подгрузка ресурсов будет только один раз.

 

JDBC Connection.png

 

 

Либо сделать JSR223 PostProcessor для JDBC Request c таким кодом:

import java.sql.*;
import org.apache.jmeter.protocol.jdbc.config.DataSourceElement;

Connection conn = DataSourceElement.getConnection("jdbcConnection");
conn.close();

* jdbcConnection - название переменной в JDBC Connection.

При следующем запуске JDBC Request, он сам пересоздаст Connection.

 

 

Коннекшины рвутся, но как-то нестабильно
я тут что подумал, в пуле у меня же несколько коннекшинов, а получаю и закрываю я какую сессию? При таком подходе я точно за себя (использованную в этом триде) закрываю, а не за "того парня"?

 

В базе есть хранимка, которая фиксирует вызовы методов и в т.ч. идентификаторы сессий - раньше количество уникальных сессий во время теста было равно (с поправкой на случай) количеству жметер тридов. А целевое приложение нагрузку с которого я имитирую открывает новую сессию на (почти) каждый запрос. Т.е. должно быть количество уникальных сешн айди должно быть примерно равно общему количеству отправленных запросов, а не количеству тридов.

Сейчас количество (после применения этого кода) сессий стало больше но повторов при этом много. 

 

 

Леша

[Timbildim]

Леша, я так понимаю, что у тебя JDBC Connection Configuration стоит на уровне Тест плана. И несколько потоков успевают там выполниться пока какой-то из них не закроет его. 

Перенеси JDBC Connection Configuration на уровень потока(Thread Group). На этом уровне все реквесты выполняются последовательно, следовательно не будет одновременного использования коннекшена. По крайней мере я на это надеюсь:)

 

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

 

P.S. Если я правильно понимаю код, если JDBC Connection Configuration на уровне Тест плана, все потоки будут использовать один коннекшен определенный в этом общем JDBC Connection Configuration. Так что рекомендую отключить его, есали будет использовать одно и тоже имя пула.
 JDBC Connection code.png   77,79К   1 Количество загрузок:

 

[Timbildim]

Почему-то не получается более редактировать сообщение. Поправлю последнее предложение:
* P.S. Если я правильно понимаю код, то когда JDBC Connection Configuration определенна уровне Тест плана, все потоки будут использовать один коннекшен определенный в этом общем JDBC Connection Configuration.Так что рекомендую отключить его на уровне тест плана, если будет использовать одно и тоже имя пула для JDBC Connection Configuration на уровне потока..

[necro]

у некоторых

 

Почему-то не получается более редактировать сообщение. Поправлю последнее предложение:
* P.S. Если я правильно понимаю код, то когда JDBC Connection Configuration определенна уровне Тест плана, все потоки будут использовать один коннекшен определенный в этом общем JDBC Connection Configuration.Так что рекомендую отключить его на уровне тест плана, если будет использовать одно и тоже имя пула для JDBC Connection Configuration на уровне потока..

у некоторых форумных движков "окно правки" открыто в течении какого-то ограниченного времени после публикации. 

[necro]

Леша, я так понимаю, что у тебя JDBC Connection Configuration стоит на уровне Тест плана. И несколько потоков успевают там выполниться пока какой-то из них не закроет его. 

Перенеси JDBC Connection Configuration на уровень потока(Thread Group). На этом уровне все реквесты выполняются последовательно, следовательно не будет одновременного использования коннекшена. По крайней мере я на это надеюсь:)

 

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

 

P.S. Если я правильно понимаю код, если JDBC Connection Configuration на уровне Тест плана, все потоки будут использовать один коннекшен определенный в этом общем JDBC Connection Configuration. Так что рекомендую отключить его, есали будет использовать одно и тоже имя пула.
JDBC Connection code.png

 

В общем перенос конфига вниз по иерархии проблему не решил. Скорее всего механизм получения коннекшина для прибивания надо усовершенствовать (может даже надо запоминать его на этапе препроцессинга, до выполнения запроса. 

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

но скорее всего убивается не тот коннекшин в который был отправлен запрос а какой-то другой.

По этому, т.к. какие-то коннекшины все же прибиваются - их количество растет, но так прибиваются не свои, а чужие - растет с рандомным эффектом  ))) 

[Timbildim]

Я накидал тут решение. У меня оно работает. 
 

По картинке будет все понятно.

 JDBC Connection.png   385,09К   5 Количество загрузок:

 

 

Это jmx файл, пришлось сменить тип на txt, чтобы можно было сюда закинуть.

 Custom DB connection.txt   5,42К   8 Количество загрузок:

 

P.S. Я не знаю какую ты базу используешь. У меня MSSQL, поэтому в коде "import net.sourceforge.jtds.jdbc.*".

Сообщение отредактировал Timbildim: 15 января 2020 - 20:52

[necro]

Я накидал тут решение. У меня оно работает. 
 

По картинке будет все понятно.

JDBC Connection.png

 

 

Это jmx файл, пришлось сменить тип на txt, чтобы можно было сюда закинуть.

Custom DB connection.txt

 

P.S. Я не знаю какую ты базу используешь. У меня MSSQL, поэтому в коде "import net.sourceforge.jtds.jdbc.*".

 

Спасибо, все понятно.

Такой подход мне даже лучше подходит т.к. я смогу более тонко настраивать стейтменты, чем это можно реализовать через "родные" семлеры джимитера.

А с производительностью такого кода проблем нет? Слышал, что кастомный java/grooovy код может драматически снижать производительность по сравнению с самлерами из коробки

 

P.S. еще как вариант на основе JDBC сэмплера написать свой с "галкой" про обрыв коннекшинов между запросами ) 

[Timbildim]

 

Я накидал тут решение. У меня оно работает. 
 

По картинке будет все понятно.

JDBC Connection.png

 

 

Это jmx файл, пришлось сменить тип на txt, чтобы можно было сюда закинуть.

Custom DB connection.txt

 

P.S. Я не знаю какую ты базу используешь. У меня MSSQL, поэтому в коде "import net.sourceforge.jtds.jdbc.*".

 

Спасибо, все понятно.

Такой подход мне даже лучше подходит т.к. я смогу более тонко настраивать стейтменты, чем это можно реализовать через "родные" семлеры джимитера.

А с производительностью такого кода проблем нет? Слышал, что кастомный java/grooovy код может драматически снижать производительность по сравнению с самлерами из коробки

 

P.S. еще как вариант на основе JDBC сэмплера написать свой с "галкой" про обрыв коннекшинов между запросами ) 

 

 

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

Но такое мизерное кол-во кода вряд ли смогут как-то повлиять на производительность, по сравнению с тем же JDBC Sampler использующим несколько тысяч строк кода.
Кроме того подгрузка ресурсов и основного кода происходят один раз. Дальше мы к ним обращаемся по ссылкам. Я не программист, пишу как понимаю, могу быть не прав.

 

У меня так же используется JSR223 sampler как хранилище методов и классов почти на 400 строк. Я не заметил падения производительности. Позже это общих код будет переведен в jar файл, но пока что у меня постоянная дороботка кода. А maven для автосборки исходников я еще не прикрутил...

[necro]

 

Давно разобрался с этим вопросом, но на всякий случай оставлю тут то решение к которому в итоге пришел. Мало ли кому пригодится. Рвать коннекшин коробочного JDBCRequest сэмплера после выполнения не получится по двум причинам. Во первых зона видимости переменной conn в которую при его инициализации передается новый коннекшин из пула. Во вторых то что после выполнения запроса она обnullяется. То каждый раз, в каждом месте где вы вызываете этот метод, из пула вытаскивается  коннекшин на какую-то уже открытую сессию и каждый раз после исполнения коннекшин схлопывается, а сессия остается открытой. И даже в рамках одного threada нет гарантии, что два последовательных запроса отправятся из одной сессии. Особенно в ситуации когда свободных коннекшинов в пуле на данный момент времени больше одного. По этому если Ваша задача в создании некой обособленной цепочки последовательных запросов в рамках одной сессии, равно как и если Вы хотите создавать новую сессию для каждого нового запроса коробочный семлер не подходит от слова совсем. Конечно, можно немного "улучшить" код семплера (на вскидку для начала надо добавить 10 символов: модификатор видимости в одном месте и два слэша в другом), чтобы получить точно такой же JDBC Request, но со своим блэкджеком и шлюхами. Но боюсь, как говорил один уважаемый мной персонаж, это "Ж-Ж-Ж" неспроста и подобные модификации чреваты далеко идущими последствиями. К тому же с передаваемыми типами у JDBC Request беда, а там 10 символами не управишься. В общем только JSR223, только хардкор )))

[Timbildim]

Necro, только увидел твой расширенный ответ. Предложенная мною последняя реализация через jsr223 sampler тебе помогла все таки? Удалось добиться поведения, которое ты хотел?

[necro]

Necro, только увидел твой расширенный ответ. Предложенная мною последняя реализация через jsr223 sampler тебе помогла все таки? Удалось добиться поведения, которое ты хотел?

Да удалось, но я скорее "в лоб" пошел, вынес груви фрагменты в тестовые файлы и передавал параметры через строку параметров самплера - есть в этом методе свое ограничения, но работает. И кстати при обрывании коннекшинов производительность упала раза в два против "фабричного" варианта, т.к. примерно половина активных сессий всегда в "закрывающемся" варианте, т.е. примерно 3 тысяч подключений хватает на примерно 1500 тридов, а дальше начинается конкуренция за свободные сессии и ошибки.