Sunday, November 22, 2009

Tuesday, November 17, 2009

SPDY – Speedy … Google’s next step

Google is in all hurry to make everything faster and focused a lot on web arena. It has set a new benchmark for the web application are designed and are high performing. Google has been very innovative when its comes to that. Lot of initiative have gone from this special company to make the website performance better like http://code.google.com/speed/ and Google has recently open sourced some tools and tuts to help developers build fast website.

They have much interesting attempt of replacing HTTP protocol. But why…, below is the answer given by Google.

  • Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests.  Browsers work around this problem by using multiple connections.  Since 2008, most browsers have finally moved from 2 connections per domain to 6. 
  • Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
  • Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB.  As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common. For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant. Reducing the data in headers could directly improve the serialization latency to send requests.  
  • Redundant headers. In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent.
  • Optional data compression. HTTP uses optional compression encodings for data. Content should always be sent in a compressed format.

More details and very interesting article to read, http://dev.chromium.org/spdy/spdy-whitepaper

Think different!!!

Monday, November 02, 2009

PHP – SOAP WSDL Cache

It is pretty common known fact that the PHP or Flash kind of application while making remote RPC over SOAP makes couple of round trip. This is because service call tries to retrieve the WSDL (service definition) for each request. So it would be advised to cache the WSDL request.

Related links:

http://www.php.net/manual/en/soap.configuration.php

http://devzone.zend.com/article/689

Drupal Devel Module

Drupal has so many contributed module that are focused on developers. These modules are focused to ease custom module development – a few of them help to keep the code consistent, a few of them help to focus on performance, some on the deployment etc.

Devel – is one such module for developer to debug the page performance. This may be sophisticated measuring approach or tool but can be pretty handy to get a hint on where to start off. This module can log page response time, memory usage, number of database calls per page.

They have configuration available with different parameter in mind like site in production environment, small site, larger site, in-memory etc. It can also generate content, nodes, comments, users etc.

http://drupal.org/project/devel