Archives
June 2005
6/30/05
6/29/05
6/29/05
6/27/05
6/26/05
6/25/05
6/24/05
6/23/05
AIM Triton Beta Memory
6/23/05
6/23/05
6/22/05
6/22/05
6/21/05
6/21/05
6/20/05
Thursday, June 23, 2005
As promissed here is a post on AIM. I wanted to spend a brief moment to discuss memory issues with the latest AIM Triton Beta client. I believe there are two major points of contention that I have read on the web.
1) Why are there 3,4,5, or 6 AOL* processes running at one time when all I did was launch AIM?
2) Why is this thing so darn slow?
So lets take number 1, yes there are lots of processes, will this change maybe/maybe not. Here is why...we have written a service architected client. Each service runs a process, they just all have the same name (this hopefully gets fixed). My argument is this, lets take this hypothetical: If AIM 5.9 takes up 35 megs of ram in one process, then compare that to the 4 process of triton, that each use 8 megs of ram, then you as the user comes out ahead.
This leads as a perfect transition into number 2. So right now we can see that each process is not using 8 megs, it is in fact using more, so when you start adding it up Triton is slow. Right now we are in a Beta period and these things will improve.
In contrast. the AIM 5.9 client code base is very mature, so when we did betas from that code base, the quality was much better since we have had 8+ years working with that code base.
Justin from the Boxely UI team actually posted a blog about this earlier today, you can read about it here.
I would love to hear what others think about this...I know machine performance is very important to people, as you can read down below regarding the Live Video post.
PS - For you sports fans out there, and I am definitely one of them, my prediction tonight is the Pistons will win game 7.
gregsblog at 5:53:00 PM EDT Blog about this entry |
Add to del.icio.us | 
digg this
AIM Triton Beta Memory
Ra - Fallen Angels
As promissed here is a post on AIM. I wanted to spend a brief moment to discuss memory issues with the latest AIM Triton Beta client. I believe there are two major points of contention that I have read on the web.
1) Why are there 3,4,5, or 6 AOL* processes running at one time when all I did was launch AIM?
2) Why is this thing so darn slow?
So lets take number 1, yes there are lots of processes, will this change maybe/maybe not. Here is why...we have written a service architected client. Each service runs a process, they just all have the same name (this hopefully gets fixed). My argument is this, lets take this hypothetical: If AIM 5.9 takes up 35 megs of ram in one process, then compare that to the 4 process of triton, that each use 8 megs of ram, then you as the user comes out ahead.
This leads as a perfect transition into number 2. So right now we can see that each process is not using 8 megs, it is in fact using more, so when you start adding it up Triton is slow. Right now we are in a Beta period and these things will improve.
In contrast. the AIM 5.9 client code base is very mature, so when we did betas from that code base, the quality was much better since we have had 8+ years working with that code base.
Justin from the Boxely UI team actually posted a blog about this earlier today, you can read about it here.
I would love to hear what others think about this...I know machine performance is very important to people, as you can read down below regarding the Live Video post.
PS - For you sports fans out there, and I am definitely one of them, my prediction tonight is the Pistons will win game 7.
gregsblog at 5:53:00 PM EDT Blog about this entry |
Add to del.icio.us | digg this
This entry has 6 comments: (Add your own)
-
Thanks Jimmy, I apprciate you jumping in here...now get back to work....;-)
-
"I still don't understand why there are so many processes running even if they are different services? I was under the assumption from reading the triton code that the services were going to be passed to the execution engine ee:\\ which would then spawn the required code to be carried out. Is this not the case? Instead we have the single process spawning more processes based on the whatever is required?"
The EE does indeed spawn off processes if required for a service. Every service has a service manifest file that specifies it's context. If a context does not exist it gets it's own AOLServiceHost.exe. We seperate UI and major business logic into two seperate contexts. However, as the EE has evolved some services have not yet caught up. This means that they have the incorrect context specified and get an AOLServiceHost all to themselves. The aim right now is to only have two AOLServiceHosts.
AOLHostManager is the controller of the EE; it is in charge of spawning off hosts and starting services.
A service can also specify it's context as in-proc. This means multiple instances of the service can exist and are loaded into the process that requests them.
"Perhaps it is because I am not directly familiar with the architecture however this seems like it could spawn a resource eating nightmare. If the single process doesn't recognize the start of the other processes then this could cause it to place the request again, and again...and.."
This is covered by the existance of the AOLHostManager.
If you see multiple AOLHostManagers then one possibility is that something didn't shut down right and managed to start another instance of the EE. Another possibility is that another AOL EE based application has been installed in a seperate directory and these by design run independantly so that no interference can occur. -
The problem is, as of now, those processes don't shutdown when the AOL software is closed. Whether it be Triton or Explorer, those processes are always present in memory. I'd rather give up another megabyte of RAM and know that when I close AIM, AIM is fully closed and not still half running on my system. I have no intent on being rude or anything, but it's simply a really bad idea to have processes for software running when the software itself isnt running.
-
I still don't understand why there are so many processes running even if they are different services? I was under the assumption from reading the triton code that the services were going to be passed to the execution engine ee:\\ which would then spawn the required code to be carried out. Is this not the case? Instead we have the single process spawning more processes based on the whatever is required?
Perhaps it is because I am not directly familiar with the architecture however this seems like it could spawn a resource eating nightmare. If the single process doesn't recognize the start of the other processes then this could cause it to place the request again, and again...and..
If this is to relieve a single process taking 54MB's and instead split each process amonst the 6 or so then on 64Bit processsors this should drop down considerably correct? Maybe you could explain more about the processes and why so many are started. I don't see where anyone could justify 6 processes or so without the other beta components each sharing them without an increase in resource usage. Just my opinion
7/2/05 12:52 AM