The Tideways blog has a post sharing things you can do in PHP to work with HTTP client timeouts in things that use the PHP sockets and streams.

Timeouts are a rarely discussed topic and neglected in many applications, even though they can have a huge effect on your site during times of high load and when dependent services are slow. For microservice architectures timeouts are important to avoid cascading failures when a service is down.

The default socket timeout in PHP is 60 seconds. HTTP requests performed with for example file_get_contents, fopen, SOAPClient or DOMDocument::load are using this timeout INI setting to decide how long to wait for a response.

He talks some about how these timeouts can effect your script and some of the common reactions (in code) to them happening. He then shows how to configure these timeouts to match the needs of you application in a few ways:

• globally in the ini configuration
• on a per-call basis in a stream_context_create call
• changing the load timeout for DOMDocument::load
• updating the setting for calls with SOAPClient
• changing the timeout on cURL extension calls

Each item on the list comes with the code/settings needed to make the change.

In a new post to his site Brian Moon has shared a problem he had with sockets and timeouts and having them perform the same way every time. He walks through the symptoms he was seeing and provides his own solution in the end.

So, it seems that when you try and connect to an IP that is routable on the network, but not answering, the TCP stack has some built in timeouts that are not obvious. This differs from trying to connect to an IP address that is up, but not listening on a given port. [...] After a lot of messing around, a coworker pointed out that in production, the failures were happening for an IP that was routable on the network, but that had no host listening on the IP.

After some testing, Brian figured out that his problem was using localhost for testing and not an actual non-host server. He made the switch and figured out how to set the timeouts low and work with error state checking to make things more stable. He explains a bit more about how the code in his solution works. You can find his solution in this gist on GitHub.

On DZone.com there's a new post from Chris Chang that's the third part of the series looking at using various language drivers for working with MongoDB. In this latest article he focuses in on the PHP driver, giving a brief introduction and a few handy tips.

This blog post is the third of a series where we are covering each of the major MongoDB drivers in depth. The driver we’ll be covering here is the PHP driver, developed and maintained by the MongoDB, Inc. team (primarily @derickr, @bjori and @jmikola).

He includes a link to some basic examples and shares a "production-ready connect string" with some MongoLab recommended settings. The tips include topics ranging from working with index builds, the lowering of is_master_interval and configuring the connectionTimeoutMS setting for optimum connection handling.

Joseph Scott has a recent post to his site looking at the idea of stateless CSRF tokens and how to create them while avoiding the typical "store them in a session" mentality.

This is all fine and good until you want to avoid using PHP sessions. Perhaps you have several web servers and don’t want to deal with shared session storage. Or have servers in multiple data centers and don’t want to try and sync state across them. What ever the reason, popping a token into $_SESSION isn’t an option in this case. In short you want some sort of stateless CSRF token.

He looks at two methods to help get around this issue. The first method is based on known values that won't change very frequently (say, maybe 24 hours). His second method, however, has a bit more strength to it. His idea uses a combination of a key, the current time, a timeout and a known string of data - all base64 encoded.

On PHPMaster.com today there's a new introductory tutorial for those trying to figure out sessions in PHP. Sessions can be one of the most powerful tools at your disposal and handling them correctly can sometimes be a little tricky.

$_SESSION is a special array used to store information across the page requests a user makes during his visit to your website or web application. The most fundamental way to explain what a sessions is like is to imagine the following scenario: You are working with an application. You open it, make some changes, and then you close it. That is a session in it’s simplest form.

They start with a basic "how to use them" example of setting a username value to the current session and pulling the value back out. They also show the use of the session_unset and session_destroy methods for ending the session. Some security tips are mentioned too - timeouts, regenerating the session ID, destroying them correctly and using a more permanent storage option (by default, they store on the local disk).

On the FinalConcept.com.au blog there's a new post from Adam Pullen showing how to solve a common issue with user logins and timeouts in Symfony applications (especially those using something like sfGuard).

Symfony uses the PHP session management sub-system to store tempoary user specific data. When using the sfDoctrineGuardPlugin, or any other application guard, the timeout and lastRequest data are stored. [...] Since PHP has no clue of Symfony it will happily delete all session files that are older than the gc_maxlifetime value. This causes Symfony to logout the user. The user then has to login again. For all "day long apps" that are only used periodically (like time tracking software) this can cause some greif for the user.

His solution is to change the gc_maxlifetime setting in your php.ini file (or just the ini settings) to something higher than what Symfony will use. This can be done directly in your application too by defining the ini value on the fly in your factories.yml config file.

In a recent post to his IIS.net blog Don Raman wants to help out all of those developers getting timeout messages on their PHP scripts running on a Windows platform and how some FastCGI settings could help.

Let's try to understand the reason behind this. [...] Let me now summarize some of the IIS FastCGI settings and PHP INI configuration directive to ensure that everyone is on the same page and which are most important for this discussion.

The two FastCGI settings he mentions are the ActivityTimeout and the RequestTimeout as well as a generic PHP setting that could be a cause of the problem, max_execution_time. He suggests some default values for each of these, but only experimentation will help you find the right balance of these three. It's a great starting place to look, though - especially if you've been battling the problem for a while.

Vinu Thomas has posted a tip for WordPress users working with scheduled posts and the "Missing Status" status that's caused by a bug in WordPress.

Ever since the upgrade to Wordpress 2.9, I've been having a problem in the scheduled posts in Wordpress. Everytime I set a post to be scheduled in the future, it used to miss the scheduled time and never get posted. When I checked the status of these posts in the posts admin area, each of these posts had the status "Missed Schedule" next to them.

To correct the issue, you need to make a change to the cron.php script for your installation (in wp-includes) to change the default timeout by quite a bit to ensure that the remote call has plenty of time to finish. It seems its related to the version of PHP's curl extension that's compiled into the web server installation.

Alison has posted a guide to a technique that can help your site resist higher loads - content caching:

Caching your database-driven website pages has a plethora of benefits, not the least of which being improved speed and reduced server loads. This article will explain how to set up a simple caching system, and will also address when and where caching might not be appropriate.

She shares her "six lines of glory" that cache the resulting HTML page (after all data has been pulled from the database and rendered) into a cached file with output buffering. On other side of things, there's another script that, based on the page requested, checks to see if a cached file exists. She also modifies it slightly to include a timestamp so things aren't just cached forever.

There's also a recommendation in the comments of the post to use the APC caching extension that's already built. Of course, this can only really be used if you have access to install it on the remote machine (not an option on things like shared hosting).

Juozas Kaziukenas has a helpful tip you can use on those long-running scripts to keep going - the set_time_limit function.

I have some very time consuming scripts running through CRON - some nice web scrapping jobs. They are not processing-intense, but rather slow because of slow websites. All these jobs are really hard to divide in to separate scripts (another article), so one script should have no limits to run for hours. However, web servers don’t like it by default.

He show how you can use the set_time_limit function to free your script of the timeout limitation (which can be a good and bad thing) or having your script output something, like a "processing" message, as it runs through the loop to keep the timeout away. You can also use the ignore_user_abort function to continue the process even if the user hits the stop button or otherwise closes the request.