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.
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).
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.
Again, if my assumption is correct, my system again scales better,
because it does not need nearly the memory your system uses.
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...
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.
I also proposed keyboard but they require the mouse :(
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 :-)
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.
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.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
