W dniu 2010-11-24 19:06, Michael Van Canneyt pisze:
On Wed, 24 Nov 2010, Dariusz Mazur wrote:
That's not true. Transfer every action to server is very simple
task, and computing results also. Thus (on my web app) it took less
than 10ms and every user very rare generate more actions than 1 per
second. Computing and sending pdf reports took much more (more
than 90% of working time). As I observe two on core machine can
work 100 users concurent without problem. With more can be problem,
but with memory.
Yes, I remember my discussion with you. I also remember that the
round trip time I observed is over 100 ms, which is noticeable.
(maybe not on intranet, but definitely on internet)
You told about scalability.
10ms is on server, on user side You should add transfer as ping (but
this not load server)
Let me put it differently. In the interface I was talking about, I
need exactly 3 HTTP requests, no matter how much the user clicks/hits
keyboard to set checks:
1. Fetch form 2. Fetch data.
[grid is built on client using fetched data]
3. Save Data (user presses save buton)
Your implementation needs 3 (maybe 2) requests to fetch form and data
and process save, plus additionally a request for each user
click/keyboard hit to set a check.
1.Fetch form with data
after user action: request what should change: server test its
validity, and generate new value for changed widgets
on most cases it took only one frame
2.Save button send nothing but number of button
If that is correct, I don't even need to build these 2 systems to know
that my system will scale better.
And - unless I understand your code wrong - you keep the complete form
state on the server ? (I.e. keep a pascal instance of all visible
TForms and controls in memory).
yes, then same as in desktop,
but also compute of data, size of "visible" control doesn't matter with it
I don't need that at all. The amount of data I need on the server per
user session is roughly 200 bytes, and it doesn't much change during
the session.
In module computing as OLAP I need 10..100MB during session
Again, if my assumption is correct, my system again scales better,
because it does not need nearly the memory your system uses.
Of course. I didn;t say not. But many Delphi todays application need
involve strong interaction between database and user front end. Very
often, after user actions, rather complicated computation on huge amount
of data is done, and its transfer to forms.
My approach has better scalability from programmer side: I don;t need
thing about browser, what should compute server and what not. Browser
paint beautiful widgets (with CSS3,HTML5) similar as OS Windows or GTK,
QT. All rest i've done without care which widgets set will be used.
That is enough fast to service 100 concurrent user , with higher demand
I can use cluster.
Looking at recent trends (Ajax, rich client interface toolkits) people
agree more with me than with you. But I may definitely be wrong;
everybody sees the world through his own spectacles...
Most of webapp are rather simple (counting forms and controls) compare
to desktop app. For example even advanced internet shop has ten times
less function than average store or POS application.
We talk about choose between fat and thin client. Both have good and bad
use case.
Secondly, you have not very demanding users and/or GUI, it seems :-)
Of course this is not game application, but on every ERP application
(like my) are places with rather sophisticated GUI.
I'll describe an interface which I currently have: A grid with about
600 checkboxes (don't ask why, they want it so). Users click the
checkboxes in rapid succession, thus generating much more than 1
event per second.
I have forms with similar widgets too. Second: faster than clicks is
keyboard.
Well, most likely not if you must check which key was pressed, discard
bad keypresses etc, on the server.
On ordinary input not, but I use this on dictionary searching thought
grid. I simply observe what users do in real.
I also proposed keyboard but they require the mouse :(
This is user choose, not us. Both should work good. Today i thinking
about fingers (on iPhone, Android)
But even that: its no problem when response arrive after next click.
If response is under 300ms users thinks : "that is at now"
On average the user sets 50 checkboxes before he presses save.
50x300ms = 15.000 Ms = 4 minutes just to process the checks ?
I don't think so :-)
You don understand. This is not sequential but pipelining. Man need
50*100ms (I dont think its so fast) Server need 50*10ms. Browser (and
user) don't need wait to response
But different behavior of user: after 10 min and clicking 50 user press
RELOAD on browser: whats happens?
But if you believe in it: why not cooperate with the Lazarus team and
create a web widget set ? All options must be explored, you
obviously have a good basis for it, so why not share it
I try to share my work (without this hope I simply not write this
post) but nobody is interesting.
link: http://www.emadar.com/fpc/xwebdemo.zip
I think most people on the Lazarus list simply didn't know about it.
But I hope for you that this will change now, and that people look at
it and prove me wrong. And in doing so, hopefully they
create a good Lazarus widget set.
I hope so.
That is finally what it is about for me: advancing FPC/Lazarus.
I have my idea about how to do this, but if other ideas exist: the
more, the better.
--
Darek
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
