Smalltalk › Frameworks & Tools › Seaside › Seaside General

Concurrent requests from multiple sessions

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 34 messages Options
12
Louis LaBrunda
Reply | Threaded
Open this post in threaded view
♦
♦
|

Concurrent requests from multiple sessions

Louis LaBrunda
Hi,

First be sure you have taken Jan's advice about setting the
#AllCallsThreaded preference in AbtDbmSystem to true.

Then see if you can drop the priority of a session with a long running
task.  This can be tricky as you may want to up the priority when the long
running task finishes.

And/Or you can relinquish the CPU in the middle (or elsewhere) of long
running tasks with "Processor yield".  It will move on to the next process
if and are ready or back to your long running process if it is the only
one.

Lou

On Tue, 10 Mar 2015 03:15:12 -0700 (PDT), wilwarin
<[hidden email]> wrote:

>Hi all,
>
>please excuse my inactivity, now I would like to summarize all above, and to
>ask you maybe for a few last answers and advices.
>
>Regarding to mentioned DB2, as I assumed, database is definitely not an
>issue, so I am sorry for my inaccuracy in my first post. At the moment we
>are sure that there is no block from the database side (we can see the block
>in data processing). Thank you guys for your solution proposals.
>
>
>> The only Seaside limitation I'm aware of is a lock around every
>> session. So only one request of 'A' can be processed at any given
>> time. However this should not affect any other users. The lock is
>> there because sessions and components are mutable. Use the code from
>> Sven to verify Seaside and your webserver are not the issue.
>
>This is the behavior we assumed, this (max. one request per session at any
>time) has to be, and actually is, enough. However we are really surprised,
>that other users are affected. And by our investigation they are always
>affected by every concurrent request, no matter how difficult it is.
>
>( I tried Sven's code and it is possible to do another work during waiting,
>it is OK. )
>
>
>> But that problem (not being able to process concurrent requests) is
>> certainly not inherent to Seaside or Pharo. If that were the case we
>> should all stop using it.
>
>Hopefully I understand, so it is not the case. If I am correct, it means
>that in Seaside it is necessary to solve similar situations with different
>access. In case of for example difficult server-side calculation (or
>processing of big amount of data), we have to count on a possible problem
>with concurrent requests from multiple sessions. Am I right? Or, if not,
>where could the problem lay?
>
>As I wrote, we are working in VAST - I tried to simulate the same problem in
>Pharo with the same result, so I think in this case it does not matter much.
>Regarding to Apache (or, when we run it from code), everything is in default
>configuration. Database is not an issue. For me it looks like everything,
>that I wrote here, is a standard behavior of application build on Seaside =>
>the application which has to serve not-so-easy concurrent requests has to
>use some way around (multiple images & load balancing, parallelization of
>processes, ...). Please correct me if I am wrong.
>
>Guys, could you please tell me what I am missing?
>
>Maybe I can imagine, that the application we are developing is not a
>'standard' Seaside app (in the sense of data amount and its difficult
>server-side processing). Then I believe it would require a non-standard
>architecture (according to that all, is Seaside still the path we can/should
>follow?). It is our problem, we do not know about a reliable way to do that
>- and this is the reason, why I am asking here.
>
>What would you recommend?
>
>Thank you again for your time, and thank you for your responses in advance.
>
>Cheers,
>Ondrej.
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Arning-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Bob Arning-2
In reply to this post by wilwarin
BTW, did you include some code in your message? I didn't see any if you did.


On 3/10/15 9:25 AM, wilwarin wrote:
I got the impression that he suggests there is a fundamental 
problem with something except his own code.

Then I have to apologize, it really was not meant to be offensive. I just
wanted to know, whether the issue we are facing is standard or not. That's
why I was asking for correction of my words. Sorry.


Well, we can't help him unless he give us a reproducible case. 

In the end I tested a really simple component:



Then the link was clicked from two different sessions simultaneously. And
now it is the time, when I have to admit I was quite wrong (problem with my
code). During first comparisons, the 'getResults' part was called during the
rendering (between those two DIVs), and results (in both VAST and Pharo)
were like following:



--- BTW: ---

Your rendering method is just for painting the current state of your 
component, it shouldn’t be concerned with changing that state.

So, when somebody does some data processing during the rendering, it will
cause this problem?
-------------

