Showing posts with label opensource. Show all posts
Showing posts with label opensource. Show all posts

Saturday, May 18, 2013

perform performance test using multi-mechanize

gave multi-mechanize a try recently, when in-need of behavior analysis for an application on massive concurrent requests being sent to it

What? multi-mechanize is an OpenSource load testing framework written and configurable in Python. So either make calls to any web service or simple import and utilize any python-accessible API/service.
It's successor of an old Python load testing framework called Pylot.

Developed and maintained @GitHub

Install available through 'pip' too as
   $ pip install multi-mechanize
It also requires matplotlib library if you wanna view Graphs in the generated HTML report (or otherwise), BUT it's not mandatory as the framework would perform all tests fine with an import error for matplotlib.

This also follows a bit convention oriented run structure. We'll see how.

Before starting any performance check user is supposed to create a project using
$ multimech-newproject project_name

This creates a dir 'project_name' at place of execution with following dir-structure
./project_name
├── config.cfg
└── test_scripts
    └── v_user.py

here './project_name/config.cfg' mainly contains global configuration around the duration to run,


[global]
run_time = 30                # second duration for test to run, required field
rampup = 0                   # second duration for users to ramp-up, required field
results_ts_interval = 10  # second time series interval for result analysis, required field
progress_bar = on         # console progress bar on/off, default=on
console_logging = off    # console logging to standard ouput, default=off
xml_report = off            # xml/jtl report generation, default=off
# results_database = sqlite:///results.db ## optional component to push results to DB
# post_run_script = do_whatever.py ## to run any script to do anything on test completion 
[user_group-1]
threads = 3                  # number of threads to run the following script in
script = v_user.py        # the actual script that will be run to test, give any 
## similar more users with same/different threads and script values can be added with names like user_group-ANYTHING.

Now, to run this prepared project
$ multimech-run ./project_name

As I already mentioned it picks certain implementations by convention, most important to notice is the way user-group-script is to be prepared.
Basically it's to be a python script that can utilize all Python magic you know or install. But it need to have a 'Transaction' class with 'run' method.
When you run your project using multi-mechanize, it instantiates 'Transaction' class and keeps calling 'run' method in a loop...

Example user-script to test load at your 'python -m SimpleHTTPServer'
# v_user_server.py
import httplib


class Transaction(object):
    def run(self):
        conn = httplib.HTTPConnection('127.0.0.1:8000')
        conn.request('GET', '/')
        resp = conn.getresponse()
        conn.close() 
        assert ((resp.status / 400) == 0), 'BadResponse: HTTP %s' % resp.status
# finito file


Find the detailed scripting guide with plenty good examples here : http://testutils.org/multi-mechanize/scripts.html

Monday, March 5, 2012

MCollective can't handle Puppet ~ just like psychotic love stories

Some puppet-izers didn't like what I said in my last post... still a mess is a mess no matter how worth it might be.
Past 2 months, I've been in pain due to the psychotic love story of MCollective and Puppet.

YES, they are very helpful products to automate configuration management and orchestrate metadata-based multicast-ed actions.

YES, they are now under the same organization PuppetLabs which is whole-heartedly working to improve them so they could retain their status in the started-to-glamour-izing DevOps domain. So, both of them will improve a lot.

But, first of all.
If you don't properly test your corporate-aiming projects over Ruby1.9.x; please do post a big notice on your projects page or at least on first page of your amazing Doc.
My story for past few weeks:
I start using a project..... oh it's failing, debug..... oh it's still failing..... debug.
Ahhhhh, ok ask at IRC.
WHAT? I'm using Ruby1.9.x so its possible I might be facing *some* issues.
Is this is a Joke, I'm trying to stabilize an important project over here.
At least be truthful, and don't behave like TV Commercials with small+quick Disclaimers.

And Again.
I'm managing MCollective over all my instances via Puppet. Obviously, because that's what Puppet is for..... managing state of instances.
I've a CI which instigates MCollective to orchestrate different actions over my infrastructure. That's why I took the pain to get the changing-but-not-releasing MCollective over my infrastructure.


Now, this also involves MCollective firing up Puppet in non-daemonizing mode.
This used to raise an Exception in MCollective due to un-handled 'nil' return value failing up my entire build.
I go on IRC, again trying to get a solution..... I get to know that even this has been fixed later in the git-repo since I rpm-ed it last time. But I also get an answer that this wouldn't work as Puppet no-daemon mode has problems. And if I wanna follow this approach, its my decision.
First of all, what the hell should I do when there is just one straight approach left. Except for if I start using something else to manage MCollective.

Though, I took the latest pull..... rpm-ed it and updated all my nodes. And the Puppet non-daemon problem has not yet been raised.
But, what kind of response is it.
If it wasn't for the team decision..... I'd have changed it overnight x(