Saturday, August 25, 2012

Most important question of your interview

I always finds it interesting how the questions answered by an interviewer are evaluated. 
Always deciding factor could be one question. What if the question is "Do you have any questions for us?"

I personally was asked this question in all interviews. Which makes this common and important. Let’s get to the answers that make differences.



  • What is the immediate need on your team that you are hoping to fill with this position?
  • What projects can I contribute to right away?
  • Is this team empowered to find better and more efficient ways to do things?
  • Can you tell me how your organization defines success?
  • How would you describe a typical day on this team?

These questions will show the interview that your unique, committed and contributor.

Source: http://lifehacker.com/5935550/the-interview-question-that-is-always-asked-and-how-to-nail-it

Tuesday, July 3, 2012

Be different from developer next to you

What every software developer, project leaders, architects, system support people should know.
1. Understanding basic operating system, memory management, I/O etc.
2. Through understanding of Disk IO.
3. TCP/IP, HTTP protocol and how it works.
4. Good understanding of database.
5. How programming language works? Build your own toy language in your favorite language if possible. This may not be production quality, but will involve a lot of learning points.
6. Thorough understanding of object oriented programming, functional programming.
7. Client side scripting foundation
8. Data structures
9. Design patterns
10. Foundational maths (not advanced maths)
11. Basic physics (most useful for game programmers and interaction designers).
12. Economics (will be useful if you need to startup your own venture and understand the demand/supply in the market)

Ref: http://geekswithblogs.net/rajeshpillai/Default.aspx

Sunday, February 5, 2012

Handling a million requests is challenging

I recently watch a video on youtube from Omar Al Zabir, where he present lot of interesting fact and preventive step that can be taken
http://www.youtube.com/watch?v=wHdvL4irsiQ&

I gonna bring the summary here and more finding from my experience

  • Preventing DOS attacks.
We all know that DOS is famous attack and it is very easy to implement and which can be achieved sending 1000 of requests in constantly and webserv

er that handles the request goes out of threads and CPU usage hits max and webserver goes down.
So the way we can prevent this by implement a HttpModule and on OnInit event track the IP address of the requestor and terminate the connection as early as possible after reaching certain limit. (Response.End())

  • ASP.NET ProcessModel optimization.
Microsoft set the default values to


1. maxWorkerThreads = 20
2. maxIOThreads = 20
3. memoryLimit = 60

These values old and are give when CPU's Single Processors, so increasing these values will make webserver to handle more request will less CPU overhead.
so maxWorkerThreads and maxIOThreads can be increased to 100 and memoryLimit can also be increased.


  • ASP.NET pipeline optimization
There are set default httpModules in machineConfig that every request go through all these httpModules, which is unnecessary overhead.
so assuming some default these can be removed from our applica
tion web.config

1. windowsAuthentication
2. PasspostAuthentication
3. AnonymousIdentification
3. FileAuthorization
4. UrlAuthorization


eg: Preventing ASP.NET Large cookies on Static Pages


  • System.Net optimization
If there are any HttpWebRequest or WebClient (WCF) calls incr
ease the maxConnections limit which present in connectionmanagment configuration. By Default one IP can send only 2 concurrent requests.


  • Optimize the ASP.NET Profile and Membership provider.
When making request to the Profile or Membership tables could be expensive. We might need to reduce the isolation levels on the some dbo. stored procedures and all the columns not indexed. (Need more writing here.)

  • HTTP Compression
With IIS 7 provides the build-in compression available from the web.config. Add this to the web.config

<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true" />

  • Cache Static files
Browser will cache files such as images, stylesheets and script files. By letting the browser cache all these files means it doesn’t need to request them again for the duration of the cache period.


<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00"/>
</staticContent>

Wednesday, March 9, 2011

Stored Procedure Optimization

1. Use stored procedures instead of heavy-duty queries.

