I am used to using application_start event in c# in glocal.ascx.
I need to create something similar in php so when the application first loads i can cache all data first time round.
Does anyone know a good way of me doing this.
PHP does not have something like an AppDomain in ASP.NET.
In ASP.NET the webserver spawns once an AppDomain process and (synchronous) requests are handled as "HttpContext threads" inside this process. Asynchronous IHttpHandlers may be handled over multiple threads, but are also sharing the same AppDomain process.
In PHP each request is a single process (as of FastCGI a thread), but you don't have a static shared scope. A script executes and then dies. To share data in-memory, you need helpers like memcache.
In php each script sequentially runs through all code and then dies. So, if I understand your question properly you basically want to build the caching system into the top of your script.
On my simpler projects I simply include a file (I called it assign.inc) which handles all my site wide/global tasks. It loads first on every page and sets up my session/db connection etc.
On my bigger projects I wrote all traffic through index.php (via .htaccess) this initiates my CMS class which does everything though __construct.
Does that help?
Related
I'm creating a plugin for a CMS and need one or more preriodical tasks in background. As it is a plugin for an open source CMS, cron job is not a perfect solution because users may not have access to cron on their server.
I'm going to start a infinite loop via an AJAX request then abort XHR request. So HTTP connection will be closed but script continue running.
Is it a good solution generally? What about server resources? Is there any shutdown or limitation policies in servers (such as Apache) for long time running threads?
Long running php scripts are not too good idea. If your script uses session variables your user won't be able to load any pages until the other session based script is closed.
If you really need long running scripts make sure its not using any session and keep them under the maximum execution time. Do not let it run without your control. It can cause various problems. I remember when I made such a things like that and my server just crashed several times.
Know what you want to do and make sure it's well tested on different servers.
Also search for similiar modules and check what methods they use for such a problems like that. Learn from the pros. :)
this side of PHP is rather new to me.
I am interested in firing off a large number (25-50) separate processes from a parent script. I would like for the parent script to not wait for these other scripts to complete AND I would like for these other scripts to run in parallel.
Each script would run for a specified amount of time calling a webservice.
Can anyone give me some direction with this? I'm not asking for a coded answer specifically, but I just need some guidance.
Much thanks.
It really depends on what you want to achieve. #Julien's forking method could work, but this is not preferable if your web service calls are data intensive. I am not saying that forking is bad on the contrary it works, but with the ammount of different wev services you want to call you should have a way manage things better.
Another thing that you can do is base this on cronjobs. For example if you're calling these webservices for some users in your app create a queue - a DB table that you add records that need to be processed. If you are using Cake use the Cake Shells. Then set up cronjobs that call a the shells that processes these records every now and then. Divide all services is separate queues - at least for those that are very different in logic. This way you will also divide your risk because if there is a failure in one of the web service calls you would not jeopardise all in some way. Have separate logging abilities for each queue which will enable you to quickly track down problems. With consuming web services very often problems are external to your application.
I want to have my own variable that would be (most likely an array) storing what my php application is up to right now.
The application can trigger few processes that are in background (like downloading files) and I want to have a list what is being currently processed.
For example
if php calls exec() that will be downloading for 15mins
and then another download starts
and another download starts
then if I access my application I want to be able to see that 3 downloads are in process. If none of them finished yet.
Can do that? Only in memory, not storing anything on the disk?
I thought that the solution would be a some kind of server variable.
PHP doesn't have knowledge of previous processes. As soon has a php process is finished everything it knows about itself goes with it.
I can think of two options. Write knowledge about spawned processes to a file or database and use it to sync all your php request, (store the PID of each spawned process)
Or
Create an Daemon. The people behind PHP have worked hard to clean up PHP memory handling and such to make this more feasible. Take a look at their PEAR package - http://pear.php.net/package/System_Daemon
Off the top of my head, a quick architecture would compose of 3 peices
Part A) The web app that will take in request for downloads, and report back the progress of all request
Part B) You daemon, which accepts requests for downloads, spawns process, and will report back status of all spawned reqeust
Part C) The spawn request that will perform the download you need.
Anyone for shared memory?
Obviously you would have to have some sort of daemon, but you could use the inbuilt semaphore functions to easily have contact between each of the scripts. You need to be careful though because sometimes if you're not closing the memory block properly, you could risk ending up with no blocks left.
You can't store your own variables in $_SERVER. The best method would be to store your data in a database where and query/update it as required.
I'm learning php and I'd like to write a simple forum monitor, but I came to a problem. How do I write a script that downloads a file regularly? When the page is loaded, the php is executed just once, and if I put it into a loop, it would all have to be ran before the page is finished loading. But I want to, say, download a file every minute and make a notification on the page when the file changes. How do I do this?
Typically, you'll act in two steps :
First, you'll have a PHP script that will run every minute -- using the crontab
This script will do the heavy job : downloading and parsing the page
And storing some information in a shared location -- a database, typically
Then, your webpages will only have to check in that shared location (database) if the information is there.
This way, your webpages will always work :
Even if there are many users, only the cronjob will download the page
And even if the cronjob doesn't work for a while, the webpage will work ; worst possible thing is some information being out-dated.
Others have already suggested using a periodic cron script, which I'd say is probably the better option, though as Paul mentions, it depends upon your use case.
However, I just wanted to address your question directly, which is to say, how does a daemon in PHP work? The answer is that it works in the same way as a daemon in any other language - you start a process which doesn't end immediately, and put it into the background. That process then polls files or accepts socket connections or somesuch, and in so doing, accepts some work to do.
(This is obviously a somewhat simplified overview, and of course you'd typically need to have mechanisms in place for process management, signalling the service to shut down gracefully, and perhaps integration into the operating system's daemon management, etc. but the basics are pretty much the same.)
How do I write a script that downloads
a file regularly?
there are shedulers to do that, like 'cron' on linux (or unix)
When the page is loaded, the php is
executed just once,
just once, just like the index.php of your site....
If you want to update a page which is show in a browser than you should use some form of AJAX,
if you want something else than your question is not clear to /me......
I am writing a Wordpress plug in php in and next step is some kind of add on to this plug in.
The add on would scrape data from web, sending forms etc. I have this part almost ready from the time before I had any thoughts about Wordpress plugin - it's coded in ruby using mechanize. I haven't found anything similar to mechanize in php anyway.
But I do not know what is the best way to call my ruby script from Wordpress. Some tasks will be managed by cron. What about the ones based on user request?
php script only triggers the ruby script. It won't wait/require anything from ruby's output
Wordpress plugin is fully portable and functional without ruby script. Ruby adds on something more. If somebody requires it.
everything will be running on my linux server where I have a root access
A WordPress plugin that depends on Ruby isn't going to be portable. That's OK if you're the only one who will be using it, though.
If the Ruby script needs to return a result that will be used immediately by the PHP script that's calling it, then something like exec() is the only way. Make sure you escape any arguments you pass to the Ruby script; otherwise you'll be vulnerable to injection attacks.
If the Ruby script doesn't need to return a result immediately (e.g. some background processing, such as thumbnail generation) then I think the best way would be for the PHP script to insert a row into a MySQL database or something similar. The Ruby script can work in the background or run from cron, check the database periodically for new jobs, and do whatever processing it needs to do. This approach avoids the performance overhead and security issues of exec(), and it's arguably also more scalable. (A similar approach would have the Ruby script listen on a socket, and your PHP scripts would connect to the socket. But this requires more work to get it right.)
If i were you i would handle all the ruby stuff from the cron. Make a queue in the DB to hand user requests then make the script (in ruby?) invoked by cron grab all the unprocessed jobs from the queue and start running them, then remove the job from the queue (or set some kind of flag for it being done). This way you dont have to call exec which in most cases is going to be off limits unless the user is running on VPS/Dedicated server where they have root access.
You could also make this a seperate job and have it poll the DB for unprocessed jobs more regularly than the primary job... if necessary.
Still, this begs the question... why use ruby in a php blog/cms app??????
Use exec() to run the ruby interpreter, giving it the path to your ruby script.
http://php.net/manual/en/function.exec.php