Some things I can tell you: For the chat, we are using nginx in front of APE. Not necessarily because of load balancing or anything else, but because we had some strange problems when we connected to APE direcly, incomplete packets, problems with Firefox on windows, ... Of course this also comes with the advantage of being able to use zip/ deflate and drastically reduce traffic - but on the other hand we are not able to use Websockets with this - as soon as they get reliable...
The machine we are running on in production is quite a fat boy, 64GB RAM, 8 cores I think - but it does quite some other things in parallel. And it worked on an old dual core, 4GB RAM as well, so this should be fine. Regarding stats, I'm not sure if I get the information (to publish), let me check. However, since we changed the app a little bit (we "forced" every user to log in to ape automatically before, now making it an option) we do not have this LARGE number of users connected anymore, so I cannot compare 1:1. But I assume the traffic and RAM/CPU usage would still be much less now. And yes, it is a non-interactive channel - actually, we do not use the "channel" at all, we keep everything on the server and do it on our own. So, clients do not send messages to a pubid but to a nickname and the server stores the pubid(s) and forwards the message. I'm planning to turn parts of this into a project, so you might get some ideas here: http://turted.xosofox.de https://github.com/Xosofox/TURTED/tree/master/comet/APE/TURTED (userlist.js and notifications.js shoudl give you an idea) On 31 Jul., 00:31, Tyler Slater <[email protected]> wrote: > Sounds like I'm on the right track then! I'm wondering how much RAM, > CPU, bandwidth, etc. You are eating up with that many users. Can you > release any of those stats? Also, are you using non-interactive > channels in order to connected your users without join/leave > notifications? I think in some versions of APE they need to be on a > channel.... > > On Jul 30, 2:26 pm, Xosofox <[email protected]> wrote: > > > > > > > > > Your questions are good, they show you got past the initial steps and > > start to understand the higher magic of ape :D > > > I can understand your concerns, I had the same when I started my > > current project. But now I would say: you can stor a hell lot of data > > on the server side. It's not CPU/Memory that will make your ape > > struggle, it's network bandwidth. > > So, anything that you can do to reduce network traffic will make your > > life easier if you scale up to several thousand users. > > > In my current project, a 1:1 chat for users, we first had an > > installation, having at peak times ~10K users. We collected join/leave > > messages in a associative JS array and sent out "bursts" ever 45 > > seconds to all users, to minimize network load. > > > What we ended up doing now (and it turns out to be a much better > > solution) is to keep lists on the server who likes to chat with whom > > and sending out join/leave only to those interested. > > So, clients send their current "chat user list" to the server, the > > server keeps track of who's following whom and then sends events only > > to the right clients - DRAMATICALLY reducing bandwidth and even CPU, > > even though there are a lot of loops invlolved. > > > BTW, we're only using associative arrays (objects) and loops like > > for (u in userlist), no standard arrays, since this seems to be a > > better fit for this job. > > > So, my answer would be: go for it! Store data on the server - but use > > it wisely. And make sure to clean up your data when a user leaves!! > > > What I would do on the server: > > var userlist={}; //global list of all known users, that gets filled on > > the addUser event > > > var user={ > > 'login':'asdf'. > > 'pipe': data.pipe //the unipipe of the user > > 'property1':'qwer', > > 'property2':'bar} > > > userlist[user.login]=user; > > So you have all you need in a neat little array and could even send > > messages from the server to the client by using. > > userlist['tyler'].pipe.sendRaw('msg',data,opts) //well, I think, > > something like that... you need to check the docs > > > Hope this helps a bit? > > > FYI: > > Reasons for why we use associative > > arrays:http://www.xosofox.de/2011/02/js-performance-numbered-array-vs-associ... > > > On 30 Jul., 11:37, Tyler Slater <[email protected]> wrote: > > > > Sorry for dominating these boards with my questions. I appreciate all > > > your help. I hope these questions are good. > > > Once I feel versed in APE, I'll try and contribute by updating the > > > wiki to clarify these issues for others. > > > > I am wondering about the viability of storing information within the > > > the script. I am wondering how much it can take. If I was storing > > > 10ish variables for each user (including a couple of objects/arrays > > > with 10 elements each) as public and private variables could the > > > system handle performing different operations on those variables for > > > each user regularly, like searching all the users to see if they have > > > a certain property? What if I scaled up to hundreds or even a few > > > thousand users at once? Would this be a RAM killer? I'd like some > > > feedback. Originally I thought I'd put everything in a database and > > > query it all the time, but it would be easier to code, and better for > > > various reasons to keep the data live in APE, assuming APE can handle > > > it. > > > > Thanks for your input! > > > > Tyler -- You received this message because you are subscribed to the Google Groups "APE Project" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ape-project?hl=en --- APE Project (Ajax Push Engine) Official website : http://www.ape-project.org/ Git Hub : http://github.com/APE-Project/
