How You Can Help In Nepal Relief Effort

As a CEO & Founder at Shine Servers LLP, i’ll be arranging some donation for supporting Nepal Relief Effort for the people effected by #NepalEarthquake tomorrow. We are not a heavy earning company but as a #Entreprneurs we can always donate a small fraction of our earnings for the people who are fighting for their survival with the Natural Calamities.

Uday Foundation​ is sending medicines and essential supplies to Nepal and is working with local organizations to ensure their urgent distribution. Medical camps will also be organised soon.

Urgent Relief Material

Dry Ration
Matches and Candles
Tarpaulins and thick plastic sheets
Blankets and Sleeping Bags
Feeding bottles
Baby Food
Sanitary napkins
Essential Medicine
Feeding bottles

Financial Assistance Details

For Online Transfers:

Bank name: HDFC Bank
Branch: Anand Niketan, New Delhi 110021
Type: Savings
A/c No. 03361450000251
IFSC Code HDFC0000336

Cheques can be made in favour of “UDAY FOUNDATION FOR CDRBG TRUST” and sent at following address:

Uday Foundation,
113A/1, (Near Govardhan Resturant), Adhchini, Sri Aurobindo Marg,
New Delhi 110017 Phone: 011-26561333/444

Since Uday Foundation is not registered with FCRA so they cannot accept foreign donations, they accepts donations from Non-Resident Indians only through any bank account operational in India. Contributions made by a citizen of India living in another country, from his personal savings, through the normal banking channels, is not treated as foreign contribution.

Please share the details after you have made the donation to [email protected], along with your complete address and PAN card no, enabling us to send a 80G tax exemption receipt of the same.

Drop-off Location

Uday Foundation
113A, Sri Aurobindo Marg, New Delhi 110017
Phone : 011-26561333/444, Mobile : 9868125819
Email : [email protected]


Note: This information has been provided/published on a good faith basis, without any commercial motive. Shine Servers LLP does not vouch for the authenticity of the claims made by the intending donee, nor can we guarantee that the donations made by a donor will be used for the purpose as stated by the intending donee. You are requested to independently verify the contact information and other details before making a donation. Shine Servers LLP and/or its employees will not be responsible for the same.


Highest Regards,
Bharat Vashist

CEO & Founder
Shine Servers LLP || Leaders In Servers ||
twitter: @shineservers || Facebook :

Shine Servers LLP empowers students offers free & discounted hosting

Shine Servers LOGO

Shine Servers LLP is excited to announce free Shared Web Hosting & 30% Off On Dedicated Servers For Lifetime.

Dear Customers,

Shine Servers LLP offers a wide range of Web Hosting Services including Self-Managed and Managed Dedicated Servers, Shared Web Hosting, Reseller Solutions, Control Panels, SSL Certificates and Domain Registration. If you require a presence on the web, we have a solution to suit your needs.

Between climbing tuition, high cost of living and low employment, college students are always living on a tight budget. Even at my older times I as a student expected something extra from every store i visit, maybe some sort of extra discount or it can be a free Coffee at Starbucks but it’s always feels quite pleasant while having these sort of freebies when on a fixed budget.

Therefore, We are excited to announce that Shine Servers is now providing “Free Shared Web Hosting” & “30% Discount On Dedicated Servers” for LIFETIME (Only For STUDENTS).

Yes, that’s right & Effective Immediately !

Features Of Free Shared Web Hosting :

>> 24/7 Technical Support (Works As Expected)
>> 99.9% Uptime Guarantee
>> Pure Raid-10 Drive Storage
>> Latest cPanel/WHM with CloudLinux
>> NGINX Web Server
>> Multiple PHP Versions
>> Softaculous One-Click Installer
>> CloudFlare CDN Plugin
>> PHP, CGI, Perl, JavaScript, SSI & MySQL Support
Free Plan Configuration :

