By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,009 Members | 1,643 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,009 IT Pros & Developers. It's quick & easy.

Force PHP CLI to stay in RAM?

P: n/a
Hello

I have a couple of command-line PHP scripts that are often called, and
I was wondering if it were possible to have the PHP interpreter remain
in RAM instead of being removed after the scipts end?

Thank you.
Dec 25 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Hi,

You can certainly do this. The script can sit in a loop waiting for an
indication to continue such as a socket connection, a file on disk
being modified, a posix signal, an update in a database, a timer, etc.

On Dec 24, 10:00 pm, Gilles Ganault <nos...@nospam.comwrote:
Hello

I have a couple of command-line PHP scripts that are often called, and
I was wondering if it were possible to have the PHP interpreter remain
in RAM instead of being removed after the scipts end?

Thank you.
Dec 25 '07 #2

P: n/a
Gilles Ganault wrote:
I have a couple of command-line PHP scripts that are often called, and
I was wondering if it were possible to have the PHP interpreter remain
in RAM instead of being removed after the scipts end?
If the script is called often enough, they *will* stay in memory. It's
something called "the operating system automatically caches the most
recently used files".

You are trying to do premature optimization. Don't.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Las deudas son como los niños; cuanto más pequeñas, más ruido hacen.
Dec 25 '07 #3

P: n/a
On Tue, 25 Dec 2007 21:21:26 +0100, Iván Sánchez Ortega
<ivansanchez-alg@rroba-escomposlinux.-.punto.-.orgwrote:
>If the script is called often enough, they *will* stay in memory. It's
something called "the operating system automatically caches the most
recently used files".
OK, I'll just let Linux handle this, and come back if it's too slow
;-) I wanted to have your opinion because the scripts are used with a
PBX, so that timing is important.
Dec 26 '07 #4

P: n/a
Gilles Ganault wrote:
I wanted to have your opinion because the scripts are used with a
PBX, so that timing is important.
Then, keep the scripts short and use efficient algorithms. Knowing the
difference between O(n^2) and O(n*log(n)) is much more important than
keeping the script in memory.
That said, if you *really* need a real-time response on a mission-critical
environment, drop PHP altogether and switch to rtlinux, lighthttpd and a
custom C CGI.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

MSN:i_*************************@hotmail.com
Jabber:iv*********@jabber.org ; iv*********@kdetalk.net
Dec 26 '07 #5

P: n/a
� wrote:
Gilles Ganault wrote:
>I wanted to have your opinion because the scripts are used with a
PBX, so that timing is important.

Then, keep the scripts short and use efficient algorithms. Knowing the
difference between O(n^2) and O(n*log(n)) is much more important than
keeping the script in memory.
That said, if you *really* need a real-time response on a mission-critical
environment, drop PHP altogether and switch to rtlinux, lighthttpd and a
custom C CGI.
:-)

he's right you know.

But real time usually just mens 'good enough' - only in real mans stuff
does it mean 'guaranteed to always be good enough'

i.e. you do NOT want your missile to decide to go memory garbage
collecting 5 ms after launch.. ;-)and self destruct when it misses a
watchdog timer..

Dec 26 '07 #6

P: n/a
On Wed, 26 Dec 2007 12:09:08 +0000, The Natural Philosopher <a@b.c>
wrote:
>But real time usually just mens 'good enough' - only in real mans stuff
does it mean 'guaranteed to always be good enough'
OK, I'll see how PHP does and see if timing is an issue. Thanks.
Dec 26 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.