Performance ... your experience ?

[benkrembs]

I've located the problem that occurs when a large number of users are on the system. Note that it is NOT due to shared hosting limitations, but do to a fundamental design of phpFreeChat.

When a user first logs into the channel, the browser issues a new request for EACH user that's on the system. That means if there are 100 users online, the next user that joins will have to issue OVER 100 REQUESTS to load all the data (via the "whois2" command).

This is very a disappointing design decision. This basically means that this system cannot be used on any site that may ever have more than 50 users on it. Your web host, even if it's a dedicated server, will go down. Not to mention that it's going to cause havoc on the poor users, too.

I'm examining ways to disable/work around it. But this is such disappointing find. Anybody else been looking into this?

[OldWolf]

No, I'm afraid your mistaken, it is directly related to shared host limitations. When you are sharing a server, the host almost always monitors your cpu usage in one way or another, and cuts it off (or otherwise limits it) if it exceeds a certain point. Then too, you must consider the fact that you don't have the server's entire resources devoted to just your chat, but are rather sharing them with several (and I mean several) other sites.

As far as what you described as a design flaw, you're close to the whole case, but you're still missing the big picture. The main problem is the simple substantial numbers of requests issued by having multiple users connected to the chat at any given time. For example, pretend that you're trying to have 50 people on the server, and your refresh delay is 2 seconds. So every in every 2 seconds, the server receives a minimum of 50 requests. That's 25 requests a second... and I'm willing to bet that most shared servers will require at least .25 seconds turn around time to process the php, check the files/sql, and so forth. You can see how this is going to quickly screw up the server's processing speeds, and tie up all the resources. And that's not even accounting for the additional requests made if someone tries to send a message or otherwise interact with the chat.

[benkrembs]

I certainly agree that just the general chat updating can chew a lot of CPU. But to the developers' credit, the "update" procedure is quick and well written.

But when there are more than 50 users in there, every new user that joins literally unleashes a DDOS of 50+ simultaneous requests (which can even quite possibly crash the browser). And since most chat rooms are either on multiple pages throughout a site, or chatters don't stay too long anyways, this rapid turnaround amounts to a ton of processing.

Here's a real world example. I'm running PFC on a shared server, in a dedicated chat capacity (i.e. users come here to chat) and averaging 75 concurrent users. When using the out-of-box PFC, the load on the server was averaging between 7-9. But after removing the "who" functionality, the load instantly dropped down to 1.5-2. (Without the chat running at all the load on the server was around .7)

So yes, there is some fundamental load that can't be avoided. However, that's just not the bottleneck when using it on a popular site. The problem to scaling is the "whois" requests that get sent out.

In case anybody's curious about how to disable that, just remove the "who" and "who2" block on line 464 of /data/public/js/pfcclient.js

[OldWolf]

I'm curious what you mean by the server is "sending out" data all at once. There are no maintained sockets with this software... so how would it be forcing the data out all at once. Everything done is handled by requests from the user's end. Do you follow what I'm saying?

[phpfreechat]

benkrembs, thank you for your objective analysis. I really agree with you about the who and whois2 bottleneck. To be honest I wrote these commands quickly without thinking a lot about optimization.
If I remember well, each time a new user join a channel, a tonne of /who are sent for each people on the channel (even if these /who were done before). A simple optimization would be to rewrite the javascript code which send the /who command. It's not necessary to send again a /who command if it has been sent before. So that, if a new user join the room, only one /who will be sent by each members of the room.

I really don't have time to work on this improvement (currently working on pfc2.0) but I can surly review/integrate a patch that fixes this issue. benkrembs or someone else, your patch is welcomed.

regards,

[OldWolf]

I'm still confused about how the server is sending out, outside of the normal responses? How can the server "send" anything without first receiving a request?

[phpfreechat]

OldWolf, you are right when you say "Everything done is handled by requests from the user's end". So I don't understand your question when you speak about "the server is sending out" ? I don't see what in the above discussion is related with that.