=> Now, after several changes it looks like we still have this problem with
a component above only in VAST.



--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929p4810964.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
sebastianconcept@gmail.co
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

sebastianconcept@gmail.co
In reply to this post by wilwarin
Hi Ondrej,

are you using an ODBC connection? What comes to mind is to check if maybe the FFI call to ODBC or whatever driver you are using to get into DB2 is blocking the VM running that image until it gets the answer.

Whatever the case, you seem to need to scale your app horizonatally with many images.

At least that’s how I do it.

Other than that, there is something that you probably don’t want to even hear about but for what’s worth: a REST backend and a single page application scales really well due to clients’ CPU dividing load and RESTful backends having way better parallelisation


On Mar 6, 2015, at 7:17 AM, wilwarin <[hidden email]> wrote:

Hi all,

Currently we are developing a web application in Seaside, and it is
necessary for us to work in VAST. The application runs as a Windows service,
and for a few days we are facing the following issue:

- At one moment there are two users (let's call them 'A' and 'B') logged in
in the application, so we have two different sessions.
- 'A' requests a page with a long list of objects obtained from DB2, so it
takes a number of seconds to get the results.
- Less than one second after 'A''s request, 'B' requests another page, for
instance an easy static page.
- For the time the 'A''s request is handled, the 'B''s browser window
freezes and waits for those number of seconds mentioned above.

We searched really a lot, but still the results are not what we would
expect. This issue makes as confused, because in the future the application
should serve hundreds of users with very similar combinations of requests.

We didn't know, where our problem lies, so we tried a similar test with a
single page with a difficult calculation inside. Then we tried the same in
Pharo to exclude the problem in VAST. Both with the same results.

Is there anything we are missing? What should we do to achieve a parallel
(or kinda better) processing of requests?

Thank you very much for your responses.

Ondrej



--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Benoit St-Jean
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Benoit St-Jean
One more thing to check : could it be possible that your query is getting blocked because of lock escalation?  Which isolation level are you using?
 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth

Blogue: endormitoire.wordpress.com

"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

From: Sebastian Sastre <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Tuesday, March 10, 2015 11:57 AM
Subject: Re: [Seaside] Concurrent requests from multiple sessions

Hi Ondrej,

are you using an ODBC connection? What comes to mind is to check if maybe the FFI call to ODBC or whatever driver you are using to get into DB2 is blocking the VM running that image until it gets the answer.

Whatever the case, you seem to need to scale your app horizonatally with many images.

At least that’s how I do it.

Other than that, there is something that you probably don’t want to even hear about but for what’s worth: a REST backend and a single page application scales really well due to clients’ CPU dividing load and RESTful backends having way better parallelisation

sebastian

o/

LinkedIn: http://www.linkedin.com/in/sebastiansastre
github: https://github.com/sebastianconcept







On Mar 6, 2015, at 7:17 AM, wilwarin <[hidden email]> wrote:

Hi all,

Currently we are developing a web application in Seaside, and it is
necessary for us to work in VAST. The application runs as a Windows service,
and for a few days we are facing the following issue:

- At one moment there are two users (let's call them 'A' and 'B') logged in
in the application, so we have two different sessions.
- 'A' requests a page with a long list of objects obtained from DB2, so it
takes a number of seconds to get the results.
- Less than one second after 'A''s request, 'B' requests another page, for
instance an easy static page.
- For the time the 'A''s request is handled, the 'B''s browser window
freezes and waits for those number of seconds mentioned above.

We searched really a lot, but still the results are not what we would
expect. This issue makes as confused, because in the future the application
should serve hundreds of users with very similar combinations of requests.

We didn't know, where our problem lies, so we tried a similar test with a
single page with a difficult calculation inside. Then we tried the same in
Pharo to exclude the problem in VAST. Both with the same results.

Is there anything we are missing? What should we do to achieve a parallel
(or kinda better) processing of requests?

Thank you very much for your responses.

Ondrej



--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
wilwarin
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

wilwarin
In reply to this post by Bob Arning-2
Hi Bob,

> BTW, did you include some code in your message? I didn't see any if you did.

yes I did. Sorry, I made it a raw text and didn't know somebody won't be able to see it. Let me share the code once more (no DB call inside):

1) getResult

        | result |
       
        startTime := Time now asString.
        result := "<DO SOME MATH>".
        finishTime := Time now asString.
       
        ^ result.

2) renderContentOn: html

        html div: [
                html anchor
                        callback: [ self getResult. ];
                        with: 'Click me!'.
        ].
       
        html div: 'Start: ', startTime.
        html div: 'Finish: ', finishTime.

