PHP versus ASP.NET – Windows versus Linux

How does IMPLEMENTATION Performance Compare ?

Usually, when someone creates benchmarks, they are trying to prove that their thing is faster than someone else's thing.

I’m PAID by Microsoft to write BOTH PHP and ASP.NET Code. I was doing PHP before .NET shipped. I love them both.

This makes it hard for me to say anything good about either one. When I confer a preference for something in PHP, my Microsoft peers send me flame mail and when I confer a preference for something in ASP.NET, my PHP friends come out of the woodwork to call me a Microsoft shill.

I started building and running these tests because everyone had opinions about comparative PHP performance (Windows versus Linux & 5.2 versus 5.3), but no one had any solid data.

So, I decided to collect some empirical evidence of my own.

Before you look at them, let m e provide some method details and context.

All tests were run on the SAME Machine.

A Toshiba Tecra M5 with 4 Gig of ram and a 60 Gig 7200 RPM Hard Drive.

Ubuntu 9 and Windows Server 2008 Standard were natively installed on 2 separate (but identical) hard drives.

The web servers were Apache2 on Linux and IIS 7 on Windows.

Both operating systems were fully patched / updated.

No Operating System or Development Runtime performance enhancements were added.

I wasn’t investigating how much speed an expert could custom tailor the tests to on a specific platform.

Yes, I could implement PHP Byte Caching, or for ASP.NET I could use Page Caching, Partial Page Caching, SQL Cache Dependency, Multi Threading, etc.

Both Windows and Linux Implementations of PHP will benefit from PHP Byte Code caching.

My goal was to determine the relative speed of THE IMPLEMENTATION.

I found the results both interesting and unexpected.

PHP on Linux Versus PHP on Windows…..

I really though one would just be faster than the other, but I was wrong. Some things are faster on Windows, other are faster on Linux.

• RAW statement execution seems faster on Windows.
• Function Calls were faster on Windows
• Object Creation / Access was faster on Linux with PHP 5.2 but faster on Windows with 5.3
• Library calls were faster on Linux. (Example: Encryption 3-5 times faster on Ubuntu.)
• File Access is faster on Linux by a small percentage, except for file copy operations which was as much as 60% slower on Windows probably due to the ACL advanced security.
• MySQL access with Linux is faster by more than a little and on Windows, MySQL access deteriorates in version 5.3 (This seems to be poor implementation, see PostgreSQL below.)
• PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3
• MS SQL Server access from PHP 5.2 on Windows is marginally slower than MySQL access on Linux. (PHP 5.3 not yet supported at the time of this writing.)

So what does all that mean ?

• We can probably say that in terms of raw execution – performance on Linux versus Windows is probably a wash (more or less equivalent) so that the performance of PHP itself becomes a moot factor in choosing Linux or Windows for PHP application deployment.
• If you are building an application, or running an application that supports it, PostgreSQL might be a better database choice since it performs pretty much the same on Windows and Linux.
• If you are running an application that locks you in to Sun Microsystems’ MySQL and you want to run it on Windows, your should do scale planning. (My personal guess is that it’s unlikely that Sun will markedly improve MySQL performance on Windows. )
• Version 1 of the PHP Driver for SQL Server (V2 is in the works) is somewhat slower than MySQL or PostpreSQL but probably not enough to discourage use where diverse developer access is desired. (v2 ot the driver will improve performance. )

By and large I think the PHP team and the Microsoft IIS team have accomplished good raw performance equivalence across platforms. (Now we just need to get the Open Source Application teams (Drupal, WordPress, Joomle, etc.) to do performance optimization on both !)

PHP versus ASP.NET Raw Performance …..

By now you have cheated and looked at the spread sheet.

Yes, ASP.NET is universally faster than PHP (on Windows and on Linux) with the exceptions of File Copy and Attribute operations.

MySQL Access from PHP on Linux is a TINY bit faster than SQL Server access on Windows (assuming common data types and SELECT statements) but probably not enough to matter.

