Если делать на локальной машине, то у нас модель обучалась за 5 часов на 20Gb чеков (это вся наша история). Что касается быстроты выдачи из модели и фильтрации, то тут не замеряли — список товаров известен, мы рассчитали все связки заранее, засунули в базу (mongo) и сайт берёт их оттуда за миллисекунды. Расчёт всех связок на наших 0.5млн товаров проходит минут за 40. Вообщем, быстро, учитывая что делать это нужно далеко не каждую неделю.
Спасибо за тёплые слова). От Word2Vec не отказались, он всё так же генерирует первоначальные связки, просто потом мы ещё обогащаем другими алгоритмами, которые сравнивают фотки, нейминг и так далее.
Да, Вы знаете, я посмотрел исходники WebClient — там действительно используется класс HttpClient, только у него пакет не java.net.http, а reactor.netty.http.client. Видимо, я пропустил этот момент в процессе подготовки, спасибо за замечание, исправлю.
Согласен. Влияние на время при комфортной нагрузке оказывает только кэширование, параллелизация/объединение запросов. Тем не менее, нашей основной задачей было сделать так, чтобы сервис держал нагрузку при заданных показателях задержки. Но, как написано в этом комментарии проблемы начинаются под нагрузкой, если нет возможности поднять очень много инстансов приложения. Так как у нас этой возможности не было, мы сделали так, чтобы нагрузка держалась на тех инстансах, которые есть. Из этих соображений: да, я считаю, что мы сделали то, что надо)
За счет чего выросла производительность и уменьшилось время отклика сервера?
Тут очень важно учитывать нагрузку. Если приложение не нагружено. т.е. ему хватает ресурсов, то, как Вы правильно заметили, именно время ответа не изменится, независимо от того, какой подход использовать. Но, когда мы начинаем нагружать сервер, то мы видим, что потоки неограниченно растут, сервер сжирает абсолютно все ресурсы и запросы начинают отваливаться по таймауту, увеличивается общее количество ошибок и задержка.
На самом деле, абсолютно то же самое происходит, если хорошо нагрузить приложение с WebFlux — у любого решения будет своё пиковое prs. Просто из нашего опыта чтобы такое увидеть у WebFlux нужно гораздо больше нагрузки, нежели чем используя RestTemplate. Кстати, мы так и не смогли дойти до этой пиковой нагрузки — у нас начинали тормозить уже доменные сервисы, а оркестратору было норм)
Может от платформы (OS) зависит.
У нас Linux
Просто из за ресурсов переходит на неблокирующую схему с ее подводными камнями как то…
Я с Вами согласен) Просто у нас не было выбора — нужно было сделать так, чтобы необходимую нагрузку держало ограниченное количество инстансов. Естественно, гораздо проще было просто проскалироваться.
Прошу прощения, не правильно выразился.
Когда используется CompletableFuture, из отдельного тред пула берётся поток, который выполняет необходимые операции. После того, как его работа будет закончена, поток вернётся в тред пул и будет ждать пока он снова кому-то не потребуется.
В случае reactor-http-epoll-1 поток никогда не перейдёт в статус ожидания by design. Это очень хорошо видно, если запустить VisualVm: картинка
Вот и получается, что если потоки CompletableFuture заблокировать, ничего страшного не произойдёт, а вот если заблокировать потоки WebClient — у приложения будут проблемы.
Тестируем конечно. Но этот кейс тесты тогда отловить не смогли. Там оказался очень специфический запрос, при котором случалась блокировка и происходило это не каждый раз — только когда треду «повезло» попасть самому на себя.
Понятное дело, что тут был всё-таки косяк тестирования. Сейчас мы включили необходимые тест-кейсы в пайплайн, но когда деплоили на прод версию, мы были уверены что всё норм, т.к. сервис проходил нагрузку.
Я бы сказал, что мы напоролись на грабли смешивания асинхронного и реактивного кода. И CompletableFuture и WebClient позволяют писать в асинхронном стиле, одно возвращает Future, второе Mono/Flux. Эти конструкции похожи, но в случае с CompletableFuture код выполняется в треде, который больше ничем не должен заниматься и вернётся в пул когда всё сделает. В случае с WebClient — ещё как должен и в пул он не вернётся никогда.
Быть может вы имели в виду то, что Mono/Flux можно использовать и без реакта, например, как имплементацию паттерна publisher-subscriber?
Да, всё верно. Единственное что обычно API Gateway просто пробрасывает апи наверх апи доменного сервиса без бизнес-логики и по этому можно использовать коробочные решения. У нас тоже такое есть)
Согласен, на каноничность я не претендую. В моей практике именно каноничный TDD не помог отказаться от психотерапевта не прижился. Тут я рассказываю про свой опыт того что помогло.
Большое спасибо за ссылки на исследования! Я, к сожалению, не смог быстро ознакомится с исследованиями полностью, но внимательно прочитал Summary (Conclusions) каждого из них.
И, если честно, после прочитанного не могу разделить Вашего пессимизма.
В первом исследовании, действительно, пишут, что TDD не всегда улучшает high сohesion. Однако, автор уточняет, что утверждение верно, если TDD практикует программист с недостаточным количеством опыта.
Цитата
Here, the empirical data indicates that TDD does not always produce highly cohesive code as suggested in the literature. This is the case, at least, when the TDD users are inexperienced developers.
Во втором же, автор пишет в первом предложении Conclusions and Discussion, что TDD даёт плюшки без значимого снижения продуктивности
Цитата
Our experiences and distilled lessons learned, all point to the fact that TDD seems to be
applicable in various domains and can significantly reduce the defect density of developed
software without significant productivity reduction of the development team
Третье же исследование утверждает, что TDD в среднем на 21% улучшает качество кода.
В первом предложении Chapter 7 Conclusions.
Цитата
This study provided substantial evidence that Test-Driven Development is, indeed,
an effective tool for improving the quality of source code. Test-Driven Development
offered an overall improvement of 21% over code written using the test-last technique.
Considering the sheer volume of the codebases being analyzed, it’s reasonable to
conclude that the substantial difference is noteworthy.
И резюмируется следующее: «With an improvement in metrics scores of 21%, Test-Driven Development appears to be extremely valuable as a Software Engineering practice. This work lends a great deal of additional validity to the assertion by Martin (2007) that not following the disciplines of Test-Driven Development would simply be unprofessional.»
«1) TDD никак не влияет на архитектуру, ее определяет лишь полнота требований к продукту.»
Согласен, однако, если мы говорим о продукте, одни и те же бизнес-требования можно реализовать как монолитом так и микросервисами. Плюс, если мы говорим об одном сервисе, то требования к нему не расскажут Вам о разделении кода по слоям, принципам single responsibility и т.д. — с точки зрения требований абсолютно не важно каким образом Вы их реализовали.
«3) Самое главное. TDD создает иллюзию хорошего кода. Это как ЕГЭ, главное тесты пройти.»
Иллюзия хорошего кода — это характеристика конечного продукта. Независимо от того как вы к нему пришли. Можно написать откровенно плохой код, покрыть его на 100% тестами и Вы получите ту же самую иллюзию. TDD — это всего лишь подход к процессу написания приложения. Вы же не измените своего отношения к качеству кода как к конечному продукту, если узнаете что он писался по TDD или нет.
«TDD пытается поставить с ног на голову и говорит, что именно проверка на ошибки и есть способ написания кода.»
В этой статье, я бы хотел предложить как способ написания кода первоначальный вопрос: «Что я от этого кода, собственно говоря, хочу?». Я не использую термин «проверки на ошибки». По моему мнению, покрытие кода тестами — это всего лишь дополнительная плюшка сверху.
«Может быть, просто начнем думать над тем кодом, что пишем, а не надеяться на 50 проверок?»
Вы абсолютно правы, я именно к этому и призываю). Абсолютно бесполезно писать тесты ради тестов.
Временная разница между несколькими итерациями была полгода. Я уже не особо помнил, что было в первый раз, так как погрузился в другие задачи. Также, пока я не написал приложение второй раз, довольно тяжело было оценить качество первой итерации. После первого написания я считал, что архитектура, в общем-то, не так уж и плоха.
Тут очень важно учитывать нагрузку. Если приложение не нагружено. т.е. ему хватает ресурсов, то, как Вы правильно заметили, именно время ответа не изменится, независимо от того, какой подход использовать. Но, когда мы начинаем нагружать сервер, то мы видим, что потоки неограниченно растут, сервер сжирает абсолютно все ресурсы и запросы начинают отваливаться по таймауту, увеличивается общее количество ошибок и задержка.
На самом деле, абсолютно то же самое происходит, если хорошо нагрузить приложение с WebFlux — у любого решения будет своё пиковое prs. Просто из нашего опыта чтобы такое увидеть у WebFlux нужно гораздо больше нагрузки, нежели чем используя RestTemplate. Кстати, мы так и не смогли дойти до этой пиковой нагрузки — у нас начинали тормозить уже доменные сервисы, а оркестратору было норм)
У нас Linux
Я с Вами согласен) Просто у нас не было выбора — нужно было сделать так, чтобы необходимую нагрузку держало ограниченное количество инстансов. Естественно, гораздо проще было просто проскалироваться.
Когда используется CompletableFuture, из отдельного тред пула берётся поток, который выполняет необходимые операции. После того, как его работа будет закончена, поток вернётся в тред пул и будет ждать пока он снова кому-то не потребуется.
В случае reactor-http-epoll-1 поток никогда не перейдёт в статус ожидания by design. Это очень хорошо видно, если запустить VisualVm:
картинка
Вот и получается, что если потоки CompletableFuture заблокировать, ничего страшного не произойдёт, а вот если заблокировать потоки WebClient — у приложения будут проблемы.
Понятное дело, что тут был всё-таки косяк тестирования. Сейчас мы включили необходимые тест-кейсы в пайплайн, но когда деплоили на прод версию, мы были уверены что всё норм, т.к. сервис проходил нагрузку.
Быть может вы имели в виду то, что Mono/Flux можно использовать и без реакта, например, как имплементацию паттерна publisher-subscriber?
не помог отказаться от психотерапевтане прижился. Тут я рассказываю про свой опыт того что помогло.И, если честно, после прочитанного не могу разделить Вашего пессимизма.
В первом исследовании, действительно, пишут, что TDD не всегда улучшает high сohesion. Однако, автор уточняет, что утверждение верно, если TDD практикует программист с недостаточным количеством опыта.
Во втором же, автор пишет в первом предложении Conclusions and Discussion, что TDD даёт плюшки без значимого снижения продуктивности
applicable in various domains and can significantly reduce the defect density of developed
software without significant productivity reduction of the development team
Третье же исследование утверждает, что TDD в среднем на 21% улучшает качество кода.
В первом предложении Chapter 7 Conclusions.
an effective tool for improving the quality of source code. Test-Driven Development
offered an overall improvement of 21% over code written using the test-last technique.
Considering the sheer volume of the codebases being analyzed, it’s reasonable to
conclude that the substantial difference is noteworthy.
И резюмируется следующее:
«With an improvement in metrics scores of 21%, Test-Driven Development appears to be extremely valuable as a Software Engineering practice. This work lends a great deal of additional validity to the assertion by Martin (2007) that not following the disciplines of Test-Driven Development would simply be unprofessional.»
Согласен, однако, если мы говорим о продукте, одни и те же бизнес-требования можно реализовать как монолитом так и микросервисами. Плюс, если мы говорим об одном сервисе, то требования к нему не расскажут Вам о разделении кода по слоям, принципам single responsibility и т.д. — с точки зрения требований абсолютно не важно каким образом Вы их реализовали.
«3) Самое главное. TDD создает иллюзию хорошего кода. Это как ЕГЭ, главное тесты пройти.»
Иллюзия хорошего кода — это характеристика конечного продукта. Независимо от того как вы к нему пришли. Можно написать откровенно плохой код, покрыть его на 100% тестами и Вы получите ту же самую иллюзию. TDD — это всего лишь подход к процессу написания приложения. Вы же не измените своего отношения к качеству кода как к конечному продукту, если узнаете что он писался по TDD или нет.
«TDD пытается поставить с ног на голову и говорит, что именно проверка на ошибки и есть способ написания кода.»
В этой статье, я бы хотел предложить как способ написания кода первоначальный вопрос: «Что я от этого кода, собственно говоря, хочу?». Я не использую термин «проверки на ошибки». По моему мнению, покрытие кода тестами — это всего лишь дополнительная плюшка сверху.
«Может быть, просто начнем думать над тем кодом, что пишем, а не надеяться на 50 проверок?»
Вы абсолютно правы, я именно к этому и призываю). Абсолютно бесполезно писать тесты ради тестов.