PHP Conference 2012

Today is Clock's 5th annual trip to the PHP Conference and generally speaking, it gets better each year.

The keynote this year is by Rasmus Lerdorf entitled "A look at PHP in 2012", and as the PHP conf site tells us, Rasmus is:

Best known for having gotten the PHP project off the ground in 1995. He then went on to be infrastructure architect at Yahoo! for more than 7 years and most recently has been advising start-ups including WePay, Etsy, and Room77. Rasmus will give insight on PHP as he sees it in 2012 - from PHP's humble beginnings as the Personal Homepage project up to what is new in PHP 5.4 and beyond. http://www.phpconference.co.uk/

We'll be live blogging and tweeting throughout the day. You can see our thoughts on the talks we attend, by either refreshing this blog or following:

• Clock Dev Ops - Which is an aggregation of links and tips by @clock's tech team (RSS here: http://bit.ly/rIQgd4)

Or individually follow some of our tech members:

• PabloSerbo (Clock's CTO)
• ClockArnIIe
• tomboa
• lukewilde
• domharrington
• rnoake

Live Feed

*A few notable tweets and a dump of data from the talks (to be formatted and summarised later!):

16:50 - Now the final talk, but this one is a panel session about 'PHP at scale' with Ian, Nikolay, Rasmus and Hugh Williams

This is going to be fast, so I'll summarise later!

Update: The panel had some great discussions and answered as much as they could. Topics included:

• Scaling a team
• Scale becomes an architecture question not a language one
• Don't just throw encrypted data at new cookies, avoiding session issues won't last long using a cookie method
• Most startups don't need to worry, there aren't that many Facebooks in the world, you can tackle it later.

16:00 - Teaching your machine to find fraudsters by Ian Barber

Ian starts with "Fraud is a big problem"

Some small numbers:

.1% a large retailer can expect to be fraudulent, 8% is the level of "Suspected" fraud.

If we had a 99% successful fraud system, we'd likely be 90% wrong on the suspected frauds.

Can already see that Ian is a great speaker, good pace and great content.

Tweet by @carshann - "Fraud Prevention/Detection talk the most solid and informative I've seen all day. Recommended! #phpuk2012 https://joind.in/4949"

Detection techniques

• Anomaly Detection (using standard deviation and historical data window to detect anomalies - need to factor in other factors "Sickness Availability")
• Building scores on details (email address vs name, geo-ip of billing vs shipping, re-sale value of item, card to addresses, previous purchase data)
• SVM (Support Vector Machines)

Really enjoyed listening to Ian, he made great sense and gave good insight, not sure how to use the info immediately, but when dealing with eCommerce the lessons shown will be really valuable, and I am confident the abstract ideas can be used in other areas.

The last three talks have been well structured and kept good pace.

14:50 - Distribute the Workload by Helgi Þorbjörnsson

Helgi promises to lead us through the world of distributed systems and scalability and how to counter a sudden rush of popularity.

Refreshing start by Hegli! Starts with humor... then straight into the meat: Why Distribute?

Answer.. Efficiency, Budget and Perception.

10 small servers > 1 big server Google and Amazon have throw away boxes. Commodity hardware.

Flickr is a good example of Perception, the service gives instant feedback and "Defers intensive processes" - Users can basically keep browsing whilst lots and lots of small servers handle the requests. Ants work exactly like this, natures perfect example of distributed systems working together to achieve a common goal.

Helgi moves onto

• Decoupling (Twitter has API issues, ok lets add a new API box as the rest of the application is running fine - decoupling logic and sections helps when scaling)
• Elasticity, Load balancing (using low TTL on DNS to remove some single point of failure issues).

We get into a Q&A about if the Load Balancer becomes the machine that you have to beef up? Simple answer yes, but load balancers are just passing data rather than processing so it isn't so much of an issue. Also someone points out that TTL's aren't always observed by ISP's so a better mechanism is Virtual IPs.

Monitoring becomes very important, as how do you know when and what to scale. Also Keeping records means you can look at trends and counter them.

Being able to monitor real-time and then using elasticity, adding and removing servers, becomes and really nice model to allow the system to become self-aware.

Helgi starts to discuss Skynet and I wonder if the "Singularity" discussion might ensue, it doesn't which is likely a good thing. Ray Kuzweil fans/critics might be sat in the conf!

Great talk by Helgi and nicely light hearted. Good speaker and handled the questions well.

13:55 - Waiting with anticipation for "To a thousand servers and beyond" by Nikolay Bachiyski

Nikolay is a long-time Wordpress contributor and will be discussing scaling a massive PHP application. Apparently he has a bear, or so it says in his bio!

Nikolay has seen Wordpress scale from 65million to 800million requests per month.

Nikolay starts with a funny story about a pig that deheads beers, and works out that understanding how foam is generated helps him with his job

The moral is... Get to know the abstraction below

One of the abstractions we face is the servers, if a site has a single server and it dies, we have a problem - we add multiple web-servers and so we add a load balancer, and the problem eventually moves somewhere else (db servers).

What happens when the data is too big for the Database? We partition the data. (which likely means no sql joins!)

HyperDB allows us to solve the issue that we don't know where to send the sql query, by using parameters to state the partition type (e.g please use the 'User' table please). HyperDB also handles failover, replication lag etc.

Next issues are load, servers bringing down database servers etc, so WordPress add caching (e.g memcache).

Ok, so Nikolay starts talking about bigger issues, imagine the servers are in a single data-centre... if the DC fails we have another "Single point of Failure" We can add more DC's and it will help, but caching becomes a problem (how do we stop the stale of cache across DC's)?

Nikolay also cites deployment as an interesting element when dealing with multiple DC's. WP commit changes approx 100 times a day, by commiting they deploy to a 1000 servers and so the commit button becomes the "button of doom!" and they have made it super fast (8 seconds).

Users don't care about commits, they just want "Publish Immediately" to mean exactly that; immediately!

But that means sorting spam, indexing, quickly, and it was slow, so WP employed AJAX to handle post-processing. And it turns out async jobs become very, very useful.

php -S

//Check if we're using cli-server
if (PHP_SAPI == 'cli-server') {