Re: Independant ASP & MSSQL Vs PHP MySQL Tests

Michael, >> Don't use ODBC on NT. No one will seriously trust those numbers, >> as ASP under NT connecting to SQL server (7.0) using OLEDB >> to connect has been a recommended method for about a year. OK then, I will test NT using both methods, ODBC & OLEDB. I am after all trying to be fair. Oh yeah and thanks for the code snippet, I'll use that. >> Why test PHP on W2000? The docs themselves say it's not ready >> for deployment on production machines Personal experience of WIN2K Server has been good so far which is why I decided to go for tests on Microsoft's latest offering. I will however, run tests on NT4 Service Pack 6 and post these results as a completely different platform. >>Im not sure what benefit 'vanilla' installs will be in judging things. As I'm sure this testing thing will be an on going issue, I'd like to have results that can be replicated by everyone, including those without server configuration and optimization skills. As we implement performance tweaks in our tests, we can publish what we done to achieve the results we are publishing. This will then, hopefully, be used by all to improve performance on your own servers. >> Linux/PHP/MySQL may indeed be faster, but MySQL also doesn't >> have all the features of SQL7. True, and that is one of the reasons why MySQL is faster. I have executed performance tests before and MySQL simply knocked so many spots off MSSQL, but again MySQL hasnt got the Distributed Transactional facilities or Stored procedures. Nice facilities to have but not always essential. Let me know about tweaks that you want me to implement to the server before I run the tests. Andy. ----- Original Message ----- From: "Michael Kimsal" <michael@tapinternet.com> To: <php-general@lists.php.net> Sent: Wednesday, August 02, 2000 4:03 PM Subject: Re: [PHP] Independant ASP & MSSQL Vs PHP MySQL Tests > Hello... > > First off, as a moderately active ASP programmer, I must jump > in here a bit. > > Don't use ODBC on NT. No one will seriously trust those numbers, > as ASP under NT connecting to SQL server (7.0) using OLEDB > to connect has been a recommended method for about a year. > > connection.Open "Provider=SQLOLEDB; Data Source=machine; User ID=ID; > Password=PASSWORD" > > It is much faster than regular ODBC. Anyone inspecting your numbers > would cry 'foul' that you used ODBC on NT but native drivers under PHP. > > Why test PHP on W2000? The docs themselves say it's not ready > for deployment on production machines (at least my readme.txt > said that). Also, it's not optimized for NT. You're setting yourself > up for disappointing numbers. In our experience NOTHING will > beat optimized ASP/VBScript/SQL7 under Windows. I wrote that > wrong. No other similar platform (PHP, CF, Perl) will beat > optimized ASP on Windows. MS *WROTE* the bloody thing - > they know all the nooks and crannies and hidden memory stuff. > You can't beat the enemy on their own ground. They've got the > 'home field advantage'. Choose another similar catchphrase if you > don't like those. > > I'm not sure what benefit 'vanilla' installs will be in judging things. > You probably have seen many reactions to NT/Linux comparisons > where people always say 'but they didn't do such-and-such tweak > to Linux - then it would have kicked butt!'. Take into account > as many enhancements on each side that you can - most > professionals in the NT side of things will tweak to make their > code as fast as possible - do the same for PHP. > > ASP has the getrows function, which many people use - there isn't an > equivalent under PHP (see archives for my question on this). Be prepared > to answer questions from prospective clients about why you didn't > compare this functionality (or use stored procs as well). > > There are many many enhancements to 'vanilla' NT that most ASP > people know something about. Be prepared to accomodate for these > discrepancies. > > I'm going thru the same issues now with a client - we're probably > migrating from ASP/NT to Linux/PHP. I've told them that straight > code for code, the Linux might be a bit slower. That's not the whole > point - you can always throw a faster processor or more boxes at the > problem. The better argument, imo, is code and maintenance. A > remote NT machine is harder to administer than a remote Linux > machine. PHP code is, imo, handier and bit more elegant than VBScript. > > Linux/PHP/MySQL may indeed be faster, but MySQL also doesn't > have all the features of SQL7. That's a benefit and hindrance. > People familiar with MSSQL will feel cramped rewriting things in PHP > or MySQL that are easier in MSSQL. But MySQL can be much faster > because it doesn't have the overhead associated with MSSQL. > Keep that in mind. > > We did similar tests a few months back - results are up at > http://www.tapinternet.com/bench.php3