Day 2 - Session 4 - Scalability via Zend Platform

So far we've briefly discussed the purpose of scalability, and what it means to be scalable.

Root-cause analysis:
When an event is captured, it's context is also saved. If a POST was made, and it threw the error event, then it would capture that POST data in order to provide contextual information to isolate the problem.
This also integrates with Zend Studio, so you can debug/profile immediately. You can even reproduce the HTTP request that triggers the problem.

Examples:
Showing an example of division by 0, and how the event is displayed in the Platform. You get tons of nice information such as the file hit, the file the error is in, the php error, event occurrence information (ie, how many times, first and last error trigger), method parameters, and the entire stack.

Comprehensive Performance:
Performance is affected by many factors, such as:

• Network load
• PHP processing time
• Server load
• DB load
• Logic in the application

A key takeaway among these performance methods is that Zend Platform can cache items all along the way.

Clustering:

• 1 key issue is sharing session data across cluster nodes.
• Shared storage becomes a bottleneck (NFS going down, DB going down).

Job Queues:
USUALLY:

• PHP is isolated, nothing sharing for parallel execution.
• Job's must finish before another starts
  
• No asynch execution
• Background processing requires "hacking"
  

NOW:

• Jobs executed in background
• scheduled via API or a web gui
• elaborate scheduling rules
• job failure handling
• monitoring and execution stats.

Personal notes about the features which are badass:
Yeah that's my official title.

• You can tell which server exactly the error comes from.
• Clustering is scalable quickly and easily.
• Caching can be set up for a lot of different things.
• You can potentially have backup plans based on clusters.