In a quick post to the Laravel News site they mention another new feature coming in the v5.7 release of the framework: the addition of the dump server for debugging output.

At Laracon US 2018 Taylor Otwell announced that Laravel Dump Server would come packaged with Laravel in version 5.7! It will be a development dependency in laravel/laravel composer file.

Starting in Laravel 5.7 you’ll get this command out-of-the-box that allows you to dump data to the console or an HTML file instead of to the browser.

The post outlines what the "dump server" provides and provides an example of the command used to start it up. You can find out more about the dump server in this previous article.

The Laravel News site has a quick post today with a helpful hint for those trying to track down exactly what queries their Laravel application is performing on database calls. In this post they show two ways to get this information - one using the Debugbar and the other with a quick script.

When you are building an application and utilizing Eloquent it’s very easy to hit the N+1 problem. This is where you select a model and then later use lazy loading to fetch child records.

They give an example of selecting a user, grabbing it's list of "posts" and then looping through them causing queries to fire for each post individually. A fix for it is using the "with" method to pre-load them but determining this could be tricky. Enter their two solutions: the Laravel Debugbar package and this quick script shared by magkopian that listens for a "kernel.handled" event and outputs the results of the "getQueryLog" method with the Laravel "dd" helper.

In a new post to his blog Sameer Borate includes a handy bit of code you can use to split up a large MySQL dump file into smaller, easier to digest chunks.

One of the frustrating things with working with MySQL is of importing large sql dump files. Either you get a 'max execution time exceeded' error from PHP or a 'Max_allowed_packet_size' from MySQL. In a recent task I needed to import a table of around a million records on a remote host, which quickly became an exercise in frustration due to various limitations on the server. SSH was of no help as changing the configuration files was restricted to the root user. My last resort was to split the huge 'INSERT' statements into smaller size files.

His script needs a little extra time to run (he sets max execute to 600 seconds) and takes the SQL file in line by line, splitting them back out to over files based on a "count" value - "dump-split-*". Depending on the size of your files, using something like this might not be an option. You might need something more like the command line "split" feature to keep it outside of PHP's memory management all together.

In a recent blog post Gaylord Aulke illustrated a method for dumping the (key) content from a memcached cache in a friendly, formatted way.

When i did some optimization of a cluster based webapp lately, I was wondering how Memcache was speading my cache entries over the cluster. So i did some research for monitoring tools. [...] Inspired by [memcache.php], i wrote a small script that fetches all data from a memcache cluster, gets all keys out of it and then sorts and displays them in a list. Yes it it ugly and yes: the memcacheD is not answering other requests while doing a cachedump.

He includes the 22 line script in the post to spit back the data in a simple array. From there it can be styled whoever you'd like.

A new note on the Internet Super Hero blog talks about a new improvement to the mysqlnd driver support a memory dump option for mysqli_debug.

Andrey has implemented a little mysqlnd only addition to mysqli_debug(): 'm' - dump memory information. It works like the other options described in PHP: Debugging ext/mysqli and mysqlnd with the only difference that it is only available with mysqlnd.

A comparison of the "before option 'm'" and "after option 'm'" is also included.

A new note on the Internet Super Hero blog talks about a new improvement to the mysqlnd driver support a memory dump option for mysqli_debug.

Andrey has implemented a little mysqlnd only addition to mysqli_debug(): 'm' - dump memory information. It works like the other options described in PHP: Debugging ext/mysqli and mysqlnd with the only difference that it is only available with mysqlnd.

A comparison of the "before option 'm'" and "after option 'm'" is also included.

Both this post on the Zend Developer Zone and tis post on the International PHP Magazine's website point to a new article over on the IBM developerWorks website by Jack Herrington, Batch processing with PHP.

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.

He talks about cron and its role in offline processing (including a basic primer on its format) before getting into the example itself. He looks at three examples:

• building an email queue
• building a generic queue system
• dumping out the database

Each example comes complete with code and descriptions to help you work them up on you very own system.

Both this post on the Zend Developer Zone and tis post on the International PHP Magazine's website point to a new article over on the IBM developerWorks website by Jack Herrington, Batch processing with PHP.

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.

He talks about cron and its role in offline processing (including a basic primer on its format) before getting into the example itself. He looks at three examples:

• building an email queue
• building a generic queue system
• dumping out the database

Each example comes complete with code and descriptions to help you work them up on you very own system.