A
Ну не каждый же раз наверно
а кто сказал что каждый раз?
Size: a a a
2019 August 27
A
вопрос был в том как сократить потребление памяти
A
Artyom
test fragments / module controllers используются?
у меня кейс был когда из-за плохой структуры много жрали test compiler классы
W
Artyom
вопрос был в том как сократить потребление памяти
Написать всё на C))
A
было
A
A
стало
VG
вижу, что в памяти хранится очень много заголовкой запросов. Нафига?
Как этого избежать...
Как этого избежать...
A
я бы советовал снимать heap dump и с MAT смотреть через dominator tree
ВС
Loop - долго. Для уменьшения потребления памяти в асинхронных тестах (с ожиданием выполнения запроса) стараюсь не использовать циклы. А использовать потоки, отдельные катушки. А синхронизацию между ними делаю через SharedHashMap, jsr-223, Property
ВС
вижу, что в памяти хранится очень много заголовкой запросов. Нафига?
Как этого избежать...
Как этого избежать...
Тема для доклада. Думаю пока что, почти никто не знает
ВС
Вероятно, заголовок запроса ввчисляется для каждого потока свой. Это точно. И возможно для каждого запроса тоже. И вот их стало 900 х 10 = много
VG
Loop - долго. Для уменьшения потребления памяти в асинхронных тестах (с ожиданием выполнения запроса) стараюсь не использовать циклы. А использовать потоки, отдельные катушки. А синхронизацию между ними делаю через SharedHashMap, jsr-223, Property
это решение, но немного гемморойное.
Нам нужно держать кучу пользаков для асинхронной работы.
Всё бы ничего, но у них раз в несколько минут протухают сессии а постоянно прелогиниваться нельзя.
то есть надо хэшмапу для самих действий+вторую хэшмапу с сессиями и временем их жизни
Нам нужно держать кучу пользаков для асинхронной работы.
Всё бы ничего, но у них раз в несколько минут протухают сессии а постоянно прелогиниваться нельзя.
то есть надо хэшмапу для самих действий+вторую хэшмапу с сессиями и временем их жизни
ВС
это решение, но немного гемморойное.
Нам нужно держать кучу пользаков для асинхронной работы.
Всё бы ничего, но у них раз в несколько минут протухают сессии а постоянно прелогиниваться нельзя.
то есть надо хэшмапу для самих действий+вторую хэшмапу с сессиями и временем их жизни
Нам нужно держать кучу пользаков для асинхронной работы.
Всё бы ничего, но у них раз в несколько минут протухают сессии а постоянно прелогиниваться нельзя.
то есть надо хэшмапу для самих действий+вторую хэшмапу с сессиями и временем их жизни
Думаю можно сделать круче. Сделать катушку, которая будет только токены получать и в очередь Rabbitmq их класть. С указанием времени жизни. Тогда rabbit сам будет старые вычищать.
Другие катушки просто получают токен. Тут же возвращают его в очередь, но с другой стороны. И делают свое дело - используют токен
Другие катушки просто получают токен. Тут же возвращают его в очередь, но с другой стороны. И делают свое дело - используют токен
M
Думаю можно сделать круче. Сделать катушку, которая будет только токены получать и в очередь Rabbitmq их класть. С указанием времени жизни. Тогда rabbit сам будет старые вычищать.
Другие катушки просто получают токен. Тут же возвращают его в очередь, но с другой стороны. И делают свое дело - используют токен
Другие катушки просто получают токен. Тут же возвращают его в очередь, но с другой стороны. И делают свое дело - используют токен
я типа такого делал, но с influxdb
ВС
Rabbit не напряжется. Он быстрый. И тест можно будет сделать распределенным даже. Для rabbit есть плагин. Есть пара версий, где можно указать заголовки.
ВС
Или вместо rabbit использовать HP Virtual Table Server
ВС
Вот это тебе понравится. Интерфейс - rest http. Плагинов не нужно никаких. Но там вычищать протухшие токены надо будет самому