How to speed up PHP's write to file time?

I’ve just made the switch from GoDaddy’s Shared Hosting to DigitalOcean and their write to disk through PHP appears to be much faster, is there any way of speeding this up?


fwrite($retrieve, $replace);
header('Location: ./');

The code above will write a certain piece of data to a specified location before refreshing the page. The problem is, when the page is refreshed, the data hasn’t been finished writing to so the user will see the old data on the page. He will have to refresh the page again to see the updates.

With GoDaddy’s Shared Hosting (using the same piece of code above), the user would be redirected through header after the new data has been written to the file so the user will see the updated contents immediately, rather than having to refresh the page again.

Is there something I’m doing wrong? Is there a way to speed up the write to file time?

I am currently on DigitalOcean’s $5/month plan and I would really appreciate any help on this, thanks!

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.



Although the execution time is around 0.0002s, I still have to set the refresh time to about 2.5 seconds

I setup a 512MB and 2GB Droplet (Ubuntu 16.04 64bit), then tested your code on it and the redirect is instant as is the form population, so it would seem something else is causing the delay – perhaps in a different area of the code.

I am, however, using PHP 7.1.x, though that really shouldn’t make too much of a difference on the read and write commands and their speed, or how quickly the redirect passes a visitor back over to index.

One thing that may, however, be effecting the display is cache. If OpCode caching is enabled on your installation, it may not be flushing as quickly. Otherwise, any other form of caching, be it local on your PC/Mac or on the server, can also cause delays.

I’m running just a barebones PHP 7.1 install which was installed by:

sudo add-apt-repository ppa:ondrej/php -y \
&& sudo apt-get update \
&& sudo apt-get -y install php7.1-fpm php7.1-cli php7.1-dev

and I’m not running in to any issues with either my code or yours.


Running a few tests on a freshly deployed droplet with only PHP 7.1 installed, I started up an instance of PHP’s built-in web server using:

php -S -t.

I then created a 64MB file to read from using:

fallocate -l 64m data.txt

I then created a very basic read/write index file with the following code:

$startup    =   microtime( true );
$filler     =   file_get_contents( __DIR__ . DIRECTORY_SEPARATOR . 'data.txt' );
$file       =   fopen( __DIR__ . DIRECTORY_SEPARATOR . 'data.' . time() . '.txt', 'w' );

fwrite( $file, $filler );
fclose( $file );

echo 'Execution Time: ' . ( microtime( true ) - $startup );

Times for the 64MB file were:

Execution Time: 0.37941408157349
Execution Time: 0.19304585456848
Execution Time: 0.15773510932922
Execution Time: 0.16210699081421
Execution Time: 0.20386791229248
Execution Time: 0.71326303482056
Execution Time: 0.67525696754456
Execution Time: 0.16588401794434
Execution Time: 0.14779591560364
Execution Time: 0.15287399291992

I then wiped the slate clean and created a 128MB file using the same command as above. Times for the 128MB file were:

Execution Time: 0.30879592895508
Execution Time: 0.35546898841858
Execution Time: 0.31786108016968
Execution Time: 0.88341999053955
Execution Time: 0.32654404640198
Execution Time: 0.35381197929382
Execution Time: 0.34370303153992
Execution Time: 0.60638308525085
Execution Time: 0.37295699119568
Execution Time: 0.34345412254333

There were a few spikes reading and writing both files. That said, the above wasn’t filled with random data, so I also wanted to test by pulling 128MB of random data from /dev/urandom.

head -c 128m </dev/urandom >data.txt

Running the same code on the above yielded slightly better results after running it 10x, with the lower execution times being around .22-.28 compared to the .30-.88 above.


It’d be hard to diagnose without knowing more about what you’re trying to write and the size of what you’re trying to write.

That said, without any type of checks being in place, your code is going to run exactly as written, so if the write hasn’t completed, the user will be redirected regardless of environment (or should).

If you can provide a little more detail such as how the data is being fetched, from where, etc, I’ll do my best to help out.