Guys, I really appreciate ideas you share. Thank you.

Cheers.
Ondrej
Philippe Marschall
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Philippe Marschall
In reply to this post by Nowak, Helge
On Tue, Mar 10, 2015 at 12:31 PM, Nowak, Helge <[hidden email]> wrote:
> Hmm,
>
> I am sure Ondrej understood what was proposed. He mentioned at least twice that the DB connections are NOT the problem. He said that the processing AFTER loading the data from the database into the image is the problem. Why shouldn't I believe him? OTOH I believe you Seaside experts that Seaside's architecture is inherently non-blocking between sessions.
>
> Thus there are two questions:
> - how could any processing block the whole Seaside image?

#valueUnpreemptively? Certain C call outs?

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Philippe Marschall
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Philippe Marschall
In reply to this post by wilwarin
On Tue, Mar 10, 2015 at 2:25 PM, wilwarin <[hidden email]> wrote:
> --- BTW: ---
>> Your rendering method is just for painting the current state of your
>> component, it shouldn’t be concerned with changing that state.
>
> So, when somebody does some data processing during the rendering, it will
> cause this problem?
> -------------

You shouldn't change component state in the render phase, you should
change component state only in the callback phase. Doing database
access for display in the render phase is fine from a Seaside
perspective.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Arning-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Bob Arning-2
In reply to this post by wilwarin
So, did your previous message indicate that this was still causing a problem in VAST? And the problem is when your "DO SOME MATH" is running, other requests to Seaside are not processed quickly/at all?

I've written your example as a single method (best way IMO to share a problem - if at all possible) and tested it in Squeak Seaside. When the "DO SOME MATH" is running, processing of other request to Seaside are delayed, perhaps as much as 1 second. How does this compare to your experience in VAST and Pharo?

renderContentOn: html

    | t0 |
   
    html div: [
        html anchor
            callback: [
                "self getResult."
                startTime := Time now asString.
                 "<DO SOME MATH>".
                t0 := Time millisecondClockValue.
                [(t0 - Time millisecondClockValue) abs < 30000] whileTrue.
                finishTime := Time now asString.
            ];
            with: 'Click me!'.
    ].
   
    html div: 'Start: ', startTime.
    html div: 'Finish: ', finishTime.



On 3/11/15 2:36 AM, wilwarin wrote:
Hi Bob,


BTW, did you include some code in your message? I didn't see any if you
did.

yes I did. Sorry, I made it a raw text and didn't know somebody won't be
able to see it. Let me share the code once more (no DB call inside):

1) getResult

	| result |
	
	startTime := Time now asString.
	result := "<DO SOME MATH>".
	finishTime := Time now asString.
	
	^ result.

2) renderContentOn: html

	html div: [
		html anchor
			callback: [ self getResult. ];
			with: 'Click me!'.
	].
	
	html div: 'Start: ', startTime.
	html div: 'Finish: ', finishTime.

Guys, I really appreciate ideas you share. Thank you.

Cheers.
Ondrej



--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929p4811143.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
wilwarin
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

wilwarin
Thank you very much, Bob.

> So, did your previous message indicate that this was still causing
> a problem in VAST? And the problem is when your "DO SOME MATH"
> is running, other requests to Seaside are not processed quickly/at all?

Yes, exactly. They are not processed at all.

> How does this compare to your experience in VAST and Pharo?

In case of Pharo, my experience is similar with yours (cca. 1 second delay). In case of VAST, I can see the time of start of the second request is equal to the time of finish of the first one.

Bob Arning-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Bob Arning-2
So, it would be interesting to run a version of something I posted yesterday:

    | nums procs big |
   
    nums := OrderedCollection new.
    big := OrderedCollection new.
    procs := (1 to: 3) collect: [ : i |
        nums add: 0.
        [
            10 timesRepeat: [
                [10000 factorial] timeToRun.
                nums at: i put: (nums at: i) + 1.
                big add: nums asArray asString,' ',Time now asString.
            ].
        ].
    ].
    procs do: [ : e | e forkAt: Processor userBackgroundPriority].
    big inspect

