скала, акторы и фьючеры
Apr. 9th, 2015 11:10 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xacidя щетаю это надо увековечить (из сегодняшнего чата):
there are couple of tests in Jenkins failing due too long login it seems.
sometimes that login seems to take ~20 sec.
почему так получилось? блокирующие операции в акторах и при этом полное непонимание того как работают акторы в скале и тд. предложения разнести блокирующие и неблокирующие операции на разные пулы потоков, вызвало опять таки полное непонимание вопроса, хотя на самом деле это сделать было бы проще пареной репы. слова же о том что им акторы вообще не нужны в таких количествах, и для бизнес-логики лучше использовать композицию фьючеров, а акторы оставить только в тех немногих местах где нужно контроллировать некий уникальный ресурс (коннекшен, причем в любую сторону - от юзера, например, или в базу данных) привели в итоге к увольнению ...
причем я им подробнейшим образом раз десять все это говорил и объяснял. показывал конкретные проблемы причем в их же собственных тестах. особый садизм был в том что тесты падали только у меня - у них же все работало хорошо (по крайней мере по их словам). под словом "они" я имею ввиду трех людей (не буду естественно называть). в принципе они не плохие ребята только вот немного не понимают "вот этого вот". хотя на первый взгляд вроде бы квалифицированные люди. у них идея фикс что "всё можно и нужно сделать на одних только акторах". вот за это я акторы и не люблю :( но там где нужен актор там конечно лучше сделать актора. главное не злоупотреблять. но идиотизм здесь в том что акторы кажутся настолько простыми для понимания и использования (что на самом деле конечно же далеко не так!) что в итоге и приводит к подобным вот проблемам.
забавно еще то что в тех, опять таки достаточно редких, случаях где вот как раз на самом деле действительно было бы правильно взять актор в одном единственном числе и в нем считать какую нибудь сложную статистику которая интересна всем пользователям и при этом не зависит от того кто смотрит и при этом просто можно апдейтить эту статистику сообщениями по мере поступления новых данных - вот там как раз наоборот они создают каждому пользователю и на каждый его отдельный запрос нового актора и в нем считают для пользователя одну и ту же самую по сути статистику запросами в базу данных - вот это самый показательный мне кажется пример.
при этом мой код им не нравился :) при этом я говорил что код то мы сделаем в итоге как нужно, давайте сначала все таки вот эти вот проблемы исправим. помню вопрос главного по этим вопросам чувака из числа этих трех (на самом деле там так - есть два чувака которые вообще ничего там по сути не делают а только формально там руководят, а есть один чувак который типа взялся делать всё сам - в основном тупит он, а эти двое даже не знаю - видимо просто не хотят вмешиваться или еще какие у них там проблемы, видимо им похуй просто) ну так вот - спрашивает меня глядя в мой код:
"а зачем нужен DBActor? он же ничего не делает! он же просто выполняет запросы и всё!"
я говорю - ну да конечно, все правильно, запросы выполняет. а что он еще делать должен? он выполняет запросы в своем отдельном специальном пуле потоков. вот что он делает. а другие акторы - в другом пуле потоков работают и при этом уже запросов (то есть блокирующих операций) не выполняют. однако его это совершенно не убедило. в его понимании актор это какая-то бизнес-логика, а если актор типа никакой бизнес-логики не несет а просто выполняет функции которые ему в сообщении присылают и отсылает назад результат - то такой актор типа не нужен на самом деле. при этом создается миллион других разных акторов (вместо большинства из них могла бы быть простая монадическая функция с фьючером в результате) и потом композятся эти все акторы между собой через блядь блокирующее ожидание ответа одним актором от другого. при этом опять таки блядь они не понимают что по сути блокируют поток! то есть мало того что он (этот чувак который спрашивал) смешивает в одном пуле потоков блокирующие и не блокирующие операции в акторах, так он еще сам создает в своих же акторах свои же собственные блокирующие операции там где они вообще не нужны и можно было бы все сделать без блокировки и ожидания (а в монадических функциях все вообще простым for или в крайнем случае аппликативом композится чудесно). но нет же!
хорошо что я не стал работать там фулл-тайм, и есть на самом деле еще чем пока заниматься фуллтайм кроме них :)
there are couple of tests in Jenkins failing due too long login it seems.
sometimes that login seems to take ~20 sec.
почему так получилось? блокирующие операции в акторах и при этом полное непонимание того как работают акторы в скале и тд. предложения разнести блокирующие и неблокирующие операции на разные пулы потоков, вызвало опять таки полное непонимание вопроса, хотя на самом деле это сделать было бы проще пареной репы. слова же о том что им акторы вообще не нужны в таких количествах, и для бизнес-логики лучше использовать композицию фьючеров, а акторы оставить только в тех немногих местах где нужно контроллировать некий уникальный ресурс (коннекшен, причем в любую сторону - от юзера, например, или в базу данных) привели в итоге к увольнению ...
причем я им подробнейшим образом раз десять все это говорил и объяснял. показывал конкретные проблемы причем в их же собственных тестах. особый садизм был в том что тесты падали только у меня - у них же все работало хорошо (по крайней мере по их словам). под словом "они" я имею ввиду трех людей (не буду естественно называть). в принципе они не плохие ребята только вот немного не понимают "вот этого вот". хотя на первый взгляд вроде бы квалифицированные люди. у них идея фикс что "всё можно и нужно сделать на одних только акторах". вот за это я акторы и не люблю :( но там где нужен актор там конечно лучше сделать актора. главное не злоупотреблять. но идиотизм здесь в том что акторы кажутся настолько простыми для понимания и использования (что на самом деле конечно же далеко не так!) что в итоге и приводит к подобным вот проблемам.
забавно еще то что в тех, опять таки достаточно редких, случаях где вот как раз на самом деле действительно было бы правильно взять актор в одном единственном числе и в нем считать какую нибудь сложную статистику которая интересна всем пользователям и при этом не зависит от того кто смотрит и при этом просто можно апдейтить эту статистику сообщениями по мере поступления новых данных - вот там как раз наоборот они создают каждому пользователю и на каждый его отдельный запрос нового актора и в нем считают для пользователя одну и ту же самую по сути статистику запросами в базу данных - вот это самый показательный мне кажется пример.
при этом мой код им не нравился :) при этом я говорил что код то мы сделаем в итоге как нужно, давайте сначала все таки вот эти вот проблемы исправим. помню вопрос главного по этим вопросам чувака из числа этих трех (на самом деле там так - есть два чувака которые вообще ничего там по сути не делают а только формально там руководят, а есть один чувак который типа взялся делать всё сам - в основном тупит он, а эти двое даже не знаю - видимо просто не хотят вмешиваться или еще какие у них там проблемы, видимо им похуй просто) ну так вот - спрашивает меня глядя в мой код:
"а зачем нужен DBActor? он же ничего не делает! он же просто выполняет запросы и всё!"
я говорю - ну да конечно, все правильно, запросы выполняет. а что он еще делать должен? он выполняет запросы в своем отдельном специальном пуле потоков. вот что он делает. а другие акторы - в другом пуле потоков работают и при этом уже запросов (то есть блокирующих операций) не выполняют. однако его это совершенно не убедило. в его понимании актор это какая-то бизнес-логика, а если актор типа никакой бизнес-логики не несет а просто выполняет функции которые ему в сообщении присылают и отсылает назад результат - то такой актор типа не нужен на самом деле. при этом создается миллион других разных акторов (вместо большинства из них могла бы быть простая монадическая функция с фьючером в результате) и потом композятся эти все акторы между собой через блядь блокирующее ожидание ответа одним актором от другого. при этом опять таки блядь они не понимают что по сути блокируют поток! то есть мало того что он (этот чувак который спрашивал) смешивает в одном пуле потоков блокирующие и не блокирующие операции в акторах, так он еще сам создает в своих же акторах свои же собственные блокирующие операции там где они вообще не нужны и можно было бы все сделать без блокировки и ожидания (а в монадических функциях все вообще простым for или в крайнем случае аппликативом композится чудесно). но нет же!
хорошо что я не стал работать там фулл-тайм, и есть на самом деле еще чем пока заниматься фуллтайм кроме них :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-04-09 02:52 pm (UTC)no subject
Date: 2015-04-10 08:59 am (UTC)почему-то эффекта это не возымело. они считают что это какая-то чисто теоретическая проблема а на практике все будет нормально как попало. то есть они что вобще делают? они считают что акторы это просто классы-потоки (как сказал этот чувак - "акторы это легковесные потоки"). они берут пишут всю бизнес-логику прямо в акторах, разбивая ее по разным классам-акторам и запускают это всё просто без какого либо конфигурирования Akka (то есть в пуле потоков по умолчанию и работают все эти акторы в одном и том же пуле все сразу). бизнес-логика предполагает выполнение запросов к базе данных, причем дофига запросов. и к тому же нужно же как то там мап-редюсить типа жеж - вот они и мап-редюсят вызывая Await на Future который возвращается из ? в акторе. получается в итоге что - акторы постоянно блокируют потоки в пуле в котором исполняются. в пуле количество потоков достаточно ограниченно (поскольку он дефолтный а там по дефолту политика такая что максимальное количество потоков определяется количеством ядер процессора умножая это количество на достаточно небольшое число вроде как 3 (три)). в результате, поскольку акторов запускается дофигища, причем даже просто в фоновом режиме - постоянно работают (шедулятся) некие процессы-акторы, которые в фоновом режиме считают и кешируют некие данные из базы - потоки в пуле все фактически заблокированны. и поэтому когда например пользователь начинает логиниться то может оказаться так что ему придется долго (в тестах например 20 секунд оказывается мало и они по таймауту отваливаются) ждать пока какой нибудь актор закончит свою работу и освободит поток для актора который пользователя залогинит. короче полный бред на мой взгляд.
причем фиксится все это предельно просто - выносим все блокирующие запросы к базе в отдельный пул акторов (через актор-роутер), который будет сконфигурирован на работу в отдельном пуле потоков. причем этот отдельный пул потоков фактически всегда будет заблокирован и будет просыпаться только тогда когда ему нужно будет забрать очередной запрос из очереди - что на самом деле происходит практически мгновенно, и потом он сразу же просто ждет ответа из базы данных (блокируется) и процессор сразу переключается на потоки из другого пула, то есть этот пул который запросы выполняет он вообще процессор не использует. а все вычислительные задачи (без блокирующих вызовов) спокойно могут через fork-join работать если их тоже правильно разбить на отдельные вычислительные функции которые будут через map асинхронно вызываться (Future's вобщем имеются ввиду).
всё это было им не один раз рассказано и даже написан был код. чувак в ответ сказал что он кода этого не понимает и будет делать как умеет (то есть через жопу)
no subject
Date: 2015-04-10 04:35 pm (UTC)no subject
Date: 2015-09-12 01:41 am (UTC)С днём Рождения! Будьте Собой! ;) Богом! Частью Его, аватарой.
no subject
Date: 2015-09-12 11:04 pm (UTC)