DNS Query Performance Testing Tool
Version: $Id: queryperf.c,v 1.8.192.4 2007/09/05 07:44:57 marka Exp $

[Status] Processing input data
[Status] Sending queries (beginning with 192.168.3.20)
[Status] Testing complete

Statistics:

Parse input file:     once
Ended due to:         reaching end of file

Queries sent:         514229 queries
Queries completed:    514229 queries
Queries lost:         0 queries
Queries delayed(?):   0 queries

RTT max:              0.000861 sec
RTT min:              0.000172 sec
RTT average:          0.000678 sec
RTT std deviation:    0.000028 sec
RTT out of range:     0 queries

Percentage completed: 100.00%
Percentage lost:        0.00%

Started at:           Tue Feb  5 06:32:42 2008
Finished at:          Tue Feb  5 06:33:00 2008
Ran for:              17.732512 seconds

Queries per second:   28999.219062 qps

When configured with forwarded option – this is when master forwards to a back-end BIND server and then replies back to the client. The following performance was recorded:
DNS Query Performance Testing Tool
Version: $Id: queryperf.c,v 1.8.192.4 2007/09/05 07:44:57 marka Exp $

[Status] Processing input data
[Status] Sending queries (beginning with 192.168.3.10)
[Timeout] Query timed out: msg id 1
[Timeout] Query timed out: msg id 2
[Timeout] Query timed out: msg id 3
[Timeout] Query timed out: msg id 4
[Timeout] Query timed out: msg id 5
[Timeout] Query timed out: msg id 6
[Timeout] Query timed out: msg id 7
[Timeout] Query timed out: msg id 8
[Timeout] Query timed out: msg id 9
[Timeout] Query timed out: msg id 10
[Timeout] Query timed out: msg id 11
[Timeout] Query timed out: msg id 12
[Timeout] Query timed out: msg id 13
[Timeout] Query timed out: msg id 14
[Timeout] Query timed out: msg id 15
[Timeout] Query timed out: msg id 16
[Timeout] Query timed out: msg id 17
[Status] Testing complete

Statistics:

Parse input file:     once
Ended due to:         reaching end of file

Queries sent:         500000 queries
Queries completed:    499983 queries
Queries lost:         17 queries
Queries delayed(?):   0 queries

RTT max:              0.009379 sec
RTT min:              0.000369 sec
RTT average:          0.003022 sec
RTT std deviation:    0.000701 sec
RTT out of range:     0 queries

Percentage completed: 100.00%
Percentage lost:        0.00%

Started at:           Tue Feb  5 06:26:58 2008
Finished at:          Tue Feb  5 06:28:19 2008
Ran for:              80.786053 seconds

Queries per second:   6188.976704 qps

The performance as a standard Bind master server was almost 5 times faster than using 3 node forwarder set-up where one server node was a benchmark traffic generator.

For example:

SELECT name,lastname from UserTable;

Optimized SQL query would be:

SELECT name,lastname from UserTable Limit 3;

Or, for example, you have a blob record of an article with 550 words and you want to display only the first 50 characters for the excerpt. Why do you need to pull out all 550 words if you can write a query that is friendlier and works much faster?

SELECT title, SUBSTRING(article,1,50) from ArticleTable Where Id=”5″;

The key to the optimization is writing smart code and always optimizing for performance.

Optimize MySQL queries:

To pull only data you need,
Limit loops,
Limit answer length when needed,
Use correct indexes,
Use MySQL caching settings.

MogileFS is a perfect choice for your next storage system if you are planning to build a high-scale service with large storage requirements that is capable of being distributed to multiple servers and low-cost hard drives. It features excellent fail-over capabilities that can be set up using Linux open-source HA project – and there are quite a few projects and solutions are available. MogileFS high-availability storage can be run on simple PC hardware in non-RAID configuration. No hardware RAID is required, because MogileFS provides full fail-over – it replicates data between multiple devices. If one server dies the MogileFS continues working without problems. This saves thousands of dollars and provides HORIZONTAL SCALABILITY from small to large projects that require large storage space and high availability at the lowest possible cost.

You can set up MogileFS replication based on predefined classes and replicate files that are important. Files that are generated from the sources – for example, resized thumbnails – can be easily regenerated from your applications if the disk or server hardware fails.

MogileFS is not POSIX compliant and thus must be implemented in your applications from the very beginning. Multiple APIs are available for PHP, Perl and Python languages, and implementation is quite trivial.

You only need a minimum of two servers to run MogileFS – trackers can be run on the same server where storage nodes are running; however, 4 boxes are preferred and trackers need to be set up in high availability.

MogileFS can be set up in any number of storage servers horizontally that provide high-availability and load balancing, and it is a much better alternative to the widely used NFS, which has many problems.

To speed up the blog loading time a little, you should serve less hits – this provides lower latency and server network stack usage. You should found out any plug-ins of your blog use their own CSS files. If plug-ins have their own style sheet that it is loaded in every page for web visitors, you should consider moving CSS definitions to your main style sheet.

Remember, even the smallest performance boost does pay back in long run. Imagine, if you are serving 10 million hits daily where 100,000 extra hits will be due to of plug-in CSS, those can be easily merged with your main CSS file.