LAMP The test we did that was closest to a pure LAMP stack ran on SUSE Enterprise Linux, Apache, MySQL and the XOOPS portal and content management system. We chose XOOPS because of its general popularity and high ranking among PHP-based portals on sourceforge.net.Click here to read about Dells direct support for two more key elements of the LAMP stack: MySQL and JBoss. For example, we saw average throughput of 120.59KB and average hits per second of 24.15. Given that this was a pure-vanilla implementation with no tuning, these numbers are actually more impressive than they seem at first. Even the most ardent PHP fans will admit that PHP is not designed with performance in mind and will usually recommend clustering or performance add-ons such as those available from PHP vendor Zend Technologies. This stacks performance numbers suggest what many who have been using PHP for some time now (including some of the busiest blogs on the Web) know to be truethat a pure LAMP-based PHP system can easily handle enterprise-class traffic and loads. Linux J2EE We ran the liferay portal system on the Linux J2EE stack because of its popularity as a Java-based portal system and because of its somewhat unusual base configuration. Liferay uses the Hypersonic SQL database engine (now the H2 Database), a Java-built database specifically designed to be very fast in Web environments. We ran Liferay on an Apache and Tomcat server infrastructure running on Cent-OS Linux. Perhaps somewhat surprisingly, this configuration was among the best performers in our tests, with an excellent average throughput of 1.56M bps and the best average hits per second, 234.81. To a large degree, we credit this outstanding performance to the lightweight Hypersonic SQL database. For years, small, focused databases have done very well in standard transactional tests similar to our performance tests. An interesting follow-up to these tests would be to run more intensive database tasks against this system. Still, these results are very promising to those interested in mixing and matching in their stacks. Businesses evaluating IT stacks, especially for running simple transactional applications, should definitely consider a stack that uses a nonstandard but potentially high-performance database. Linux JBoss for our tests of this stack, we decided to include JBoss Portal. JBoss is one of the top open-source Java application server vendors, but JBoss Portal is relatively immature compared with the other portal applications in this evaluation, which have been around for years and have seen a lot of real-world testing and refinement. That immaturity is perhaps why this stack performed relatively poorly. We ran JBoss on CentOS with MySQL, and, while the stack wasnt the worst performer in all tests, it always tended toward the bottom of the scale. (In JBoss defense, JBoss Portal on Windows performed considerably better than JBoss on this CentOS Linux setup.) We think JBoss Portal will work out most of its kinks across platforms in time, just as its app server sibling has. It would be worth it to run JBoss on this setup with additional tuning, and also to run it with other databases, including the Hypersonic SQL database that performed so well in the Liferay-based stack test. Linux Python One potential iteration of the LAMP stack has Python in the "P" position. The most popular core applications in the Python stacknamely, the Zope application server and the Plone portal and content management systemare not only agnostic when it comes to the rest of the stack but actually tend to replace stack components with their own systems. For our tests, we ran what is essentially a pure Zope/Plone implementation, with Plone running on a SUSE Enterprise Linux system. In some benchmarks, Plone was an average performer, sticking close to the middle. This is actually better than we expected, given that the Plone documentation is very upfront about the fact that Plone shouldnt be used alone in a production environment and should be run behind other servers to improve performance. We saw why in the average-transactions-per-second and average-download numbers, where Plone on SUSE was among the slowest of the systems we tested (with an average page download time of 156.22 seconds and an average document download time of 75.94 seconds). Most of these numbers came from the end of the test, when Plone started showing the stress of the high loads it was enduring. Still, in an internal server setting, a naked Python-based stack using Plone would most likely run well, based on the numbers we saw. .Net A few years ago, microsoft threw around the .Net moniker so aggressively in so many areas that it became difficult to figure out exactly what the term meant. But, as all the irrational exuberance that comes with a failed marketing blitz finally pulled back, .Net went back to being what it was originally intended to be: the name of Microsofts server and service stack. To test the .Net stack, we ran Windows Server 2003 R2, SQL Server 2005 and SharePoint Portal Server 2003. Across the board, this configuration performed very well, with the top overall average throughput (by far) at 4.59M bps. To a large degree, we credit this strong showing to the high level of integration that exists among the components of this stack. While most of the open-source and Java systems are developed independently of each other, each of the .Net components is designed specifically to integrate and perform well together. Even if the .Net stack had bombed convincingly in these tests, it would probably still maintain popularity in many companies. But its strong showing should give companies confidence that the .Net stack will handle most high-level enterprise needs. Next Page: Mixing Windows and open source.
In nearly every test we ran, this PHP-based LAMP configuration was a solid, middle-of-the-road performer.