This can reduce network traffic as your client will send to the server only the stored procedure name (perhaps with some parameters) instead of all the text from a large heavy-duty query. Stored procedures can be used to enhance security and conceal underlying data objects as well. For example, you can give the users permission to execute the stored procedure to work with restricted sets of columns and data.


2. Include the SET NOCOUNT ON statement in your stored procedures to stop the message indicating the number of rows affected by a Transact-SQL statement.

This can reduce network traffic due to the fact that your client will not receive the message indicating the number of rows affected by a Transact-SQL statement.


3. Call stored procedures using their fully qualified name.

The complete name of an object consists of four identifiers: the server name, database name, owner name, and object name. An object name that specifies all four parts is known as a fully qualified name.

Using fully qualified names eliminates any confusion about which stored procedure you want to run and can boost performance because SQL Server has a better chance to reuse the stored procedures execution plans if they were executed using fully qualified names.


4. Consider returning the integer value as a RETURN statement instead of returning an integer value as part of a recordset.

The RETURN statement exits unconditionally from a stored procedure, so the statements following RETURN are not executed. Though the RETURN statement is generally used for error checking, you can use this statement to return an integer value for any other reason. Using the RETURN statement can boost performance because SQL Server will not create a recordset.


5. Don't use the prefix "sp_" in the stored procedure name if you need to create a stored procedure to run in a database other than the master database.

The prefix "sp_" is used in the system stored procedures names. Microsoft does not recommend using the prefix "sp_" in user-created stored procedure names as SQL Server always looks for a stored procedure beginning with "sp_" in the following order: the master database, the stored procedure based on the fully qualified name provided, followed by the stored procedure using dbo as the owner (if one is not specified).

When you have the stored procedure with the prefix "sp_" in a database other than master, the master database is always checked first. If the user-created stored procedure has the same name as a system stored procedure, the user-created stored procedure will never be executed.


6. Use the sp_executesql stored procedure instead of the EXECUTE statement.

The sp_executesql stored procedure supports parameters. So, using the sp_executesql stored procedure instead of the EXECUTE statement improves readability of your code when many parameters are used.

When you use the sp_executesql stored procedure to execute a Transact-SQL statement that will be reused many times, the SQL Server query optimizer will reuse the execution plan it generates for the first execution when the change in parameter values to the statement is the only variation.


7. Use the sp_executesql stored procedure instead of temporary stored procedures.

Microsoft recommends using temporary stored procedures when connecting to earlier versions of SQL Server that do not support the reuse of execution plans. Applications connecting to SQL Server 7.0 or SQL Server 2000 should use the sp_executesql system stored procedure instead of temporary stored procedures in order to have a better chance of reusing the execution plans.


8. If you have a very large stored procedure, try to break down the stored procedure into several sub-procedures, and call them from a controlling stored procedure.

The stored procedure will be recompiled when any structural changes are made to a table or view referenced by the stored procedure (an ALTER TABLE statement, for example), or when a large number of INSERTS, UPDATES or DELETES are made to a table referenced by a stored procedure. So, if you break down a very large stored procedure into several sub-procedures, there's a chance that only a single sub-procedure will be recompiled, while other sub-procedures will not.


9. Try to avoid using temporary tables inside your stored procedures.

Using temporary tables inside stored procedures reduce the chance to reuse the execution plan.


10. Try to avoid using DDL (Data Definition Language) statements inside your stored procedure.

Using DDL statements inside stored procedures also reduce the chance to reuse the execution plan.


11. Add the WITH RECOMPILE option to the CREATE PROCEDURE statement if you know that your query will vary each time it is run from the stored procedure.

The WITH RECOMPILE option prevents reusing the stored procedure execution plan, so SQL Server does not cache a plan for this procedure and the procedure is always recompiled at run time. Using the WITH RECOMPILE option can boost performance if your query will vary each time it is run from the stored procedure, because in this case the wrong execution plan will not be used.


12. Use SQL Server Profiler to determine which stored procedures have been recompiled too often.

