We're looking @ taking the plunge and UG'ing our 4.5.2 system to 6.3
After reviewing
the sizing docs provided by our integrator, it would seem we need a much
larger server
environment to support 6.3 v. 4.5.

Particulars: Currently running 4.5 on Solaris with Oracle 8i
(co-located). Dual 400Mhz
procs, w/2GB RAM and running about 11K transactions/mo. (yes, all one on
one machine,
along with a coupld of other apps.)

Recommended: 2-3 dedicated quad 1.2Ghz machines w/4GB RAM (1 quad for
App Server,
1 quad for DB, and 1 dual for Mid-tier/web.

Is there this much software bloat on 6.3? This seems unrealistic to me....

Is there data points to draw from?


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

What is your highest concurrent user base?

Keep in mind that:
DB Server is more i/o bound than cpu bound
ARS Server is more cpu bound than i/o bound, though probably not by much

Regardless of the configuration you choose, you can bring a system to
it's knees if you write Remedy workflow without the Db and network in
mind, and this is esp. true of mid-tier use. Poorly written apps will
eat whatever you give them and well written apps can fly on less
resources.

The biggest reason I've seen to upgrade the hardware between Remedy
version does not lay with the Remedy server, but more wiht the
applications. In the advent of the CMDB, larger hardware is a
necessity because you can run into contention issues between the time
required to complete class changes and the highest configurable
arserver timeout periods. Which brings me to my next question. Are
you using or do you plan to use the CMBD?

Axton


On 11/7/05, Wilson Mohr wrote:
> We're looking @ taking the plunge and UG'ing our 4.5.2 system to 6.3
> After reviewing
> the sizing docs provided by our integrator, it would seem we need a much
> larger server
> environment to support 6.3 v. 4.5.
>
> Particulars: Currently running 4.5 on Solaris with Oracle 8i
> (co-located). Dual 400Mhz
> procs, w/2GB RAM and running about 11K transactions/mo. (yes, all one on
> one machine,
> along with a coupld of other apps.)
>
> Recommended: 2-3 dedicated quad 1.2Ghz machines w/4GB RAM (1 quad for
> App Server,
> 1 quad for DB, and 1 dual for Mid-tier/web.
>
> Is there this much software bloat on 6.3? This seems unrealistic to me....
>
> Is there data points to draw from?
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>

Well, we haven't used the CMDB (obviously) and have no immediate plans to...


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

If you are using home grown apps and have a development environment, I
would encourage you to upgrade to 6.3 in that environment and perform
some simulations to stress the system.

The biggest differences between 4.5 and 6.3 (in terms of
architecture/resource requirements) follow:
- The adoption of java for certain subsystems like the email engine,
flashboards, and mid-tier. To be frank, Java can be a resource pig
(cpu and memory). The way it allocates and deallocates memory through
garbage collection is an ineffeciency and causes apps to require more
memory. A second ineffeciency of Java is the unavoidable overhead
associated with higher level programming languages.
- The new interfaces for external integrations: plugin server
(ARDBC/AREA/Filter), view forms, and web services.
- For Remedy developed applications, apps that use external processes
or plugins to manipulate form/workflow definitions. These can be
bound by unconfigurable timeouts on slower systems resulting in half
completed operations for form/workflow definition/metadata changes,
which are not pretty to deal with after the fact.

If you use these subsystems, they have not really changed all that much:
- approval server
- dso server

If costs are a concern, you may be able architect your environment to
offload these subsystems to newer servers while maintaining your
existing servers for your core arsystem server. The following
subsystems are capable of running on seperate hardware:
- email
- mid-tier (which includes the flashboards rendering)
- flashboards history collection server
- plug-in server (AREA, ARDBC, Filter)

Ask yourself these questions:
- What types of utilization are you seeing on your current system?
(high cpu usage, fully throttled disks, fully throttled network
interfaces, memory usage)
- Are there major points of contention that need to be addressed in
the near term? (such as disk subsystem, cpu usage, network interface,
memory)
- Are you expecting lots of growth for the system in the near or
medium term? (in terms of user base, new apps, new integrations)
- Do you expect large changes in your application architecture?
(version upgrade, rewrites, etc.)

IMHO, if you are not expecting new versions of the applications you
use and are not expecting a huge jump in the usage of the system,
going from where you are to where you are proposing is probably not
justified. Quad cpu machines are not cheap, esp. 1.2ghz sun machines.
If you are expecting a growth in the medium term, go with an
architecture that allows for growth by using servers capable of
handling more cpu's and memory as needed and properly subdividing the
seperate systems accordingly. Why pay for more than you need.

Axton

Axton,

Although I agree with some of your thoughts, I am going to correct a few
mistruths in your posting.

"To be frank, Java can be a resource pig", is perhaps the biggest mistruth
that one can make. Java can be slow and memory hungry, but only when the
program has been written by a poor developer, and that's the same for any
application (including C based applications such as the AR System).

"Java is a high level programming language". Well, it depends on your
definition of 'high level'. Java is somewhat easier to use than C, however
there's no reason why extremely complex applications can not be written
using bit shifting and other 'low level' constructs. In today's climate of
'easy to use' programming languages, I rather think that PHP would be
considered a high level language and Java would sit somewhere between C++
and PHP. Python is an interesting example, and although I could throw some
Python at you that most so called Python coders would simply not understand,
I still consider Python and Java to be equals. In fact, I rather think the
Python constructs are much nicer than Java, even after Java 1.5's new
auto-boxing additions.

"New interfaces for external integrations". If this wasn't written
efficiently then that is entirely the fault of the coder. There's no reason
for an application to become overly heavyweight because interfaces for new
features have been added. If one were to add twenty plugins, then I'd expect
the system to run rather more slowly, however with no additional
plugins/etc. running, I should not expect to see any obvious difference in
performance. Even then, I expect well written plugins with an efficient
threading model. Let me draw your attention to the Apache 2 webserver, which
has a fantastic plugin architecture that doesn't require gigs of RAM (in
fact, it'll happily run on a 32meg 100Mhz machine).

You are correct that Remedy are using C/Java bindings to add new
functionality, and this is completely bizarre. Take the webservices
extensions; if you reverse engineer the websvc51.jar and look at the code (I
include introspection in the term 'reverse engineer'), not only will you
find a whole bunch of unused classes but test methods that do not actually
function!

But taking a step back, why on earth did someone decide to use the Java
implementation of Axis to provide webservices in the AR System, when the
Apache group provide a perfectly good C implementation? Had someone
suggested this for a final project at the University I attended, they'd have
been kicked out (and quite rightly so).

Application maturity is something we have also not covered. I expect well
written applications to become more efficient with time, and there are
plenty of open source projects that demonstrate exactly this. Look at the
huge strides being made with OpenOffice; version 1.0 would spend so long
starting up that I could make a cup of tea, yet version 2.0 is far closer to
the MS Office 'benchmark'. Look at Mozilla; a bloaty and memory hungry
browser that's now much faster and efficient than IE. Yet, the AR System
seems to become more bloated and memory hungry with every release, while
adding little in the way of 'stunning new features' - in the real world,
webservices and a plugin server are not great advances, and certainly not
worthy of a XGhz quad processor machine!

Putting aside a few mistruths around the use of Java, I completely agree
with your conclusions over hardware requirements. There's no reason to start
spending thousands of dollars on hardware, and if there is, the problem is
most likely in the software.



John

Java System Solutions : http://www.javasystemsolutions.com


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Agree with the comments on java, but consider the source of the java
apps most commonly used with Remedy. I have not been too impressed
with the performance or system consumption of the email engine,
mid-tier (have not looked at 6.3 yet), and flashboards history
collection. Why does my flashboard server need 768mb memory to
collect history for 40 fb variables? Seems a bit excessive to me when
it executes around 10 sql queries per minute which results in around
1000 rows to process per minute.

I say java is a higher level programming language because it
incorporates several things that differentiate it:
- not having to explicitly manage memory operations
- not having to worry about OS dependant implementations
- not having to worry about character sets
- OOP concepts and design
- large number of classes that come with java to address things that
most other programming languages require third party or custom
libraries/modules

I'm currently learning java now, so most of it is new to me. Just
trying to share what I've seen.

Commenting on application maturity is a tough one with Remedy
products. I say tough because so many of the products are neglected
for long periods of time. Take EIE, approval, Tivoli adapters,
migrator, and so on. EIE and approval server have been in a state of
stagnation since v4. Migrator has not changed much since it was
bought from Ostream, though IMHO there is a lot of room for
improvement for all these apps, but it's just not happening.

Axton

On 11/8/05, John Baker wrote:
> Axton,
>
> Although I agree with some of your thoughts, I am going to correct a few
> mistruths in your posting.
>
> "To be frank, Java can be a resource pig", is perhaps the biggest mistruth
> that one can make. Java can be slow and memory hungry, but only when the
> program has been written by a poor developer, and that's the same for any
> application (including C based applications such as the AR System).
>
> "Java is a high level programming language". Well, it depends on your
> definition of 'high level'. Java is somewhat easier to use than C, however
> there's no reason why extremely complex applications can not be written
> using bit shifting and other 'low level' constructs. In today's climate of
> 'easy to use' programming languages, I rather think that PHP would be
> considered a high level language and Java would sit somewhere between C++
> and PHP. Python is an interesting example, and although I could throw some
> Python at you that most so called Python coders would simply not understand,
> I still consider Python and Java to be equals. In fact, I rather think the
> Python constructs are much nicer than Java, even after Java 1.5's new
> auto-boxing additions.
>
> "New interfaces for external integrations". If this wasn't written
> efficiently then that is entirely the fault of the coder. There's no reason
> for an application to become overly heavyweight because interfaces for new
> features have been added. If one were to add twenty plugins, then I'd expect
> the system to run rather more slowly, however with no additional
> plugins/etc. running, I should not expect to see any obvious difference in
> performance. Even then, I expect well written plugins with an efficient
> threading model. Let me draw your attention to the Apache 2 webserver, which
> has a fantastic plugin architecture that doesn't require gigs of RAM (in
> fact, it'll happily run on a 32meg 100Mhz machine).
>
> You are correct that Remedy are using C/Java bindings to add new
> functionality, and this is completely bizarre. Take the webservices
> extensions; if you reverse engineer the websvc51.jar and look at the code (I
> include introspection in the term 'reverse engineer'), not only will you
> find a whole bunch of unused classes but test methods that do not actually
> function!
>
> But taking a step back, why on earth did someone decide to use the Java
> implementation of Axis to provide webservices in the AR System, when the
> Apache group provide a perfectly good C implementation? Had someone
> suggested this for a final project at the University I attended, they'd have
> been kicked out (and quite rightly so).
>
> Application maturity is something we have also not covered. I expect well
> written applications to become more efficient with time, and there are
> plenty of open source projects that demonstrate exactly this. Look at the
> huge strides being made with OpenOffice; version 1.0 would spend so long
> starting up that I could make a cup of tea, yet version 2.0 is far closer to
> the MS Office 'benchmark'. Look at Mozilla; a bloaty and memory hungry
> browser that's now much faster and efficient than IE. Yet, the AR System
> seems to become more bloated and memory hungry with every release, while
> adding little in the way of 'stunning new features' - in the real world,
> webservices and a plugin server are not great advances, and certainly not
> worthy of a XGhz quad processor machine!
>
> Putting aside a few mistruths around the use of Java, I completely agree
> with your conclusions over hardware requirements. There's no reason to start
> spending thousands of dollars on hardware, and if there is, the problem is
> most likely in the software.
>
>
>
> John
>
> Java System Solutions : http://www.javasystemsolutions.com
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>

**

Good Comment, Hear, Hear !

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton
Sent: Tuesday, November 08, 2005 10:18 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy Server Sizing

Agree with the comments on java, but consider the source of the java apps most commonly used with Remedy. I have not been too impressed with the performance or system consumption of the email engine, mid-tier (have not looked at 6.3 yet), and flashboards history collection. Why does my flashboard server need 768mb memory to collect history for 40 fb variables? Seems a bit excessive to me when it executes around 10 sql queries per minute which results in around 1000 rows to process per minute.

I say java is a higher level programming language because it incorporates several things that differentiate it:
- not having to explicitly manage memory operations
- not having to worry about OS dependant implementations
- not having to worry about character sets
- OOP concepts and design
- large number of classes that come with java to address things that most other programming languages require third party or custom libraries/modules

I'm currently learning java now, so most of it is new to me. Just trying to share what I've seen.

Commenting on application maturity is a tough one with Remedy products. I say tough because so many of the products are neglected for long periods of time. Take EIE, approval, Tivoli adapters, migrator, and so on. EIE and approval server have been in a state of stagnation since v4. Migrator has not changed much since it was bought from Ostream, though IMHO there is a lot of room for improvement for all these apps, but it's just not happening.

Axton

On 11/8/05, John Baker wrote:
> Axton,
>
> Although I agree with some of your thoughts, I am going to correct a
> few mistruths in your posting.
>
> "To be frank, Java can be a resource pig", is perhaps the biggest
> mistruth that one can make. Java can be slow and memory hungry, but
> only when the program has been written by a poor developer, and that's
> the same for any application (including C based applications such as the AR System).
>
> "Java is a high level programming language". Well, it depends on your
> definition of 'high level'. Java is somewhat easier to use than C,
> however there's no reason why extremely complex applications can not
> be written using bit shifting and other 'low level' constructs. In
> today's climate of 'easy to use' programming languages, I rather think
> that PHP would be considered a high level language and Java would sit
> somewhere between C++ and PHP. Python is an interesting example, and
> although I could throw some Python at you that most so called Python
> coders would simply not understand, I still consider Python and Java
> to be equals. In fact, I rather think the Python constructs are much
> nicer than Java, even after Java 1.5's new auto-boxing additions.
>
> "New interfaces for external integrations". If this wasn't written
> efficiently then that is entirely the fault of the coder. There's no
> reason for an application to become overly heavyweight because
> interfaces for new features have been added. If one were to add twenty
> plugins, then I'd expect the system to run rather more slowly, however
> with no additional plugins/etc. running, I should not expect to see
> any obvious difference in performance. Even then, I expect well
> written plugins with an efficient threading model. Let me draw your
> attention to the Apache 2 webserver, which has a fantastic plugin
> architecture that doesn't require gigs of RAM (in fact, it'll happily run on a 32meg 100Mhz machine).
>
> You are correct that Remedy are using C/Java bindings to add new
> functionality, and this is completely bizarre. Take the webservices
> extensions; if you reverse engineer the websvc51.jar and look at the
> code (I include introspection in the term 'reverse engineer'), not
> only will you find a whole bunch of unused classes but test methods
> that do not actually function!
>
> But taking a step back, why on earth did someone decide to use the
> Java implementation of Axis to provide webservices in the AR System,
> when the Apache group provide a perfectly good C implementation? Had
> someone suggested this for a final project at the University I
> attended, they'd have been kicked out (and quite rightly so).
>
> Application maturity is something we have also not covered. I expect
> well written applications to become more efficient with time, and
> there are plenty of open source projects that demonstrate exactly
> this. Look at the huge strides being made with OpenOffice; version 1.0
> would spend so long starting up that I could make a cup of tea, yet
> version 2.0 is far closer to the MS Office 'benchmark'. Look at
> Mozilla; a bloaty and memory hungry browser that's now much faster and
> efficient than IE. Yet, the AR System seems to become more bloated and
> memory hungry with every release, while adding little in the way of
> 'stunning new features' - in the real world, webservices and a plugin
> server are not great advances, and certainly not worthy of a XGhz quad processor machine!
>
> Putting aside a few mistruths around the use of Java, I completely
> agree with your conclusions over hardware requirements. There's no
> reason to start spending thousands of dollars on hardware, and if
> there is, the problem is most likely in the software.
>
>
>
> John
>
> Java System Solutions : http://www.javasystemsolutions.com
>
>
> UNSUBSCRIBE or access ARSlist Archives at
> http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>


This posting was submitted via the Web interface

Axton,

- not having to explicitly manage memory operations

Unless you're using weak/soft references.

- not having to worry about OS dependant implementations

There are perfectly good libraries in C to allow the same kind of ignorance.

- not having to worry about character sets

You do have to worry about them, and you will note Remedy have failed to
understand them for years. The horrors inside the AR API Util class (reverse
engineer back to source, read their character set matching/conversion)
demonstrates that if you don't worry, you get it wrong.

- OOP concepts and design

C++ provides very much the same, and other variants of C++ (such as
'developer studios') have nice little wizards to do all this for you :)

