libpurple in server

[Alexey Nezhdanov]

On Friday 01 June 2007 09:26, Ethan Blanton wrote:
> Christopher Baus spake unto us the following wisdom:
> > I'm currently working on such a project.  I think the only potential
> > issue is handling the single threaded event loop in a scalable manner. 
> > For instance doing I/O when handling messages is going to block the
> > entire glib event distribution until the I/O completes.  This will result
> > in poor CPU and I/O utilization.
>
> So, while this is true at some level, you should be able to handle an
> awful lot of IM connections before this becomes a problem.  Most of
> your I/O will be simple buffer reads and writes, and the only real
> cost you'll pay is the system call overhead.  (Disk I/O in libpurple
> is about the only thing which might degenerate into something other
> than a buffer read or write, as it is blocking.)
>
> If you're wanting to serve thousands of IM accounts at the same time,
> you'll certainly have to do something about this ... if you're wanting
> to serve dozens or hundreds (for a small company or school, say), I
> doubt this will become a problem.  Threads are not necessary nearly as
> often as people like to think.  :-)
I am working on such application too.
The biggest problem that we are coping with atm is memory leak. One hundred 
accounts online gives about 70-100M RSS increase per hour. Also CPU 
consumption starts increasing and drops only when we restart the serverside 
component so it returns to much lower RSS and CPU usage.
If anybody can give any hint how to catch these leaks - it will be very 
helpful. So far we wasn't able to find the source of such perfomance.
We used 1.3.0 then beta2 then beta6 (and up to present moment). Leak was 
always present, just currently it become a problem as number of users rising.
> Ethan

-- 
Respectfully
Alexey Nezhdanov