Concurrency in Pharo?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Concurrency in Pharo?

Andrei Stebakov
I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo.
I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems. 
For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core?
Is Pharo a right tool for that?
Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue...

Thank you,
Andrei

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Mariano Martinez Peck
This is a good question. I don't have experience by myself but I can tell you what I think it is usually done:

1) For one CPU:
 
If the image don't need to be saved (no need of in image persistence) you can take the same VM and load N number of images running at the same .image. You can even not use .changes and .sources. Each image in different port. Then, you have in front of them a web server (Apache or friends) and you do load balance. The only thing you should take care with Seaside is to have AFFINITY -> the same client should go always to the same image while a conversation occurs. This is just a web-server setting.

2) For multiple core, I am thinking, maybe I am wrong, you may be able to load different vms. For assigning each VM to a particular CPU. I don't know windows, but in Linux (maybe I am wrong) I think you can specify where to exclusively run a process. The, for each VM you do 1).
Do you know if this can work?

Finally, there are different VM that aim not necessary multiple CPU but similar:

- COG VM
- Hydra

I cc'ed may developers of them so that they can help you.

Cheers

Mariano


2010/5/24 Andrei Stebakov <[hidden email]>
I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo.
I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems. 
For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core?
Is Pharo a right tool for that?
Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue...

Thank you,
Andrei

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Dale Henrichs
Andrei,

GemStone/S and GLASS provides a free for commercial use multi-vm
environment that provides "image-based persistence". With an annual
license you can use multiple vms across multiple cores.

A number of folks using GemStone develop in Pharo and deploy in
GemStone, so that mode of operation is realistic...

Dale

Mariano Martinez Peck wrote:

> This is a good question. I don't have experience by myself but I can tell you what I think it is usually done:
>
> 1) For one CPU:
>
> If the image don't need to be saved (no need of in image persistence) you can take the same VM and load N number of images running at the same .image. You can even not use .changes and .sources. Each image in different port. Then, you have in front of them a web server (Apache or friends) and you do load balance. The only thing you should take care with Seaside is to have AFFINITY -> the same client should go always to the same image while a conversation occurs. This is just a web-server setting.
>
> 2) For multiple core, I am thinking, maybe I am wrong, you may be able to load different vms. For assigning each VM to a particular CPU. I don't know windows, but in Linux (maybe I am wrong) I think you can specify where to exclusively run a process. The, for each VM you do 1).
> Do you know if this can work?
>
> Finally, there are different VM that aim not necessary multiple CPU but similar:
>
> - COG VM
> - Hydra
>
> I cc'ed may developers of them so that they can help you.
>
> Cheers
>
> Mariano
>
>
> 2010/5/24 Andrei Stebakov <[hidden email]<mailto:[hidden email]>>
> I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo.
> I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems.
> For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core?
> Is Pharo a right tool for that?
> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue...
>
> Thank you,
> Andrei
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]<mailto:[hidden email]>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Lukas Renggli
In reply to this post by Andrei Stebakov
> I've been really impressed with what Seaside and Pier were capable of and
> really wanted to start my new web project with Pharo.

GemStone/S runs Seaside and Pier and scales across multiple CPUs
infinitely, if scalability with Pharo should be a problem.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Stéphane Ducasse
In reply to this post by Andrei Stebakov
you know dabbledb, cmsbox and other are all based on squeak/pharo so you heart does not have to sink yet :)


Stef

On May 24, 2010, at 8:36 PM, Andrei Stebakov wrote:

> I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo.
> I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems.
> For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core?
> Is Pharo a right tool for that?
> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue...
>
> Thank you,
> Andrei
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Igor Stasenko
In reply to this post by Mariano Martinez Peck
On 24 May 2010 21:47, Mariano Martinez Peck <[hidden email]> wrote:

> This is a good question. I don't have experience by myself but I can tell
> you what I think it is usually done:
>
> 1) For one CPU:
>
> If the image don't need to be saved (no need of in image persistence) you
> can take the same VM and load N number of images running at the same .image.
> You can even not use .changes and .sources. Each image in different port.
> Then, you have in front of them a web server (Apache or friends) and you do
> load balance. The only thing you should take care with Seaside is to have
> AFFINITY -> the same client should go always to the same image while a
> conversation occurs. This is just a web-server setting.
>
> 2) For multiple core, I am thinking, maybe I am wrong, you may be able to
> load different vms. For assigning each VM to a particular CPU. I don't know
> windows, but in Linux (maybe I am wrong) I think you can specify where to
> exclusively run a process. The, for each VM you do 1).
> Do you know if this can work?
>

3) write a good code, so it could handle things well without need of
so much horsepower :)

> Finally, there are different VM that aim not necessary multiple CPU but
> similar:
>
> - COG VM
> - Hydra
>
> I cc'ed may developers of them so that they can help you.
>
> Cheers
>
> Mariano
>
>
> 2010/5/24 Andrei Stebakov <[hidden email]>
>>
>> I've been really impressed with what Seaside and Pier were capable of and
>> really wanted to start my new web project with Pharo.
>> I learned that Pharo (and most other open source ST implementations) only
>> use green threads, having no ability to use a multi-core CPU systems.
>> For those of you with experience building mid to heavy load web sites, how
>> do you expect them to scale up on using just one core?
>> Is Pharo a right tool for that?
>> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
>> heart really sank when I learned about this issue...
>> Thank you,
>> Andrei
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency in Pharo?

Adrian Lienhard
In reply to this post by Mariano Martinez Peck
Hi Andrei,

1) is what most do (at least what we do at netstyle.ch for apps that can have higher loads). The following blog post is a nice writeup from Ramon Leon describing how to implement such a system:

http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing

HTH,
Adrian

On May 24, 2010, at 20:47 , Mariano Martinez Peck wrote:

> This is a good question. I don't have experience by myself but I can tell
> you what I think it is usually done:
>
> 1) For one CPU:
>
> If the image don't need to be saved (no need of in image persistence) you
> can take the same VM and load N number of images running at the same .image.
> You can even not use .changes and .sources. Each image in different port.
> Then, you have in front of them a web server (Apache or friends) and you do
> load balance. The only thing you should take care with Seaside is to have
> AFFINITY -> the same client should go always to the same image while a
> conversation occurs. This is just a web-server setting.
>
> 2) For multiple core, I am thinking, maybe I am wrong, you may be able to
> load different vms. For assigning each VM to a particular CPU. I don't know
> windows, but in Linux (maybe I am wrong) I think you can specify where to
> exclusively run a process. The, for each VM you do 1).
> Do you know if this can work?
>
> Finally, there are different VM that aim not necessary multiple CPU but
> similar:
>
> - COG VM
> - Hydra
>
> I cc'ed may developers of them so that they can help you.
>
> Cheers
>
> Mariano
>
>
> 2010/5/24 Andrei Stebakov <[hidden email]>
>
>> I've been really impressed with what Seaside and Pier were capable of and
>> really wanted to start my new web project with Pharo.
>> I learned that Pharo (and most other open source ST implementations) only
>> use green threads, having no ability to use a multi-core CPU systems.
>> For those of you with experience building mid to heavy load web sites, how
>> do you expect them to scale up on using just one core?
>> Is Pharo a right tool for that?
>> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my
>> heart really sank when I learned about this issue...
>>
>> Thank you,
>> Andrei
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project