Re: ADV: comparing BMC's ITSM v9 against older versions

[Tony Myers]

2 new blog posts on communities that are applicable to this thread. Thought I 
would post here.

1) from Vipul Jain - 
https://communities.bmc.com/community/bmcdn/bmc_remedy_ar_system/blog/2015/07/27/remedy-90-vs-81-performance-comparison
2) from Tony Myers - 
https://communities.bmc.com/community/bmcdn/bmc_remedy_ar_system/blog/2015/07/28/five-reasons-why-you-should-upgrade-to-remedy-9-today#comment-65696

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ADV: comparing BMC's ITSM v9 against older versions

[Singh, Bhanu]

BMC has been doing platform transformation for last many years and different 
components/modules have been released in different releases along the way. How 
long pure Java API have been there John; which do not use C-API underneath? 
This has been a journey to bring in Java technology stack and eliminate 
proprietary commodity code in every aspects of the platform.


1.   Mid-tier was moved to Java and JavaScript in 6.3 release.

2.   Dev Studio and Pure Java API was released in AR System 7.5 ( 6 years 
now)

3.   Plug-in and FTS code was moved to Java in 8.0 ( 4 years )

4.   Approval server, Assignment and DSO has been on Java since 8.1 ( 3.5 
years)

5.   All other peripheral plug-ins have been transformed into java in the 
earlier releases.

6.   AR Server is transformed into Java in Remedy 9.0

So, java is not new and all performance, scale and endurance characteristics 
have been measured and tested along the way with every little change that was 
made and shipped. The key is how it was done, it was done in such a way so that 
existing AR apps continue to work without any change and platform provided 
upgrade from existing environment to new. No platform in the world has done 
anything like that. It has gone through the right rigor and discipline to call 
it V9. You can do your homework as your solution lives and breathes on this 
platform and let’s know how it works and how easy it is for you NOW to extend 
and expand your solution using standard APIs and extended architecture.


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of John Sundberg
Sent: Friday, July 24, 2015 8:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: ADV: comparing BMC's ITSM v9 against older versions

**
OK - that was probably the wrong thing to call it.

Given - it is a ground up rewrite …

Ground up rewrites have new issues and new performance characteristics.
http://www.joelonsoftware.com/articles/fog69.html

So — anybody’s past performance experience is pretty irrelevant. — therefore we 
are sort of at a 1.0 scenario.

So 1.0 or “new” or 9 or ??? somebody wants to call it … in some ways we are all 
starting over.

And in other ways - we are just going from 8.1 to 9.0 — which for the most part 
applies to the ITSM application — not the engine.

What has happened is BMC has blended the applications and the engine as one 
version number.
(IMHO - to get rid of the concept of using ARS as a dev engine …. which IMHO - 
is what people liked about ARS all along)
Because - apps are easier to sell and more profitable than engines 
(temporarily). (See SNOW)

But - that versioning and blending is false IMHO.

It should not be called v9 instead it should be:
9.0/1.1
or maybe
9011

Who knows … I was just saying that our past performance experience has little 
to do with future experience, we are effectively at a 1.0 in terms of 
understanding performance and as a result CAUTION is wise. You are wise to 
consider that your existing hardware and OS environment is not necessarily the 
right fit for your new environment. With that bit of caution - you will be well 
served. Go blind around the corner ??? — well — go for it.

To simplify:
I see this whole transition something like this…

ARS went from a diesel engine to a rotary engine…

Everybody still knows how to drive the car (applications are the same).
It just takes different skills/understanding to work on the engine.


There should not be fear, lots of people know how to work with rotary engines, 
and there are tons of tools for it … it just is the case that the current 
skilled people with the diesel engine … need to “rethink/retrain” a bit — and 
then they will be caught up.


Now the next question … should we do something about this Pacer?



-John



On Fri, Jul 24, 2015 at 8:37 AM, Chris Hughes 
mailto:chris_hug...@bmc.com>> wrote:
> This release is really a 1.0 release (although called v9),
...
> Regardless, this is a first release of a complete ground up rewrite - so 
> CAUTION is the proper approach


Hi John -

It is is not  the case  that AR 9 is the first release of the AR Java Sever.  
The AR Java server was originally released to a limited customer base well over 
a year ago.  These customers have been running the stack in production for most 
of this past year as well.  The 9.0 release builds on the experience of those 
initial customers.

Regards,

Chris

___
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org<http://www.arslist.org>
"Where the Answers Are, and have been for 20 years"



--

John Sundberg
Kinetic Data, Inc.
"Your business. Your process."

651-556-0930 I 
john.sundb...@kineticdata.com<mailto:john.sundb...@kineticdata.com>
www.kineticdata.com<http://www.kineticdata.com/> I 
community.kineticdata.com<http://community.kineticdata.com/>