5 GB Performance Raid-10 Drive Storage
500GB Premium Bandwidth
Latest cPanel
One-Click Installer Softaculous
CloudFlare CDN Plugin
3 Add-On Domains
Unlimited Sub Domains
Unlimited Parked Domains
Unlimited MySQL Databases
Unlimited FTP Accounts
Unlimited E-Mail Accounts
Unlimited Forwarders
Unlimited Auto Responders
SSH Access
Ruby On Rails
Perl, CGI, Python, cURL, GD2, ionCube PHP Loader, phpMyAdmin
Activation Time: Instant

How To Order a Free Shared Web Hosting:

1. To Avail the Free Shared Hosting, Click Here To Order
2. Once Ordered, Do not pay the invoice that has been generated while order processing instead Raise a ticket at our Client Area by attaching your Student ID Card.
3. Once your ID is “Verified” then we will instantly setup your hosting.

How To Order a Discounted Dedicated Server:

Kindly use StudentShineDEDICATED Coupon Code To avail 30% Recurring Discount on any Dedicated Server listed here
If anyone is facing any issues, please feel free to raise a ticket at our Customer Support or Email Us directly.

Suggestions are most welcome!

Thank You!
Bharat Vashist

Ten SEO Mistakes Made on Database Driven Websites

Search engine friendly websites is one of those often heard phrases, both from web site development companies and from their clients. Everyone knows that this is important to have, and yet it is one of the things that is actually often overlooked.

Search engine optimisation companies actually spend a lot of their time analysing a website and removing barriers to the search engines ranking a site highly. At the web development level, it is possible to build a site that is perfectly search engine friendly. One of the hardest types of sites to get right though are database driven websites. Listed below are ten of the most common issues that are created, often unknowingly, in the development process of a dynamically generated web site.

1. Pages with duplicate content – not enough differential areas within the pages, so that only small areas of the page change from page to page. It is essential that enough of the page text changes for the search engines to see an appreciable difference between one page and the next.

2. Pages with duplicate page titles – the page title is a great indicator to the search engines of the primary content of the page. Whilst this is often unique on sites such as e-commerce websites, it is often overlooked in other sites, particularly where small areas of the site are generated from a database, such as news pages.

3. Pages with duplicate meta descriptions – again, this is easy to overlook and set a global or category level meta description. These give the search engines a reason to penalise your site for not giving them enough information, and again, creating a unique meta description for every page is an essential SEO task.

4. Using auto-generation of pages as a shortcut instead of creating good content. This is linked quite closely to point 1, where it is possible to create pages that have only a tiny percentage difference between them. Databases are fantastic ways of storing information, but you still need to put the work in to fill them with content. Unique information about the subject of the page will immensely help both the long tail and the ability of the search engines to determine that a page is valuable.

5. Creating pages that are hidden behind form submissions or javascript postbacks that cannot be accessed by a search engine crawler. This is far more common that is generally realised. For instance .NET creates postback links by default instead of proper links – potentially making huge sections of a site unreachable. Likewise, it is easy to hide lovely content rich areas of your site behind a drop down selector in a form that means certain areas of the site are not visible.

6. Too many query strings – this is a common bugbear of the professional SEO, where complicated database selections create deep levels of pages, but with seven or eight &id= type strings. Additionally, some bad development methodology can leave pages with null query strings that appear in every URL but don’t do anything. The answer to this is generally URL rewrites, creating much more search engine friendly and user-friendly URLs!

7. Putting query strings in different orders when accessed through different places – this can create duplicate content issues, which can cause major penalties.

8. Not using user language to generate automated pages – if you are going to create a database driven website that uses words in the query strings (or better in rewritten URLs) make sure that you use words that will help you with SEO – if you sell widgets, make sure you are using the word widgets somewhere in the URL instead of just product= or id= – keyword research can assist with this.

9. Not allowing the meta data and title to be edited easily after the site build. It is possible to hardcode the generation of meta information into a database that doesn’t allow it to be edited later. Creating a mechanism for modifying this information initially helps everyone at a later stage when the information needs changing without shoehorning it into an already developed structure.

