An Interview With George Schlossnagle

      4 Comments on An Interview With George Schlossnagle

p. george_schlossnagle_card At OSCON 2006, I caught up with most of the principals of OmniTI. They each gave me some time out of their busy schedule to ask them about their history, the company, PHP and technology in general. One of the OmniTI gang I got to talk with was George Schlossnagle.

p. I was able to pry George away from speaking and taking pictures long enough to sit down and talk tech for a few minutes. Here’s how our conversation went.

p. **George, let’s get a little background on you. How did you get into programming and how did that lead you into programming with PHP?**
I started programming in the early 90’s when I was in College. I was studying mathematics at the time and went from there into computational mathematics so I was doing a good bit of numerical work in FORTRAN. From there, when I left grad school, I went into operations works. I did a little bit of systems engineering and systems administration. I picked up C and Perl for that. That had to be sometime in the late 90’s.

p. I started working with PHP in 1999. This was right at the PHP 3/PHP 4 cutover point. I was working for a company called “Community Connect” which at the time was doing quite a bit of traffic on their web site and struggling to grow with PHP. So I had to learn it so we could figure out how to make it scale.

p. **So how did that lead you to work at OmniTI?**
Theo Schlossnagle, my brother, was the original founder of the company. I started working part time with him in 1997 or 1998, back when it was still a company of one. I was primarily doing high-end performance work, Oracle tuning, website performance diagnostics, etc. In that time, the late 1990’s there were a lot of people who had built sites in the mid 1990’s that worked great with their one thousand users. As the boom started, people had these applications and they said “I love my application. It worked great when it was running with one thousand users, now I have one hundred thousand users and it doesn’t work any more and I need it to work.” That was sort of the problem that we focused on. Originally the focus of the company was Perl. When I came on board, I brought with me my PHP focus. Since then we’ve expanded a lot around PHP. We brought on Chris Shiflett, Laura Thomson and Wez Furlong and we now have a huge amount of highly talented people on staff.

p. **OmniTI has an entire division working on email solutions so it is a topic you obviously know something about. Let’s talk about Email for a moment if we can.**
Yes, we have 2 major business units within the company messaging and consulting. As we discussed, we started out doing high-end performance tuning work, a lot of times that bridged into custom engineering. So again, in the late 1990’s the commercial tools on the market for doing “High Performance” in just about anything related to the web weren’t terribly good. So we got our hands dirty and our value add became the fact that we could come in and solve your problem. We would either find a tool or build a tool to solve the problem.

p. We were building a lot of high performance email infrastructures during that time period. There weren’t any good commercial solutions on the market and the open source solutions really wouldn’t scale very well in the direction we needed them to. So we identified this as a niche and said “Let’s take our systems engineering experience and focus that on email.” In 1999 we started building a product called Ecelerity which is a high performance MTA. We took it to market in 2002 and it’s been going really well since. It’s been doing so well that we are about to split off the messaging business unit into a company called “Messaging Systems”.

p. **Ok, let’s move on and talk about PHP for a bit. You said that OmniTI got it start doing performance and scalability enhancements; do you still do a lot of that type of work?**
Yes, we do. We still have a lot of companies both high and low profile, that we still work with. Companies like Friendster, for whom we do a lot of performance engineering. It’s still really exciting work. As PHP continues to be accepted into the enterprise and into the large portal space people keep running into challenges. Not necessarily limitations of PHP but limitations of any system. Situations like “I’ve got this thing, it worked great when I had one million users. Now I have tem million users and I need it to work just as well.”

p. IMG_2672 **That segues right into my next question. If you could pick one issue that is the scalability bottleneck that you find the most in large scale PHP applications.**
It really varies greatly. If I had to pick one bottleneck though I’d say it was accessing any data store. People are used to thinking “This is my database and my database is very fast.” Then you start using it more and more and your dataset grows along with the number of queries you are doing on a particular page to accomplish a task. That has to be the most common bottleneck, database access. This can usually be cured by looking at what you are doing on the page and analyzing whether or not you should be doing that.

p. **Since scalability is a buzzword floating around the web these days, lets talk about it and how it applies to PHP. There has been a lot of talk over the past two years about the scalability of PHP. Can you give us your insight to how scalable PHP is?**
Well, I think the fact that Yahoo runs PHP across a large portion of their infrastructure now should dispel any notion that PHP does not scale. I think it’s ridiculous to say that PHP does not scale. At the same time it needs to be said that you can make just about any technology scale. The real question is can you do it efficiently? From this aspect, I think PHP has a couple of things going for it. One is that the language itself, by being simple and having a very simplistic approach to what you can do in PHP and what you should do somewhere else encourages a development paradigm where you don’t build things into your application that can’t scale. So when I am building a large Java solution, I have an incredible temptation to build all sorts of middleware into my applications. Things that are custom because I have these one hundred Java engineers on staff and that is what the company spends it’s time on. It’s cool to build cool things. What you end up with is a large infrastructure that is hard to scale. PHP encourages people to use the best tool for the job.