Re: ADV: comparing BMC's ITSM v9 against older versions

[Jason Miller]

Those Mazda Rotary engines are silly fast!

Then there is the Rotary Rocket
; which I made some parts for
in my past life as a welder (1 or 2 years before I met Remedy). Bummer it
was too hairy to move by Chinook or it would be in a small museum about 40
minutes away from me.

Jason

On Fri, Jul 24, 2015 at 8:19 AM, John Sundberg <
john.sundb...@kineticdata.com> wrote:

> **
> OK - that was probably the wrong thing to call it.
>
> Given - it is a ground up rewrite …
>
> Ground up rewrites have new issues and new performance characteristics.
> http://www.joelonsoftware.com/articles/fog69.html
>
> So — anybody’s past performance experience is pretty irrelevant. —
> therefore we are sort of at a 1.0 scenario.
>
> So 1.0 or “new” or 9 or ??? somebody wants to call it … in some ways we
> are all starting over.
>
> And in other ways - we are just going from 8.1 to 9.0 — which for the most
> part applies to the ITSM application — not the engine.
>
> *What has happened is BMC has blended the applications and the engine as
> one version number.*
> *(IMHO - to get rid of the concept of using ARS as a dev engine …. which
> IMHO - is what people liked about ARS all along)*
> *Because - apps are easier to sell and more profitable than engines
> (temporarily). (See SNOW)*
>
> But - that versioning and blending is false IMHO.
>
> It should not be called v9 instead it should be:
> 9.0/1.1
> or maybe
> 9011
>
> Who knows … I was just saying that our past performance experience has
> little to do with future experience, we are effectively at a 1.0 in terms
> of understanding performance and as a result CAUTION is wise. You are wise
> to consider that your existing hardware and OS environment is not
> necessarily the right fit for your new environment. With that bit of
> caution - you will be well served. Go blind around the corner ??? — well —
> go for it.
>
> To simplify:
> I see this whole transition something like this…
>
> ARS went from a diesel engine to a rotary engine…
>
> Everybody still knows how to drive the car (applications are the same).
> It just takes different skills/understanding to work on the engine.
>
>
> There should not be fear, lots of people know how to work with rotary
> engines, and there are tons of tools for it … it just is the case that the
> current skilled people with the diesel engine … need to “rethink/retrain” a
> bit — and then they will be caught up.
>
>
> Now the next question … should we do something about this Pacer?
>
>
>
> -John
>
>
>
> On Fri, Jul 24, 2015 at 8:37 AM, Chris Hughes 
> wrote:
>
>> > This release is really a 1.0 release (although called v9),
>> ...
>> > Regardless, this is a first release of a complete ground up rewrite -
>> so CAUTION is the proper approach
>>
>>
>> Hi John -
>>
>> It is is not  the case  that AR 9 is the first release of the AR Java
>> Sever.  The AR Java server was originally released to a limited customer
>> base well over a year ago.  These customers have been running the stack in
>> production for most of this past year as well.  The 9.0 release builds on
>> the experience of those initial customers.
>>
>> Regards,
>>
>> Chris
>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
>>
>
>
>
> --
>
> *John Sundberg*
> Kinetic Data, Inc.
> "Your business. Your process."
>
> 651-556-0930 I john.sundb...@kineticdata.com
> www.kineticdata.com I community.kineticdata.com
>
>
>  _ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ADV: comparing BMC's ITSM v9 against older versions

[John Sundberg]

OK - that was probably the wrong thing to call it.

Given - it is a ground up rewrite …

Ground up rewrites have new issues and new performance characteristics.
http://www.joelonsoftware.com/articles/fog69.html

So — anybody’s past performance experience is pretty irrelevant. —
therefore we are sort of at a 1.0 scenario.

So 1.0 or “new” or 9 or ??? somebody wants to call it … in some ways we are
all starting over.

And in other ways - we are just going from 8.1 to 9.0 — which for the most
part applies to the ITSM application — not the engine.

*What has happened is BMC has blended the applications and the engine as
one version number.*
*(IMHO - to get rid of the concept of using ARS as a dev engine …. which
IMHO - is what people liked about ARS all along)*
*Because - apps are easier to sell and more profitable than engines
(temporarily). (See SNOW)*

But - that versioning and blending is false IMHO.

It should not be called v9 instead it should be:
9.0/1.1
or maybe
9011

Who knows … I was just saying that our past performance experience has
little to do with future experience, we are effectively at a 1.0 in terms
of understanding performance and as a result CAUTION is wise. You are wise
to consider that your existing hardware and OS environment is not
necessarily the right fit for your new environment. With that bit of
caution - you will be well served. Go blind around the corner ??? — well —
go for it.