10. Creating keyword stuffed pages by using auto-generation. Once upon a time, search engines quite liked pages with high densities of your keywords, but now these are likely to get you marked down rather than up. So be aware when creating pages that long pages with lots of your products on can create too high a density. For instance listing blue widgets, light blue widgets, navy blue widgets, sky blue widgets is going to create a page with a very dense page for the phrase “blue widgets”.

These are just 10 of the most common potential optimisation pitfalls when creating dynamic websites. There are many more facets to producing a great database driven site, including user friendliness, speed, performance and security, but they all add together to make the best solution to your needs.

About the Author: Mark Stubbs is a freelance writer who specialises in internet marketing and web site development. For more information on database driven websites he suggests that you visit


How To Use MySQL Query Profiling

What is the MySQL slow query log?

The MySQL slow query log is a log that MySQL sends slow, potentially problematic queries to. This logging functionality comes with MySQL but is turned off by default. What queries are logged is determined by customizable server variables that allow for query profiling based on an application’s performance requirements. Generally the queries that are logged are queries that take longer than a specified amount of time to execute or queries that do not properly hit indexes.

Setting up profiling variables

The primary server variables for setting up the MySQL slow query log are:

slow_query_log			G 
slow_query_log_file			G 
long_query_time			G / S
log_queries_not_using_indexes	G
min_examined_row_limit		G / S

NOTE: (G) global variable, (S) session variable

slow_query_log – Boolean for turning the slow query log on and off.

slow_query_log_file – The absolute path for the query log file. The file’s directory should be owned by the mysqld user and have the correct permissions to be read from and written to. The mysql daemon will likely be running as `mysql` but to verify run the following in the Linux terminal:

 ps -ef | grep bin/mysqld | cut -d' ' -f1

The output will likely display the current user as well as the mysqld user. An example of setting the directory path /var/log/mysql:

cd /var/log
mkdir mysql
chmod 755 mysql
chown mysql:mysql mysql

long_query_time – The time, in seconds, for checking query length. For a value of 5, any query taking longer than 5s to execute would be logged.

log_queries_not_using_indexes – Boolean value whether to log queries that are not hitting indexes. When doing query analysis, it is important to log queries that are not hitting indexes.

min_examined_row_limit – Sets a lower limit on how many rows should be examined. A value of 1000 would ignore any query that analyzes less than 1000 rows.

The MySQL server variables can be set in the MySQL conf file or dynamically via a MySQL GUI or MySQL command line. If the variables are set in the conf file, they will be persisted when the server restarts but will also require a server restart to become active. The MySQL conf file is usually located in `/etc or /usr`, typically `/etc/my.cnf` or `/etc/mysql/my.cnf`. To find the conf file (may have to broaden search to more root directories):

find /etc -name my.cnf
find /usr -name my.cnf

Once the conf file has been found, simply append the desired values under the [mysqld] heading:

slow-query-log = 1
slow-query-log-file = /var/log/mysql/localhost-slow.log
long_query_time = 1

Again, the changes will not take affect until after a server restart, so if the changes are needed immediately then set the variables dynamically:

mysql> SET GLOBAL slow_query_log = 'ON';
mysql> SET GLOBAL slow_query_log_file = '/var/log/mysql/localhost-slow.log';
mysql> SET GLOBAL log_queries_not_using_indexes = 'ON';
mysql> SET SESSION long_query_time = 1;
mysql> SET SESSION min_examined_row_limit = 100;

To check the variable values:

mysql> SHOW GLOBAL VARIABLES LIKE 'slow_query_log';
mysql> SHOW SESSION VARIABLES LIKE 'long_query_time';

One drawback to setting MySQL variables dynamically is that the variables will be lost upon server restart. It is advisable to add any important variables that you need to be persisted to the MySQL conf file.

