Philip Tellis

Philip Tellis is a geek who likes to make the computer do his work for him. As Principal RUM Distiller at Akamai, he analyses the impact of various design decisions on web application performance, scalability, and security. He is the lead developer of “boomerang” — a JavaScript-based web performance testing tool.

In his spare time, Philip enjoys cycling, reading, cooking and learning spoken languages.

Philip has spoken at several conferences, including Velocity, Fluent, JSConf, Paris Web, IPC, Webinale, FOSSDEM, FOSS.IN, FREED.IN, Ubuntulive, Linux Symposium, OpenSource Bridge, PHP Quebec, ConFoo, WebDU, Midwest.IO, and We Love Speed. He also writes for Smashing Magazine, blogs at http://tech.bluesmoon.info/ and is @bluesmoon on twitter.

Where do you work, what is your current role?

I currently work at Akamai. I lead the data science team for mPulse, our RUM performance measurement tool. I came into Akamai through a second level acquisition of a company I founded around performance measurement and analytics.

How do you use PHP professionally?

I do not currently use PHP. I used PHP extensively between 2004 and 2011 while I worked at Yahoo!, but haven’t used it since leaving. Our current tech stack is Julia running in a Jupyter notebook server running on Linux. Our charts are all JavaScript based, primarily using d3 or vega. Our performance measurement code is also JavaScript based.

How and when did you get involved speaking or writing in the community?

I’ve been speaking publicly since 1998 when I was asked to speak at my alma mater in India about a career involving computers and the web. The web had only been generally accessible in India for about 2 years at the time. I then got heavily involved in the local Linux user’s group, giving many talks and workshops. The first conference I spoke at was Linux Bangalore in 2004, and I’ve spoken almost continuously since then only taking a break when my son was born.

What’s your best conference memory?

There are many great conference memories, almost all involving the hallway or restaurant track.

Probably the most memorable conference experience was the time Buddy (my co-founder), and I spoke at Velocity UK in 2012. We were redoing our talk from Velocity Santa Clara, except at Santa Clara we’d had a 3rd speaker, so while speaking in London, we realized at some point that we were almost done with our presentation, but had only used up 2/3rds of the time. While Buddy stretched his last few slides into a lot of detail and took questions, I added more slides to the end of the shared deck to fill in the extra time. I don’t think anyone noticed a break in continuity.

What advice do you have for someone going to their first conference?

There’s a lot of depth you’ll get in the talks itself, but the hallway track (that’s where people chat over coffee in the hallway between conference rooms) is where you’ll get a lot of first-hand experiences from people who aren’t on stage. You might even find your next great hire there. I’ve found quite a few.

What’s your primary OS: Windows, Mac, or Linux?

Mac/Linux

I’m a backend dev, why is front end performance important to me?

Front-end performance doesn’t mean that the problems and solutions exist only on the front-end. It means that the problems have the most impact on the front-end—which is where your users hang out, and presumably, users are the reason you have a site and get paid. Decisions we make at all parts of the stack, even things we don’t think about like, “which OCSP vendor should I use?” will have an impact on user experience. Parts of your stack closer to the user will have a more noticeable impact, but unless your site has no backend, it’s highly likely that what you can do on your frontend is highly dependent on services provided by the backend.

What’s one myth about performance that people get wrong?

That the average bandwidth available to users is going up so sites should automatically get faster. Unfortunately, the speed of light is constant and is the primary limiting factor for latency.

Can’t you just add more servers to make stuff faster?

Yes, sometimes. You can also have fewer servers to make stuff faster because the fastest request is one that isn’t made. Keeping more content cached in the browser or intermediate caches means we can provide better performance with fewer servers. For the majority of problems that we try to solve over the web, server-side CPU is never the bottleneck. Individual boxes can handle hundreds of thousands of concurrent short-lived connections, and we seldom do anything fancy with SQL.

The bottleneck is almost always getting code and data to the client, and rendering them in the right order.