Slashdot Mirror
Sun Offering Optimized AMP Stack On Solaris
tbray writes "This is your friendly local Sun corporate drone reporting that we're going to be building and optimizing and DTrace-ing and shipping and supporting the AMP part of LAMP (details here). I think that basically the whole tech industry, excepting Microsoft, is now at least partly in the AMP camp."
Microsoft is indeed working on optimizing PHP for Windows, and they certainly support Python with IronPython (which is quite often faster than CPython).
dom
I wish there were a simple tool I could run that would analyze a LAMP install and migrate it to Postgres instead of MySQL.
I don't want to get into a holy war about the relative merits: we already use Postgres, we will not support two database systems, we are not switching from Postgres to MySQL. MySQL might be good for others, but not for us.
But we do get these LAMP apps that come bundled with MySQL. Usually they don't use any MySQL specific features that Postgres (and maybe moving some functions across the app/DB boundary) can't directly support. So I'd like to get a LAMP -> LAPP migrator that will automate the switch. Leaving optimizations for after the switch, to be performed by other (Postgres) tools or programmers/DBAs. The open source of these two DBs, and the open source of all these LAMP apps, should make migration between them accessible.
I'm sure there are lots of people like me. Where's the tool that makes the open source as good for migrating among these programs as creating them from scratch?
--
make install -not war
For us we doubled the performance on our db by switching from RHEL4 to Solaris 10. The support for Solaris 10 is less than for RHEL4
I don't think there's any real reason to, if you're familiar with Linux ... Sun would like people to use Solaris, and they have some interesting administration tools, and of course they'll sell you a support contract and might be more "PHB compatible" than many Linux vendors, but I've yet to see any good comparisons.
... but if they can't, except for people who already are familiar and more comfortable with it than they are with Linux, I don't see a major draw.
A while back there were some interesting comparisons of SQL performance on Darwin/Mac OS X versus Linux, under controlled conditions on similar hardware; it would be interesting to see a Sun-AMP versus LAMP comparison, done by some disinterested party, using the same versions of all the same software except for the OS, wherever possible. If Sun could outperform Linux, it would be intriguing
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Hell, I more than doubled my performance on my filesystem-heavy loads going from RHEL4 to RHEL3. The syscall overhead went through the roof in EL4, even with SELinux off. I got tired of trying to compile a kernel (hey vendors, would it kill you to ship a config that doesn't panic when I compile using it without changing anything?) so I just retrograded. The next move will most likely be lateral, to another vendor.
Done with slashdot, done with nerds, getting a life.
Ah, but remember -- Sun can sell you a machine which goes well beyond the whole 'similar hardware'.
If they can sell someone an optimized, supported, and enterprise-class piece of hardware which is basically turnkey, and can fill the job of being your web-facing front-end, there will be companies for whom this is a very good idea.
What Sun can sell you is the higher end for which there is no way you could build it with a commodity PC. Enterprise customers have enterprise hardware needs, and enterprise mindsets. Being "PHB Compatible" is a valuable thing in business, cause if things go to shit, you have someone who can come in and make things go again.
Sun isn't trying to get the hobbyist shop; they're targeting higher end companies with bigger budgets who want reliability.
If for nothing else than they're going to support the AMP stack, I have to commend Sun on this decision. This can only be good for those parts of the stack, and it won't really hurt Linux in any way -- this is complementary. This will have the effect of giving PHBs an option which uses Apache, MySQL, and PHP/PostgressSQL (whichever it is). I don't see this as being a 'lose' for the OSS people.
Why is Slashdot so pathologically opposed to someone buying a computer and operating system, even if it makes sense for their business goals?
Cheers
Lost at C:>. Found at C.
Solaris is a pretty darn good product. And if Sun starts providing full time support for the "AMP" part of the stack, you can probably bet that bug fixes for Solaris won't be far behind those for Linux. And if Sun follows through and GPLv3's Solaris, things really start to get interesting...
Just junk food for thought...
I have a feeling Dtrace probes might be a big, big win here - if they instrument it as they have the Solaris system itself that level of performance tuning integrated into the entire software stack may allow for some Really Impressive payoffs.
On the high end, bottlenecks are something to really watch for and identify, and Dtrace is an excellent tool for that sort of activity. This will be very interesting to watch.
Also, if Solaris DOES go GPLv3, the immediate availability of a superior SAMP stack that is GPL could turn a lot of heads, and may even displace some LAMP systems quickly and painlessly.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Its not that you *have* to do that amount of debugging, but that you *can*. I suppose it does matter if you have several teams that write different tiers of a n-tier architecture (we've done that - web monkeys wrote the front end to a specified API, DBdevs write stored procedures. Poor application programmers get the blame when anything goes wrong, and poor system/middleware devs have to then find out who's right (or wrong as is the case). So being able to debug all the way through is rather handy.
Really - don't knock something for being good.