I also thought about this approach some time ago. If you look at handling
one request, you are certainly right. By sending off several requests at
once, you can reduce the response time if a small number of requests is
processed by the portal.
However, the usual scenario for a portal is that you have a large number of
users that use the portal in parallel. In that case, the picture probably
looks different. For example, if you have only 100 requests concurrently
processed by the portal and in average five portlets per page that make
requests to external information sources, the portal would want to send off
500 requests from 500 threads.
An alternative approach that often used to get better performance is to
have a permanently updated replica of the content at the portal site. Many
content providers provide special clients that take care of keeping the
replica up to date with content on the internet.
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
Hi all ...
I am just writing some portlets connecting to external sources and had some
ideas on how to enhance the request performance (processing time).
As I understand, Jetspeed calls every getContent() of a portlet in a
sequential way. This means if a portlet waits for an answer of a third
party system,
the hole request will wait till this third party system has answered.
So if you have 3 portlets in a portal screen connecting to different third
party systems a request in the jetspeed engine would look like this.
--
request time
-> portlet01.getContent()
-> connect to third party system 10 ms
-> wait for result 90 ms
-> porcess and return result 10 ms
-> portlet02.getContent()
-> connect to third party system 10 ms
-> wait for result 160 ms
-> porcess and return result 10 ms
-> portlet03.getContent()
-> connect to third party system 10 ms
-> wait for result 120 ms
-> porcess and return result 10 ms
return result
-- processing time 420 ms
Another solution to handle this request is by a thread pool which will
call the getContent() method of each portlet in parallel, the request would
look like this.
-->
request time
-> portlet01.getContent()
-> connect to third party system 10 ms
-> portlet02.getContent()
-> connect to third party system 10 ms
-> portlet02.getContent()
-> connect to third party system 10 ms
-> wait for result 160 ms
-> porcess and return result 10 ms
-> porcess and return result 10 ms
-> porcess and return result 10 ms
return result
<-- processing time 220 ms
The processing time for a request would be pretty faster. Even when adding
some time for thread handling and synchronization would beat the sequential
method. Or do I oversee something?
Comments, remarks, criticisms welcome...
Mirko Buholzer
--
Sent through GMX FreeMail - http://www.gmx.net
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
