1

So I'm working on a discussion platform, and various clients will visit http://host/thread.php, which will render the discussion thread to date in addition to a form to submit a new post. When a new post is submitted, I would like all of the other clients with browser windows open to have it appear in near-real-time.

One of the constraints of my script is that it may not use a DBMS and it must stay in the filesystem. Additionally, I can't use any PECL/PEAR extensions like inotify or anything like that for IPC.

The flow will look like this:

  • Client A requests thread.php and the thread is so far empty, but nonetheless it opens a Server-Side Event at eventPusher.php.
  • Client B does the same.
  • Client A fills out a post in the form and and submits (POSTs) it to subHandler.php.
  • ??? (subHandler stores the new submission into the main thread storefile which gets read from when a fresh, new client requests thread.php, in addition to somehow signalling to the continually-running eventPusher event-source that a new comment was posted and that it should echo the event-json to the client. How, exactly, it will send this signal I'm yet unsure of, but there are a few options that I've thought of -- this is the crux of the question, so see below for more clarification)
  • eventPusher.php happily pushes the new event to the client and it shows up soon after it was originally submitted on all clients who have the page open's screens.
  • PROFIT!

Now for the #4 missing-link mystery-step, I see a few problems. I mean, either way, eventPusher is gonna be doing a while loop of some sort -- it's gonna be polling something, I think that much is clear. (If that's a bad assumption please do let me know.) Now, the simplest way would be subHandler gets invoked on the form submission, writes it to the main store in addition to newComments.xml, then exits without doing anything else. Then eventPusher checks in newComments.xml every X seconds (by the way, what would be a reasonable time interval here?) and if it finds something then it emits an event to the client. Now, my fear with this is that the server's hard drive will have to constantly start spinning up. Maybe this isn't the case, perhaps it would just get cached in RAM and the linux kernel would take care of this transparently such that filesystem access doesn't actually engage the device because the kernel knows that that particular file hasn't changed since last read. * idea #2: I have no idea how to go about this, but perhaps there is a variable scope that gets stored in general RAM on the system which can be read by any process. Like if we mega-exported a bash variable so that $new_post is normally false but it gets toggled to true by subHandler, and then back to flase once it's pushed to the client. I doubt there's such a variable scope in PHP directly, but I struggle with the concept of variable scope, I just can't seem to understand it no matter what I read on it. * idea #3: eventPusher queries ps in its whileloop for another instance of itself. If there's not another eventPusher active then it's highly unlikely that new comments will be getting submitted. It's okay if this only works >=90% of the time, it doesn't need to be completely foolproof. * idea #4: eventPusher queries DMESG to see if that file's been written to recently.

So to sum everything up, I need to have inter-php-script-communication in near-real-time that will work on a standard mod_php shared hosting setup without any elevated privileges, PHP addon modules, or other system adjustments that can't be done from the PHP script itself at runtime. With*out* spinning up the drive more than a few times. No SQL servers either.

Apologies if my english isn't the best, I'm still trying to improve on it.

hakre
  • 193,403
  • 52
  • 435
  • 836
jackie
  • 33
  • 3
  • BTW, I just found [this](http://stackoverflow.com/a/7118584/1500450). Do you think it applies here? I'm just afraid that if its a different process reading and writing to the file that it won't be recognized as the file that's cached. Even if that answer does have me covered, I'd still appreciate any input and suggestions on my implementation, I could use some mentoring/guidance on this one. :) – jackie Jul 04 '12 at 07:28
  • FYI, I posted this [here](http://serverfault.com/questions/404646/) in a somewhat confused state. I'm new to stack exchange, so I wasn't relaly sure what the best place to post my question was in the first place and then on top of that I meant to post it here and ended up goofing up on it. So it's now cross-posted in both locations, but any admins reading this do feel free to remove the one that is in a less appropriate site. Thanks! – jackie Jul 04 '12 at 07:29
  • This is pretty long and I didn't read it all in depth, but in general, there's no need to worry about file system accesses until you really have an actual problem. I've seen sites where every request generated hundreds of filesystem accesses, with thousands of requests a minute or more. Don't worry about the hard drive - but if you're seeing performance issues, consider using an opcode cache: http://en.wikipedia.org/wiki/List_of_PHP_accelerators – Pekka Jul 04 '12 at 08:56
  • The hard drive will not need to "spin up" every few seconds, on a server the hard drive should never stop to begin with. Servers also usually have disks with large caches, which means if the file is often used, it's not necessarily actually physically read from disk, but from the cache to begin with. – deceze Jul 04 '12 at 09:33
  • I am constantly amazed at what all kinds of things people manage to worry about. – JJJ Jul 07 '12 at 06:18

0 Answers0