W dniu 2010-11-24 19:06, Michael Van Canneyt pisze:
Show quoted text 30 lines
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
Show quoted text 8 lines
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 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.
Show quoted text 15 lines
>> 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)
Show quoted text 7 lines
> 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?
Show quoted text 15 lines
>> 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.
Show quoted text 5 lines
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