To simplify:
I see this whole transition something like this…

ARS went from a diesel engine to a rotary engine…

Everybody still knows how to drive the car (applications are the same).
It just takes different skills/understanding to work on the engine.


There should not be fear, lots of people know how to work with rotary
engines, and there are tons of tools for it … it just is the case that the
current skilled people with the diesel engine … need to “rethink/retrain” a
bit — and then they will be caught up.


Now the next question … should we do something about this Pacer?



-John



On Fri, Jul 24, 2015 at 8:37 AM, Chris Hughes  wrote:

> > This release is really a 1.0 release (although called v9),
> ...
> > Regardless, this is a first release of a complete ground up rewrite - so
> CAUTION is the proper approach
>
>
> Hi John -
>
> It is is not  the case  that AR 9 is the first release of the AR Java
> Sever.  The AR Java server was originally released to a limited customer
> base well over a year ago.  These customers have been running the stack in
> production for most of this past year as well.  The 9.0 release builds on
> the experience of those initial customers.
>
> Regards,
>
> Chris
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>



-- 

*John Sundberg*
Kinetic Data, Inc.
"Your business. Your process."

651-556-0930 I john.sundb...@kineticdata.com
www.kineticdata.com I community.kineticdata.com

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ADV: comparing BMC's ITSM v9 against older versions

[Chris Hughes]

> This release is really a 1.0 release (although called v9), 
...
> Regardless, this is a first release of a complete ground up rewrite - so 
> CAUTION is the proper approach


Hi John -

It is is not  the case  that AR 9 is the first release of the AR Java Sever.  
The AR Java server was originally released to a limited customer base well over 
a year ago.  These customers have been running the stack in production for most 
of this past year as well.  The 9.0 release builds on the experience of those 
initial customers.

Regards,

Chris

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ADV: comparing BMC's ITSM v9 against older versions

[John Sundberg]

C is a fine language.

Java is a fine language.

This release is really a 1.0 release (although called v9), it is a ground
up rewrite in a new language.

I think BMC has done a fantastic job in getting this 9.0 product out the
door and performing as well as it does and as compatible as it is.

(Kinetic runs on v9 with 0 changes to Kinetic — that is pretty impressive
as we work the BMC ARS API pretty heavily, Kinetic is really an API program
not an active link/filters program)

Regardless, this is a first release of a complete ground up rewrite - so
CAUTION is the proper approach, v9 will have a different performance
footprint than the previous releases.

I think the “interesting things” will be in the near future as BMC will be
able to benefit on the fact that they have rewritten this thing (and
probably got rid of a lot of code crap) and will be able to iterate faster.



-John












On Thu, Jul 23, 2015 at 12:41 AM, John Baker  wrote:

> Tony,
>
> Interesting feedback.
>
> > 3. Memory usage. V9 does use more RAM/Virtual memory than v8 because it
> is a JAVA application.
>
> I can not understand how a modern Java based application could be less
> efficient (CPU and memory) than the bloated C based arystem process,
> that had become so utterly inefficient in previous releases. Anything
> requiring GBs of RAM to even start, and vast amounts of CPU to become
> 'ready', is in need of help. Java isn't an inefficient platform - it's
> got an old school reputation for being a bit inefficient, but it's the
> application not the language at fault now-a-days...
>
>
> John
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>



-- 

*John Sundberg*
Kinetic Data, Inc.
"Your business. Your process."

651-556-0930 I john.sundb...@kineticdata.com
www.kineticdata.com I community.kineticdata.com

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

ADV: comparing BMC's ITSM v9 against older versions

[John Baker]

Tony,

Interesting feedback.

> 3. Memory usage. V9 does use more RAM/Virtual memory than v8 because it is a 
> JAVA application. 

I can not understand how a modern Java based application could be less
efficient (CPU and memory) than the bloated C based arystem process,
that had become so utterly inefficient in previous releases. Anything
requiring GBs of RAM to even start, and vast amounts of CPU to become
'ready', is in need of help. Java isn't an inefficient platform - it's
got an old school reputation for being a bit inefficient, but it's the
application not the language at fault now-a-days...


John

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ADV: comparing BMC's ITSM v9 against older versions

[Tony Myers]

Some things to consider when reading the current version of the report include 
the following...

