Nov 26, 2009

What if I have been in NYC, London and SF in the same day?

When you analyzing a website performance, it's always a mystery what is the performance issue root cause (well at least till we dive in and reveal it :-).

A common issue in this analysis is what is the network round trip time (RTT) in the play, and who is to blame for. Usually we start with following measures:
  1. Analyze the website from our offices. This test includes both Wireshark analysis to analyze the network RTT and FireBug to understand website behavior.
  2. Analyze the website performance in the hosting environment by running a terminal services on a server (or the appropriate measure in Linux or UNIX based environment), were RTT should be zero.
  3. Finally, we usually connect the site from another site around the world. This is done usually by connecting a server in another hosting environment (booting a server for a hour using Amazon AWS is a great solution for that).

    These tests are usually a good method in order to evaluate the communication layer play in the performance issue. However, testing from remote sites is not always accurate and sufficient. In these cases we recommend using a service name, that provides you a FireBug like analysis from several sites around the world.  

    Keep Performing!
    Moshe Kaplan. 9AFW6C8B3GKN

    Nov 18, 2009

    Boost Your Website Performance (Front End)

    This great Yahoo! article is (almost) everything you need in this field.

    Keep Performing,
    Moshe Kaplan

    Nov 9, 2009

    Should MySQL backup be equal to system downtime?

    I had a short conversation with my mate, Romi Kuntsman regarding a common issue in current systems: the database backup.
    Since database systems are very active, the database backup process takes relatively long time and the whole system performance is going down (or in some cases the whole system stops responding and going down...)

    Should I backup or Should I don't?
    Well, first of all, keep backup your system. You never know when your system will corrupt due to hardware failure, when a hacker will decide to "check" your system, or when the regulator will visit your offices.

    So how should I keep my system responding to users?
    Well... lets take a look at storage systems: when you have a large storage machine (SAN) you usually do not backup the primary site machine, but rather backup the secondary storage machine by splitting it from the main site (or by using a snapshot of the secondary site). This way your primary machine keeps serving clients with interference, while the secondary machine is taking care of the backup. When backup is finished, the sync between the machines is being restored.

    So it works for storage systems, how can it work for databases?
    Well lets implement a similar design to your database system:
    1. Install another MySQL instance
    2. Configure this instance to be a slave of your master database
    3. Schedule a job to bring down the sync, backup the slave and bring back the sync

    And what about the hot backup?
    Well, if you still want to maintain high availability during backup (and you should), implement a two slaves configuration, where the first slave is used for high availability and the second for backup.

    Keep Performing,
    Moshe Kaplan. RockeTier. The Performance Experts.

    Nov 5, 2009

    SQL Server NOLOCK: Should I use or should I not?

    Well, the simple answer is NO!

    What is NOLOCK?
    NOLOCKS enables you to make a SELECT statement while avoiding current locks on the tables by other statements such as DELETE and UPDATE.

    Why should you use NOLOCK?
    Well, the answer is simple, you have locks in the database, users in your website receive exceptions and errors instead of answers, and your boss is getting nervous. The simple way is just place an extra WITH(NOLOCK) and things seems to be OK:

    SELECT field_name FROM table_name WITH(NOLOCK)

    Why should you avoid NOLOCK?
    If your database suffers from locks, avoiding these performance issues now, will result in larger problems in the future. Your database is a key feature in your architecture, and your should take care of him and not avoid the problems.
    Moreover, using NOLOCK does not gurrentee that your users will receive updated and current data which may sensitive when financial or sensitive data is getting into place.

    Keep Performing,
    Moshe Kaplan.


    Intense Debate Comments

    Ratings and Recommendations