ASP.NET (C#) operations, object use, library calls, etc. are SIGNIFICANTLY faster that the PHP equivalents.

I know my PHP friends and the Linux dudes (and dude-etts) will probably come out of the wood work to refute my tests and results :)

I’ve always thought that if high end performance options were part of your needs requirements,  then .NET programming has some advanced options “out of the box” like multi-threading, asynchronous requests, and a number of caching options.

NOTE – I’m not saying “ASP.NET is Faster so you shouldn't choose PHP !!!!  I’ve always contended that the affable simplicity of PHP had some drawbacks for certain advanced applications. (Just as the early learning complexity of ASP.NET can have it’s drawbacks. )

To me (your mileage may vary) the exciting thing about PHP is not the language / platform so much as it is what thousands of clever PHP Developers have done with it (Drupal, Joomla, Wordpress, PHPBB, Nuke, etc.)

In any event, it’s nice to now have some data that PHP performance on Windows and Linux are “in the same ballpark”.

Now I can start writing those Windows specific PHP  libraries I’ve been dreaming about for years !!

COMMENT WARNING

• I know some will be incensed by these tests. You are welcome to comment and disagree, but if you can't be polite I’ll simply delete your comments and block your IP address.
• If you dislike the results and want to refute them – DO THE WORK. Accompany your dissent with DATA. Take my code or write your own and argue with FACTS.

Posted in: General asp.net | Tags: asp.net php windows linux implementation performance compare windows versus linux sql server postgresql ms sql server mysql

---

New Features in ASP.NET AJAX 4

New Features in ASP.NET AJAX 4

Note   The documentation in this section concerns ASP.NET 4 AJAX Preview 4. A more recent preview release might be available at the URL above. If so, it will include updated documentation.

The new functionality in ASP.NET AJAX enables new client data scenarios for page and component developers that enable JSON data from the server to be rendered as HTML in a highly manageable and efficient way. To enable these scenarios, ASP.NET AJAX includes the following major features:

· Client-side template rendering.

· Declarative instantiation of client-side behaviors and controls.

· Live data binding.

· Use of the observer pattern with JavaScript types.

· An AdoNetServiceProxy class for client-side interaction with ADO.NET Data Services.

· A client-side DataView control for data-bound UI in the browser.

· DataContext and AdoNetDataContext classes for interaction with Web services.

· Refactored ASP.NET AJAX framework libraries.

· Support for the DOM Ready event.

· Using JSONP to retrieve cross-domain data.

Client Template Rendering

In client-based development, templates are the most manageable way of creating UI from data. ASP.NET AJAX 4 includes a new template engine for client development that meets the following requirements:

· Performance — The engine must be able to render a typical number of items using a reasonably complex template before users perceive an interruption in their interaction with the application.

· Simplicity — The template syntax must be very readable and must be optimized for the most common scenario, namely one-way/one-time binding.

· Expression language — Templates must support an expression language to go beyond the simplest cases. The expression language should use familiar syntax, ideally JavaScript syntax.

· Interspersed code and markup — It must be possible to perform conditional rendering or to loop over markup by using code that surrounds HTML.

· Components — When using the template syntax, the developer must be able to instantiate client-side controls and behaviors that attach to HTML elements in the page or within templates.

Template Example

The following example shows a typical client template that you can create using ASP.NET AJAX 4.

<ul id="myTemplate" class="sys-template"

sys:attach="dataview"

>

<li>

<h3>{{ Name }}</h3>

<div>{{ Description }}</div>

</li>

</ul>

The class attribute of the outer div element is set to sys-template, which is a convention that is used in order to hide the initial template from the user. You should define this class in your CSS style sheet as {display:none;}.

When the template is rendered, it has a data item as context. Fields or properties of that data item can be included in the template markup by using {{ }} expressions — for example, {{ Name }}, if the data item has a Name field. These expressions can be placed anywhere in text content, or you can use them as the value of an attribute. In addition to fields or properties, the expression blocks can also contain any JavaScript expression that can be evaluated as a string.