Three processes at the same priority - on Squeak and Pharo, time gets shared between the three somewhat equally. What happens in VAST?

contents of "big" in Squeak:

(0 0 1) 9:11:58.022 am
(0 1 1) 9:11:58.053 am
(1 1 1) 9:11:58.388 am
(1 1 2) 9:11:58.974 am
(2 1 2) 9:11:59.06 am
(2 2 2) 9:11:59.078 am
(2 2 3) 9:11:59.71 am
(3 2 3) 9:12:00.044 am
(3 3 3) 9:12:00.06 am
(3 3 4) 9:12:00.625 am
(4 3 4) 9:12:00.663 am
(4 4 4) 9:12:00.739 am
(5 4 4) 9:12:01.274 am
(5 4 5) 9:12:01.57 am
(5 5 5) 9:12:01.657 am
(5 5 6) 9:12:02.135 am
(6 5 6) 9:12:02.216 am
(6 6 6) 9:12:02.252 am
(6 7 6) 9:12:02.88 am
(6 7 7) 9:12:03.436 am
(7 7 7) 9:12:03.575 am
(7 8 7) 9:12:03.66 am
(7 8 8) 9:12:04.082 am
(8 8 8) 9:12:04.158 am
(8 9 8) 9:12:04.237 am
(8 9 9) 9:12:04.975 am
(9 9 9) 9:12:05.104 am
(9 10 9) 9:12:05.127 am
(9 10 10) 9:12:05.457 am
(10 10 10) 9:12:05.472 am


On 3/11/15 8:54 AM, wilwarin wrote:
Thank you very much, Bob.


So, did your previous message indicate that this was still causing 
a problem in VAST? And the problem is when your "DO SOME MATH" 
is running, other requests to Seaside are not processed quickly/at all? 

Yes, exactly. They are not processed at all.


How does this compare to your experience in VAST and Pharo?

In case of Pharo, my experience is similar with yours (cca. 1 second delay).
In case of VAST, I can see the time of start of the second request is equal
to the time of finish of the first one.





--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929p4811195.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
wilwarin
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

wilwarin
> What happens in VAST?

I tried it in Workspace (but 10000! caused a stack overflow, so I used 1000!). The result follows:

(0 0 1) 14:36:43.923
(0 0 2) 14:36:43.932
(0 0 3) 14:36:43.940
(0 0 4) 14:36:43.947
(0 0 5) 14:36:43.952
(0 0 6) 14:36:43.957
(0 0 7) 14:36:43.962
(0 0 8) 14:36:43.967
(0 0 9) 14:36:43.972
(0 0 10) 14:36:43.976
(0 1 10) 14:36:43.980
(0 2 10) 14:36:43.985
(0 3 10) 14:36:43.989
(0 4 10) 14:36:43.993
(0 5 10) 14:36:43.997
(0 6 10) 14:36:44.1
(0 7 10) 14:36:44.4
(0 8 10) 14:36:44.8
(0 9 10) 14:36:44.12
(0 10 10) 14:36:44.16
(1 10 10) 14:36:44.20
(2 10 10) 14:36:44.23
(3 10 10) 14:36:44.27
(4 10 10) 14:36:44.31
(5 10 10) 14:36:44.35
(6 10 10) 14:36:44.39
(7 10 10) 14:36:44.42
(8 10 10) 14:36:44.46
(9 10 10) 14:36:44.50
(10 10 10) 14:36:44.54
Bob Arning-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Concurrent requests from multiple sessions

Bob Arning-2
Just to be sure that we are wasting enough time, you might want to make that

    100 timesRepeat: [1000!]

But assuming that makes no difference:

So that's the issue. Squeak and Pharo rotate the order of processes at a given priority whenever one is interrupted by a higher priority process. VAST appears not to do that (or there are no higher priority process running...). IOW,

Squeak and Pharo offer a Poor Man's Time Slicing, although with no guarantee that the slices are equal in width.
VAST offers what seems to ensure a process will not be pre-empted by another process at the same priority (which has a certain logical appeal ;-) ).

Not having access to VAST, I can't tell you if this difference is accidental or intentional. Perhaps someone know a bit more...

On 3/11/15 9:36 AM, wilwarin wrote:
What happens in VAST?

