David Dickson wrote:
> Richard Lynch wrote:
>> Plus you are unlink-ing 10 files. That's probably the real problem.
>>
>> You'd have to write some timing code to be sure, though, as a slow
>> database server and a very fast hard drive could be involved.
>>
>> Here are some things you could do to speed it up, assuming you don't
>> want
>> the ON DELETE CASCADE option, or if your database doesn't provide that
>> option.
>
> You should do this (even if you don't want to) because it is good
> design. If when a member is deleted you want all associated tables to
> also delete this member information then you should set up your foreign
> keys properly.
But you may not want this to *ALWAYS* happen in your business logic.
I don't know enough about the application he's writing to say for sure
either way.
You'd think that you wouldn't want related records hanging around when
deleting a user, but sometimes one does. Just depends on the application.
> Something else you could do is to build one big rm statement and run it
> in the background. This would save you building a cron job which
> sometimes isn't possible depending on the hosting arrangement.
>
> <?php
>
> $Remove = "rm $ImageLocation1; rm $ImagLocation2; rm $ImageLocation3";
> exec("nohop $Remove > /dev/null 2>&1 &");
nohop?
Maybe you mean nohup?...
Or maybe I need to go read "man nohop"... :-)
I've found inconsistent results with trying to fork in the shell from PHP
-- Again this may go back to earlier versions, but I don't know that this
will work for sure in all versions.
> Where the $ImageLocationx is the full path to the image you want to
> delete. The & at the end of the exec tells the command to run in the
> background, which means your script won't wait for the command to finish
> before continuing. The output redirection ( > /dev/null 2>&1) is also
> necessary to allow the script to continue. See the PHP documentation on
> exec for more details.
The downside is that it makes this difficult to debug.
Probably better to re-direct the errors *somewhere* so you have a chance
at debugging things when (not if, when) they break.
Though it probably takes care of whatever was messing me up back in the
day when I was trying to get exec() to fork.
I must say, though, I've found over time that setting up a cron job to
take care of this kind of stuff usually works better for me and the user
experience than exec/fork.
Even with the & to fork, exec is not all that fast, I don't think.
A quick insert to a small table so that a cron job can unlink (and delete
from the table) later works better/faster for me. YMMV.
Just my opinions, of course.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
