For some time, I’ve been aware that the performance of
Errbit is not great. But that problem has
so far taken a back seat to Errbit’s other priorities. For v0.5.0, I want to at
least make a dent here and actually do something to improve this situation.
But before I get started, I felt like it was a good idea to put together some
kind of bench test for two reasons. First, I want a record of where this began
so I can see how much progress we make over time. Second, and more importantly,
I need a decision making framework. If I need to make a decision to sacrafice
some functionality for performance, I want to have a handle on how much
relative performance is at stake.
My goal is not to create a perfect or objective or complete measurement of
Errbit’s behavior, but simply to get a sense of how Errbit’s performance
characteristics change as errors are added to its database and as the code
changes over the course of this performance improvement project.
To start, I created
errbit_loader with a pair of
load tests for the two most common errbit uses, creating and finding errors.
You start the test by specifying the number of errors to create and search for
in each block (count), and the number of parallel requests to keep open at any
one time (concurrency). In this round of testing, I used count=1000 and
concurrency=8. In each test, errbit_loader runs the create batch, followed by
the search batch and then repeats this pair of tests until stopped.
90% of the errors created by errbit_loader are repeating, so they should be
grouped with other like errors. The other 10% have unique messages which should
cause them to be not grouped with other errors.
I know from experience that performance degrades tremendously with many
millions of errors, but it took more than six hours just to create 100,000
errors in these load tests in my environment. For that reason, I have decided
to stop at 100,000 for now and increase the total count after we make some
Software and Hardware Information
For this round of testing, I am using Errbit
v0.4.0, Ruby 2.1.2, and mongo
2.6.3. Errbit is using its default deployment strategy which is single-threaded
unicorn with three worker processes and preload_app set to true. The test
process, mongo, and Errbit itself are all running on the same physical machine
which is a Lenovo ThinkPad T430s.
In just over six hours (6:02.59), I inserted 100,000 errors, in blocks of 1,000
and completed 100,000 searches. There is a bit of noise in these data between
80-90k because I forgot the tests were running at one point and started using
my laptop for other things. The results should still be usable, though, since
the underlying trends are clearly visible.
This first chart is a total request time overview. Out of each block of 1,000
tests, I’m showing the 95th percentile, with five percent of requests being
slower than each point on the chart. Time to insert errors appears to be fairly
constant as the database grows, while searching seems to grow linearly.
Here’s a closer look at the results for creates. This chart shows the 90th,
95th and 99th percentile.
And here’s the same view of search requests.
My hunch is we can do a lot better than this. Instinctively, it doesn’t seem
like it should take anywhere near a full second to insert an error. I’m not
completely unhappy with the results for search requests, but I think that’s
only because there are still relatively few errors in the database. Once we
speed up the inserts, we should be able to more easily test how performance
degrades as we start getting into millions of errors.
As you probably do not recall, this blog was not always running on
Wordpress. In it’s first incarnation, it was actually running Drupal
. And as
of yesterday, we can add Wordpress to the list of former lithostech.com
site is now running on Jekyll, and since it seems to be relatively
unkown compared to wordpress, I thought I’d take the opportunity to
explore this change and explain the move. What follows could be looked
at as a comparison of Wordpress to Jekyll as a blogging platform.
Wordpress has served me well. There are plenty of free, prebuilt themes
ready to rock. Sadly, if you’re searching for Wordpress themes and you
only consider themes that are mobile-friendly, SEO-friendly, easy to
work on and not full of bloat, you’ve already elimated the vast majority
of both free and paid themes that are available. If you want something
visually appealing, you’re really down to a small handful of available
themes which means your only real option is to use one of those and
extend it, or write your own.
This is a bit daunting, but totally possible, especially starting from
an example. Just read theme development docs
and have a great time.
You can <?php var_dump($foo); die(); ?> your way to a complete theme if
you have the time, but unless you’re very familiar with this theming
API, it’s going to take a while. It’s possible to do just about anything
you can imagine, but I found theme authorship to be slow and painful and
more than a little annoying.
Jekyll uses liquid for templating which is
quite powerful and much more compact than plain PHP. After all, Jekyll
is a much simpler tool than Wordpress, and for me that simplicity is a
core strength. Have a look at this page’s layout
to get an idea of how simple it is to write Jekyll themes.
looking through all the options, I just haven’t found the perfect
framework. That’s why I’m introducing my own framework to provide the
best possible interface, helping you to inject exactly the dependency
First, I want to introduce the problem we’re trying to solve. Let’s say
knows too much about the dependency. This is what smarty-pants engineers
call “tight coupling”:
Suddenly this topic seems to be all around me. Although, I’m not sure if
it was always here, or if I just wasn’t paying attention. But it’s here
in a big way. The meritocracy discussion seems to be mainly about women
in tech, but to a lesser extent, minorities.
At first it was an old colleague of mine on twitter. And frankly, I was
annoyed to see his many-times-a-day posts about feminism and how the
whole world is conspiring to keep his daughter from enjoying science and
math. It went on like this for years and I eventually stopped following
him because he never talked about anything else and I was tired of his
What I didn’t understand at the time was this was all part of a much
larger discussion. Although I did notice the growing trend about a year
ago and started to take notice. Looking back at stories from the past
few years shows just how much attention this is getting from major
internet media outlets:
The Boston Globe.
You can even watch the rise of the term ‘meritocracy’ on
as it begins in early 2009, likely in association with its so-called
Recently, I also ran across an indiegogo project called
CODE: Debugging the Gender Gap
which promises to explore the lack of diversity in the tech world. At
this point, it’s fully funded and I’m excited to see it when it’s ready.
Today, the discussion seems to be finding new ground after Microsoft CEO
Satya Nadella’s remarks caused a minor internet storm, where he made
some regretful remarks about how women should behave regarding salaries
and ended up having to
take it all back.
And that’s great, the man ate his silly words and hopefully we all
Through our work on the OptionsHouse API
we’ve somehow become known as trading algorithm experts. At least once a
week, Branded Crate gets a phone call or email from someone who wants to
automate trading activity. To even have a thought like this requires
some level of sophistication. Even so, many potential clients aren’t
aware of what it takes to create and manage a system like this. That’s
our area of expertise, so if you’re considering trading automation, read
on to learn more about how we do it.
The very heart of any trading algorithm is the actual algorithm, written
using instructions a machine can understand (code). This is mainly what
clients think about when they talk to us. The idea generally seems
simple at first, but complexities emerge as you begin to consider
automation. Without even thinking, clients “just know” to do things a
certain way as they execute their trading strategies manually.
Computers, on the other hand, don’t know anything.
Let’s say a client wants to buy N shares of some stock when the current
price of that stock is lower than it was at the same time on the
previous trading day and sell when the current stock price is higher
than the same time on the previous trading day. This is probably a
terrible strategy, but ignore that because it can still serve as an
example of how and where complexities emerge.