Page 3 of 3

Posted: Wed Jun 21, 2006 7:13 pm
by AKA Panama Jack
Depending upon what he is doing with the queries he could possibly use table joins and have only one query.

Posted: Wed Jun 21, 2006 7:52 pm
by s.dot
Until I can find time to better play around with sockets and making a front end, I'm going to use -Rojas- suggestion to have the backend only do the queries and push it out to the end users. perhaps by writing a small text file once a second and having the ajax script read that. it seems to me that one query per second (total, instead of once per user) and reading a small file (talking a few bytes here) would be way less server intensive.

Posted: Wed Jun 21, 2006 8:51 pm
by Weirdan
AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
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.

Moreover, it might be possible to run PHP server via inetd... it could simplify the server (not a real daemon in this case) because inetd would handle LISTEN phase of connection... dunno. It needs to be researched.

Posted: Wed Jun 21, 2006 9:53 pm
by Roja
Weirdan wrote:
AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
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.
Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.

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.

Posted: Thu Jun 22, 2006 7:30 am
by bg
Roja wrote:
Weirdan wrote:
AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
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.
Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.

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.
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.

Posted: Sat Jun 24, 2006 3:32 am
by s.dot
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.

Posted: Sat Jun 24, 2006 1:05 pm
by Weirdan
- 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)
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.

Posted: Sat Jun 24, 2006 1:45 pm
by Christopher
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.
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.

I don't think I have seen anyone mention PHP's shared memory functions (shmop_*) but they might be of use here. You could maintain the chat queues in shared memory as they are not really that big.

But you need to install the shmop library in PHP, so it might not be available.

Posted: Sat Jun 24, 2006 1:47 pm
by s.dot
Is it possible to stream the text file?

Posted: Tue Jun 27, 2006 12:28 pm
by bg
scottayy 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.
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 just

Code: Select all

SELECT * FROM chat WHERE chatroom_id = 2 AND time_said > (last time the client polled the server)
You will also want to clean up the chat table, or atleast move records to a chat_history table that isn't constantly queried but will allow you to see past conversations.

Posted: Wed Jul 26, 2006 3:47 am
by dzver
I think that the best way to create web IRC client is to AVOID using of php or another server side script, no matter compiled or not.

I've made php3/php4 irc webchat several years ago using technology similar to AJAX (frames communication, not xml, for compatibility with browsers like netscape 4.0... no longer supported). It is probably largest php webchat ever made by anyone anywhere. It had about 5200 users peak with largest channel with over 1700 users (~50%-70% of them were php webchat users and rest - mIRC, JAVA etc). I had constant need of more and more memory, servers, maintenance and care :/

I think now that adequate webchat is flash with direct connection to local IRC server without gateway. But I am not familiar with this technology and I don't know if it is possible with the use of flash XML sockets.