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.

Matt Frost has shared some of his work he's done with the SoapClient in PHP and how he mocked it out for his unit tests (since it's an external resource).

The concept of mocking web services for testability took a little while to sink in for me. A big part of it was that my job doesn't see me consuming web services all that often, but I had an opportunity to give it a shot with SOAP. I found that I learned a lot more about testing in general having worked through this. I used SoapClient and wrapped it, so here's a little bit about some of things I learned. Hopefully you don't have to work with SOAP, but if you do you can test it pretty easily.

He walks through the mocking of the client itself and how he handled it's ability to translate function calls into SOAP method calls (using "__call") and how he mocked that. He also makes the suggestion that you actually wrap the SoapClient inside of another class rather than trying to mock the actual SoapClient. He also touches on the testing of exceptions that might be thrown by the service and how he tested those using his wrapper class.

Danne Lundqvist is frustrated with the SOAP functionality that comes native with PHP on one very specific subject - its handling of SOAP structures.

Handling SOAP structures in PHP can sometimes be really annoying. If an interface is defined in the WSDL as returning an array I can't be sure that I will get an array. If there is only one element in the array PHP tries to be clever and turn the wanted array into an object which, too me, isn't really smart. I don't know if this is a problem/limitation on the client side, server side or if it is just me doing something stupid in the wsdl.

He gives an example of the WSDL that was requested and the differing results from a call that returned one Map item verses several (how the objects were returned). In asking for help, it looks like he got some in the comments - an attribute called SOAP_SINGLE_ELEMENT_ARRAYS that can be added to the configuration array when creating the SoapClient object.