|
| Re: Evaluation Report on RAP [message #82325 is a reply to message #82118] |
Thu, 10 April 2008 21:25   |
Eclipse User |
|
|
|
Originally posted by: jkrause.innoopract.com
Hi Arpit,
Thanks for posting your questions. Comments inlined ..
Arpit Desai wrote:
> Hello group,
>
> I am preparing an evaluation report for my group. I would really
> appreciate if I can put in some information about current/test
> enterprise level deployments of web applications based on RAP technology.
>
There are a couple of enterprise deployments that I am not (yet) allowed
to talk about publicly. But I will send you a private mail on this topic.
> What I am looking for is how many concurrent users are supported for
> transactional system. What are the hardware requirements to scale to for
> about 15000 - 20000 users (not concurrent) worldwide.
>
If you take general best practices for distributed applications into
account (e.g. keep as little data per user session as possible) you
should be able to handle 500-1000 concurrent users on a standard
dual-core server with 4-8 GB of RAM. If you cluster the nodes behind a
load-balander (could be apache httpd) you can easily serve 5000
concurrent users, which seems as much as you likely going to get, with
around 5-10 nodes.
> Also, the choice of application/web servers.
>
You can stick with the app servers you are already using, we have not
seen any special requirements by Equinox based apps.
> Also, from the RAP team I wanted to find out where is the technology
> heading right now. Yes, we see that idea is to port entire eclipse
> workbench on the web. But as far as RAP is concerned, it is closely tied
> with qx and SWT.
SWT will stay a constant for RAP, from our point of view this is one of
the main advantages of RAP. We offer a consistent and established API.
For client side implementations we will likely see more choice in the
near future. We just (yesterday) introduced fragments for creating
different implementations of client side technologies, we are starting
this of with the new version of qx (v0.8). But nothing is holding us (or
you) back to provide your own implementation using flex, silverlight or
different JS frameworks.
> Extending current UI components is not trivial.
This is true, but from our experience this is true for all client side
JS if you start to develop real applications. At least we shield this
job from the application developers, and dedicated developers with the
right know how can handle this job.
> Adding
> custom Javascript once the plug-in is compiled is not supported
> currently.
I don't fully agree here: If you look at the google maps example, the
gmap JS code is loaded from somewhere on the net. You are able to change
that code at any time, but you can't change the Java API of the
component. You can also use the browser component to integrate arbitrary
html / js code and interact with it using the execute command (at least
if everything is hosted on the same domain).
Can we expect more options on some of these fronts in the
> future (maybe a year down the line)?
As described above, offering fragments for providing the client side
code and client-server communications is an important step forward. but
we would also like to learn about your concrete requirements to see if /
how we can accomodate them.
>
> Please feel free pass comments I am open to discussions. Any guidance is
> welcome.
>
> Thank you all for wonderful technology and support.
>
> Arpit
Cheers,
Jochen
|
|
|
| Re: Evaluation Report on RAP [message #82626 is a reply to message #82325] |
Sun, 13 April 2008 16:45 |
 Arpit Desai
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Hello Jochen,
Thank you for taking time out to compile the below response. It contains
good information I can use. I would really appreciate if you can share
some data about the enterprise deployments. I am in touch with Elias and
he has my work emailid. If you can send some data across over there it
would be of great help.
Once again, thanks for taking time to reply.
Regards,
Arpit Desai
Jochen Krause wrote:
> Hi Arpit,
>
> Thanks for posting your questions. Comments inlined ..
>
> Arpit Desai wrote:
>> Hello group,
>>
>> I am preparing an evaluation report for my group. I would really
>> appreciate if I can put in some information about current/test
>> enterprise level deployments of web applications based on RAP technology.
>>
>
> There are a couple of enterprise deployments that I am not (yet) allowed
> to talk about publicly. But I will send you a private mail on this topic.
>
>
>> What I am looking for is how many concurrent users are supported for
>> transactional system. What are the hardware requirements to scale to
>> for about 15000 - 20000 users (not concurrent) worldwide.
>>
>
> If you take general best practices for distributed applications into
> account (e.g. keep as little data per user session as possible) you
> should be able to handle 500-1000 concurrent users on a standard
> dual-core server with 4-8 GB of RAM. If you cluster the nodes behind a
> load-balander (could be apache httpd) you can easily serve 5000
> concurrent users, which seems as much as you likely going to get, with
> around 5-10 nodes.
>
>> Also, the choice of application/web servers.
>>
>
> You can stick with the app servers you are already using, we have not
> seen any special requirements by Equinox based apps.
>
>> Also, from the RAP team I wanted to find out where is the technology
>> heading right now. Yes, we see that idea is to port entire eclipse
>> workbench on the web. But as far as RAP is concerned, it is closely
>> tied with qx and SWT.
>
> SWT will stay a constant for RAP, from our point of view this is one of
> the main advantages of RAP. We offer a consistent and established API.
> For client side implementations we will likely see more choice in the
> near future. We just (yesterday) introduced fragments for creating
> different implementations of client side technologies, we are starting
> this of with the new version of qx (v0.8). But nothing is holding us (or
> you) back to provide your own implementation using flex, silverlight or
> different JS frameworks.
>
>> Extending current UI components is not trivial.
>
> This is true, but from our experience this is true for all client side
> JS if you start to develop real applications. At least we shield this
> job from the application developers, and dedicated developers with the
> right know how can handle this job.
>
>> Adding custom Javascript once the plug-in is compiled is not supported
>> currently.
>
> I don't fully agree here: If you look at the google maps example, the
> gmap JS code is loaded from somewhere on the net. You are able to change
> that code at any time, but you can't change the Java API of the
> component. You can also use the browser component to integrate arbitrary
> html / js code and interact with it using the execute command (at least
> if everything is hosted on the same domain).
>
> Can we expect more options on some of these fronts in the
>> future (maybe a year down the line)?
>
> As described above, offering fragments for providing the client side
> code and client-server communications is an important step forward. but
> we would also like to learn about your concrete requirements to see if /
> how we can accomodate them.
>
>>
>> Please feel free pass comments I am open to discussions. Any guidance
>> is welcome.
>>
>> Thank you all for wonderful technology and support.
>>
>> Arpit
>
> Cheers,
>
> Jochen
|
|
|
Powered by
FUDForum. Page generated in 0.04178 seconds
] 
Search
Help
Register
Login
Home
