Posts

Showing posts from February, 2012

Best Practices for HTTP Servers

How can web servers be optimised to perform faster? Can resources be cached, compressed, etc. There are a number of HTTP headers that one needs to understand in order to deal with performance optimisations. Last-Modified – Origin server indicates when the resource was believed to have been last modified. Given by both date and time. Etag – Entity tag or unique ID for each version of a resource which is usually comprised of the file-location, file-size and last modified date Expires – Origin server indicates to the browser when the resource becomes stale or how long to keep in cache. Applicable to HTTP/1.0; apparently  deprecated in HTTP/1.1 Cache-control – Origin server indicates to the browser and intermediaries whether or not to cache the resource and if to cache, for how long (cache-control:max-age). Applicable to HTTP/1.1 Notice the similarity in some definitions. In practice, Last-Modified and Etag are similar validators and can be grouped together. Expires and cach

Sending SMS

Image
There are different means of sending SMS that I’m aware of, namely: via GSM modem via SMSC (SMS Centre) via 3rd-party gateways Given that the 3rd-party gateways have got different offerings from vendor to vendor, here are some differences between the 1st two: GSM Modem SMSC Cost Usually lower and is fixed per SMS Normally higher unless there is bulk discount Use of short code (4-5 digit numbers)? No Yes Use of TPOA No Yes Latency per SMS (or throughput) 5-8 secs or 13-17 secs with DR (up to 15-20 SMS/sec) Less than 1 sec (20-40 or up to 100s SMS/ sec) Interface/ protocol USB/ COM ports Usually SMPP (TCP/IP) TPOA - Stands for Transmission Path Originating Address . It is a feature to mask the originating number with a alphanumeric string (up to 11 characters). E.g. Citi, HSBC To understand how all these entities/ components come together, see the following UML diagrams:

Troubleshooting Common .NET HTTP Connection Errors

The first is to identify whether the error is with the client or server (or even intermediaries). Most of the errors begin with “ The underlying connection was closed: “… Indications of client error An unexpected error occurred on a send – Could be due to: antivirus software installed on the client machine   Indications of intermediary error The remote name could not be resolved or The proxy name could not be resolved – Could be due to: DNS issue inability to access the hosts file Unable to connect to the remote server – Likely to have gotten through the DNS but hit a connection glitch due to: proxy firewall network authentication   Indications of server error or intermediaries (e.g. load balancer, proxy, etc.) An unexpected error occurred on a receive – Server or intermediary unexpectedly closes the TCP connection. May be due to: Server or intermediary timeout values set too low ( TODO : increase the client’s request timeout & also the server’s execut

Best Practices for running ASP.NET on IIS 7

When should application pools be turned into web gardens? Web gardens should only be used if the application doesn’t use in-process session variables but rather out-of-process ones (e.g. session state service or database session state). Reason is that a web garden would have at least 2 worker processes which do not share in-process (session) memory. Drivers to using web gardens are: Application makes long-running synchronous requests Application is low in availability and crashes often Application creates high CPU load on worker process Best Practices Systems Settings Optimum paging file size setting: 1.5x the RAM for 32-bit OS system-managed for 64-bit OS Disk queue length should always average less than 2 Processor queue length should be less than the number of processors  Network utilisation should be less than 50% Application Isolation Policy Some applications should be deployed into their own application pool mission critical and should be highly a

Solving Mixed-Content Warnings

Web applications can be written to work with HTTP as well as HTTPS schemes. To do so, URLs to resources should be encoded as relative URLs. For example, on a site (softwarehard.blogspot.com), all URLs to resources should be encoded as “/images/imageResource.jpg” or “images/imageResource.jpg”   instead of “http://softwarehard.blogspot.com/images/imageResource.jpg” Doing so will allow for the resource to be served in both HTTP and HTTPS schemes depending on the the page request. However, if an external resource is required, the authority (domain name) needs to be included. The most portable way to include the external resource is to use a scheme-less URL. For example: “//cdn.blogger.com/js/jquery.js” Note that neither HTTP nor HTTPS have been specified and doing so will allow us to skirt the mixed-content issue. This is valid under the URI RFC However, the caveats are that: this works well in web browsers but will likely break in email clients! there is also a minor downside