Rork said:
Hi,
I have to integrate few reports (made in crystal) into the web application.
Integration would be in a form of simple link that users wil click which
will result execution of report. I know that I need Crystal Reports Server
(formerly known as RAS or Crystal Embeded). My question is: how many threads
(simlutaneously requests) accepts Crystal Reports Server 11? For example 9th
cersion of RAS use only 3 threads (so only 3 reports can by made at once,
rest reports wait in queue). I read everything on crystal decisions page but
there is nothing I need (as far as I know number of CALs is not the
information I am looking for).
thanks in advance
Rork
Hi, Rork!
This is a little off-topic, so I can say straight off that I've no
idea how many threads Crystal Reports Server can manage.
Here starth the off-topic bits.
Threads are difficult. They're difficult to use, and difficult to
understand. Threading, therefore, causes problems.
So before we begin looking at what on earth a server has to do with
threads, let's get one thing clear: threads have – fundamentally –
nothing to do with allowing software clients work in parallel towards
a common software server.
That word, "Fundamentally," is important.
Threads may allow clients to work more efficiently towards a common
software server, but this is a derivative of threads, not a
fundamental, and it is always dangerous to design towards a
derivative. A fundamental may have several, derivative consequences,
and if you design solely towards the fundamental then you'll reap the
benefits of all its derivates.
If you design towards a derivative, however, then you'll at most reap
the benefits of that one derivative, and all other derivatives of the
fundamental will be ignored.
Always be wary of someone's saying, "Right, we'll have ten users of
our system, so we'll have one thread per user, which gives us a
maximum of ten, multiple threads in our system."
So what is the threading fundamental? It's this: threads are a
blocking-management technology. They have nothing to do with
number-of-users. They have everything to do with number-of-blocks.
Take the example of some pre-emptive scheduling web server code that
calculates PI to a given number of decimal places; let's say it takes
this server code five seconds to achieve an accuracy of twenty million
places. This calculation is quite simple, and can be self-contained
within a single class of the code.
Then take ten pieces users with web browser clients, all of whom
simultaneously access the web server software, specifying twenty
million places.
Threading-derivative-lovers may take the following design approach, if
they had been responsible for designing the server software: use one
thread per client in which to perform the PI calculation.
If we ignore peripheral threads (for queuing requests to IP ports,
garbage collection, etc.) then the ten users will start ten threads,
each of which will start calculating PI. The problem here is that the
web server software doesn't naturally block between the beginning of
the calculation and the end: the software essentially enters a loop,
and iterates over an algorithm. Yet because we have ten threads
running simultaneously, each will pre-emptively interrupt the other's
otherwise uninterrupted calculation.
The result is that, as each calculation takes five seconds, and as
each of the ten threads is getting equal time-slices in the scheduling
algorithm, then none of the ten threads will have finished before
fifty seconds has elapsed. Even if we presume zero-time context
switching, then only on the fiftieth second will all threads return
their answers to their clients.
The average response time, then, is 50 / 10 = 5 seconds.
Those who view threads not viewed as client-driven but viewed as
blocking-driven would have designed the web server software
differently. They would see that the calculation is inherently
non-blocking, and so would see no reason to introduce a thread per
request. They would, instead, have one thread to queue the requests,
and one thread to service the request, no matter how many clients
there are.
So can one thread lower the average response time?
If again all ten clients again access the web server code
simultaneously, then one thread will start to calculate the result,
and all the rest will block (either in the IP queuing thread, or an
application-specific queuing thread). This first request will be
serviced after five seconds (again, ignoring context-switching times).
The second request will be serviced after ten seconds. The third will
be serviced after fifteen seconds. So the average response time will
be (5 + 10 + 15 + 20 + 25 + 30 + 35 + 40 + 45 + 50) / 10 = 275 / 10 =
2.75 seconds.
An almost 50% improvement over the thread-per-client solution.
The reason for this improvement is because the calculations are
non-blocking in themselves, and as threads are a blocking-management
technology, then there's nothing here for them to solve.
If the machine running the web server software had to synchronously
request half of the calculation from a second machine, then multiple
threads would be a better solution. This is because there would then
be a natural blocking introduced into the arrival at the result. The
first machine would block until the second machine had finished its
calculation, and instead of blocking, two threads could be used: one
to perform half the calculation on the first machine, and one to send
and retrieve the request from the second machine.
Again, even with this blocking, there is no need for one thread per
client; there is just a need for an extra thread to handle the new,
single blocking-point.
I'm of course not saying that the Crystal Report Server is designed
like this - it may have all sorts of
network-requests/off-processor-databases, etc., which are perfectly
valid cases for spawning new threads.
But then, it may not.
..ed
www.EdmundKirwan.com - Home of The Fractal Class Composition.
