From: Chris Schlaeger (cs_at_suse.de)
Date: Tue Feb 22 2005 - 03:41:52 CET
From: Chris Schlaeger <cs@suse.de> Date: Mon, 21 Feb 2005 19:41:52 -0700 Message-Id: <200502211941.58876.cs@suse.de> Subject: Re: [taskjuggler] Experiences with many tasks
On Monday 21 February 2005 12:47, Dick Kniep wrote:
> Hi list,
>
> Is there anyone out there that is using Taskjuggler with MANY tasks. We
> developed a program that generates automated plans for many users and many
> tasks. It can happen that we have some 40 resources and per resource some
> 1500 tasks.
You are definitely pushing it, but there are no built-in limits. You need to
consider memory consumption and scheduling time. TaskJuggler uses a
scoreboard algorithm that requires a pointer for each time slot for each
resource in each scenario.
MEM = time slots * resources * scenarios * sizeof(pointer)
The number of timeslots depends on the length of the project and the
scheduling resolution (default is 1 hour). So a year long project has 365 *
24 = 8760 time slots.
The number of resources is actually the number of used resources. So it's no
problem to have all 4000 employees of your company in the project file. Only
the allocated ones require memory.
The size of a pointer is 4 bytes on a 32 bit system and 8 bytes on a 64 bit
system.
Certainly tasks, accounts, shifts and other stuff needs some memory, but the
above equation captures the big consumer.
Scheduling time is another issue you might want to keep in mind but it is a
lot harder to quantify. The number of tasks certainly plays an important
role, but constructs like limits and mixing ALAP and ASAP tasks has a much
greater impact. The more tasks you have, the more these features will hit
you.
The biggest culprit are tasks like this one:
task t "Bad Task" {
start 2005-02-21
end 2005-12-31
allocate jim
}
They look harmless but the 'end' after the 'start' turns this into an ALAP
tasks that gets scheduled backwards. Mixing this with many priority levels
forces the scheduler to schedule one task after another, basically extending
the scheduling time by a factor of the number of ALAP tasks.
So better write:
task t "Bad Task" {
end 2005-12-31
start 2005-02-21
allocate jim
}
or
task t "Bad Task" {
start 2005-02-21
end 2005-12-31
scheduling asap
allocate jim
}
Our projects have about 160 people and 500 - 800 tasks. So you should be ok.
Especially when you can do batch scheduling and don't need interactive
response like the new front-end does. The 2.1 version was optimized for
scheduling speed because of this.
Chris
-- KDE 3.3: Conquer your Enterprise Desktop! See http://www.kde.org! GPG Key: 1024D/0500838B A5FE C051 2AFC 9A14 768A 5125 5829 5750 0500 838B
This archive was generated by hypermail 2.1.7 : Tue Feb 22 2005 - 03:42:21 CET