p. **Along those lines, but speaking more specifically; in a multi-web server application, what is the best way you have found to handle sessions?**
There are a number of good session management solutions. I think the first thing you need to do is answer the questions “What do I need to have stored in the session? What session data is really important? Which part of it is completely transient? If it’s transient, can it be off-loaded to a client-side cookie?” If it can, then it takes absolutely no resources on my server. It also means that the client is responsible for managing that. Obviously though, you can’t store a lot of data in that fashion. So moving into the server, if it doesn’t need to be persistent, if you are not worried about what happens when a web server crashes, you can stick it in memcached; you can stick it in MySQL’s MaxDB – their high performance, replicated, in-memory storage system. I think there are a lot of good solutions for that depending on what sort of data retention you need for your sessions and what technologies and platforms you prefer.

p. Obviously there are some bad choices as well. I think that storing them in files obviously has limitations.

p. **Let’s move on. Marco Tabini recently published his article titled “Five Top PHP Mistakes”. What do you think is the number one mistake made in developing PHP, the language?**
Well, everybody has their list of what annoys them about PHP. Some people are really annoyed by the inconsistency in function prototypes. For instance depending on which str* function you want, it may be “haystack, needle” or “needle, haystack”. I’m perfectly willing to concede that those are annoying but I don’t think they rise to the level of design deficiencies to me.

p. If I can pick two, one would be the lack of integrated compiler cache into the language. You shouldn’t have to use a third-party product to overcome this. It’s one of those things that when you talk to developers from any other language, they are astounded that this feature is not in the platform. That’s one of my top ones.

p. The most annoying thing to me on a regular basis is the lack of good namespaces. Not having namespaces in the language means that it’s very difficult to package things. Since we have many clients at OmniTI, if I want to write something that is reusable, I’m forced to use these really long, obfuscated function names to guarantee that I’m not going to have a collision wherever I use them. It makes things cumbersome. You can put them all in classes and make them static methods but then they are slower and it’s really not the right way to do it.

p. **When working with PHP at OmniTI, do you code using procedural or Object Oriented?**
Really, we are agnostic. For things that we develop internally, I’d say there was a good mix, something along the lines of 70% OO and 30% procedural. However, a lot of our work is on pre-existing code bases on client’s sites. One of our most stringent standards is that we adhere to clients coding standards and development guides. So when we go into a customer where everything is OO, even perhaps to a ridiculous extent, we feel like our mandate is “This is how they do it, they are going to have to maintain this after we are gone, and so we should adhere to that.” So if it’s all procedural, we’ll keep it that way; the same with OO.

p. **Let’s move on to some forward looking questions. First, let me ask you; for your in-house development, are you using PHP 4 or PHP 5?**
All of our in-house development is done on PHP 5.

p. **When PHP 5 was finally released, what was the one new feature that made you say “Yes!”**
Well, both Wez and I, Wez more so than I, are pretty active in the development of the language and in the community. Internally at OmniTI, there was a large amount of anticipate around the release of PHP 5. Particularly, things like the improvement of the object model and “pass by reference, not by value”. These things were really important to us. Another thing was PDO. PDO is very nice to have in PHP 5. Those are probably the primary motivators for me to move to PHP 5.

p. **Let’s set our sites to the future now and look forward to PHP6. What are you anticipating in PHP 6?**
Obviously, the killer feature in PHP 6 is native Unicode support. I think that anyone who has ever had to do internationalization in PHP will look forward to it with great anticipation. Other than that, just generic improvements in the object model that will make it better.

p. **Let’s talk a bit about PHP in the enterprise. What do you see as the major roadblock that PHP has to overcome to be more readily accepted in the enterprise?**
I think the biggest thing that PHP has to overcome is the pro-Java and pro-.NET attitude in the enterprise. Both of those are pushed by major corporate entities and that puts a lot of marketing behind them. People feel like they are the right solution for enterprise problems because they’ve been told that for ten years now. I think overcoming those prejudices are the biggest task. I also think that people find it hard to accept the use of a scripting language in an enterprise environment. There’s a feeling that going with a statically types, compiled language gives you greater safety.

p. I think the answer to all these things is looking at what the technology is supposed to be accomplishing and where does PHP fit in. Should you be implementing your back-end fulfillment system logic in PHP? Probably not, you should probably be using something else. That’s not a bad place to use Java or c++ but it’s probably not the right place for a scripting language. However, up front, in the web, when you are basically building a presentation layer on top of some of those resources it’s a great place to use PHP.

p. **Does OmniTI deal with a lot of mixed environments where PHP being the glue language on top of other systems?**
Yes, a good bit of the systems we work with are mixed like this.

p. **Ok, now to a couple of fun questions I like to ask in all my interviews. First, of all the technologies out there, PHP or non-PHP, which one has you the most excited?**
I guess the stock answer if you ask anyone at OmniTI this question, would be dtrace. dtrace is an extremely flexible profiling system that is part of OpenSolaris and Solaris Ten. It basically allows you to dynamically inspect your running code. It’s like strace on crack. From the point of view of doing C-Level engineering, which is what I spend most of my time doing, working in C, it’s great. There are ports in progress to bring that into FreeBSD and Linux.

p. **Finally, what is your favorite web page or blog?**
Well, I’d feel really shallow if I said it was “”: but that would really have to be on the short list. If I had to chose one, I’d have to say “”:

p. That’s it. After that, I made sure I took a picture so that my next batch of PHP Trading Cards had the correct picture for George. Thank you once again George for taking the time to sit down with me.