<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Sun, 19 May 2013 08:17:42 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[James Cohen's Blog: Poor Man's Parallelization for Batch Processing Jobs]]></title>
      <guid>http://www.phpdeveloper.org/news/16355</guid>
      <link>http://www.phpdeveloper.org/news/16355</link>
      <description><![CDATA[<p>
<i>James Cohen</i> has a quick post about what he calls a <a href="http://webmonkeyuk.wordpress.com/2011/05/17/poor-mans-parallelization-for-batch-processing-jobs/">"poor man's parallelization"</a> for working with batch jobs. It takes in parameters that tell it which set of jobs to run through when looping.
</p>
<blockquote>
One common problem that I've seen time and time again with batch processing jobs (generally cronjobs) is that when they're written they run quickly. Over time their workload grows until eventually it's unacceptably slow. [...] To create a simple of way of separating the jobs in a consistent way we can use the <a href="http://en.wikipedia.org/wiki/Modulo_operation">modulus operator</a>. It just calculates the remainder of two numbers. It's a common arithmetic operator in almost all languages so this technique is pretty portable.
</blockquote>
<p>
His proof-of-concept script takes in two parameters, the starting job number and the number to increment. His example is user IDs, but this type of script could be used for anything with an ID number. The script is then run from the command line with the parameters of your choosing.
</p>]]></description>
      <pubDate>Wed, 18 May 2011 11:56:31 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Zoe Slattery's Blog: Oh no! Not more tests!]]></title>
      <guid>http://www.phpdeveloper.org/news/12836</guid>
      <link>http://www.phpdeveloper.org/news/12836</link>
      <description><![CDATA[<p>
As <i>Zoe Slattery</i> mentions in <a href="http://zoomsplatter.blogspot.com/2009/07/on-no-not-more-tests.html">her new post</a> more testing for PHP is a good thing, but has come with a bit of a problem.
</p>
<blockquote>
One of the problems with the incredible level of success of the PHP TestFest is that PHP gets more tests, <a href="http://results.testfest.php.net/">887</a> more to be precise. Well, isn't that the point? Yes, but it's beginning to take *forever* to run them which is a bad thing and as TestFests get bigger and better this will only get worse.
</blockquote>
<p>
As a result, more work has been put into a project started a while back - a tool to allow more than one test to run at once (instead of linearly). <a href="http://2.bp.blogspot.com/_EifRUa32KOM/SlT0h_jwyAI/AAAAAAAAAEc/jeaDlz72dTg/s1600-h/run-tests.png">This grab</a> shows some of the resulting gains in speed. It jumps to about half to the time to make it through the ~7700 tests.
</p>]]></description>
      <pubDate>Thu, 09 Jul 2009 09:42:16 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Symfony Blog: Batches are dead, long life to tasks!]]></title>
      <guid>http://www.phpdeveloper.org/news/10421</guid>
      <link>http://www.phpdeveloper.org/news/10421</link>
      <description><![CDATA[<p>
On the Symfony blog today, <i>Romain Dorgueil</i> shows how to <a href="http://www.symfony-project.org/blog/2008/06/14/batches-are-dead-long-life-to-tasks">create tasks</a> to help automate things in your application like database updates, console scripts or other "repetitive maintenance tasks".
</p>
<blockquote>
Symfony 1.1 extends symfony 1.0 pake tasks to create a powerful and uniform command line utility for your projects, fully integrated with the symfony Command Line Interface (CLI).
</blockquote>
<p>
This means that is has the abilities to automatically support a "help" parameter, to grab a current task list the app is using, correct handling of the input parameters, set up a good environment and make sure that the source is readable. The post shows how to create a new task for your application - their examples are a "doNothingTask" that, well, does a lot of nothing and the typical "doHelloWorldTask" that just echoes.
</p>
<p>
They show how to define the task (including a namespace for it) and how to run it, outputing the results of the execute() method ("I did nothing successfully!" in the first case and a string of passed in parameters in the second.
</p>]]></description>
      <pubDate>Mon, 16 Jun 2008 12:05:36 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[IBM developerWorks: Batch processing in PHP]]></title>
      <guid>http://www.phpdeveloper.org/news/6844</guid>
      <link>http://www.phpdeveloper.org/news/6844</link>
      <description><![CDATA[<p>
Both <a href="http://devzone.zend.com/node/view/id/1334">this post</a> on the Zend Developer Zone</a> and <a href="http://www.php-mag.net/magphpde/magphpde_news/psecom,id,26637,nodeid,5.html">tis post</a> on the International PHP Magazine's website point to a new article over on the IBM developerWorks website by <i>Jack Herrington</i>, <a href="http://www-128.ibm.com/developerworks/opensource/library/os-php-batch/">Batch processing with PHP</a>.
</p>
<blockquote>
What do you do when you have a feature in your Web application that takes longer than a second or two to finish? You need some type of offline processing solution. Check out several methods for offline servicing of long-running jobs in your PHP application.
</blockquote>
<p>
He <a href="http://www-128.ibm.com/developerworks/opensource/library/os-php-batch/">talks about cron</a> and its role in offline processing (including a basic primer on its format) before getting into the example itself. He looks at three examples:
<ul>
<li>building an email queue
<li>building a generic queue system
<li>dumping out the database 
</ul>
Each example comes complete with code and descriptions to help you work them up on you very own system.
</p>]]></description>
      <pubDate>Thu, 07 Dec 2006 09:06:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Wez Furlong's Blog: Background/batch/workflow processing with PDO::PGSQL]]></title>
      <guid>http://www.phpdeveloper.org/news/6591</guid>
      <link>http://www.phpdeveloper.org/news/6591</link>
      <description><![CDATA[<p>
<i>Wez Furlong</i> wants a bit more out of his PHP script, naemly the ability to be able to <a href="http://netevil.org/node.php?nid=925">process things in the background</a> without tying up or immediately using the script that's running.
</p>
<blockquote>
In my recent talk on <a href="http://images.omniti.net/omniti.com/talks/furlong-best-mailing-practices.pdf">sending mail from php</a> I mention that you want to avoid sending mail directly from a web page. A couple of people have asked me how to implement that, and one of the suggestions I have is to queue your mail in a database table and have some other process act on that table.
</blockquote>
<p>
He <a href="http://netevil.org/node.php?nid=925">gives a solution</a> that's a bit more optimized for this solution than just polling the same information over and over - using PDO and LISTEN/NOTIFY processing along with transactions to make the CLI script only grab information when there's something new.
</p>]]></description>
      <pubDate>Fri, 27 Oct 2006 08:42:00 -0500</pubDate>
    </item>
  </channel>
</rss>
