Generate fast pseudorandom data in PHP

I need to generate uncompressible data (therefore pseudorandom), and have been trying with the code below. But it's only producing about 10MB/s of data. I need about 100-200 MB/s. Do you have any advice?

if ($length > 8*1024*1024){ //Default max string length in php.
    while (($length - $bytesGenerated)>8*1024*1024){
 开发者_如何转开发       $bytesGenerated = $bytesGenerated + (8*1024*1024);
        print(openssl_random_pseudo_bytes(8*1024*1024));
    }
}
print(openssl_random_pseudo_bytes($length - $bytesGenerated));

if you are working under linux you could just read from /dev/urandom, its kernels fast pseudorandom generator.

on the other way you could use openssl rand and pipe that into php.

Do you need cryptographic-safe pseudo random numbers? Otherwise you could try to implement a Linear feedback shift register

That's gonna be hard on PHP, even with accelerators. I would write C++ module specifically for that feature (but even on C++ it's not very easy).

At peak theoretical maximum performance on a 3GHz CPU (x86), you would have a budget of just under 4 CPU instructions per random byte, if you were trying to hit 200MB/s. Real-world performance is going to be considerably less than this. I'd posit that this is going to be extremely difficult in any language. You're well into the kinds of speeds which tend to employ dedicated hardware accelerator (i.e. you're attempting to do 1.56Gbit per second). In networking or video applications, there is a considerable amount of external hardware dedicated to permitting this kind of throughput. An extremely efficient implementation in C or assembly might allow you to hit this constraint, but you're really hitting the limits of what is possible using just general-purpose hardware.

I would consider either pre-generating the data (as has already been suggested) or employing some kind of hardware crypto-accelerator in order to hit anything resembling these kinds of throughputs. I found this list of crypto accelerator hardware vendors.

As a final thought, you did in fact mean 200 mega bytes per second, right? If you meant mega bits then this problem is much more easily solvable.