Re: [PHP] image files - upload and managment
On 30 Oct 2004 22:30:35 -, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote: > I have difficulty believing retrieving an image from a database will > have similar speed performance as simply grabbing it from the > filesystem... and if you're seeing a need to cache images on the > filesystem anyways, that's certainly already an argument against it. Zend.com / Leon Atkinson benchmarked it. http://www.zend.com/zend/trick/tricks-sept-2001.php Conclusions Based on the test results, it seems that keeping files in a database cuts performance by approximately a third. It's hard to accept this penalty in light of any meager advantages offered by keeping the files in the databases instead of in a directory. -- Greg Donald Zend Certified Engineer http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] image files - upload and managment
On Saturday 30 October 2004 23:06, Robby Russell wrote: > > I understand the argument regarding a future change in thumbnail sizes. > > However, generating thumbnails on a filesystem of images is something > > that is easily scripted and can be performed on an as-needed basis. > > (ImageMagick is great for this sort of thing, and scripts in PHP using > > GD could also be used.) > > As I can do when I want it to be a thumbnail. Infact, in PostgreSQL, I > can use plPHP, plPerl, psycopg, etc and perform these tasks within > database functions. This isn't an issue at all. So the point (still) is why generate each request on the fly? > Also, Gallery 2, is moving to a database backend, one would wonder why > that would be a good move, considering the sole purpose of gallery is to > display images. Moving to a database backend is a good move on the part of Gallery because the current version uses flat files to store its data. However are you certain that the database backend is also used to store the pictures themselves? AFAICT this is not the case and pictures are still stored in the file system. -- Jason Wong -> Gremlins Associates -> www.gremlins.biz Open Source Software Systems Integrators * Web Design & Hosting * Internet & Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* Earth Army Recruiting Center: What are you, chicken? Buk buk buk! */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] image files - upload and managment
On Sat, 2004-10-30 at 22:30 +, Matthew Weier O'Phinney wrote: > * Robby Russell <[EMAIL PROTECTED]>: > > On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: > > > App needs to allow users to upload pictures. (jpg and gif), > > > needs to create thumbnails of those pictures > > > and to store thumbnails and full pictures. > > > > > > App needs to manage all those files - can be as much as 20K plus > > > images. > > > > > > I think image file size, file type and image dimensions restrictions > > > should be easy to handle by using $_FILES array and getimagesize > > > function. > > > > > > The issues that I am thinking of and need suggestions about are > > > > > > 1) Storage and retrieval - File system sounds like a better choice > > > over database. We are talking about 20 thousand plus pictures. > > > > I would do it in the database (PostgreSQL in my case). The speed isn't > > going to be much slower if you keep things optimized. You can even cache > > your images if necessary on the filesystem (for high traffic images). > > I have difficulty believing retrieving an image from a database will > have similar speed performance as simply grabbing it from the > filesystem... and if you're seeing a need to cache images on the > filesystem anyways, that's certainly already an argument against it. > I tend to stick as much in the database with strict restraints. I know that in my database, an image cannot be deleted unless several rules are met. In the filesystem, a number of things could accidently delete the wrong file. I treat my images as another piece of data and that data is kept there by constraints. > > > 2) Thumbnails - Should I create those once and save it in a file when > > > the image is uploaded for the first time. Looks like a faster option > > > than creating them every time on the fly. > > > > I just recently finished working on a project where I knew that would > > automatically create a thumbnail version of each image on upload... but > > then I realized that I might one day want to change the default > > thumbnail sizes.. so what I did was have it create a thumbnail on the > > fly from the database. (this way I can control the thumbnail size in the > > future). The speed difference was hardly noticed. I have done what I > > mentioned above and am now caching images that get loaded frequently. > > Thumbnailing on the fly may have decent performance, but it *is* slower > than simply serving up an image. If you doubt that, try surfing from a > T1 connection some time (dial-up users may not notice the extra time > required to generate the image, but those on broadband will). In > addition, if you generate a thumbnail every time the image is requested, > you're making your server do extra work -- even if you're caching > oft-requested images. > > I understand the argument regarding a future change in thumbnail sizes. > However, generating thumbnails on a filesystem of images is something > that is easily scripted and can be performed on an as-needed basis. > (ImageMagick is great for this sort of thing, and scripts in PHP using > GD could also be used.) > As I can do when I want it to be a thumbnail. Infact, in PostgreSQL, I can use plPHP, plPerl, psycopg, etc and perform these tasks within database functions. This isn't an issue at all. Here are a few reasons why storing in the DB can be more useful. http://www.oracle.com/technology/products/intermedia/htdocs/why_images_in_database.html Also, Gallery 2, is moving to a database backend, one would wonder why that would be a good move, considering the sole purpose of gallery is to display images. -Robby -- /*** * Robby Russell | Owner.Developer.Geek * PLANET ARGON | www.planetargon.com * Portland, OR | [EMAIL PROTECTED] * 503.351.4730 | blog.planetargon.com * PHP/PostgreSQL Hosting & Development *--- Now supporting PHP5 --- / signature.asc Description: This is a digitally signed message part
Re: [PHP] image files - upload and managment
* Robby Russell <[EMAIL PROTECTED]>: > On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: > > App needs to allow users to upload pictures. (jpg and gif), > > needs to create thumbnails of those pictures > > and to store thumbnails and full pictures. > > > > App needs to manage all those files - can be as much as 20K plus > > images. > > > > I think image file size, file type and image dimensions restrictions > > should be easy to handle by using $_FILES array and getimagesize > > function. > > > > The issues that I am thinking of and need suggestions about are > > > > 1) Storage and retrieval - File system sounds like a better choice > > over database. We are talking about 20 thousand plus pictures. > > I would do it in the database (PostgreSQL in my case). The speed isn't > going to be much slower if you keep things optimized. You can even cache > your images if necessary on the filesystem (for high traffic images). I have difficulty believing retrieving an image from a database will have similar speed performance as simply grabbing it from the filesystem... and if you're seeing a need to cache images on the filesystem anyways, that's certainly already an argument against it. > > 2) Thumbnails - Should I create those once and save it in a file when > > the image is uploaded for the first time. Looks like a faster option > > than creating them every time on the fly. > > I just recently finished working on a project where I knew that would > automatically create a thumbnail version of each image on upload... but > then I realized that I might one day want to change the default > thumbnail sizes.. so what I did was have it create a thumbnail on the > fly from the database. (this way I can control the thumbnail size in the > future). The speed difference was hardly noticed. I have done what I > mentioned above and am now caching images that get loaded frequently. Thumbnailing on the fly may have decent performance, but it *is* slower than simply serving up an image. If you doubt that, try surfing from a T1 connection some time (dial-up users may not notice the extra time required to generate the image, but those on broadband will). In addition, if you generate a thumbnail every time the image is requested, you're making your server do extra work -- even if you're caching oft-requested images. I understand the argument regarding a future change in thumbnail sizes. However, generating thumbnails on a filesystem of images is something that is easily scripted and can be performed on an as-needed basis. (ImageMagick is great for this sort of thing, and scripts in PHP using GD could also be used.) > > 3) Security issues - I believe I must have a world writable "666" > > permissions directory to keep images as users of the web app are > > uploading them. Does that create any security holes in my application? Depends on if you're on your own server or a shared host. One thing you can do even on a shared host is to make one directory 777 and then have PHP create directories within that; however, as noted by somebody else previously, someone else on the shared host could be malicious then and write over those directories. If you're on your own server or a dedicated host, give read and write permissions only to the web server and one or two groups. > The database will help you add a nice layer of security. If the OP is on a shared host, that is one of the rare instances I'd suggest putting uploaded information into a database -- and only if there's a liklihood of other clients on the server being malicious. However, in a shared host environment, if a user *does* do something malicious, you can usually complain to the service provider and get compensation. -- Matthew Weier O'Phinney | mailto:[EMAIL PROTECTED] Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] image files - upload and managment
Robby Russell wrote: On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: Hi People, I am writing a web app on LAMP. The app is sort of yellow pages where people can login and post advertisments with pictures. App needs to allow users to upload pictures. (jpg and gif), needs to create thumbnails of those pictures and to store thumbnails and full pictures. App needs to manage all those files - can be as much as 20K plus images. I think image file size, file type and image dimensions restrictions should be easy to handle by using $_FILES array and getimagesize function. The issues that I am thinking of and need suggestions about are 1) Storage and retrieval - File system sounds like a better choice over database. We are talking about 20 thousand plus pictures. I would do it in the database (PostgreSQL in my case). The speed isn't going to be much slower if you keep things optimized. You can even cache your images if necessary on the filesystem (for high traffic images). Robby's post is full of usefull information however though I am a postgresql fan i beg to differ on this point. Speed is definitely going to be slower when you insert and retrieve from blob (bytea) fields in any database. That's probly why you you think caching is needed for high traffic images :-) -- Raditha Dissanayake. http://www.radinks.com/sftp/ | http://www.raditha.com/megaupload Lean and mean Secure FTP applet with | Mega Upload - PHP file uploader Graphical User Inteface. Just 128 KB | with progress bar. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] image files - upload and managment
On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: > Hi People, > > I am writing a web app on LAMP. > The app is sort of yellow pages where people can login and post > advertisments with pictures. > > App needs to allow users to upload pictures. (jpg and gif), > needs to create thumbnails of those pictures > and to store thumbnails and full pictures. > > App needs to manage all those files - can be as much as 20K plus > images. > > I think image file size, file type and image dimensions restrictions > should be easy to handle by using $_FILES array and getimagesize > function. > > The issues that I am thinking of and need suggestions about are > > 1) Storage and retrieval - File system sounds like a better choice > over database. We are talking about 20 thousand plus pictures. > I would do it in the database (PostgreSQL in my case). The speed isn't going to be much slower if you keep things optimized. You can even cache your images if necessary on the filesystem (for high traffic images). > 2) Thumbnails - Should I create those once and save it in a file when > the image is uploaded for the first time. Looks like a faster option > than creating them every time on the fly. > I just recently finished working on a project where I knew that would automatically create a thumbnail version of each image on upload... but then I realized that I might one day want to change the default thumbnail sizes.. so what I did was have it create a thumbnail on the fly from the database. (this way I can control the thumbnail size in the future). The speed difference was hardly noticed. I have done what I mentioned above and am now caching images that get loaded frequently. > 3) Security issues - I believe I must have a world writable "666" > permissions directory to keep images as users of the web app are > uploading them. Does that create any security holes in my application? > The database will help you add a nice layer of security. > 4) Any thing else related to image uploads that one might need to take > care of. Are there any tutorials on image upload issues. > an example: http://blog.planetargon.com/index.php?/archives/26_Uploading_images_into_PostgreSQL.html and here is how you can display the images from the db. I am also using mod_rewrite so that it looks like it's coming from the filesystem, for example: mydomain.com/images/mypic.jpg actually calls ./image.php?filename=mypic.jpg http://blog.planetargon.com/index.php?/archives/27_Displaying_image_from_PostgreSQL_large_object_with_PHP.html hth, -Robbyu -- /*** * Robby Russell | Owner.Developer.Geek * PLANET ARGON | www.planetargon.com * Portland, OR | [EMAIL PROTECTED] * 503.351.4730 | blog.planetargon.com * PHP/PostgreSQL Hosting & Development *--- Now supporting PHP5 --- / signature.asc Description: This is a digitally signed message part
Re: [PHP] image files - upload and managment
On Saturday 30 October 2004 09:43, Jaskirat Singh wrote: > 1) Storage and retrieval - File system sounds like a better choice > over database. We are talking about 20 thousand plus pictures. Using a file system is usually the better choice. With the quantity of files you're handling it might be wise to implement some kind of directory hashing. For example having several thousand files in a single directory using ext2/ext3 file system results in very poor performance. > 2) Thumbnails - Should I create those once and save it in a file when > the image is uploaded for the first time. Looks like a faster option > than creating them every time on the fly. Definitely much faster to create it once (probably on upload) and store it rather than create on the fly each time. > 3) Security issues - I believe I must have a world writable "666" > permissions directory to keep images as users of the web app are > uploading them. Does that create any security holes in my application? If you're on a shared-host there's really not much you can do to keep your files really (or even fairly) safe from your 'host mates'. What you can do is largely limited by how the system was configured. Storing files in the database can potentially add a layer of protection. If security is a concern then you should shell out the extra for a dedicated host. -- Jason Wong -> Gremlins Associates -> www.gremlins.biz Open Source Software Systems Integrators * Web Design & Hosting * Internet & Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* I am more bored than you could ever possibly be. Go back to work. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] image files - upload and managment
Hi People, I am writing a web app on LAMP. The app is sort of yellow pages where people can login and post advertisments with pictures. App needs to allow users to upload pictures. (jpg and gif), needs to create thumbnails of those pictures and to store thumbnails and full pictures. App needs to manage all those files - can be as much as 20K plus images. I think image file size, file type and image dimensions restrictions should be easy to handle by using $_FILES array and getimagesize function. The issues that I am thinking of and need suggestions about are 1) Storage and retrieval - File system sounds like a better choice over database. We are talking about 20 thousand plus pictures. 2) Thumbnails - Should I create those once and save it in a file when the image is uploaded for the first time. Looks like a faster option than creating them every time on the fly. 3) Security issues - I believe I must have a world writable "666" permissions directory to keep images as users of the web app are uploading them. Does that create any security holes in my application? 4) Any thing else related to image uploads that one might need to take care of. Are there any tutorials on image upload issues. Thanks and HAND. Jas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
