This is a followup to my December post on performance testing.

View Performance Testing on Scribd

XSLT, Extensible Style sheet Language for Transformations, is a powerful language that makes processing and transforming XML into other documents such as new XML, HTML and text documents possible. It provides a relatively simple, efficient and quick method to bridge communication between B2B. XSLT gives developers the ability to output different or some portions of xml rather than all and to generate in both human readable and/or machine formats.

XSLT became a recommendation of the W3C on 11/16/1999. Since then, XSLT has given the ability to imbed logic in documents without scripting, deliver information to variety of devices, even low-function devices, and provide a template system. XSLT is one of two families of standards for style sheets, the other being CSS. Examples of the logic possible with XSLT are conditional processing, looping, if statements, if else, and sorting.

Conditional Processing & Looping:

* IF statements

<xsl:if test="grade = 0">
Come to tutoring
</xsl:if>

* IF ELSE

<xsl:choose>
<xsl:when test="grades > 75">
PASSED
</xsl:when>
<xsl:otherwise>
FAILED
</xsl:otherwise>
</xsl:choose>

* LOOPING

<xsl:for-each select="class/student">
Student Name and Grade
</xsl:for-each>

* SORTING

<xsl:sort select="grades"/>

For our business demands, it has proven to be an effective transactional email template system. As our emails become more complex and richer in data, our ability to maintain quality and consistency would have proportionally escalated with the demands of a fast growing company. More resources would have to be allocated and could potentially become a managerial nightmare. With XSLT, we are able to maintain the same level of resources and even allow for multiple developers to rotate and still deliver the same professional results. We are able to support changes and updates across multiple different transactional email types and even add new emails almost effortlessly in no time.

We have found that XSLT gives cheap viagra pills us advantages over conventional programming. We’ve been able to apply and set rules for transforming XML and in a method that is easily applicable to all transactional emails.  We can dynamically change the order in which elements appear in a document, do computations, combine multiple documents, and email out thousands of emails within an hour with 100 percent consistency. XSLT has given us the flexibility, regardless of the data source, to generate the same email every time, ability to maintain structured documents, and keep our email logic separate from our website

base logic.

Performance testing

A few weeks ago, a Product Manager asked me “what is the performance difference between the new code and old cold?”. I did not have an answer because up to this point, we did not have a system in place to do front end performance testing. Sounds like a great code freeze project. Over the past few days, I have been working on designing and implementing a basic performance testing system utilizing JMeter from the Apache Jakarta project. The premise for this endeavor is to find site performance problems early in the QA and Development cycle ultimately providing for a great experience to our beloved members.

Before starting on this, I created the following objectives that our performance testing system should achieve:
1. Track historical performance of our site over time
2. Use data to pinpoint bottlenecks due to software/hardware changes
3. Identify and remedy any detrimental impact on performance
4. Allow QA Engineers to quickly create and execute tests from 1 location
5. Provide Executive management with quick metrics on site performance

Before embarking on performance testing I had to ask myself the following question. What is performance testing and what am I measuring? There are several subsets of performance testing including load, stress and endurance to name a few. In this case, I wanted to perform load testing by measuring server response times by hitting the site around the clock to establish a baseline. This will allow us to gather response times while the system under various loads and build historical data. Our peak time starts at 8 am, lasts until 10 am and tapers off throughout the day. Data gathered during each run is stored in a jtl file that contains the results of each run and can be rendered in Graph Results listener found in the JMeter gui or exported to a CSV or XML file.

Installing JMeter was simple and setting up tests was not difficult thanks to the contribution of the online community sharing tutorials, documentation and videos. All performance tests are run on a linux virtual host. Since Jmeter has a graphical interface, I had to enable X11 forwarding and install a few X11 libraries to enable making changes to JMeter test plans and execute while working on my windows desktop to the remote host. Furthermore, JMeter can run from the command line for easy scheduling of execution in a batch or cron job.

Over the next few weeks, we will spend time refining and extending the tests to better suit our needs. This includes load testing in QA and staging environments and having this become part of the QA test plan. JMeter also extends to testing databases and webservices among other server types. Over the next few months, we will be exploiting this tool and sharing its useful features on the HauteLook Tech Blog.

I wrote a blog post about the use of ORM in response to aother blog post about the move away from using an ORM. This is the philosophy I spread at HauteLook. When dealing with big data, patterns like Active Record just don’t cut it. We pay very close attention to the queries that drive HauteLook’s most popular pages.

The holiday season is HauteLook’s busiest time of year. We have spent a lot of time creating new products and optimizing website performance for the increase in traffic. We can now sit back and monitor our dashboards. This makes it a perfect time for us to implement a code freeze and spend some time on internal projects. These projects include paying off technical debt, planning for the 2012 year and training. Here are some of my activities during code freeze:

Attended the jQuery Summit

I spend most of my time working with server-side technologies, such as PHP and MySQL. The jQuery Summit had a great developer track that exposed many of the new trends and technologies being used to power websites. I discovered things like Backbone.js, RequireJS (AMD), better ways to handle iframes and now have a more in-depth understanding how jQuery works.

Streamlining the build process

We like pushing lots of small changes throughout the workday instead of large changes. I have been working with the release manager on some bottlenecks in the release process. I have been adding new features to our open source IRC bot plugin to make it easier for our developers to keep track of what is being released. HauteLook uses the Phergie IRC bot and our Jira plugin exposes a lot of common Jira tasks as IRC commands.

Learning Backbone.js

I am working with the front-end team to integrate Backbone.js into our existing codebase. We are always trying to improve processes, especially the amount of time it takes to create and improve features. The HauteLook backend is fairly well architected and organized. There is a clear separation of MVC concerns and our Restful API makes it easy to expose HauteLook to other platforms. Backbone.js looks to provide this same sort of separation to the front-end. A number of us are implementing existing website features using Backbone.js and discussing what we learned and what best practices to introduce to the entire team.

Fixing bugs and adding features to xhprof

Performance is a big deal at HauteLook. Our bursty traffic patterns present a hard, but interesting challenge to keep the API, website and all platforms fast. I created a custom fork of Facebook’s xhprof to store PHP performance profiling data on Amazon S3 and created a more functional dashboard to view the results. Recently, I stumbled across a tweet from Paul Reinheimer about the xhprof fork he had been working on. I decided to collaborate with him and merge my changes into his fork.

Attending the PHP Architect Cloud Summit

PHP Architect hosted a cloud summit where a number of startups presented on how they were using the cloud. HauteLook is traditional in that we have a data center with hardware that we own. We do use some cloud features, such as Amazon S3, where appropriate. A number of us attended the online summit and discussed the ways we can leverage new cloud technology.

Planning for the release PHP 5.4

The release of PHP 5.4 will bring about some significant fundamental changes to the way PHP works. I am already assessing what PHP changes we have to make in order to upgrade to 5.4. This involves custom builds of PHP to run the .phpt tests that ship with PHP on our production web servers and running our PHPUnit test suite against 5.4.

I was asked about how we do caching here at HauteLook, so I made this little diagram.
Enjoy.