On Fri, January 25, 2008 12:59 pm, Eric Butera wrote:
> On Jan 25, 2008 1:39 PM, Richard Lynch <ceo@xxxxxxxxx> wrote:
>> On Fri, January 25, 2008 7:27 am, Eric Butera wrote:
>> > I think the memory size can (sort of) be determined by width *
>> height
>> > * bits * channels / 8. I've never found anything better than
>> that.
>> > There are a few comments on the php site in the gd section about
>> such
>> > things but I've never seen it work 100%. I always set the real
>> memory
>> > limit much higher than what I say the max is for the memory size
>> just
>> > in case it gets an image that could break it. At least that
>> stopped
>> > the friendly white screens of death. :)
>> >
>> > If anyone has better ways of handling this I'd love to hear them.
>>
>> Don't try to do the thumb-nail in real-time for the user that
>> uploads it.
>>
>> They already know what the image looks like. :-)
>>
>> Off-load that task to a separate cron job, run from CLI, which can
>> use:
>>
>> php -q -d memory_limit 1000000000 thumbnail.php /path/to/image.jpg
>> /path/to/thumbnails/
>>
>> This way, you are not letting your HTTP php processes chew up more
>> RAM
>> than they really should, and you can give the thumbnail script a GIG
>> (or more) of RAM to do whatever it needs to do.
>>
>> Run that job often enough, and the thumbnail will be available "fast
>> enough" for the users who don't know what the image looks like.
>>
>
> Hi Richard,
>
> The way I handle thumbnail creation is (this is generalized) but an if
> statement that says
>
> if (thumbnail file name not in db) {
> set img src to a script that renders thumbnail, saves it
> somewhere, and updates the db record so that this never happens again
> until i reset it (in case they want to change thumb sizes)
> } else {
> raw link to image
> }
>
> The main issue is that when someone uploads an image for a piece of
> content or a product image I need to scale it down to a sane amount of
> ~800 w/h before I even allow it on the site. From there I use the
> thumbnail on demand.
Perhaps you could check the size of the image in another elseif() in
the middle and handle over-size images specially.
> I'm not sure the cron job idea is the best for my situation though.
> When a client uploads a product image in a store they just paid for
> they expect it to show up before 3am when the server load is down. If
> I run it every 15 minutes I really don't see the advantage of that
> seeing as I can do an ini_set on the memory limit at any point I
> decide since it is my server. Cron for 15 minutes still means at 3pm
> which we are at a heavy load the 1g script would kick in.
The difference is that you have one (1) CLI script using 1G, instead
of *EVERY* Apache child using 1G...
You could also run the CLI at nice -n 19, so that it is super low
priority, and then not worry about server load. :-)
Separating the process off from your main logic gives you all sorts of
flexibility that just isn't there when you try to do it inline.
If you are using fast_cgi instead of mod_php, I'm not sure this helps
much in terms of RAM usage...
> The good thing though is that most people just set up their
> store/content and don't really update it too much after that. That is
> why I'm after a solution that allows me to figure out the memory size
> so I can just tell them if they need to lower the resolution a bit and
> try again.
>
> I'll keep this cron solution in mind though, could come in handy at
> some point.
>
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