NOTE: The syntax for setting variables dynamically via SET and placing them into the conf file are slightly different, e.g. `slow_query_log` vs. `slow-query-log`. View MySQL’s dynamic system variables page for the different syntaxes. The Option-File Format is the format for the conf file and System Variable Name is the variable name for setting the variables dynamically.

Generating query profile data

Now that the MySQL slow query log configurations have been outlined, it is time to generate some query data for profiling. This example was written on a running MySQL instance with no prior slow log configurations set. The example’s queries can be run via a MySQL GUI or through the MySQL command prompt. When monitoring the slow query log, it is useful to have two connection windows open to the server: one connection for writing the MySQL statements and one connection for watching the query log.

In the MySQL console tab, log into MySQL server with a user who has SUPER ADMIN privileges. To start, create a test database and table, add some dummy data, and turn on the slow query log. This example should be run in a development environment, ideally with no other applications using MySQL to help avoid cluttering the query log as it is being monitored:

$> mysql -u <user_name> -p

mysql> CREATE DATABASE profile_sampling;
mysql> USE profile_sampling;
mysql> INSERT INTO users (name) VALUES ('Walter'),('Skyler'),('Jesse'),('Hank'),('Walter Jr.'),('Marie'),('Saul'),('Gustavo'),('Hector'),('Mike');mysql> SET GLOBAL slow_query_log = 1;
mysql> SET GLOBAL slow_query_log_file = '/var/log/mysql/localhost-slow.log';
mysql> SET GLOBAL log_queries_not_using_indexes = 1;
mysql> SET long_query_time = 10;
mysql> SET min_examined_row_limit = 0;

There is now a test database and table with a small amount of test data. The slow query log was turned on but the query time was intentionally set high and the minimum row examined flag kept off. In the console tab for viewing the log:

cd /var/log/mysql
ls -l

There should be no slow query log in the folder yet, as no queries have been run. If there is, that means that the slow query log has been turned on and configured in the past, which may skew some of this example’s results. Back in the MySQL tab, run the following SQL:

mysql> USE profile_sampling;
mysql> SELECT * FROM users WHERE id = 1;

The query executed was a simple select using the Primary Key index from the table. This query was fast and used an index, so there will be no entries in the slow query log for this query. Look back in the query log directory and verify that no log was created. Now back in your MySQL window run:

mysql> SELECT * FROM users WHERE name = 'Jesse';

This query was run on a non indexed column – name. At this point there will be a query in the log with the following info (may not be exactly the same):


 # Time: 140322 13:54:58
# [email protected]: root[root] @ localhost []
# Query_time: 0.000303  Lock_time: 0.000090 Rows_sent: 1  Rows_examined: 10
use profile_sampling;
SET timestamp=1395521698;
SELECT * FROM users WHERE name = 'Jesse';

The query has been successfully logged. One more example. Raise the minimum examined row limit and run a similar query:

mysql> SET min_examined_row_limit = 100;
mysql> SELECT * FROM users WHERE name = 'Walter';

No data will be added to the log because the minimum of 100 rows was not analyzed.

NOTE: If there is no data being populated into the log, there are a couple of things that can be checked. First the permissions of the directory in which the log is being created in. The owner/group should be the same as the mysqld user (see above for example) as well as have correct permissions, chmod 755 to be sure. Second, there may have been existing slow query variable configurations that are interfering with the example. Reset the defaults by removing any slow query variables from the conf file and restarting the server, or set the global variables dynamically back to their default values. If the changes are made dynamically, logout and log back into MySQL to ensure the global updates take effect.


Analyzing query profile information

Looking at the query profile data from the above example:

 # Time: 140322 13:54:58
# [email protected]: root[root] @ localhost []
# Query_time: 0.000303  Lock_time: 0.000090 Rows_sent: 1  Rows_examined: 10
use profile_sampling;
SET timestamp=1395521698;
SELECT * FROM users WHERE name = 'Jesse';

The entry displays:

  • Time at which the query was ran
  • Who ran it
  • How long the query took
  • Length of the lock
  • How many rows where returned
  • How many rows where examined