You can set up DOM events by using the $addHandler method. The DOM on* attributes of elements (for example, onclick=method) also work from within templates.

Instantiating a Template by Using the DataView Control

The most convenient way to use client templates in ASP.NET AJAX 4 is through the DataView control. The content of a DataView control is used as a template that renders the data item that is provided to the control. If you set the DataView control's data property to an array, the template is rendered once for each item in the array. The DataView control binds to live data, meaning that the control is automatically updated when the data changes, without the need to rebind. This provides a dynamic data-driven UI in the browser. The following example shows the declarative markup for a DataView control that binds to an array named imagesArray.

<body xmlns:sys="javascript:Sys"

xmlns:dataview="javascript:Sys.UI.DataView"

sys:activate="*">

<ul sys:attach="dataview" class="sys-template"

dataview:data="{{ imagesArray }}"

>

<li>

<h3>{{ Name }}</h3>

<div>{{ Description }}</div>

</li>

</ul>

</body>

Instantiating a Template by Using Code

You can also create a compiled template from code by using the Sys.UI.Template class, as shown in the following example:

var t = new Sys.UI.Template($get("myTemplate"));

The constructor takes the parent element of the template as its argument. You can then render a compiled template into the DOM by calling its instantiateIn method and specifying an HTML container element and a data item as context. The following example shows how to do this.

t.instantiateIn(

$get("targetContainer"),

{

Name: "Name",

Description: "Description"

}

);

Using Pseudo-Columns in a Template

In addition to providing access to fields and properties of the data item, the template rendering engine also provides access to pre-defined "pseudo-columns" such as $index and $dataItem. These pseudo-columns give you access to values from the rendering engine at render time. You can use pseudo-columns the way you use any JavaScript variable in the template instance. The first example applies a different CSS class to the div element for alternating items that are rendered by the dataView control. The second examples passes the pseudo-column $dataItem, which represents the data for the current row, to a custom function named nameConvert for processing.

<div class:alternateitem="{{$index%2 == 1}}">

<span>{{nameConvert($dataItem)}}</span>

Incorporating Code into a Template by Using the code:if, code:before, and code:after Attributes

You can add the new code:if, code:before, and code:after declarative attributes to any DOM element within a template in order to render the element conditionally (code:if) or to render arbitrary code before (code:before) or after (code:after) the element. The following example shows how to use the code:If attribute to render an hr element as a separator between items. The code:if attribute uses the value of the $index pseudo-column to ensure that the hr element is rendered only between items, and not before the first one or after the last one.

<ul id="myTemplate" class="sys-template">

<li>

<hr code:if="$index!==0" />

<h3>{{ Name }}</h3>

<div>{{ Description }}</div>

</li>

</ul>

Posted in: asp.net | Tags: asp.net asp.net 4.0 performance feature asp.net ajax ajax dataview adonetdatacontext datacontext rendering simplicity template example

---

Common Questions and Answers from Performance Tuning Webinars

Q: Which will be faster out of these two queries?

SELECT ... WHERE some_col IN (1,2,3) or
SELECT ... WHERE some_col = 1 OR some_col = 2 OR some_col = 3

A:

Neither. The optimizer rewrites an IN() operator to a series of OR conditions, so there will be no performance diffference. Use IN() as it makes the code shorter and more readable.

Q: Where does MyISAM cache table records?

A:

Nowhere. MyISAM does not cache table records like InnoDB does in it's innodb_buffer_pool. Instead, MyISAM relies on the operating system buffering to buffer table records as it reads them from the .MYD file. The MyISAM key_buffer only stores index blocks, not data records.

Q: Which will be faster out these two queries:

SELECT ... FROM t1, t2 WHERE t1.id = t2.id
SELECT ... FROM t1 INNER JOIN t2 ON t1.id = t2.id

A:

Neither. The optimizer actually will rewrite the bottom query into the top form. The SQL style you use is, of course, entirely up to you, however I recommend using the bottom style (known as ANSI syntax) over the top style (known as Theta syntax) for a couple reasons:

• MySQL only supports the inner and cross join for the Theta syntax. However, MySQL supports INNER, CROSS, LEFT and RIGHT outer joins for the ANSI syntax. Mixing and matching both styles can lead to hard-to-read SQL code.
• It is supremely easy to miss a join condition with Theta style, especially when joining many tables together. Leaving off a join condition by accident in the WHERE clause will lead to a cartesian product (not a good thing!). ANSI syntax is more explicit, and it is much harder to forget a join condition

Q: Is InnoDB faster/better than MyISAM

A:

It completely depends. Nobody ever really likes the answer to this question, but it is completely true. There are strengths and disadvantages to each storage engine. MyISAM has very good read performance, bulk load performance, and has a small footprint. But, InnoDB is great for heavy UPDATE environments, transaction needs, referential integrity, and fast single key lookups. You need to pick an engine based on what your application needs, and not some general "only use XXX engine" dictate.

Q: Is CHAR faster than VARCHAR?

A:

No, not really. If there is any performance difference, it is negligible. Pick CHAR if you know that the data has a specific number of characters (like a social security number, for instance) and VARCHAR otherwise.

Q: Is VARCHAR(80) faster than VARCHAR(255)

A:

Yes, but probably not in the way you think. AFAIK, there's no difference (at least in recent versions of MySQL and InnoDB) between the speed at which VARCHAR columns of different lengths are retrieved from disk or memory. However, there is a big difference when either of the following scenarios occurs:

• A temporary table is implicitly created to handle a GROUP BY or ORDER BY clause and a VARCHAR column is in the SELECT statement
• A temporary table is created explicitly which contains a VARCHAR column

In these cases, the length of the VARCHAR columns does come into play. Why? Because temporary tables in memory are actually just tables of the MEMORY storage engine. The MEMORY storage engine, for some reason, treats all VARCHAR(X) columns as CHAR(X) columns.

This means that if you define two fields, one as VARCHAR(255) and another as VARCHAR(128), the latter will consume half as much space when allocated in a temporary table. The more records can fit into the max_heap_table_size, the fewer cases of swapping to disk tables (look for SHOW STATUS LIKE 'Created_tmp_disk_';) will occur, resulting in better overall performance.

Q: Are there performance issues when joining tables from different storage engines

A:

No. Issuing a SELECT against multiple storage engines is fine. It's when you mix and match transactional and non-transactional engines within a transaction that modifies data that you will get unpredictable results.

Q: If I change a derived table to a view, will performance increase?

A:

No. A view is simply a derived table behind the scenes (at least when created using the TEMPTABLE algorithm). This means there is no performance difference between a regular derived table and a view. The view will simply make the code more readable and more "componentized".

Q: If I see "Using temporary; Using filesort" in the Extra column of EXPLAIN output, does that mean a temporary table is created on disk?

A:

No. A disk-based table will only occur in the following situations:

• When the size of the implicitly created temporary table (from a GROUP BY or ORDER BY on a non-indexed column) is greater than both tmp_table_size and max_heap_table_size
• When there are any BLOB or TEXT fields in the SELECT expression
• When a full table scan occurs that exceeds the read_buffer_size variable (configured per connection thread)

These are the scenarios (off the top of my head) I can think of which cause disk-based temporary table creation. There could be a few more. By the way, the disk-based temporary table created is a MyISAM table.

Q: Is it possible to do a FULL OUTER JOIN in MySQL?

A:

Yes. Use both LEFT and RIGHT JOIN on the same join condition in the same query, like so:

SELECT *
FROM A LEFT JOIN B ON A.id = B.id
UNION ALL
SELECT *
FROM A RIGHT JOIN B ON A.id = B.id
WHERE A.id IS NULL

Posted in: Interview Questions database | Tags: interview questions and answers interview performance mysql database sql pl sql tuning webinars full outer join outer join using

---