I tried it in Workspace (but 10000! caused a stack overflow, so I used
1000!). The result follows:

(0 0 1) 14:36:43.923
(0 0 2) 14:36:43.932
(0 0 3) 14:36:43.940
(0 0 4) 14:36:43.947
(0 0 5) 14:36:43.952
(0 0 6) 14:36:43.957
(0 0 7) 14:36:43.962
(0 0 8) 14:36:43.967
(0 0 9) 14:36:43.972
(0 0 10) 14:36:43.976
(0 1 10) 14:36:43.980
(0 2 10) 14:36:43.985
(0 3 10) 14:36:43.989
(0 4 10) 14:36:43.993
(0 5 10) 14:36:43.997
(0 6 10) 14:36:44.1
(0 7 10) 14:36:44.4
(0 8 10) 14:36:44.8
(0 9 10) 14:36:44.12
(0 10 10) 14:36:44.16
(1 10 10) 14:36:44.20
(2 10 10) 14:36:44.23
(3 10 10) 14:36:44.27
(4 10 10) 14:36:44.31
(5 10 10) 14:36:44.35
(6 10 10) 14:36:44.39
(7 10 10) 14:36:44.42
(8 10 10) 14:36:44.46
(9 10 10) 14:36:44.50
(10 10 10) 14:36:44.54




--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929p4811210.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Nowak, Helge
Reply | Threaded
Open this post in threaded view
♦
♦
|

AW: [Seaside] Re: Concurrent requests from multiple sessions

Nowak, Helge

I don’t know VAST, yet in VisualWorks you can call “Processor yield“ in your process which will give way to other processes. By that you’ll get a simple “parallel” execution of your processes.

 

HTH

Helge

 

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Bob Arning
Gesendet: Mittwoch, 11. März 2015 15:04
An: [hidden email]
Betreff: Re: [Seaside] Re: Concurrent requests from multiple sessions

 

Just to be sure that we are wasting enough time, you might want to make that

    100 timesRepeat: [1000!]

But assuming that makes no difference:

So that's the issue. Squeak and Pharo rotate the order of processes at a given priority whenever one is interrupted by a higher priority process. VAST appears not to do that (or there are no higher priority process running...). IOW,

Squeak and Pharo offer a Poor Man's Time Slicing, although with no guarantee that the slices are equal in width.
VAST offers what seems to ensure a process will not be pre-empted by another process at the same priority (which has a certain logical appeal ;-) ).

Not having access to VAST, I can't tell you if this difference is accidental or intentional. Perhaps someone know a bit more...

On 3/11/15 9:36 AM, wilwarin wrote:

What happens in VAST?
 
I tried it in Workspace (but 10000! caused a stack overflow, so I used
1000!). The result follows:
 
(0 0 1) 14:36:43.923
(0 0 2) 14:36:43.932
(0 0 3) 14:36:43.940
(0 0 4) 14:36:43.947
(0 0 5) 14:36:43.952
(0 0 6) 14:36:43.957
(0 0 7) 14:36:43.962
(0 0 8) 14:36:43.967
(0 0 9) 14:36:43.972
(0 0 10) 14:36:43.976
(0 1 10) 14:36:43.980
(0 2 10) 14:36:43.985
(0 3 10) 14:36:43.989
(0 4 10) 14:36:43.993
(0 5 10) 14:36:43.997
(0 6 10) 14:36:44.1
(0 7 10) 14:36:44.4
(0 8 10) 14:36:44.8
(0 9 10) 14:36:44.12
(0 10 10) 14:36:44.16
(1 10 10) 14:36:44.20
(2 10 10) 14:36:44.23
(3 10 10) 14:36:44.27
(4 10 10) 14:36:44.31
(5 10 10) 14:36:44.35
(6 10 10) 14:36:44.39
(7 10 10) 14:36:44.42
(8 10 10) 14:36:44.46
(9 10 10) 14:36:44.50
(10 10 10) 14:36:44.54
 
 
 
 
--
View this message in context: http://forum.world.st/Concurrent-requests-from-multiple-sessions-tp4809929p4811210.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
 

 


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Louis LaBrunda
Reply | Threaded
Open this post in threaded view
♦
♦
|

Concurrent requests from multiple sessions

Louis LaBrunda
Hi Guys,