[OldWolf]

If I remember well, each time a new user join a channel, a tonne of /who are sent for each people on the channel (even if these /who were done before).

This is what I'm referring to.

Here's how I understand it:

User's make requests, say, every 2 seconds:
User request
2 seconds
User request
User joins within 2 seconds
User request (included in the result is the new who info)

Now, if this is the case performance would not be greatly effected by the added who info.

What I'm noticing both of you saying (or at least it appears), is this/:
User request
2 seconds
User request
User joins - server sends who info to all users
User request

The difference being that the server sending out the who information to all users at once WOULD effect performance, but if it's part of the normal user's request cycle, it wouldn't.

So could someone then explain how it actually works, I likely just have it wrong.

Thanks,
OldWolf

[phpfreechat]

Here is an example of the performance problem:
01- Suppose User1 and User2 are both on the "test" room
02- User1 request: /update
03- wait 1 second
04- User3 request: /join "test"
05- wait 1 second
06- User1 request: /update) <-- he his informed that User2 and User3 have just joined
07- User1 request: /who User1 <-- this /who is not necessary because User1 is already known (it's me!)
08- User1 request: /who User2 <-- this /who is not necessary because User2 is already known
09- User1 request: /who User3 <-- this /who is necessary to know informations about this unknown user (for the User1 point of view)
10- User2 request: /who User1 <-- not necessary as above
11- User2 request: /who User2 <-- not necessary as above
12- User2 request: /who User3 <-- necessary as above
13- User2 request: /whois "test" and /who User1, /who User2 and /who User3 ...
14- wait 2 seconds
15- User1 request: /update <-- and again and again
16- User2 request: /update <-- and again and again
17- User3 request: /update <-- and again and again

The points which could be optimized are 07, 08, 10, 11. So this is why when lot of users are joining/leaving, pfc performances are not good.
Hope this is clearer ?

[OldWolf]

This makes more sense, thank you for explaining. So the issue falls on unnecessary requests to the server then.

[dreamdust]

Was this solved with revision 1256?

[CricketWeb]

I used phpmyarcadescript last week for a chat with 108 users and it killed my dedicated user and I'm now looking for a better option.

I'm wondering if the above performance problems have been fixed in the latest release?

[OldWolf]

There aren't "performance problems"... that would be expected performance. The way this chat works has it's strengths and weaknesses. The chat is built as nothing more than a javascript app, meaning no downloads and fast loads, and seamless easy integration to a site. This set up also requires no special server side hosting of any kind, so that allows any box capable of handling php (pretty much any host) to be able to run one of these (unlike something like IRC, which is next to impossible to get on a host. But the downside to this is that this means the server has to be constantly polled for changes... and of course every one of those adds up. There are some changes you can make (such as increasing the refresh time) to make it easier for your server to handle larger loads... but ultimately the technology the chat uses isn't meant to function at higher volumes as it would be with so many members.

[h4ever]

I go on one chat server in my country (not PFC) and they have hundreds of users in chat rooms. E.g. meeting section has 47 rooms and 465 people right now. The default refresh time is set 20s. The less time you can set is 10s. I think this time is enough - usually you need some time to write your own message. So I don't understand why you use 2s refresh time? I think it's too low. I also have found the refresh_delay_steps which should increase the effectiveness of PFC performance. Can you test the performance for 15s refresh time? I think this would be more intelligent.

Did you repair the 'who' command behavior in version 1.3?

EDIT:
You do a refresh every 2 seconds in every opened room/channel? I think this would be non-sense. If I am not in room (but have it open) then I don't need to see any updates of chat text of that room. There for, just to make a update if I enter the room. Therefor to disable the yellow bubble and save much resources.
See more here:
http://www.phpfreechat.net/forum/viewto ... 170#p15170

[OldWolf]

Actually... a refresh rate of 2s makes perfect sense for most users. You're of course welcome to set your own refresh rate for your chat (that's why parameters exist)... but most people want faster updates so they can see what's happening.