RE: C++ Garbage Collector on VMS?
- From: "Main, Kerry" <Kerry.Main@xxxxxx>
- Date: Sun, 22 Apr 2007 10:14:49 -0400
-----Original Message-----
From: Arne Vajhøj [mailto:arne@xxxxxxxxxx]
Sent: April 21, 2007 11:46 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: C++ Garbage Collector on VMS?
Main, Kerry wrote:
And there are numerous J2EE app's designed for mission critical
applications that in the end, do not scale anywhere near as high as
they were designed for and in the end they start throwing HW at the
final solution.
They should scale great.
Performance is not always as good as it could be.
And HW is usually not a problem in th app tier. What does a
HP box with two quad Xeon and RHEL cost ?
These days, HW cost is the smallest cost associated with a application environment. Its almost a rounding error. Especially with multiple tiers and multiple dev/test/QA environments. Each server needs to be monitored, patched, licensed etc. - not only for the app, but also the supporting apps as well e.g. backups, AV, batch, monitoring/mgmt agents etc. In addition, staffing costs are typically something like 60-70% of the typical IT budget today.
As I recall (but willing to be corrected) BEA alone charges USD $10K per CPU (list), Oracle charges USD $40K / cpu (enterprise) and $60K/ cpu with RAC. Now look at all these different server environments and when you add them up, it is significant.
To your question about the HW cost - lets look at real costs for SW for 2 servers - RH Linux, any vendor box, quad Xeon cpu's. One for App server, one for DB.
BEA WLS - 1 servers x 4 cpu's = $40K (list)
Oracle - 1 servers x 4 cpus = $160K (list)
So, if we were talking typical J2EE App, RH Linux + BEA WLS + Oracle RAC = USD $200K for basic SW stack. This does not include support Apps as well (backup, AV, monitoring/mgmt agents) etc.
Now, say we needed HA, so we add 2 servers so that we have 2 App servers + 2 DB servers.
BEA WLS - 2 servers x 4 cpu's = 8 x$10K = $80K (list) (Assume WLS clustering not involved here as I do not know how much that adds)
Oracle - 2 servers x 4 cpus with RAC = 8 x$60K = $480K (list)
Cost with HA = USD $560K.
And this is only one application in production environment. What about adding BEA WLI or other Oracle or Cognos products in as well?
Now - what about the Dev / Test / QA environments? Will they be similar to the production environment? If so, you can do the math.
Consider that most medium to large companies will literally have hundreds of applications (that is what is typically found in consolidation engagements) and you begin to see the scale of the IT problem facing large companies today.
And then there is all the regulatory compliance challenges associated with many of these servers as well.
And for Windows/Linux then you add in the 5-20 security patches per month recommended by each of these vendors. Now, consider the support costs of these monthly security patches - will you test your applications before releasing these patches or blindly install them and trust (hope) that no problems will occur?
Imho, when looking at servers today, the key criteria of the future will be not how much the server TCO is to run that one application, but rather how much is the server TCO if you put 5 or 10 applications on it?
When comparing OpenVMS vs Windows for example - how many Customers would put 5-10 separate Windows apps on the same server? With OpenVMS, this is common place. With Windows if you have 5-10 applications, you are typically looking at 5-10 servers (many more of course if you have N-tier in each case)
That will be the next big thing being requested by C levels to further reduce costs as this one-app, multiple server model is rapidly coming to an end.
Bottom line - Imho, the model is just way to expensive to license, support and to complex to maintain.
A sure sign of this is VMware virtualization literally flying off the shelves as companies try and consolidate all their HW. And IDC recently dropped their expected server numbers due to all the virtualization activities going on.
http://tinyurl.com/ys8dsu (see VMware notes)
Will that be a problem for OS platforms or App groups that are used to one app, many physical servers?
Yep.
Some might say it was the nature of OO which makes it more difficult
to design truly scalable, system specific optimized code,
OO versus procedural is mostly relevant for source code. The
impact on performance should be minimal. Often OO takes a bit
of more memory, but generally no problem.
some might
say it was all the various tiers and associated network latencies
It actually improves scalability. But it too many tiers can make
it very hard to get acceptable latencies.
Compare the overall time to do a direct IO request with system level caching to a network IO request. Now look at this from a extremely busy App to DB server environment.
Who wins?
Tiers were a great concept when HW could not keep up with the processing required by each tier and network speeds were slow and unreliable. That is no longer the case as the typical Wintel/UNIX server today is only 10-25% busy - in peak times!
(SAP now recommends tier consolidation putting App tier on same
server as DB tier)
"tier consolidation" is a new term to me, but what it describes
is a standard technique nowadays.
I do not understand the point in the app tier db tier consolidation,
because app servers are usually load sharing while database are
usually failover. I which case it is impossible to consolidate
those tiers.
Tier consolidation refers to the HW, so you may still have 10 App servers, but they will be running on 2 servers instead of 10. The next step would be tier rationalization where you crank down the number of App servers (depending on the App environment of course).
> or perhaps it is at least partly do to with
"stuff" running in the background doing things that a well designed
app environment would not need to do.
I have not seen many GC related performance problems. The typical
business critical app involves database. GC is much faster than
databases.
Both .Net and J2EE are OO based strategies and there is a lot ofconvinced
market momentum to adopt one or both of these, but I am not
that OO strategies are the best ones to adopt for very scalable,very
mission critical systems.
I can not imagine anyone not using OO today.
See scenario above and the huge costs facing companies today with the one app, many server and multiple tier model.
J2EE scales very nicely.
J2EE or a .NET solution are rather obvious for a typical
business applications.
In small to medium app environments, I would agree.
In large environments (and in consolidation of many small environments to fewer, but larger servers), it takes a lot of work and is very complex when troubleshooting many different components running on many different systems.
Again - if Wintel//Linux, then you also have the 5-20 security patches (not bug fixes, security) per month to review / test / apply in Dev/Qa/Test/Prod as well.
Where they do not fit quite as well is in real time and embedded.
Sun and Microsoft and all of the supporting casts on both sides want
Cust's to pick one (.Net or J2EE) and ditch their current 3GL
environments (with all of the 10-20 year investments), but I just do
not believe it is the right way to go for the future. Picking either
approach is an App only driven strategy whereby I believe the future
for mission critical stuff will be much more solution driven i.e.
3GL's or equiv prod's integrated with OS specific features.
Both Java and C# are 3GL's.
.NET has a very tight integration with one particular OS.
Well, as much as I hate to say it, I do think .Net has an advantage in this respect. Top to bottom integration optimized with one specific platform. The devil is in the details of course, but overall, I have to agree they have a good strategy in this respect. The .Net challenge is still the culture of one app, one (or more) servers.
While portability is often a bigger goal of small to med shops, that is not the case for large MC environments where they pick an OS they trust and then build their mission critical app environment around it for max scalability and availability.
It is very good system design to consider the possibility that
programmers make mistakes.
Kind of like giving everyone a parachute when they board a plane
because "mechanics do make mistakes..."
:-)
Not parachutes when boarding just life jackets under
the seats.
Reminds me of the well known airline exec speech to IBM field typesindustry
about the difference in focus on quality between the airline
vs. the computer industry. That speech was delivered in the middleat
1960's and the same speech today would not have to be changed much
all.
<joke>
At a conference about quality in software engineering the speaker
started by asking the audience "How many of you would get off a plan
if you just before takeoff realized that your companies software
was flying the plane?". All except one raised their hands. The
speaker looked at the one guy not raising his hand and asked "So you
create high quality software?". He answered "Not at all, but it is so
bad that the plane will never get off the ground, so I am not
worried!".
</joke>
Arne
:-) :-)
Hey, perhaps there is something to GC .. after all, planes require regular GC after each flight as well.
:-)
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
.
- Follow-Ups:
- Re: C++ Garbage Collector on VMS?
- From: Arne Vajhøj
- Re: C++ Garbage Collector on VMS?
- Prev by Date: Re: 64-bit: Intel Unveils New x86 Microarchitecture
- Next by Date: Re: 64-bit: Intel Unveils New x86 Microarchitecture
- Previous by thread: Re: C++ Garbage Collector on VMS?
- Next by thread: Re: C++ Garbage Collector on VMS?
- Index(es):
Relevant Pages
|
