I made three ZIP files (one with no compression settings, one with minimal compression and one with maximum compression)
I then had my script unzip each one, and timed it. First I did it with ZipArchive, then with exec('unzip')
Every time, it was faster using ZipArchive then exec('unzip')
I thought that surely a native program would be faster than a library? Are there some switches I could use with exec('unzip') (that would make it similar to ZipArchive) to make it as fast?
Related
I need to do the following image manipulations for images uploaded by users on my site:
Resize images (if greater than a certain dimension)
Convert all image formats to jpg's
Add a watermark to the bottom of all images
Do I need to use either the MagickWand or iMagick extensions or can I just get away with running the terminal commands inside PHP's exec function?
Is there a reason why the PHP extensions would be preferred? Which would be faster and better for performance (this site may have lots of users and there would be a ton of image processing at any given time)?
I'd like to make a counterpoint to drew010's answer. In his answer he states:
You would benefit a lot using the PHP extensions instead of using exec
or similar functions. Built in extensions will be faster and use less
memory as you will not have to spawn new processes and read the output
back
For processing images, this is true. Well, I know for a fact that calling on ImageMagick binaries using PHP's exec() function (or similar functions) carries additional overhead above using embedded PHP libraries however I'm not clear on how much overhead there is.
But there's another side of the coin. If you embed the ImageMagick code into PHP via an extension, then every request using PHP takes more memory whether the request processes an image or not. If you're using Apache's mod_php then this becomes even more of an issue because now every request to your server has the ImageMagick libraries in memory even if it's serving an HTML file!
So it really depends. You really want to keep PHP's memory footprint as low as possible. If you're processing a large number of requests which require ImageMagic and you're using FastCGI or php_fpm, then you'll probably see a benefit to using embedded ImageMagick. But if you're only occasionally processing requests using ImageMagick and/or using Apache's mod_php then you may get much better performance calling ImageMagick via exec().
You would benefit a lot using the PHP extensions instead of using exec or similar functions. Built in extensions will be faster and use less memory as you will not have to spawn new processes and read the output back. The image objects will be directly available in PHP instead of having to read file output, which should make the images easier to work with.
If you have a busy site, creating lots of processes to edit images may start to slow things down and consume additional memory.
I always use PHP GD http://php.net/manual/en/book.image.php
You can accomplish resizing, converting to JPG and watermarking your images. I know your post said you have to use MagickWand or iMagick, but I just wanted to present this option in case it would work for you.
I've recently been given a task that involves uploading a zip file, storing it in a database as a blog, and then extracting and presenting the contents of that zip file when the client requests it.
I've got two approaches for this task: Using the exec command to execute the zip command native to the Linux OS the web server is running on, or using the ZipArchive class that comes with PHP.
Which approach uses the least amount of memory?
Which approach offers the most flexibility? W
What are the major advantages of one approach
over the other?
exec('zip') is way faster for large/many files. The built-in routines are always slower(due to many library calls & overhead. The system zip may have the advantage of using highly optimized routines. As a plus to the exec method, is the ease to change output formats from zip to rar, or 7zip or bzip etc...
I am needing to download a very large file via PHP, the last time I did it manually via http it was 2.2gb in size and took a few hours to download. I would like to automate the download somehow.
Previously I have used
file_put_contents($filename, file_get_contents($url));
Will this be ok for such a large file? I will want to untar the file post downloading and then perform analysis of the various files inside the tarball.
file_get_contents() is handy for small files but it's totally unsuitable for large files. Since it loads the entire file into memory you need like 2GB of RAM for each script instance!
You should use resort to old fopen() + fread() instead.
Also, don't discard using a third-party download tool like wget (installed by default in many Linux systems) and create a cron task to run it. It's possibly the best way to automate a daily download.
You will have to adapt your php.ini to accept larger files in upload, and adapt your memory usage limit.
I am writing an app that will need to unzip user uploaded archives. PHP provides the ZipArchive class, but it should also be possible to unzip using unzip via exec(), my question is which is preferrable in terms of performance & scaling?
A you use php, I guess it would be an online App.
As Brian hinted library will most probably be faster as it has much less to do.
On the other hand if you really want to know for sure, just try. Things like compilation options for ZipArchive and binary unzip can have high impact.
You should also consider unziping as a background task with some ajax to warn when it's done as unzipping can be a long task.
I have a PHP script that uses adds a lot of small files into the same zip arhchive file using PHP's ZipArchive class.
Recently script started to run out of memory, although the archive is large, but I add only small files one by one, safely re-opening archive each time I need to add a file.
The initial archive file grew little by little to 50 mb so I assume adding little files is not a problem, the real problem might be that whenever ZipArchive class adds a file, it unpacks the whole archive into memory. Is this correct assumption, can it be so?
Memory management isn't one of PHP's strong points. I don't see anything in the manual to confirm or dispel the idea that the entire archive is unpacked into memory, but I'd guess that it is.
Try comparing the return value of $zip->open() to ZIPARCHIVE::ER_MEMORY - if they're equal, that should confirm that PHP is opening the entire archive in memory.
Another way to confirm it would be to compare the setting of memory_limit (http://us2.php.net/manual/en/ini.core.php#ini.memory-limit) to the size of the zip file.