I know VAST pretty well but this is an area few people delve into and I
haven't looked at it for a while.  That said, I think VAST ask the OS for
an interrupt every 100 milliseconds.  At which time it readies any
processes that are no longer delayed and dispatches the highest priority
process.  As far as I can tell it does this without reordering processes of
the same priority.  So the interrupted process will resume if it is still
the highest priority process.

This is why I suggested earlier to either drop the priority of a process
when it is engaged in heavy CPU usage and/or call "Processor yield" to let
the next guy run for a while.  Priorities range from 1 to 7.  I think you
will normally be at userSchedulingPriority - 3 and can drop to
userBackgroundPriority - 2 with:

self activeProcess priority: Processor userBackgroundPriority.

and back with:

self activeProcess priority: Processor userSchedulingPriority.

The change in priority will take effect at the next interrupt.  I think you
can just put the above calls at the beginning and end of any heavy CPU
work.  The key word being "heavy", you don't want to wrap everything or
your just running it all at a lower priority.  If you can do this right you
will have a high priority for short running things and a low priority for
long running things.

You should double check what priority Seaside is running sessions at.

If you can find a convenient spot or spots that will break up the heavy
processing in the middle (one or more middles) then calling Processor yield
will give you a round robin effect.

Good luck and feel free to ask more questions.  You might also post this
question at: https://groups.google.com/forum/#!forum/va-smalltalk.

Lou


On Wed, 11 Mar 2015 14:15:39 +0000, "Nowak, Helge" <[hidden email]>
wrote:

>I don't know VAST, yet in VisualWorks you can call "Processor yield" in your process which will give way to other processes. By that you'll get a simple "parallel" execution of your processes.
>
>HTH
>Helge
>
>Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Bob Arning
>Gesendet: Mittwoch, 11. März 2015 15:04
>An: [hidden email]
>Betreff: Re: [Seaside] Re: Concurrent requests from multiple sessions
>
>Just to be sure that we are wasting enough time, you might want to make that
>
>    100 timesRepeat: [1000!]
>
>But assuming that makes no difference:
>
>So that's the issue. Squeak and Pharo rotate the order of processes at a given priority whenever one is interrupted by a higher priority process. VAST appears not to do that (or there are no higher priority process running...). IOW,
>
>Squeak and Pharo offer a Poor Man's Time Slicing, although with no guarantee that the slices are equal in width.
>VAST offers what seems to ensure a process will not be pre-empted by another process at the same priority (which has a certain logical appeal ;-) ).
>
>Not having access to VAST, I can't tell you if this difference is accidental or intentional. Perhaps someone know a bit more...
>On 3/11/15 9:36 AM, wilwarin wrote:
>
>What happens in VAST?
>
>
>
>I tried it in Workspace (but 10000! caused a stack overflow, so I used
>
>1000!). The result follows:
>
>
>
>(0 0 1) 14:36:43.923
>
>(0 0 2) 14:36:43.932
>
>(0 0 3) 14:36:43.940
>
>(0 0 4) 14:36:43.947
>
>(0 0 5) 14:36:43.952
>
>(0 0 6) 14:36:43.957
>
>(0 0 7) 14:36:43.962
>
>(0 0 8) 14:36:43.967
>
>(0 0 9) 14:36:43.972
>
>(0 0 10) 14:36:43.976
>
>(0 1 10) 14:36:43.980
>
>(0 2 10) 14:36:43.985
>
>(0 3 10) 14:36:43.989
>
>(0 4 10) 14:36:43.993
>
>(0 5 10) 14:36:43.997
>
>(0 6 10) 14:36:44.1
>
>(0 7 10) 14:36:44.4
>
>(0 8 10) 14:36:44.8
>
>(0 9 10) 14:36:44.12
>
>(0 10 10) 14:36:44.16
>
>(1 10 10) 14:36:44.20
>
>(2 10 10) 14:36:44.23
>
>(3 10 10) 14:36:44.27
>
>(4 10 10) 14:36:44.31
>
>(5 10 10) 14:36:44.35
>
>(6 10 10) 14:36:44.39
>
>(7 10 10) 14:36:44.42
>
>(8 10 10) 14:36:44.46
>
>(9 10 10) 14:36:44.50
>
>(10 10 10) 14:36:44.54
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12
Free forum by Nabble Edit this page