- large number of classes that come with java to address things that most
other programming languages require third party or custom libraries/modules

That's only because Sun 'own' Java, however parts of the JDK are unashamedly
'pinched' from the open source world, with Logging and Regular Expressions
being obvious examples.

In my mind, Java is a 'higher level' language, but it's not a 'high level'
language when you put it along side PHP, VB, Visual XXX, etc. :)


John

Java System Solutions : http://www.javasystemsolutions.com


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

John:

- not having to explicitly manage memory operations
> Unless you're using weak/soft references.

Like I said, I'm still learning the language


- not having to worry about OS dependant implementations
> There are perfectly good libraries in C to allow the same kind of ignorance.

Ignorance is bliss


- not having to worry about character sets
> You do have to worry about them, and you will note Remedy have failed to
understand them for years. The horrors inside the AR API Util class (reverse
engineer back to source, read their character set matching/conversion)
demonstrates that if you don't worry, you get it wrong.

I was referring to the explicit requirement that the values contained
in variables of type char be treated as Unicode characters


- OOP concepts and design
> C++ provides very much the same, and other variants of C++ (such as
'developer studios') have nice little wizards to do all this for you :)

this is true of c++ but does not apply to all the lower level languages


- large number of classes that come with java to address things that most
other programming languages require third party or custom libraries/modules
> That's only because Sun 'own' Java, however parts of the JDK are unashamedly
'pinched' from the open source world, with Logging and Regular Expressions
being obvious examples.

I'll take your word for it.


>In my mind, Java is a 'higher level' language, but it's not a 'high level'
language when you put it along side PHP, VB, Visual XXX, etc. :)

Agreed.


Let me ask you a question. How do you account for the multitude of
deprecated classes associated with each java release? A prime example
being java.util.Date. Seems that the earth moves with every new
release of java.

Axton

Axton,

How do I account for the amount of deprecated classes? Well if I had my way,
I'd want to see a JRE release that didn't support deprecated classes. But it
does seem as if the huge pile of deprecation has come from the earlier
1.0/1.1/1.2 releases. I'd love to see all the deprecation go given it would
expose a whole army of useless Java devlopers.

But let's give Sun credit for actually admitting they got it wrong and
re-writing code, rather than claiming it's a 'design limitation' and trying
to build more functionality on top. :)


John

Java System Solutions : http://www.javasystemsolutions.com


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)