To check if a stored procedure has been recompiled, run SQL Server Profiler and choose to trace the event in the "Stored Procedures" category called "SP:Recompile". You can also trace the event "SP:StmtStarting" to see at what point in the procedure it is being recompiled. When you identify these stored procedures, you can take some correction actions to reduce or eliminate the excessive recompilations.

13. Use IF EXISTS (SELECT 1) instead of (SELECT *):

To check the existence of a record in another table, we uses the IF EXISTS clause. The IF EXISTS clause returns True if any value is returned from an internal statement, either a single value “1” or all columns of a record or complete recordset. The output of the internal statement is not used. Hence, to minimize the data for processing and network transferring, we should use “1” in the SELECT clause of an internal statement, as shown below:

IF EXISTS (SELECT 1 FROM sysobjects
WHERE name = 'MyTable' AND type = 'U')

14. Try to avoid using SQL Server cursors whenever possible:

Cursor uses a lot of resources for overhead processing to maintain current record position in a recordset and this decreases the performance. If we need to process records one-by-one in a loop, then we should use the WHILE clause. Wherever possible, we should replace the cursor-based approach with SET-based approach. Because the SQL Server engine is designed and optimized to perform SET-based operation very fast. Again, please note cursor is also a kind of WHILE Loop.

15. Keep the Transaction as short as possible:

The length of transaction affects blocking and deadlocking. Exclusive lock is not released until the end of transaction. In higher isolation level, the shared locks are also aged with transaction. Therefore, lengthy transaction means locks for longer time and locks for longer time turns into blocking. In some cases, blocking also converts into deadlocks. So, for faster execution and less blocking, the transaction should be kept as short as possible.

T16. Use TRY-Catch for error handling

Ref: http://www.databasejournal.com/features/mssql/article.php/1565961/SQL-Server-Stored-Procedures-Optimization-Tips.htm

http://sqlserverpedia.com/blog/sql-server-bloggers/sql-server-%E2%80%93-stored-procedure-optimization-tips-%E2%80%93-best-practices/

Thursday, December 9, 2010

HTML5 client local storage

Most talked feature of html5 is storing data on client side. This could be achieved in 3 ways.
  1. Session storage.
  2. Local storage
  3. Database storage
Session storage: This is more like a upgraded version of a cookie. It persists only during browsing and once window is closed data is lost. This is easy to implement.
sessionStorage.setItem('shoppingId', '23234')
alert("Shopping Id is: " + sessionStorage.getItem('shoppingId'));
//same thing could also be achieved with sessionStorage.shoppingId

//to remove
sessionStorage.removeItem('shoppingId');




Saturday, November 13, 2010

High Performance Client side technology tweaking for a website

When a page is rendered a typical browser subsystems used and there Best Practices

1. Networkingcompress network traffic with gzip and not compress not
  • Images because they are already compressed.
  • Providing cache able content
  • Conditional Requests
  • Minifing Javascript
  • Don't scale images on the html. Crop to the required size before setting it on the html.
  • Use Image sprites.
2. HTML Parser
  • Avoid Inline Javascript
  • Avoid Linking javascript in head tag
  • Link javascript at end of the body tag, But if required use it with 'defer' tag.
3. CSS ParserAvoid Embedded styles.
  • Counter to Js files use Css linking in the head tag.
  • Avoid @import tag in CSS files but if required for cascading or hierarchical style sheet use it with link tag on the page.
4. Collections
5. Javascript
  • Minimize symbol resolution










  • Minimizing symbol resolution for functions
  • Use JSON Native methods

6. Marshalling
  • Minimize DOM interaction.. Retreive all the DOM elements in one call like
    var elems = document.body.all                                                    
    var lside = elems.lside.value;                                                      
    var rside = elems.rside.value;  
7. DOM
  • Built in methods are always effective.
  • Use selector API's for efficient access of collections (CSS Selectors)
8. Formatting
  • Only send required styles.
  • Simply selector pattern. Avoid Descendent selectors
9. Block Building 10. Layout 11. Rendering --> Layout Optimization
  • Batch Visual Changes