The Future of BMP
TL;DR ā Iām leaving BMP but I hope the project continues under new leadership. I have some ideas about what work needs to happen and Iām here to help with the transition. Read moreā¦
Over the last year Iāve come to two conclusions:
I am personally no longer able to commit the time necessary to maintain the BMP project, primarily because of Real Life: two young daughters (1.5yo an 3.5yo) and an increasingly-demanding day job.
The BMP codebase is somewhere between āmiddle-agedā (the SiteBricks / REST API layer) and ādecrepitā (see history below).
Given these two facts, Iāve decided that the best thing for the project and the community is for me to (gradually) retire from the project.
I donāt want to leave the community in a lurch, so my hope is to recommend a technical direction (outlined here) and nominate a number of recent, active BMP contributors to carry the torch.Ā
I will, however, not be responding to any open pull requests or incoming support questions on the mailing list starting immediately. My commitment is that I support anyone else who wishes to continue this project or start up a similar-but-alternative one.
But first, a bit of historyā¦
BMP (aka BrowserMob Proxy) dates way, way backā¦ about ~10 years ago, when Selenium was first getting off the ground. You may not know, but Selenium wasnāt aways offered as a native āWeb Driverā to various browsers. Back then, it was a simple JavaScript library that ran inside the web application.
Some of the committers (myself included) realized that this approach was limited and required that the application under test bundle Selenium inside of it. In order to bypass that requirement, we created an HTTP proxy injected the JavaScript in to each header of each page load and did all sorts of tricky stuff. Eventually we started doing really funky stuff, like doing man-in-the-middle āattacksā so that we could inject in to SSL.Ā
Meanwhile, I began to get in to performance monitoring and load testing and realized that the proxy could be modified to serve my desire to measure HTTP request performance. I ended up starting two separate startups and forking the Selenium code to serve my needs. While during my second startup (BrowserMob) I realized that it would be helpful if other people could get performance data from their Selenium tests, so I forked the Selenium code a third time and BrowserMob Proxy (BMP) was born.
I tell all this history partly because Iām a bit nostalgic as this is the last remnant of code Iāve dabbled with for a decade, but also partly because it helps explain why the project has the features and cruft that it has.
The Features aka The Good
Because of my participation and leadership in the web performance market, I learned a lot about the features people need when doing performance testing. Some of these features can only be done through an HTTP proxy. I wonāt outline all of them (consult the docs or API if you want a full list), but the main ones I think matter are:
SSL support!
Control over DNS lookup behavior
Bandwidth simulation
Injecting headers in the request and response
Handling authentication
Backlisting individual URLs and URL patterns
And of course: extracting performance data in a useful format (HAR)
Any one of these features can be done using non-proxy technology, but itās hard and requires multiple complex pieces of software to do it all. Thatās why I believe that for general purpose usage, the approach BMP takes is a good one for most people. That said, I do discuss alternatives (proxy and non-proxy alike) in a moment.
The Cruft aka The Bad
There are two fundamental problems with BMP:
Iām a mediocre programmer :) Seriously, the code base is monolithic and tangled, making it harder to maintain than it should be.
It depends on a very old chunk of Jetty code that was created and donated by Jetty founder, Greg Wilkins, ages ago.
Issue #1 isnāt too big of an issue: we just need to get some better programmers involved, which has already been happening.Ā
Issue #2 is more challenging: in order to maintain SSL support and ensure that BMP works reliably with modern stuff like, say, WebSockets, we need to have a more modern proxy engine, but weāre unable to upgrade to something newer, including Jetty.
This is because the SslRelay code that does the man-in-the-middle termination is incredibly complex and hard to reproduce, especially with newer web servers like Jetty and Netty, that use async.Ā
The concept of the code is simple, but I will be the first to admit that Iāve never fully understood the deep, dark corners of the Jetty 5 codebase on which it depends and Iāve fortunately been able to simply tweak Gregās code over the years.
Recommendation
My recommendation is that BMP needs a major overhaul ā probably a complete rewrite. In particular, I believe that BMP could become a nice performance-oriented project that wraps around LitteProxy.
LittleProxy can do most/all of the basic proxy stuff BMP needs, including SSL, and it has most of the necessary callbacks/extensions to support the BMP features. It may be missing a few things, but I believe those can be addressed by contributing to LittleProxy and leaving BMP to focus on the clean, performance-oriented wrapper around it.
Writing it out it doesnāt sound like much, but in fact this is a considerable amount of work!
In addition to this core proxy work, I also think the project would benefit from pulling apart the core server from the client driver(s) for each programming language. On top of that, a nice web-based GUI could be incredibly useful for people just getting started or for people doing exploratory testing.
Alternatives
I believe that BMP is the best choice for most performance testing needs, but it would be prudent to call attention to some important alternatives.
On the proxy side of the house, there is Charles Proxy and Fiddler, which are both much more popular and well-known. The main downside for both of them is they donāt have all the features I outlined and they (IMO) are not quite as easily embedded inside of test automation systems.
More importantly, there are some interesting non-proxy solutions that should be considered, especially if you donāt need all the features of BMP and just want performance data.
If youāre using PhantomJS + GhostDriver, consider the getLog() API and ask for the type āharā and youāll get back a very nice HAR file with all the timings of the assets.
If youāre using ChromeDriver, there is some really in-depth performance data available, though sadly not in the convenient HAR format.
If youāre using Firefox, with a little elbow grease you can get FireBug + the NetExport plugin to leave HAR files behind in a folder or sent to a beacon after every page load.
And lastly, many modern browsers now support the Resource Timing spec, which means you can make the JavaScript call of āwindow.performance.getEntries()ā and get back individual timings for most assets on the page. Sadly, response code and file size are not included.
The New Guard
So who will carry the torch? Iām not sure! But the good news is that there have been a number of contributors and commercial organizations using BMP over the last few years. In particular, three individuals stand out: andyclark, jekh, and nite23.
Iāve already granted all three commit rights to the codebase and I hope that at least one of them steps up and carries forward the BMP vision. If they do, Iāll be here to help them along the way.
