I am trying to justify an upgrade of Grails from 1.0 to 1.3 and am wondering if I can add speed to the benefits. Does anyone have any empirical data on the subject?
It depends on a lot of things of course, and you haven't shared many details of your application. If you're using 1.0.3 or earlier, the default was to eagerly load collections and this bug was fixed in 1.0.4, so upgrading to 1.3 will certainly be faster when working with collections that you expect to be lazy-loaded. There have also been significant performance increases in GSP rendering in 1.1, 1.2, and 1.3. In addition GSPs are now precompiled when building a war file, so deployed applications use a lot less permgen.
Groovy has also gotten a lot faster from the 1.5.x that was used in 1.0 to the 1.7.8 that's used in 1.3.7.
There are other non-performance-related reasons to upgrade too. These include access to newer features that didn't exist in 1.0, plugins that won't work in older versions, and better IDE support.
That's a big jump and I don't for sure how much performance benefit you will see but it's certainty a lot. However, you should consider other advantages for the upgrade -- bug fixes, new features, easier gorm query, able to use latest plugins, etc.
FYI: We did upgrade from 1.* to 1.3, and it's requires some code change. Not a lot but take it as opportunity to clean and cut down on code count.
Related
Currently, we are using the JMeter 2.13 version for load testing. I am planning to migrate to JMeter 3.0 version.
I have not started working on the JMeter 3.0 till now.I don't know pros and cons of it.
Please suggest me, Shall I upgrade scripts to 3.0 or shall I continue with Jmeter2.13.
Of course it's better to go with newer version. Apart from new technologies are showing up each day and you need to be able to test them, there are always bug fixes and improvements, performance boost,...
For full list of fixes, improvements and new stuff, refer to change logs:
History of Previous Changes
By the way, if you are planning to move to newer version, why don't go to 3.2 directly?
3.1 to 3.2 Change Log
The general recommendataion is use the latest version of JMeter where possible
Pros: newer JMeter versions normally come with new features, performance improvements, bug fixes, etc.
Cons:
there could be some incompatible changes (normally you will need to override some JMeter Properties to revert JMeter configuration to match previous version behaviour, restore deprecated elements if you are using them in the tests, etc.
results on newer JMeter version might be not inline with what you used to have, i.e. due to aforementioned performance improvements JMeter could generate higher loads
Noticed that there is a 2.0 version of the Spring IO Platform available as a snapshot. I am looking to understand what might be driving the major version number change. Can someone with better insight into the changes share the themes here (or point to somewhere where this is better documented)?
Look at the "Upgrading" section of the documentation: http://docs.spring.io/platform/docs/2.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#upgrading-removal
Some dependencies were removed, which leads to a major version, since it's a breaking change.
We are evaluating reactor library for using it in our project. Our project was backed by spring context. So we needed a tool to build event-driven application which has the spring support.
Also our main area of focus was on ability to composing sequence of asynchronous events (Streams & Promises). In certain other use cases we might be in need of publisher/subscriber model or running long running processes asynchronously.
As I was evaluating, I noticed some of the following the latest released reactor-spring version is v1.1.3 with dependency on reactor-v1.1.3 which we could use.
But I also noticed the there’s reactor-v.2.0.0 (under development) which had quite a bit of changes especially in the area of Streams and Promises.
Please suggest me if it is a good idea for going with reactor-v1.1.3 with spring support or should we wait for reactor-v2.0 if we have to use more of Streams and Promises.
If we go ahead with reactor-v1.1.3.RELEASE how much code changes might be needed to get ourselves upgraded to v2.0.0.
I also wanted to check if we have any branch of ‘reactor samples’ for reactor-v1.1.3/v1.1.4. As of now I could see only one master branch available which has been updated to use reactor-v2.0.
Do we have the reactor API for latest release v1.1.4. Currently the API (https://reactor.github.io/docs/api/) points to Reactor 1.1.0 Release.
Where can I find the reactor-core-2.0.0 codebase? I am finding difficult to locate.
As I am new to this library, please feel free to correct me if any of my mentioned points/questions were incorrect. Thanks.
If you're starting new development, definitely go with Reactor 2.0. It's mainly the substantial improvements in the Stream and Promise APIs which resulted in having to bump the major version number. Differences in the rest of the codebase are pretty minimal. Converting between 1.1 code and 2.0 code requires some package renaming and a few tweaks here and there (like eliminating the use of the Deferred object in Stream 1.1).
The other major change that justifies a major point release bump is the implementation of the Reactive Streams specification. It's out of the scope of this question to discuss it further but it is an important part of Reactor moving forward. Being able to natively integrate with Akka Streams, Ratpack, RxJava, and other libraries that already (or will shortly) implement Reactive Streams is a huge benefit to Reactor 2.0.
The reactive-streams branch contains the code for Reactor 2.0. M1 is coming shortly and we'll start the process of updating the samples, though as you've noticed, some components like Spring support have already had to be bumped to Reactor 2.0 since they're relied on in some major almost-production applications.
I really love Grails but I was wondering how to get the performance benefits of Groovy 2.
The question is how to configure the development and production environments in order to get that "close to Java" performance boost.
So, if I setup:
* JDK 7
* Groovy 2 (indie JAR to use invokedynamic)
* Grails 2.2
are there any guidelines in order to really speed my webapp out-of-the-box?
And do I need to do any re-factoring in my Grails webapp codebase? I mean that dependency injection stuff like referencing services in controllers should be statically compiled or should I keep writing code as the docs say?
ps: I guess Groovy #CompileStatic and Grails might be a relevant question...
It depends on what might be slowing your web application down :) I know "it depends" is so often the answer, but it's still true.
Anyway, I've asked around and it seems that Grails and invokedynamic won't go together just yet. The reloading agent needs updating and there may be problems with the cglib/asm libraries used by Hibernate.
Regardless, internally Grails is making more and more use of #CompileStatic (for the stuff that wasn't already written in Java), so unless your app is doing a lot of work itself, you're unlikely to see a big boost with invokedynamic.
It would be useful to have some official information on this, but it's not out there right now.
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).