Posted: Wed Jun 21, 2006 7:13 pm
Depending upon what he is doing with the queries he could possibly use table joins and have only one query.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.Weirdan wrote:You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
Please elaborate, on the original posters solution. I must have missed it. Unless you're referring to the flash solution which isn't really a solution to the problem.Roja wrote:Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.Weirdan wrote:You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
I've answered the original poster, I've researched my posts, and I've provided the links to everything needed to do precisely what the OP wanted. I have no interest in further arguments with people on the topic.
You're risking to lose some messages because client-side (ajax) polling is not synchronized to server-side polling (writing the file). There would be cases when a client did not receive previous chunk of messages because the server overwritten the file with a new chunk already.- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
I'm not sure that anything would be missed because it does not appear that what is being saved is a queue -- is sounds more like a snapshot of the current chat history. But it is always possible to miss something by reading before the next write in these systems -- but that gets fixed on the next read.Weirdan wrote:You're risking to lose some messages because client-side (ajax) polling is not synchronized to server-side polling (writing the file). There would be cases when a client did not receive previous chunk of messages because the server overwritten the file with a new chunk already.
Caching to a text file wont do you any good since it is such a simple select statement. If it were a complex select to get the chat history then caching might be a good idea, but it really shoudnt be anymore complicated than justscottayy wrote:Okay, sorry to revive this topic, but I'm bouncing back and forth between so many projects.. its been a while since I've visited this one.
What do you guys think of my proposed solution?
- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
This would be saving a crapload of queries, but I understand file writing is slow. But a second interval should be way more than enough to write a file a few bytes in size.
Would this be less server intensive then 3 queries per second - per user?
In total there would be two actions per second.
- checking for new messages and writing them
- checking the text file for content and appending it to the chat area
This does bring up a problem of when there are no users in chat. This would be checking for new messages when there won't be any.
I'm interested in hearing you guys' opinions.
Code: Select all
SELECT * FROM chat WHERE chatroom_id = 2 AND time_said > (last time the client polled the server)