1. Machine sizes and configuration. The deployment does not reflect a 
production environment or one that BMC would perform load and scale testing on 
in our lab – this is a reference environment that we would use to confirm Load 
scripting and general product regression testing and confirmation. Also, the 
report indicated OOTB configuration. BMC has tuning guidelines that are 
specific to load testing across the versions under test. These settings and 
tuning characteristics are also the ones we deploy in customer environments 
when they have scale requirements.
2. Scale. At scale and under load the CPU cycles are maxed out in your 
environment. Remedy is a CPU bound application and so once load impacts CPU 
beyond 80% then the hardware needs to be scaled in order to get accurate 
performance load results. We would never recommend our customers to run that 
usage load on a server that is exhibiting CPU activity at or close to 100% 
usage. We also carry this same methodology into our performance scale lab. We 
always recommend no more than 80% CPU load on a single VM or server instance.
3. Memory usage. V9 does use more RAM/Virtual memory than v8 because it is a 
JAVA application. BMC has compared this usage in the lab and we monitor for 
memory usage and related GC activity. Sizing the application under load will 
reveal how much RAM memory is required and then the JVM start size can be tuned 
to maximize the JVM and application performance.
4. Performance. BMC’s own internal testing of performance and scale with Remedy 
9, on a right-sized, tuned and configured environment is showing different 
results than those observed in the report. BMC sees a similar number to 8.1 in 
some use case scenarios while in others we actually see better performance and 
scale. We did not observe areas where performance regressed and if we had then 
this would have been a release gating defect. Lastly, there were some targeted 
areas that we focused on making significant improvements in performance that 
were not highlighted in the report. FTS-based search speed increased by up to 
11 times and CMDB reconciliation throughput more than doubled.
5. Codebase. It’s unclear if this is run using BETA code or the GA code in the 
report.

Thanks, TM

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

ADV: comparing BMC's ITSM v9 against older versions

[Iain McLeod]

Benchmarking BMC Remedy ITSM version 9.0 with Scapa TPP

Although the latest release of BMC Software’s Remedy ITSM platform – version 
9.0 – contains no major new features, it has been re-engineered from a C-based 
into a Java-based application. The significance of this change will, doubtless, 
be to facilitate future development of this business-critical system.

Scapa Technologies has a vast amount of experience in testing and monitoring 
this type of system and, along with our partners at Alderstone Consulting, we 
didn’t want to let the release of this milestone ITSM version pass by without 
conducting our own research into its potential performance levels. We, 
therefore, conducted a number of benchmark tests comparing version 9.0 against 
the last 2 major releases of ITSM.

Three identical environments were set up in order to conduct a fair analysis of 
how these ITSM releases compare. We installed ITSM 7.6.04, ITSM 8.1 SP2 and 
ITSM 9.0 with default configurations and used Scapa Test and Performance 
Platform (Scapa TPP) to perform the performance tests.

Our initial findings show that ITSM 9.0 has very similar performance 
characteristics to ITSM 7.6.04. However, ITSM 8.1 SP2 showed marginally 
improved stability at the edge of capacity than either of the other two 
versions. The graph below shows how the performance varies between the three 
main systems as the user count ramps up.

Benchmarking Remedy ITSM

Both ITSM 7.6.04 and ITSM 9.0 begin to behave erratically and user response 
times spike when the concurrent user load increased from 160 to 260, whereas 
the ITSM 8.1 environment remained constant. The full report of the results and 
findings of our tests, published by Alderstone Consulting, can be downloaded 
here.

Although these tests and the analysis of the results provide an interesting 
insight into the core stability and performance of these versions of ITSM, they 
are based on a very limited set of use cases. Similar tests examining the 
relative performance of your own system running version ITSM 9.0 would, without 
doubt, produce different findings, given that usage and environment, amongst 
other factors, all have an effect. Both Scapa Technologies and Alderstone 
Consulting can help you understand how your system would perform on ITSM 9.0. 
Alderstone Consulting is a product and services company, focusing on very high 
quality solutions in the IT Service Management, Data Centre Management, Cloud 
and Banking markets.

Scapa Technologies’ tools measure the end to end performance of the system, 
from the users’ perspective – the measurement that is most meaningful to your 
business operations, productivity and profits AND which produces the most 
accurate results. Our approach to testing, benchmarking, capacity planning, 
regression testing and production monitoring – by replicating real users’ 
actions to obtain their perspective of how your systems perform – is unique.

Our tools are capable of testing many systems, as well as a mixture of API and 
GUI tests at the same time, so you can identify bottlenecks and other potential 
issues quickly, to maintain performance and Service Level Agreements (SLAs). 
Our expertise in building custom workflows for a wide range of systems is 
second to none. This experience, coupled with the flexibility of our tools, is 
the best solution for building a robust, reliable testing framework for your 
unique application mix.

http://www.scapatech.com/benchmarking-bmc-remedy-itsm-version-9-0-with-scapa-tpp/

UPDATE: We have received an initial response from BMC on these preliminary 
findings, and they have provided some useful insights. Scapa and Alderstone 
will be working with the BMC performance teams over the next few weeks to pull 
together a more exhaustive and representative report based on production class 
environments using their recommended hardware sizing and configuration. Watch 
this space!

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"