Jacques Goto ...webtools/control/entitymaint in both 12.x and 9.x. In 9.x, the page loads instantly, in 12.04, it takes several seconds. Its anecdotally like 1000% slower. Thats the worst case I have seen.
I have hundreds of custom services, one of which runs before a custom inventory screen loads. I noticed this screen taking a long time to load and timed the service. It was taking about 2 seconds longer to run. It is basically a database lookup for unshipped orders, outstanding backorders, incoming inventory that needs packaged, etc. Nothing at all extraordinary. After timing it 10 times using System.currentMillsecs(), I noted it was taking about 18% more time on the same dataset. In this case, I actually put a profiler on both of them trying to see something different in the call trees (BTW, jProfiler is killer for this purpose). Unfortunately, I do not remember what was there except for a notably high amount of time in the logging code called from the delegator code tree even though logging was set to error and there were no errors. Someday, I'll get back to exploring this more. Note: this is with the 9.x code running Minerva and the 12.04 code running DBCP. If I put them both on Minverva, 12.04 is something 35% slower. I did not test the other way, i.e. DBCP on both because I am not sure it would run at all on 9.x code. Second, I have some custom rest services attached to external POJO screens. These services get a session, login, sometimes get a shopping cart, sometimes lookup prices and stock, etc. These felt slow as well, so I timed one of them(again using System.currentMillsecs()) and found the REST calls return 20% slower. This is essentially just the amount of time it takes on a local machine to get a JSON response from http://localhost:8080/someurl. You can't really see the time difference here unless you do it a hundred times because the time for each is so small, but for these POJO apps, that is exactly what they do, login, lookup a customer, get some inventory counts, etc, all in rapid succession. One more thing, in my 9.x code, I used Minerva because because DBCP was causing some errors. When I tried the DB stuff with Minerva in the 12.04 code, it was like 35% slower (both systems running Minerva). After discussing it with you here on the ML, I moved to DBCP and speed improved to a generally acceptable level (except as noted above). A months beta testing (with users doing mostly the same thing on old and new systems) shows there have been no issues with DBCP, as you suggested would be the case some time back. Even though 12.04 is significanly slower, I am moving ahead with its adoption because the widget code is failing periodically in 9.x because of locking issues and I love the MacroScreenRenderer stuff. I suspect that lots of the slowness is because incoming data is scrubbed for security and thats a good thing. Too bad about the Opentaps project. Their user interface in the 9.x timeframe was lightyears ahead of ofbiz in my view (and still is for that matter). There is lots of good stuff in there that would be useful in ofbiz. I was particularly impressed with their dojo based pagination. I too adopted some code from them, but contributed lots back as well. Hope this helps. Skip -----Original Message----- From: Jacques Le Roux [mailto:[email protected]] Sent: Monday, September 16, 2013 10:42 PM To: [email protected] Subject: Re: FW: Mirgration to OFBiz newer version Skip, I know what you are talking about, I had my share with a part of Opentaps adaptation for https://issues.apache.org/jira/browse/OFBIZ-4247 So believe me, I'm very cautious when deprecating stuff. BTW you said that "Things are about 20% slower." Where, in which areas, did you cross this? How did you measure? Jacques Skip wrote: > Jacques > > Being nearly done with this and my frustrations long since passed, I have > only a couple of things to say about this for future development. I have > been writing developer software for multiple decades and found from > experience that backward compatibility is your most important concern. > > No one should ever change stuff just because they do not like wording or > style. For example, there were wholesale changes to the xsd for widgets. > There was no real benefit to the change other than readability. It should > never have been done. Instead, both words should have been supported. For > me, this required days and days of search and replace for no value. > > Another is the replacement of new EntityExp() with > EntityCondition.makeCondition() etc. Someone decided that they liked this > better. That is the only possible reason for the change because the > underling code could have supported either or both APIs. This kind of stuff > is unforgivable in my view for developer software and that is what ofbiz is. > It has very little value OOTB and requires developers to give it life. Some > of us have thousands of other files written to these apis and to force us to > change them for no real value is frustrating to the maximum. > > Finally, the change in the password hash is the most agreggious example in > my view. It would have been a simple matter to use both (or in this case > all three hashing methods). When a password changes, use the newest, best > method, but allow the existing hashes stored in the database until changed. > I modified the ofbiz code to do exactly that and it works fine and took me > all of an hour once I spend several hours tracking down the problem. > > As Ofbiz contributors, I am sure you guys wear two hats. One as an Ofbiz > contributor and one as a developer using Ofbiz for end users who actually > pay you. As you make changes to Ofbiz code to implement something a > customer really wants, remember to not screw the hundreds (thousands ?) of > other Ofbiz developers who depend on it like you do. > > Backward compatibility is or should be your most important concern. Just > take a look at the compile log for Ofbiz and see how many deprecated Java > methods we still use. Then, look at how long they have been deprecated. > Some for decades. > > Thanks for all you do. > > Skip > > -----Original Message----- > From: Jacques Le Roux [mailto:[email protected]] > Sent: Saturday, September 14, 2013 10:01 AM > To: [email protected] > Subject: Re: FW: Mirgration to OFBiz newer version > > > Pierre Smits wrote: >> Jacques, >> >> Updating (or migrating) is determined by various factors. Each update >> brings risks and cost. Especially with a system in production. The >> (perceived value of the) improvements must weigh against the cost involved >> in implementing. >> >> I thank Skip for sharing the experience. I will surely use it as part of >> my migration plans. As far as I can go back it is the first time that it is >> done. Sharing implementation and upgrade experiences builds confidence. It >> should be encouraged. >> >> What worries me though is the experienced decrease in performance. > > This would need much more measures to know what we are talking about... > >> With kind regards, >> >> Pierre Smits
