Matt Stauffer continues his series looking at the improvements in Laravel 5.2 with this new post talking about the included rate limiting functionality.

More and more of my work in Laravel lately has been creating APIs. I have a manual rate limiter class I've been using, but I've had a sense that there's a cleaner way to do it. Unsurprisingly, when Taylor set out to write a rate limiter middleware for Laravel, he did it cleaner and better than I had.

Matt briefly introduces the concept of rate limiting and how some optional headers (in the X- family) can be used to let the end user/script know when their requests will be rate limited: X-RateLimit-Limit, X-RateLimit-Remaining and Retry-After. He then gets into the example of it in use, showing how to simply add the middleware to the routing and the results in the HTTP response. He ends the post with a bit on customizing the middleware, updating both the times per minute setting and a "block" time limit for when to completely block out the user.

Matthew Setter has posted the third part of his series looking at the Zend Framework 2's DbSqlSelect component and its use. In this latest (and last) tutorial, he talks more specifically about columns, limiting and ordering.

Welcome to the third and last part in this series, introducing you to working with the ZendDbSqlSelect classes in Zend Framework 2. In part one we looked at building SQL Where clauses using the where related functions, predicates and closures, as well as compound queries. In part 2, we looked at all forms of SQL joins as well as a slightly more esoteric feature of SQL – UNIONS. Here, in part 3, in the words of Coldplay, we’re going back to the start, and looking at the fundamentals.

He looks at three specific elements - the class constructor, the "limit" and "order" functions and the "Expression" class. He includes sample code showing how to create the class - one normally and one bound to a specific table. The next example shows how to define the columns to be selected using the "select" method. Finally, he shows the use of the "Expression" objects to perform SQL operations in the query (like "COUNT").

In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that’s not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It’s a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let’s illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

Derick Rethans has a new post to his site today about MongoDB cursors in PHP when using the PHP driver and how it handles pulling data from the server.

Recently I was asked to improve the MongoCursor::batchSize documentation. This began an indepth investigation in how the PHP driver for MongoDB handles pulling data that's been queried from the MongoDB server. Here are my findings.

He talks about the cursor that's created when a "find" call is made and how you can add on additional options (via other methods on the cursor) to its execution. He also covers how you can set your own batch size, using limit to only fetch a certain number of results and combining the two to make for more memory efficient, yet complete, returned data sets.

Slawek Lukasiewicz has posted about a handy tool that can be used to track memory consumption and performance in your PHP application - memtrack.

Application profiling can help us determine bottlenecks and possible problems during development. But sometimes we also need to diagnose problems in production environment. Frequent performance problems are connected with functions and methods using too much memory.

The tool allows you to set up thresholds for memory consumption and, if the scripts exceeds it, add warnings to your log files. He includes the simple instructions to install it (via PECL) and enable it in your php.ini. Some sample code to create a memory overvload is included to test it out. Configuration options let you set the limits and define functions to ignore if you know for sure there's trouble spots.

In a new post to his blog Martin Psinas talks about some of his pains experienced with upgrading his code to use PDO instead of the mysql extension for database interaction.

I read not too long ago that the mysql library in PHP is being deprecated as of v6.0 in favor of mysqli or PDO, so of course I had to update all of my database code keep on top of things. I spent about 5 or 6 hours over the course of 2 days familiarizing myself with the new syntax and updating my code offline. Without any testing, I decided I could go ahead and push the code "live" because I'm just that over-confident sometimes, although I did make a backup in case anything went wrong (or so I thought).

Two problems jumped out immediately - a SQL error caused by this bug and the other being a problem with preparing his statement inside of a session handling method.

Daniel Cousineau has a new post to his blog today looking at an alternative that can be used for pagination in your MSSQL queries than the trick with TOP and reversing the ORDER BY in Doctrine.

As ugly as this technique is, it works. The problem is it requires an extreme amount of intelligence or an extreme amount of simplicity in the query in order for an automated system like Doctrine to be usable. The biggest caveat with this technique is good goddamned luck paging your query if it doesn't have an ORDER BY. And sometimes queries that are complex enough break the modified Zend_Db code. There exists an easier MSSQL paging technique. Using features first available in SQL Server 2005, with only 1 subquery you can mimic MySQL's LIMIT clause with ease.

He includes the query that will make it happen (the SQL for it) and then the implementation as an adapter you can use to get it to cooperate in your Doctrine queries.

DevShed continues their series on the Active Record pattern in PHP with this new article implementing the LIMIT statement on your abstraction class.

In its current version, it'll be able to accomplish only a few basic database operations tasks. Therefore, this fifth article of the series will be focused on enabling the class to fetch database rows by using the LIMIT clause.

They add the LIMIT clause as a part of its own function and its own SQL statement. You define the number of rows to fetch, the table to fetch it from and the offset to start from. The SQL is passed off to their fetchRow statement and the results are returned in an array.

Havard Eide looks at another aspect of the Standard PHP Library in a new blog post today - iterators.

[It's] a set of classes in the SPL that implements various iterating patterns: ArrayIterator, AppendIterator, FilterIterator, LimitIterator and NoRewindIterator. Hopefully you'll get a idea of what these are capable of and that you can get some new ideas for your day-to-day tasks.

He breaks it down into example of each, explaining what they can be used for, how they work and a code example of each in action (with output). You can find more information in iterators and their functions in the SPL section of the manual.

A new tutorial has been posted on the PHPFreaks.com site today dealing with paginating your data (in their example, info from a database).

It makes way more sense to break up your list into page-sized chunks, and only query your database one chunk at a time. This drastically reduces server processing time and page load time, as well as gives your user smaller pieces of info to digest, so he doesn't choke on whatever crap you're trying to feed him. The act of doing this is called pagination.

They include the full script for those that want to jump right in and the detailed info in the rest of the tutorial for those that need a little more insight. The script gets a count of the results first then uses the LIMIT format for MySQL to restrict the number of rows returned each time and where to start those returned rows from.