This is useful because any query that violates the performance requirements specified with the server variables will end up in the log. This allows a developer, or admin, to have MySQL alert them when a query is not performing as well as it should [opposed to reading through source code and trying to find poorly written queries]. Also, the query profiling data can be useful when it is profiled over a period of time, which can help determine what circumstances are contributing to poor application performance.

Using mysqldumpslow

In a more realistic example, profiling would be enabled on a database driven application, providing a moderate stream of data to profile against. The log would be continually getting written to, likely more frequently than anybody would be watching. As the log size grows, it becomes difficult to parse through all the data and problematic queries easily get lost in the log. MySQL offers another tool, mysqldumpslow, that helps avoid this problem by breaking down the slow query log. The binary is bundled with MySQL (on Linux) so to use it simply run the command and pass in the log path:

mysqldumpslow -t 5 -s at /var/log/mysql/localhost-slow.log

There are various parameters that can be used with the command to help customize output. In the above example the top 5 queries sorted by the average query time will be displayed. The resulting rows are more readable as well as grouped by query (this output is different from the example to demonstrate high values):


Count: 2  Time=68.34s (136s)  Lock=0.00s (0s)  Rows=39892974.5 (79785949), root[root]@localhost
  SELECT PL.pl_title, P.page_title
  FROM page P
  INNER JOIN pagelinks PL
  ON PL.pl_namespace = P.page_namespace
  WHERE P.page_namespace = N

The data being displayed:

  • Count – How many times the query has been logged
  • Time – Both the average time and the total time in the ()
  • Lock – Table lock time
  • Rows – Number of rows returned

The command abstracts numbers and strings, so the same queries with different WHERE clauses will be counted as the same query (notice the page_namespace = N). Having a tool like mysqldumpslow prevents the need to constantly watch the slow query log, instead allowing for periodic or automated checks. The parameters to the mysqldumpslow command allow for some complex expression matching which help drill down into the various queries in the log.

There are also 3rd party log analysis tools available that offer different data views, a popular one being pt-query-digest.

Query breakdown

One last profiling tool to be aware of is the tool which allows for a complex break down of a query. A good use case for the tool is grabbing a problematic query from the slow query log and running it directly in MySQL. First profiling must be turned on, then the query is ran:

mysql> SET SESSION profiling = 1;
mysql> USE profile_sampling;
mysql> SELECT * FROM users WHERE name = 'Jesse';

After profiling has been turned on, the SHOW PROFILES will show a table linking a Query_ID to a SQL statement. Find the Query_ID corresponding to the query ran and run the following query (replace # with your Query_ID):


Sample Output:

1 starting 0.000046
2 checking permissions 0.000005
3 opening tables 0.000036

The STATE is the “step” in the process of executing the query, and the DURATION is how long that step took to complete, in seconds. This isn’t an overly useful tool, but it is interesting and can help determine what part of the query execution is causing the most latency.

For a detailed outline of the various columns:

For a detailed overview of the various “steps”:

NOTE: This tool should NOT be used in a production environment rather for analyzing specific queries.

Slow query log performance

One last question to address is how the slow query log will affect performance. In general it is safe to run the slow query log in a production environment; neither the CPU nor the I/O load should be a concern ¹ ². However, there should be some strategy for monitoring the log size to ensure the log file size does not get too big for the file system. Also, a good rule of thumb when running the slow query log in a production environment is to leave long_query_time at 1s or higher.

IMPORTANT: It is not a good idea to use the profiling tool, SET profiling=1, nor to log all queries, i.e. the general_log variable, in a production, high workload environment.


The slow query log is extremely helpful in singling out problematic queries and profiling overall query performance. When query profiling with the slow query log, a developer can get an in-depth understanding of how an application’s MySQL queries are performing. Using a tool such as mysqldumpslow, monitoring and evaluating the slow query log becomes manageable and can easily be incorporated into the development process. Now that problematic queries have been identified, the next step is to tune the queries for maximum performance.