Mac Image Broken?
Locked
 
|
Hi All,
I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: 1) The image runs 'hot' at 10% CPU. 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). T. Ted Wrinch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Ted,
This definitively should not happen. So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ? If I would have to guess, maybe this has something to do with networking (dns). Sven On 12 Jul 2011, at 21:52, Ted Wrinch wrote: > Hi All, > > I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: > > 1) The image runs 'hot' at 10% CPU. > > 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. > > None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). > > T. > > Ted Wrinch > > > > > _______________________________________________ > 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 |
|
|
Hi Sven,
It was the one-click, all in image from the Seaside site: see the link '' 'Seaside One-Click Experience 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. The VM is part of the one-click and I believe is the 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it is as the Mac thinks it's a text file, and not a Unix binary or shell script. The ab command was 'ab -c50 -n1000 "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting 400 packets or so. I think that the use of the loop back address means that it can't be using DNS. My guess, from some of the older list comments, was that perhaps this VM is still built using polling for events, rather than handling them on interrupts, which could explain packet loss and suggest an inefficient UI loop. T.
Ted Wrinch
On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Ted,
I quickly tested on my own main image (Pharo 1.2.2 + Seaside 3.0.3 + Cogit VM), using the ZnZincServerAdaptor (because I know that one best). The problem is the high concurrency level of benchmark combined with the backlog size of the server socket. Try lower numbers for -c, like 10 or 20. For Zinc, the default backlog size for the server socket is 32 (ZnNetworkingUtils class>>#listenBacklogSize). So here, -c 30 works, -c 40 breaks after a couple of hundreds of requests. For other servers, I don't now the default backlog size (or the backlog size when none is specified, which might be platform/vm/os dependent). I imagine that raising the limit above 50, will make your -c 50 pass. I terms of performance, I get numbers in the 70 to 150 reqs/s range. My image stays stable. HTH, Sven PS: Currently, #listenBacklogSize is not a settable parameter, but I could change that in Zn. On 13 Jul 2011, at 13:18, Ted Wrinch wrote: > Hi Sven, > > It was the one-click, all in image from the Seaside site: see the link '' 'Seaside One-Click Experience 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. The VM is part of the one-click and I believe is the 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it is as the Mac thinks it's a text file, and not a Unix binary or shell script. The ab command was 'ab -c50 -n1000 "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting 400 packets or so. I think that the use of the loop back address means that it can't be using DNS. My guess, from some of the older list comments, was that perhaps this VM is still built using polling for events, rather than handling them on interrupts, which could explain packet loss and suggest an inefficient UI loop. > > T. > > Ted Wrinch > > > > > On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote: > >> Hi Ted, >> >> This definitively should not happen. >> >> So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ? >> >> If I would have to guess, maybe this has something to do with networking (dns). >> >> Sven >> >> On 12 Jul 2011, at 21:52, Ted Wrinch wrote: >> >>> Hi All, >>> >>> I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: >>> >>> 1) The image runs 'hot' at 10% CPU. >>> >>> 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. >>> >>> None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). >>> >>> T. >>> >>> Ted Wrinch >>> >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks Sven,
I know it's high concurrency: I'm testing for high load, 'worst case' scenarios :). So you are saying that the listener packet queue is overflowing? And the fix is to increase that. That could explain a lot and I'll poke around and see if the Comanche value for this can be changed. But my guess is that it's buried in the VM somewhere/somehow, as otherwise how would Comanche work in Windows? Perhaps the solution is for me to switch to Zinc? I don't mind either way and your 70-150 requests ps sounds rather good! T. Ted Wrinch On 13 Jul 2011, at 12:47, Sven Van Caekenberghe wrote: > Hi Ted, > > I quickly tested on my own main image (Pharo 1.2.2 + Seaside 3.0.3 + Cogit VM), using the ZnZincServerAdaptor (because I know that one best). The problem is the high concurrency level of benchmark combined with the backlog size of the server socket. > > Try lower numbers for -c, like 10 or 20. > > For Zinc, the default backlog size for the server socket is 32 (ZnNetworkingUtils class>>#listenBacklogSize). So here, -c 30 works, -c 40 breaks after a couple of hundreds of requests. For other servers, I don't now the default backlog size (or the backlog size when none is specified, which might be platform/vm/os dependent). > > I imagine that raising the limit above 50, will make your -c 50 pass. > > I terms of performance, I get numbers in the 70 to 150 reqs/s range. My image stays stable. > > HTH, > > Sven > > PS: Currently, #listenBacklogSize is not a settable parameter, but I could change that in Zn. > > > On 13 Jul 2011, at 13:18, Ted Wrinch wrote: > >> Hi Sven, >> >> It was the one-click, all in image from the Seaside site: see the link '' 'Seaside One-Click Experience 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. The VM is part of the one-click and I believe is the 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it is as the Mac thinks it's a text file, and not a Unix binary or shell script. The ab command was 'ab -c50 -n1000 "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting 400 packets or so. I think that the use of the loop back address means that it can't be using DNS. My guess, from some of the older list comments, was that perhaps this VM is still built using polling for events, rather than handling them on interrupts, which could explain packet loss and suggest an inefficient UI loop. >> >> T. >> >> Ted Wrinch >> >> >> >> >> On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote: >> >>> Hi Ted, >>> >>> This definitively should not happen. >>> >>> So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ? >>> >>> If I would have to guess, maybe this has something to do with networking (dns). >>> >>> Sven >>> >>> On 12 Jul 2011, at 21:52, Ted Wrinch wrote: >>> >>>> Hi All, >>>> >>>> I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: >>>> >>>> 1) The image runs 'hot' at 10% CPU. >>>> >>>> 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. >>>> >>>> None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). >>>> >>>> T. >>>> >>>> Ted Wrinch >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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 |
|
|
Ted,
On 13 Jul 2011, at 16:11, Ted Wrinch wrote: > Thanks Sven, You're welcome. > I know it's high concurrency: I'm testing for high load, 'worst case' scenarios :). You are probably looking for some kind of confirmation that Smalltalk/Seaside can handle the load ? It can, but for most production systems that get some serious load, you will need to do more: put some (reverse) proxy in front of the site, handle static content directly and load balance (with sticky sessions) over several Seaside images, use caching where needed. This has been done before (and it is similar to what needs to be done for other popular stacks like RoR). Also beware that simply benchmarking Seaside with ab is misleading: Seaside has quite complex and heavy session management, it uses redirects, all requests have a different URL, ... FYI, to get an idea of the absolute maximum speed at which a single Pharo could server small static HTTP requests with keepalive, check this http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037875.html Yes, +2000 req/s is actually possible, but you'll never get that for a real application ;-) > So you are saying that the listener packet queue is overflowing? And the fix is to increase that. That could explain a lot and I'll poke around and see if the Comanche value for this can be changed. But my guess is that it's buried in the VM somewhere/somehow, as otherwise how would Comanche work in Windows? Perhaps the solution is for me to switch to Zinc? I don't mind either way and your 70-150 requests ps sounds rather good! I think Comanche is using 10, but I am not sure (TcpListener class>>backlogSize). But that would not explain why it works on Windows ;-) Zinc is just an option, of which I know the internals a lot better. It is included by default in Pharo 1.3 and higher. Regards, Sven > T. > > Ted Wrinch > > > > > On 13 Jul 2011, at 12:47, Sven Van Caekenberghe wrote: > >> Hi Ted, >> >> I quickly tested on my own main image (Pharo 1.2.2 + Seaside 3.0.3 + Cogit VM), using the ZnZincServerAdaptor (because I know that one best). The problem is the high concurrency level of benchmark combined with the backlog size of the server socket. >> >> Try lower numbers for -c, like 10 or 20. >> >> For Zinc, the default backlog size for the server socket is 32 (ZnNetworkingUtils class>>#listenBacklogSize). So here, -c 30 works, -c 40 breaks after a couple of hundreds of requests. For other servers, I don't now the default backlog size (or the backlog size when none is specified, which might be platform/vm/os dependent). >> >> I imagine that raising the limit above 50, will make your -c 50 pass. >> >> I terms of performance, I get numbers in the 70 to 150 reqs/s range. My image stays stable. >> >> HTH, >> >> Sven >> >> PS: Currently, #listenBacklogSize is not a settable parameter, but I could change that in Zn. >> >> >> On 13 Jul 2011, at 13:18, Ted Wrinch wrote: >> >>> Hi Sven, >>> >>> It was the one-click, all in image from the Seaside site: see the link '' 'Seaside One-Click Experience 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. The VM is part of the one-click and I believe is the 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it is as the Mac thinks it's a text file, and not a Unix binary or shell script. The ab command was 'ab -c50 -n1000 "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting 400 packets or so. I think that the use of the loop back address means that it can't be using DNS. My guess, from some of the older list comments, was that perhaps this VM is still built using polling for events, rather than handling them on interrupts, which could explain packet loss and suggest an inefficient UI loop. >>> >>> T. >>> >>> Ted Wrinch >>> >>> >>> >>> >>> On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote: >>> >>>> Hi Ted, >>>> >>>> This definitively should not happen. >>>> >>>> So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ? >>>> >>>> If I would have to guess, maybe this has something to do with networking (dns). >>>> >>>> Sven >>>> >>>> On 12 Jul 2011, at 21:52, Ted Wrinch wrote: >>>> >>>>> Hi All, >>>>> >>>>> I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: >>>>> >>>>> 1) The image runs 'hot' at 10% CPU. >>>>> >>>>> 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. >>>>> >>>>> None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). >>>>> >>>>> T. >>>>> >>>>> Ted Wrinch >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 |
|
|
Morning Sven,
I am looking to check for load capability, yes. And that's a v. impressive figure! I was able to get my C# MVC app, serving 1k of static page data and running under IIS Express (a slightly disabled version of the full IIS - so v. fast), to run no faster. But you're right about real world usage and as soon as I added in the instantiation of 20 objects from the dbase and the serving of a mixed static/dynamic 2.5k page the performance dropped to a less impressive 35 per second. I'm currently coding up this small prototype into Seaside and Magma and am hoping to get something similar in performance (with a much nicer dev environment :)). I understand your point about the artificiality of my ab testing but it was simple to do and provided a nice, starting benchmark. I've read around the production issues, as well as bought a PDF copy of the book (v.nicely done BTW), and was aware of the issues you mention (but thanks for thinking of me). I've found Ramon Leon's work with re-write rules and port pools v. interesting (he doesn't actually use the Apache load balancing mod at all) and would like to try something like this for our environment. Spot on! I set backlogSize to 100, saved the image, re-started and re-benchmarked to get a figure of 200 (and that's serving an 8k or so dynamic page)! My machine is a 2 year old 1.86 Core 2 Duo MacBook Air with SSD. But this rate progressively drops on re-runs, and the image size goes up by 10M a run - maybe fixing the image memory limit would help prevent this drop in performance (they recommend 250M in the book)? I wonder if it's ok to leave backlog at this size. And we're still left wondering how Windows works (BTW: I was running in Parallels for my Windows tests, which might help explain the slower throughput). When you said in an earlier post that your image ran stable did you mean that it doesn't use CPU when sitting idle? I am still a little concerned that mine uses 10% (even the latest Pharo uses 8%) and it crunches through my battery when I'm away from mains. T. Ted Wrinch On 13 Jul 2011, at 16:00, Sven Van Caekenberghe wrote: > Ted, > > On 13 Jul 2011, at 16:11, Ted Wrinch wrote: > >> Thanks Sven, > > You're welcome. > >> I know it's high concurrency: I'm testing for high load, 'worst case' scenarios :). > > You are probably looking for some kind of confirmation that Smalltalk/Seaside can handle the load ? > > It can, but for most production systems that get some serious load, you will need to do more: put some (reverse) proxy in front of the site, handle static content directly and load balance (with sticky sessions) over several Seaside images, use caching where needed. This has been done before (and it is similar to what needs to be done for other popular stacks like RoR). > > Also beware that simply benchmarking Seaside with ab is misleading: Seaside has quite complex and heavy session management, it uses redirects, all requests have a different URL, ... > > FYI, to get an idea of the absolute maximum speed at which a single Pharo could server small static HTTP requests with keepalive, check this > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037875.html > > Yes, +2000 req/s is actually possible, but you'll never get that for a real application ;-) > >> So you are saying that the listener packet queue is overflowing? And the fix is to increase that. That could explain a lot and I'll poke around and see if the Comanche value for this can be changed. But my guess is that it's buried in the VM somewhere/somehow, as otherwise how would Comanche work in Windows? Perhaps the solution is for me to switch to Zinc? I don't mind either way and your 70-150 requests ps sounds rather good! > > I think Comanche is using 10, but I am not sure (TcpListener class>>backlogSize). > But that would not explain why it works on Windows ;-) > > Zinc is just an option, of which I know the internals a lot better. It is included by default in Pharo 1.3 and higher. > > Regards, > > Sven > >> T. >> >> Ted Wrinch >> >> >> >> >> On 13 Jul 2011, at 12:47, Sven Van Caekenberghe wrote: >> >>> Hi Ted, >>> >>> I quickly tested on my own main image (Pharo 1.2.2 + Seaside 3.0.3 + Cogit VM), using the ZnZincServerAdaptor (because I know that one best). The problem is the high concurrency level of benchmark combined with the backlog size of the server socket. >>> >>> Try lower numbers for -c, like 10 or 20. >>> >>> For Zinc, the default backlog size for the server socket is 32 (ZnNetworkingUtils class>>#listenBacklogSize). So here, -c 30 works, -c 40 breaks after a couple of hundreds of requests. For other servers, I don't now the default backlog size (or the backlog size when none is specified, which might be platform/vm/os dependent). >>> >>> I imagine that raising the limit above 50, will make your -c 50 pass. >>> >>> I terms of performance, I get numbers in the 70 to 150 reqs/s range. My image stays stable. >>> >>> HTH, >>> >>> Sven >>> >>> PS: Currently, #listenBacklogSize is not a settable parameter, but I could change that in Zn. >>> >>> >>> On 13 Jul 2011, at 13:18, Ted Wrinch wrote: >>> >>>> Hi Sven, >>>> >>>> It was the one-click, all in image from the Seaside site: see the link '' 'Seaside One-Click Experience 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. The VM is part of the one-click and I believe is the 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it is as the Mac thinks it's a text file, and not a Unix binary or shell script. The ab command was 'ab -c50 -n1000 "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting 400 packets or so. I think that the use of the loop back address means that it can't be using DNS. My guess, from some of the older list comments, was that perhaps this VM is still built using polling for events, rather than handling them on interrupts, which could explain packet loss and suggest an inefficient UI loop. >>>> >>>> T. >>>> >>>> Ted Wrinch >>>> >>>> >>>> >>>> >>>> On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote: >>>> >>>>> Hi Ted, >>>>> >>>>> This definitively should not happen. >>>>> >>>>> So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ? >>>>> >>>>> If I would have to guess, maybe this has something to do with networking (dns). >>>>> >>>>> Sven >>>>> >>>>> On 12 Jul 2011, at 21:52, Ted Wrinch wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that: >>>>>> >>>>>> 1) The image runs 'hot' at 10% CPU. >>>>>> >>>>>> 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up. >>>>>> >>>>>> None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!). >>>>>> >>>>>> T. >>>>>> >>>>>> Ted Wrinch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
'mixed static/dynamic page of 2.5k' should read '...of 25k'. Whoops. T. Ted Wrinch From my iPhone Begin forwarded message:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ted Wrinch
Ted,
On 14 Jul 2011, at 10:30, Ted Wrinch wrote: > Spot on! I set backlogSize to 100, saved the image, re-started and re-benchmarked to get a figure of 200 (and that's serving an 8k or so dynamic page)! My machine is a 2 year old 1.86 Core 2 Duo MacBook Air with SSD. But this rate progressively drops on re-runs, and the image size goes up by 10M a run - maybe fixing the image memory limit would help prevent this drop in performance (they recommend 250M in the book)? I wonder if it's ok to leave backlog at this size. And we're still left wondering how Windows works (BTW: I was running in Parallels for my Windows tests, which might help explain the slower throughput). Doing very large amounts of requests in a short amount of time generates very large amounts of garbage (of specific kinds). The garbage collection policy could be tuned. There is something called the SeasideGCPolicy floating around. This is more for servers in production use. Another thing is that sockets might get cleaned up in a delayed fashion using finalization. It all depends, it is a quite complex field (what your app really does also plays an important role). > When you said in an earlier post that your image ran stable did you mean that it doesn't use CPU when sitting idle? I am still a little concerned that mine uses 10% (even the latest Pharo uses 8%) and it crunches through my battery when I'm away from mains. An image is never completely idle, 5 to 10 % busy seems quite normal on my Mac. It seems a bit better on Linux. I would not worry about that too much. Sven_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks Sven,
That's helpful and I'll take a look at it. Anything like this I think will be v. useful if/when we go to production (still early days yet in the business's history). I'm still puzzled about that percentage. On my Parallels Windows session it seems much more efficient, using between 0 and 1% (mostly 0). I think I need to re-test the Windows VM outside the Parallels environment, perhaps on a dual boot... T. Ted Wrinch On 14 Jul 2011, at 16:08, Sven Van Caekenberghe wrote: > Ted, > > On 14 Jul 2011, at 10:30, Ted Wrinch wrote: > >> Spot on! I set backlogSize to 100, saved the image, re-started and re-benchmarked to get a figure of 200 (and that's serving an 8k or so dynamic page)! My machine is a 2 year old 1.86 Core 2 Duo MacBook Air with SSD. But this rate progressively drops on re-runs, and the image size goes up by 10M a run - maybe fixing the image memory limit would help prevent this drop in performance (they recommend 250M in the book)? I wonder if it's ok to leave backlog at this size. And we're still left wondering how Windows works (BTW: I was running in Parallels for my Windows tests, which might help explain the slower throughput). > > Doing very large amounts of requests in a short amount of time generates very large amounts of garbage (of specific kinds). The garbage collection policy could be tuned. There is something called the SeasideGCPolicy floating around. This is more for servers in production use. Another thing is that sockets might get cleaned up in a delayed fashion using finalization. > > It all depends, it is a quite complex field (what your app really does also plays an important role). > >> When you said in an earlier post that your image ran stable did you mean that it doesn't use CPU when sitting idle? I am still a little concerned that mine uses 10% (even the latest Pharo uses 8%) and it crunches through my battery when I'm away from mains. > > An image is never completely idle, 5 to 10 % busy seems quite normal on my Mac. It seems a bit better on Linux. I would not worry about that too much. > > Sven_______________________________________________ > 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 |
|
|
In reply to this post by Ted Wrinch
2011/7/13 Ted Wrinch <[hidden email]>:
> Hi Sven, > It was the one-click, all in image from the Seaside site: see the link '' > 'Seaside One-Click Experience > 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. > The VM is part of the one-click and I believe is the > 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it > is as the Mac thinks it's a text file, and not a Unix binary or shell > script. The ab command was 'ab -c50 -n1000 > "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting > 400 packets or so. I think that the use of the loop back address means that > it can't be using DNS. My guess, from some of the older list comments, was > that perhaps this VM is still built using polling for events, rather than > handling them on interrupts, which could explain packet loss and suggest an > inefficient UI loop. While this is nice because it may give you nice numbers it's important to remember that this does nothing have to do with what you'll see in production. Everything you will see in production, bottlenecks, throughput, latencies, memory usage, cpu usage will be drastically different. The numbers you'll get have absolutely no significance. You'll probably benchmark how fast Seaside can create new sessions because every request creates a new session. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I understand that things will be different in a real world situation and that using ab to test is not realistic. Nevertheless, it does give a starting point for comparison; and as long as one bears this in mind I think that these kinds of figures are quite useful. The way I work is that I like to start off with *something*, that one can get quickly and easily, and build from there. This was one of the things that I liked about Smalltalk itself of course :)
T. Ted Wrinch On 14 Jul 2011, at 20:07, Philippe Marschall wrote: > 2011/7/13 Ted Wrinch <[hidden email]>: >> Hi Sven, >> It was the one-click, all in image from the Seaside site: see the link '' >> 'Seaside One-Click Experience >> 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. >> The VM is part of the one-click and I believe is the >> 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it >> is as the Mac thinks it's a text file, and not a Unix binary or shell >> script. The ab command was 'ab -c50 -n1000 >> "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting >> 400 packets or so. I think that the use of the loop back address means that >> it can't be using DNS. My guess, from some of the older list comments, was >> that perhaps this VM is still built using polling for events, rather than >> handling them on interrupts, which could explain packet loss and suggest an >> inefficient UI loop. > > While this is nice because it may give you nice numbers it's important > to remember that this does nothing have to do with what you'll see in > production. Everything you will see in production, bottlenecks, > throughput, latencies, memory usage, cpu usage will be drastically > different. The numbers you'll get have absolutely no significance. > You'll probably benchmark how fast Seaside can create new sessions > because every request creates a new session. > > Cheers > Philippe > _______________________________________________ > 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 |
|
|
In reply to this post by Philippe Marschall
On Thu, Jul 14, 2011 at 8:07 PM, Philippe Marschall
<[hidden email]> wrote: > 2011/7/13 Ted Wrinch <[hidden email]>: >> Hi Sven, >> It was the one-click, all in image from the Seaside site: see the link '' >> 'Seaside One-Click Experience >> 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26. >> The VM is part of the one-click and I believe is the >> 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it >> is as the Mac thinks it's a text file, and not a Unix binary or shell >> script. The ab command was 'ab -c50 -n1000 >> "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting >> 400 packets or so. I think that the use of the loop back address means that >> it can't be using DNS. My guess, from some of the older list comments, was >> that perhaps this VM is still built using polling for events, rather than >> handling them on interrupts, which could explain packet loss and suggest an >> inefficient UI loop. > > While this is nice because it may give you nice numbers it's important > to remember that this does nothing have to do with what you'll see in > production. Everything you will see in production, bottlenecks, > throughput, latencies, memory usage, cpu usage will be drastically > different. The numbers you'll get have absolutely no significance. > You'll probably benchmark how fast Seaside can create new sessions > because every request creates a new session. Actually, probably how fast your Smalltalk iterates over large dictionaries, since every 10th request triggers reaping of expired sessions. :) Since that also enters a critical section, you would at a minimum want to increase that number (10) to something substantially higher. Really, if you were expecting a high volume of sessions, you would want to use a different strategy for clearing out expired sessions altogether. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Oh, that's a good idea. Thanks, I'll give that some consideration when/if I get closer to production.
T. Ted Wrinch |
|
|
Ted,
Note that if you are running Seaside on GLASS, we arrange for a separate VM (maintenance vm) to run once a minute to expire the sessions. I don't recommend that you change the reaping strategy with GLASS, but the loop that does the expiration can be tuned .. See WAGemStoneMaintenanceTask class>>maintenanceTaskExpiration for the algorithm used ... BTW, I had to run at pretty high rates (in the neighborhood of >500 request/second?) before I needed to monkey with the algorithm. Dale ----- Original Message ----- | From: "Ted Wrinch" <[hidden email]> | To: [hidden email] | Sent: Wednesday, August 3, 2011 11:56:46 AM | Subject: [Seaside] Re: Mac Image Broken? | | Oh, that's a good idea. Thanks, I'll give that some consideration | when/if I | get closer to production. | | T. | | Ted Wrinch | | -- | View this message in context: | http://forum.world.st/Mac-Image-Broken-tp3663370p3716512.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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |