Frank de Jonge has a tutorial posted to his site showing you how to use partitioning for concurrency in optimizing the business logic processing in your PHP applications.

With new ways of dealing with problems, new problems emerge. When the solution space evolves, so do the problems we deal with. One could say we only exchange one type of problem with another.

[...] Such constraints might steer you towards a synchronous solution, but a deeper understanding of a given domain might allow for an alternative approach. The need for synchronous processing is not always as final as it may seem. Sequential handling may only be a requirement within a certain context. A context may be defined by anything related to a single user, group, or even a process.

He talks some about concurrent processing versus sequential processing and how, sometimes, pure versions of either aren't exactly the right fit. Instead he proposes a system where multiple streams could be used with synchronous handling keeping with the concurrency between the streams. He illustrates his point with a "silly chat application" with the requirement that users all get their emails in order. In his proposal he starts with a standard single thread/multiple workers scenario but points out that this may lead to messages being out of order depending on the processing time for the worker it ends up on. He refactors this into a system that uses the parallel processing instead, including the PHP code that's required to make it work.

On the MyBuilder.com Tech blog they've posted a tutorial from Edd Mann looking at the use of constraint-based ordering in PHP applications.

An interesting problem arose last week when we wished to generate a listing of recently completed jobs (along with their shortlist fees). Upon review of some earlier attempts, we did not like the aesthetics present when many of a particular shortlist fee were clustered together (i.e. two or more adjacent jobs with the same shortlist fee). What we were instead looking for was to create a constraint-based ordering that when applied to the recently completed jobs, would give an even distribution of shortlist fees (data-set permitting).

Initially he tried a "low-high" ordering method based on their "fee" value. Instead, to make the solution more "random" he reframed the need and broke it down into three separate actions: sort, partition and interleave. As PHP only has one of those, he came up with his own solutions for the other two (code included). He explains briefly how it all works together and what kind of benefits it has over the low-high solution originally created.