DIFERENCIAS ENTRE WINDOWS 32 BITS Y WINDOWS 64 BITS.

Vamos a ver que nos aporta Windows 64 bits y si merece la pena instalarlo en un PC de uso doméstico.

Lo primero que hay que tener muy en cuenta es que para instalar un sistema operativo de 64 bits hay que tener un procesador de 64 bits y una placa base que lo admita de forma nativa. Actualmente quedan en el mercado muy pocos procesadores que sean de 32 bits (solo algunos de gama baja, normalmente para RMA o equipos de muy bajo precio) y la practica totalidad de las placas base son de 64 bits, pero los equipos algo más antiguos (por ejemplo, P4 478) si que son de 32 bits.

En primer lugar vamos a ver que ventajas tienen las versiones de 64 bits.

La principal de todas es que las versiones de 64 bits suportan mucha más memoria (tanto RAM como virtual) que las versiones de 32 bits.

Todos los sistemas operativos de 32 bits tienen un límite en la memoria RAM de 4Gb (que además, en el caso de Windows, no suelen aprovecharse completos). Esto en realidad para uso doméstico no es un gran obstáculo, ya que no es habitual instalar esa cantidad de memoria.

Las versiones de 64 bits no tienen ese límite, por lo que podemos instalar bastante más memoria.

La cantidad máxima de RAM soportada por las versiones de 64 bits de Windows son las siguientes:

Windows XP Profesional 64 bits.- 16Gb de memoria RAM.
Windows Vista Home Basic 64 bits.- 8Gb de memoria RAM.
Windows Vista Home Premiun 64 bits.- 16Gb de memoria RAM.
Windows Vista (Resto de versiones) de 64 bits.- - 128Gb de memoria RAM.

Como podemos ver, las cantidades de RAM son bastante mayores.

Además de esta ventaja en la RAM, los sistemas operativos de 64 bits son algo más rápidos que los de 32 bits, más estables y más seguros.

¿Quiere decir esto que sea mucho mejor instalar Windows 64 bits que Windows 32 bits?.

Pues hasta cierto punto no. Los SO de 64 bits están diseñados más para un uso profesional que doméstico.

Estos sistemas tienen también tienen una serie de inconvenientes para uso doméstico.

En primer lugar, decir que en el caso del Windows XP 64 bits, le pasa exactamente lo mismo que al XP Media Center.
Es la versión inglesa (EEUU) con MUI en español, lo que suele dar algunos problemas con actualizaciones y con algunos programas.

Esto está solucionado en las versiones de 64 bits de Windows Vista, que si son en el idioma correspondiente.

Además de este problema, las versiones de 64 bits tienen una serie de inconvenientes:

- No son compatibles con programas de 16 bits o inferiores.
- Algunos programas (como algunos antivirus, algunos programas de grabación y similares), aunque son programas de 32 bits no son compatibles con Windows Vista 64 bits.
- Hay problemas de drivers para 64 bits.
- Los SO de 64 bits son más caros que los de 32 bits (aunque la diferencia de precio no es muy grande).

En cuanto al sistema en sí (manejo, utilidades, etc.) son exactamente iguales a las versiones de 32 bits correspondientes.

Hay que dejar bien claro otro punto:
Un programa de 32 bits va a correr EXACTAMENTE IGUAL en un sistema operativo de 64 bits que en uno de 32 bits, por lo que en este aspecto no vamos a notar ninguna mejora.

Hay algunos programas desarrollados para 64 bits, pero son programas profesionales que un usuario doméstico no va a utilizar normalmente.

Conclusión:

Para un uso particular la opción más interesante sigue siendo las versiones de 32 bits.

Para un uso en empresas y profesional, dependiendo de las necesidades de memoria y de los programas que utilicemos si que son interesantes las versiones de 64 bits.

Top 10 Best Practices for Production ASP.NET Applications

In no particular order, here are the top ten things I've learned to pay attention to when dealing with production ASP.NET applications. Hopefully they will help you save you some time and headaches. As always, your thoughts and additions are welcome.

1. Generate new encryption keys

When moving an application to production for the first time it is a good idea to generate new encryption keys. This includes the machine validation key and decryption key as well as any other custom keys your application may be using. There is an article on CodeProject that talks about generating machineKeys specifically that should be helpful with this.

2. Encrypt sensitive sections of your web.config

This includes both the connection string and machine key sections. See Scott Guthrie's post for some good references. Note that if your application runs in a clustered environment you will need to share a custom key using the RSA provider as described in an MSDN article.

3. Use trusted SQL connections

Both Barry Dorrans and Alex Chang have articles which discuss this in detail.

4. Set retail="true" in your machine.config

<configuration>
<system.web>
<deploymentretail="true"/>
system.web>
configuration>

This will kill three birds with one stone. It will force the 'debug' flag in the web.config to be false, it will disable page output tracing, and it will force the custom error page to be shown to remote users rather than the actual exception or error message. For more information you can read Scott Guthrie's post or the MSDN reference.

5. Create a new application pool for your site

When setting up your new site for the first time do not share an existing application pool. Create a new application pool which will be used by only by the new web application.

6. Set the memory limit for your application pool

When creating the application pool, specifically set the memory limit rather than the time limit which is set by default. Asp.net has a good whitepaper which explains the value of this:
By default IIS 6.0 does not set a limit on the amount of memory that IIS is allowed to use. ASP.NET’s Cache feature relies on a limitation of memory so the Cache can proactively remove unused items from memory.
It is recommended that you configure the memory recycling feature of IIS 6.0.

7. Create and appropriately use an app_Offline.htm file

There are many benefits to using this file. It provides an easy way to take your application offline in a somewhat user friendly way (you can at least have a pretty explanation) while fixing critical issues or pushing a major update. It also forces an application restart in case you forget to do this for a deployment. Once again, ScottGu is the best source for more information on this.

8. Develop a repeatable deployment process and automate it

It is way too easy to make mistakes when deploying any type of software. This is especially the case with software that uses configuration files that may be different between the development, staging, or production environments. I would argue that the process you come up with is not nearly as important as it being easily repeatable and automated. You can fine tune the process as needed, but you don't want a simple typo to bring a site down.

9. Build and reference release versions of all assemblies

In addition to making sure ASP.NET is not configured in debug mode, also make sure that your assemblies are not debug assemblies. There are of course exceptions if you are trying to solve a unique issue in your production environment ... but in most cases you should always deploy with release builds for all assemblies.

10. Load test

This goes without saying. Inevitably, good load testing will uncover threading and memory issues not otherwise considered.