How many times has this been asked on forums? It is an understandable question but ultimately betrays how narrow most people's understanding of software is. It's like someone who writes a rock-solid web application but puts it on a host that is unsecure and loses data - performance, like security, has many layers and the total performance is the sum of all such layers.

Take the above question, it seems fair but the intention of the question is "If I want my system to perform well, should I opt for PHP instead of .Net?" Of course, this is probably because of Microsoft's reputation (sometimes deserved) for writing bloated and slow software. But is it really?

The uninformed response is, "PHP is faster than .Net", a more informed but still incomplete response is "try it and see". Why is it incomplete? Well let's look at the variables.

  1. The web itself is often reasonably slow point-to-point. Why? Well, traffic loads, service-provider issues. Slow DNS lookups etc. at least this slowness is shared by both systems but it also might suggest that it is a more significant issue for performance than the application or server (but it might not be!).
  2. DNS is often overlooked as part of the performance of a site, in most senses, once you have done the site lookup, your ip address will be cached for a period of time but that is determined by your DNS settings (or rather by the TTL setup on the DNS record) so if that time is short, your users might make frequent trips to their DNS registries, which, again, can be significantly slow.
  3. The hosting centre who serve your site (or indeed your own data centre) has various limits on its performance and bandwidth, these might vary depending on traffic levels causes by other sites hosted at the centre which might vary their loading significantly during the day and which might be taking your CPU cycles on a shared VM host or otherwise the network bandwidth at any point on the hosting companies networks.
  4. Your actual server, which is likely to be virtual, has a whole host of issues that might mean it works well or not depending on factors like the OS you are running, the kind of loads you are putting on it, the speed and arrangement of disk arrays etc. Most of this is invisible to you but it certainly can add latency, either consistently or erratically.
  5. Your application then runs on some kind of operating system. This could be Linux or Windows as well as other stranger variations but depending on who installed and setup the server, it might not be optimised for web in one way or another. This might be because certain security that has been configured adds latency and these security measures may or may not be needed depending on where the system is hosted. Is your OS firewall simply a duplication of something that already exists on the boundary of your host network?
  6. Your web server software (Apache, nginx, IIS etc) is a variable. You can serve PHP, for instance, from most web servers but only IIS is optimised for ASP.Net (unless you count the slightly less well-featured Mono on Linux). So choosing one language over another can affect not only your web server software but also, by implication, the OS you have to run on. Also, Apache is available for multiple platforms but does it perform identically on each? Do you even have a way to tell?
  7. Any libraries (3rd party or core) you use that call into the OS may or may not be optimised, they may or may not perform well and this is hard to tell during development, what happens when the method is called 1000 times per-second? Of course, this might only manifest when a particular part of your code is being called, which may or may not be continuous/consistent.
  8. Then your choice of files will affect the performance of the system, and this is not necessarily consistent across all web servers. Web sites that feature heavy amounts of static content might fly on nginx but if you include a significant amount of dynamic content, Apache might perform better. Of course, in many scenarios, this is both not easy to determine and certainly isn't something that we can predict for the future very well.
  9. Then the application itself can be written well or badly at various levels. Basics such as calling into code that adds no additional functionality (perhaps it doesn't do anything, perhaps it is redundant because the functionality has already occurred earlier in code). An example might be re-checking form input against a Regular Expression even though it is already attached to a server control that does the validation for you. Of course, there are also more subtle optimisations which you may or may not have spotted. For instance, if you have a set of checks carried out on some input, do they run in an order which makes the most common failure be checked first to save calling other checks unecessarily?
  10. If you change languages are you as expert in the other language as you are in the one you currently use? If not, you might make the overall system less well performing even if the new language is potentially faster overall.
  11. If you use a database, how fast is that? Is it optimised for the type of data you use? Have you moved maximum processing into the web application so that the database can be light-weight and not require the large overhead of sharding or replication?
When you take the hoslitic view, it is clear that there is much that can affect performance and most of it is either outside of our visibility or outside of our expertise or ability to put right. My personal opinion along the axiom of simplicity is that it is preferable to have a system that is easy to understand, easy to maintain, using tried and tested principles, even if these make your system a few percent slower than it is to try and squeeze a few extra cycles out while at the same time pushing the system outside your expertise. Someone once said, "The first rule of optimisation is: Don't.", because we often optimise things that we think would be a problem even if they aren't. Who cares if a page takes 2 seconds instead of 1/2 second for something that is run once per day by 10 people if the alternative is complex coding or defect injection?

IT departments often complain about costs but how much does it cost to incur hours, days or weeks of downtime/work to fix something that wouldn't have happened if you stayed within your expertise or well-known design patterns/frameworks? Often, in cloud-based or well-written web applications, it is much easier to spend a few dollars more a month to get a larger host machine which will increase performance than it is risking moving your whole stack over from IIS/Windows/ASP.Net to Linux/Apache/PHP or back again.