10 Comments

  1. Exactly Moisés, that’s the point that I missed.

    I’ve applied reactive in a stream solution and it’s work very well.

    You’ve confirmed my opinion about reactive, you cannot applied it as solution for every problem, but it depends a lot on your use case and how you’re going to access the data and not only the data stored into the database.

    I think it’s not so clear this concept of this topic, specially in the practical examples the I found out over the net.

    Thanks again for your time and your suggestions.

    1. Author

      you cannot applied it as solution for every problem, but it depends a lot on your use case and how you’re going to access the data and not only the data stored into the database

      Indeed, that’s the key. I tried to reflect on that in the conclusions of this guide and a bit during the introduction, but maybe not deep enough. I’m working now on the book and there I’ll try to give a bit more of practical comparison and insights.

  2. Hi Moisés,
    Sorry, it’s my fault, I hadn’t seen your test before writing my comment.

    I tested only the repository driver with a big number of users and req/sec and I found out big difference between reactive and no-reactive solution.

    Applying your test I get your expected result, reactive faster than no-reactive but I tried to make a test editing your method:
    quoteMongoReactiveRepository.findAll()

    excluding pagination and delay in order to compare it with no-reactive one:

    quoteMongoRepository.findAll().

    With a load of 10,000 entries I got the last solution better performant than reactive repository; I’d like to know your opinion about that conclusion.

    Thanks again for your time

    1. Author

      I guess you’re measuring the performance of the overall process of retrieving all the 10k entries. If you do that, I think it’s normal that you find the reactive solution slower since there is an overload in the implementation in order to make the whole process reactive. I’ve tried to find the paragraph explaining this same thing in the Project Reactor docs and Spring WebFlux (since I remember having seen it) but couldn’t find it this time.

      Take into account that if you ask Mongo for 10k entries in a reactive way but you block your process waiting for them to measure the amount of time to get the whole set, and you do the same in a non-reactive way, the latter might perform better since Mongo knows in advance that you can wait for the complete 10k entries, thus avoiding any kind of implementation overload. I don’t know how the mongo reactive driver works, but it surely requires some extra plumbing to make it reactive.

      The advantages of retrieving data in a reactive manner are different. Think of this: when you ask for those 10k entries, how long does it take to get the first 10 so you can send them to your client? Much less than using the blocking style.

  3. Hi Moisés.
    Thank you for sharing this article, I really enjoyed reading it.

    Just a question: have you ever tried to compare Reactive repository with a classical repository in order to understand the scalability of the last?
    I avoided using the stream of the output to keep the solutions comparable.
    Well, I’m struggling to make solution based on reactive Mongo repository performant as non-reactive solution but I keep on seeing better result with non-blocking.

    I published my result on github https://github.com/MarcoGhise/ReactiveMongoPerformance and I’d really appreciate to know what you think about this issue.

    1. Author

      Hi Marco,
      Given that I provide performance tests too, just give it a try and extend it / modify it to include Gatling tests if you wish. As you’ll see, I got different conclusions but scenarios might differ.
      Let me know if you find something I missed.

  4. Thanks for these tutorials. Is there any particular reason why you are implementing your own CORS filter instead of configuring CORS through @CrossOrigin annotation?

    1. Author

      Good one. That’s also possible, but take into account that the @CrossOrigin annotation works only at method or class level for a controller. That means you need to put that annotation in all your controllers to make it work. I’d rather use that approach when a fine-grain configuration is needed, while the CORS filter configuration applies overall to the entire application.

Comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.