restore chatroomread.php performance hacks
justinrandell - December 24, 2008 - 03:33
| Project: | Chat Room |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | justinrandell |
| Status: | closed |
Jump to:
Description
the current D6 beta's don't use chatroomread.php for the frequent polling requests.
this makes the chatroom module a server eating bit of code.
this issue will track restoring this code path for the simple poll operations while trying to keep as much of the new D6 goodness of the port.
#1
just a note to say i'll be back on this. plan to release an at least vaguely working module with the server-eating code intact, then start a fresh branch to restore the performance code so the module can be used for moderately sized rooms again.
#2
i've now created a new dev branch for this work.
#3
What counts as a "moderately sized room"? If I'm using the existing 6.x-1.0 version with the "server-eating code", how many users is a reasonable number? and what's likely to happen if I go over that number?
#4
well, it all depends on the hardware and setup you have for your site. i would say that 100 people in chats across a site would be 'medium' sized - there are lots of sites with more than a hundred active users. so this means:
- each chat that is open in someone's browser typically pings the server once every second, so if you have 100 people chatting across several rooms, you're getting 100 requests a second just for the polling
- right now, every single poll request does a full drupal bootstrap, even though a very large number of those requests won't actually get anything new back from the server
how much is too much depends on what your hardware can handle, but for the vast bulk of sites, 100 requests a second is a significant load increase, but 100 active users is not so rare.
if we have the poll requests hit a dedicated script, we can serve the requests for which nothing has changed much, much quicker. its a hack, but a hack with a clear performance win.
#5
this is done.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.