__/ [ Roy Schestowitz ] on Wednesday 12 July 2006 14:03 \__
> __/ [ nessuno@xxxxxxxxxxxxxxxxxxx ] on Wednesday 12 July 2006 13:59 \__
>
>> Maybe you should forward this to Vaughn-Nichols, since he's worrying
>> about performance issues in Linux.
>
> I'll do just that.
Response just arrived (and appended). I'll ask him to post another essay to
clarify what he said previously. He seems quite keen on doing so.
On Wed, 2006-07-12 at 14:21 +0100, Roy Schestowitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear Steven,
>
> Please allow me to introduce myself. I am a long-time Linux advocate and
> the person behind many of PJ's news items in Groklaw. I also syndicate
> and read your site regularly, frequently submitting pointers to
> Digg.com, which earn you traffic from the front page.
Indeed it does. Thanks.
>
> I came across your write-up on Jim's (a friend/colleague?) article in
> eWEEK < http://www.eweek.com/article2/0,1895,1983364,00.asp >. I must
> admit that I was slightly disappointed to find no skepticism in your
> analysis/post-mortem. Let me begin by presenting an article that was
> published as recently as this afternoon:
>
> Sybase And IBM Set Transaction Processing Record For Linux
>
> ,----[ Snippets ]
> | Sybase, provider of enterprise infrastructure and mobile software,
> and IBM
> | announced that IBM System p5 520 and Sybase Adaptive Server Enterprise
> | (ASE) for Linux set a new transaction processing performance record for
> | 2-core systems by delivering 81,439 transactions per minute (tpmC) on the
> | leading TPC-C benchmark...
> |
> | [...]
> |
> | This new record beats the previous 2-core HP/Itanium2 and Oracle 10g
> | performance record for Linux by 58 percent. It also beats the previous
> | 2-core HP/Opteron and Microsoft SQL Server performance record and is less
> | expensive by 23 percent.
> `----
>
> http://in.sys-con.com/read/246319.htm
>
TPC-Cs are, how to put it, pretty easy to game. Everyone who cites TPC-C
does it, which means you can actually somewhat trust the comparative
results. Just don't expect these numbers to have much to do with
real-world performance.
> Please let me append a few arguments that were raised in the Linux
> advocacy newsgroup -- these which address the article and your write-up
> directly. I will quote just relevant fragments to save you time. In
> reference to Jim's article:
>
>
> ===
> >> Why would you want to marry free with something proprietary, requiring
> >> licences, high exit costs, and so on?
> >>
> >> I appreciate that these articles are focussed on the technical aspects
> >> of things, but you can't ignore costs.
> >
> > They also neglect stability, which affect TCO, unlike performance in
> > isolation (as skeptic as I may be about it as a whole[1]). Might as well,
> > squeeze in some IIS and call that a WIMP. If you ask me, the article is
> > attempting to be cocky to both sides, avoiding any flames and lost
> > readership.
All true, but again, that wasn't the point of that story. I brough up
several of those matters myself. I will say, however, that Server 2003
really has become quite stable. Linux still has the advantage, but it's
not as big a one as it has been before.
> >
>
> I think that these articles probably need to 'grow up' a little.
> Probably the writers need to, in order to make that happen.
>
> >
> >
> > [1] Which distribution used? What specifications (it's a black art of
> mis/fit
> > to system requirements)? X enabled/running? Conclusion: not enough
> > information. Most benchmarks are inconclusive, biased and subjected to
one
> > point in time (specification 'demography').
> ===
>
>
>
> ===
> >> it would be an interesting read if I could get a copy of the apache and
> >> mysql configs for Linux, as it is, all we have are bits of the data,
> >> without the meat.
> >
> > They specifically noted that for LAMP and Windows .Net stack that both
> > configurations were default. No special tweaking for either platform.
> > They also justified their position in testing this way.
> >
>
> Yes, I read that, however, There's a big difference between the default
> Apache install from a tarball of the source, and the CentOS rpm, no
> mention of which method was used for install/config. There are several
> simple settings in Apache that make a huge difference in performance in
> many situations (whether the logfiles have ips, or they do on the fly
> reverse dns for one, keepalive for another.) Those settings vary between
> different "default" settings.
Sure. It was RPM by the way.
>
> I can't comment on the .net stuff, don't do MS if I can avoid it, but
> I'd like to see the apache and mysql config, and the php if possible.
> There's a lot of room for tweaking there.
> ====
>
>
> In relation to your article:
>
> ===
> > "I think the tests were perfectly fair. "
> >
> > http://www.linux-watch.com/news/NS6492047053.html
>
> Ahh yes, the magician's look over here when there's something happening
over
> there.
>
> First, the test. We are NOT testing the same things across all servers.
This
> is more a test of CMS systems. Without first measuring a common performance
> baseline, these tests mean less than nothing, they actually misrepresent
> what they are supposed to measure.
Web portals actually, but it was a test of what people commonly do with
these stacks.
>
> - From the article:
> "One could argue that we were testing the subject apps?the portals?and not
> the stacks themselves. Of course, one could also argue that tests using a
> custom-built subject application would be less a test of the stacks than a
> test of the porting skills of the programmers."
>
> This is absolutely bogus! It shows Jim Rapoza of eweek does not have the
> prerequisite knowledge about performance testing to make any such test or
> claims. Worse yet, were I cynical, and I am, I would say that this is a
> shill article planted to create FUD.
>
I have to disagree with you on this one. I've done a lot of benchmark
designing
and testing over the year. He's right. If you look at custom programming
what you really end up doing is evaluating the programmer's tuning
skills.
> Here's the deal people: web server performance is a red herring. Seriously,
> it isn't a big deal.
>
> If you have a single server sitting in a basement with a T1 line you're not
> getting any hits anyway, you could practically type the responses yourself.
True, but that wasn't the case here. They do point out that they were
using a real load on these systems.
>
> If you have any sort of site, you have a load balancer and [N] web server
> boxes dealing with HTTP requests. The web server boxes don't cost much,
> maybe about $2000 MAX! Maybe about a couple hundred dollars a year in power
> and depreciated connection hardware. They are like toasters, all the same
> and easily replaceable.
Actually, they're not, but that's a tale for another day. Again, though,
that wasn't the case here.
> Linux and PHP are more stable than .NET on Windows,
> that is a HUGE difference. Which vehicle would you choose for a general
> work? A pickup truck that does 80MPH~90MPH or a paper mache' rocket sled
> that does 240MPH?
> ===
Linux and PHP are more stable than .NET on XP, .NET on Server 2003 is
another matter. Of course, since IIS is part of the 2003 kernel, if
something does go wrong, bye-bye operating system. In practice, that
hasn't happened very often.
Now, what would have made a huge difference would have been the use of
a PHP Accelerator like Turck MMCache
>
> Could you perhaps shed some light on this, perhaps in a follow-up article?
>
Would you mind if I quoted some of your comments in a follow-up. I
thinking of doing not just a follow-up but simple things you can do with
LAMP to make it perform much better.
Steven
--
Steven J. Vaughan-Nichols sjvn@xxxxxxxx
Editor, Linux & Open Source Ziff Davis Internet
http://www.linux-watch.com http://www.desktoplinux.com
http://linux.eweek.com http://www.linuxdevices.com
|
|
