The document discusses using queues to improve the scalability of PHP applications. It describes how queues allow asynchronous and distributed processing of tasks to improve performance and allow applications to handle more traffic. Specifically, it promotes using Zend Server's job queue to offload long-running tasks like payments processing so the frontend can scale independently of backend processing. Examples show building jobs that communicate with the queue to asynchronously execute tasks like payments.

1. Do you queue? Characteristics of scalability Kevin Schroeder Technology Evangelist Zend Technologies

2. About me Past: Programming/Sys Admin Current: Technology Evangelist/Author/Composer @kpschrade

3. I blog at eschrade.com Follow us! (good things will happen to you) Zend Technologies http://twitter.com/zend http://twitter.com/kpschrade (me!)

4. Twtpoll results Could your PHP apps benefit from being able to process data or execute asynchronously?

5. Why would you want to queue? Performance Execute logic apart from the main request (asynchronicity) Scalability The ability to handle non-immediate logic as resources are available

6. Typical anatomy of a PHP Application Bad for scala-bility! Presentation Application Control Database Access Business Logic Presentation Application Control Business Logic Presentation | 6

7. Good for Scalability Presentation Something.phtml Something.phtml Something.phtml Something.phtml Something.phtml Something.phtml Something.phtml Something.phtml Application Control Something.php Something.php Something.php Something.php Something.php Something.php Something.php Something.php Business Logic Something.php Something.php Something.php Something.php Something.php Something.php Something.php Something.php Database Access Something.php Something.php Something.php Something.php Something.php Something.php Something.php Something.php | 7 | 8-Feb-11

8. What helps make software scalable? Defined tasks Loose coupling Resource discovery

9. The Golden Rule of Scalability “It can probably wait”

10. Asynchronous execution uses Pre-caching data Data analysis Data processing Pre-calculating (preparing data for the next request) Data is “out of date” once it leaves the web server Immediacy is seldom necessary

11. Characteristics A sledgehammer can hit a machine Scalability and High Availability are yin and yang A site that can’t keep running is not scalable A site that can’t scale will fail (if it gets really popular) Machines can be added and removed at will Not “cloudy” necessarily No single point of failure Data exists in at least two, preferably at least three, places

12. Considerations Waste disk space Control usage (don’t let users do anything they want) Pre-calculate as much as possible Calculate and cache/store Keep data processing off the front end servers Don’t just cache Don’t let it substitute for thought Cache hit rates can be meaningless if you have hundreds of cache hits for a request

14. Make as much as possible configurable/discoverableDecouple/Partition Don’t tie everything (relationships and such) into the database Use queues/messaging Stomp interfaces are really good for PHP – Can also use Java Bridge Zend_Queue has several interfaces Try to use stateless interfaces (polling is more scalable than idle connections)

15. Options Use Cron /w PHP CLI (not the best idea) People mostly use cron simply due to availability It’s an available option, not necessarily the best option. Use Gearman Use home-grown (don’t do this) Use pcntl_fork() (NEVER do this) Use Zend Server Job Queue

16. Your only real options Very cloud friendly * I am not an expert on Gearman. Corrections will be taken in the spirit that they are given. For obvious reasons, I will focus on Zend Server

17. Zend Framework Zend Server PHP Application Performance Reliability & Management Scale-Out Business-grade PHP Acceleration Monitoring Clustering Hot Fixes Optimization Root-Cause Job Queue Support Caching Downloads Java Bridge Configuration Linux (rpm/web repositories) IBM i (PTF) Windows (MSI) What the heck is Zend Server? 16 Zend Server

18. Job Queue Architecture – Elastic Backend Web Server /w JQ Web Server Users! Web Server /w JQ Web Server Load Balancer Web Server /w JQ Web Server Pros Scale the backend as necessary Default (easy) mechanism Cons Getting the job status requires using a DB

19. Job Queue Architecture – Elastic Frontend Web Server Web Server /w JQ Users! Web Server Web Server /w JQ Load Balancer Web Server Web Server /w JQ Pros Easy to communicate with the Job Queue server handling the job Cons Requires you to build your own interface (or just use mine!)

20. Kevin’s favorite way to implement it Create a task-handling controller Create an abstract task class Understands the Job Queue Self contained If Elastic Backend: connects to localhost If Elastic Frontend: connects to load balancer (my preferred), load balanced JQ servers manage themselves Execute the task, have it serialize itself and send it to send to the task handler

21. Classes involved in the demo Manager Handles connecting to the queue and passing results back and forth JobAbstract Abstract class that a job would be based off of Response The response from the manager when a job is queued. Contains the server name and job number GetRemoteLinks Scans a given web page and reports back a list of all the links on the page

22. Execution Flow Create job and set data Execute job Job passes itself to the queue manager Manager serializes job Manager uses HTTP call through a load balancer to queue the job The queue on the other end returns the job id and server name Job ID and server name is passed to the client Client polls the manager to get a completed job When the job is returned pass the serialized version of the executed job

23. Demo

24. Neato, but how in the world does this pertain to Magento?

25. How? Long running front-end requests kill front-end responsiveness which kills the user experience 40% will wait no more than 4 seconds for a website (Forrester) Calculating cache data on-the-fly can lead to bad user experiences (abruptly slow page load times) and consistency problems Long running page requests can push up against max_execution_time For example, handling payments from a slow CC API Simply setting it to run longer is a band-aid on a broken bone

26. Solution? Build Zend Server integration extensions Zendserver_Jobqueue Zendserver_Monitor Utilize the event system to intercept actions Async_Payment (for payments, in this case) Profit! (scalability AND performance, actually)

27. Building a job Install the Zend Server Magento extension Create a class that extends Zendserver_Jobqueue_JobAbstract Call $job->execute();

28. Payment as an example Hooks an observer into controller_action_predispatch_checkout_onepage_saveOrder, core_block_abstract_to_html_after Checks if a defined template is being rendered Injects JavaScript that changes the review.save() method Injects a new URL for submitting the transaction which creates a job Passes POSTed data to a job Job executes by submitting the payment URL on behalf of the browser, storing the result Browser pings the server to see if the job has completed executing yet

29. Scaling the solution Webserver Job Queue/ Webserver Webserver Load Balancer Job Queue/ Webserver Webserver Job Queue/ Webserver * Duplicate deployments on ALL machines Database or Session Clustering

30. Downloads Zend Server http://www.zend.com/server Zendserver_Jobqueue https://github.com/kschroeder/Magento-ZendServer-JobQueue Zendserver_Monitor https://github.com/kschroeder/Magento-ZendServer-Monitor Async_Payment https://github.com/kschroeder/Magento-Async-Payment Job Queue library & demo https://github.com/kschroeder/ZendServer-JobQueue-Job-API http://bit.ly/hWJBYw

31. Magento/Zend Case Study - http://bit.ly/horpFF Follow us! Zend Technologies http://twitter.com/zend http://twitter.com/kpschrade (me!)

32. Get this information and all the examples at eschrade.com…