[Pharo-project] cool to see pier, and other running on 1.3
Hi lukas this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool. Stef
Yes, this is very cool indeed. On 28 Jul 2011, at 11:59, Stéphane Ducasse wrote:
Hi lukas
this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool.
Stef
Yep, here: https://twitter.com/renggli/status/96470364368023552 I haven't thoroughly tested everything yet, but unit tests pass and everything works smoothly. What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images. Lukas On 28 July 2011 12:41, Sven Van Caekenberghe <sven@beta9.be> wrote:
Yes, this is very cool indeed.
On 28 Jul 2011, at 11:59, Stéphane Ducasse wrote:
Hi lukas
this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool.
Stef
-- Lukas Renggli www.lukas-renggli.ch
We now have builds with Zinc, Kom and Swazoo. Zinc is the default for all subsequent builds (Seaside One-Click, Magritte, Pier). Strangely none of the server adaptors works when the image comes up (Kom and Zinc worked out of the box in Pharo 1.2). After stop and restart Kom and Zinc work though. Swazoo seems to be broken. Lukas On 28 July 2011 13:20, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 28 Jul 2011, at 12:54, Lukas Renggli wrote:
What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images.
OK, please let me know ASAP if run into any issues.
Sven
-- Lukas Renggli www.lukas-renggli.ch
Hi Lukas, On 28 Jul 2011, at 16:51, Lukas Renggli wrote:
We now have builds with Zinc, Kom and Swazoo.
Zinc is the default for all subsequent builds (Seaside One-Click, Magritte, Pier).
Supercool, thanks a lot !
Strangely none of the server adaptors works when the image comes up (Kom and Zinc worked out of the box in Pharo 1.2). After stop and restart Kom and Zinc work though.
How exactly do you start the adaptor ? ZnZincServerAdaptor new port: 8080; start Only the default Zn server gets registered automatically for this, see ZnSingleThreadedServer class>>#defaultOn: (inherited by ZnMultiThreadedServer) other manually started servers have to register themselves using ZnServer>>#register I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image. Sven
How exactly do you start the adaptor ?
    ZnZincServerAdaptor new port: 8080; start
Yep.
I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image.
Yes, the WAServerManager should bring them up again. I suspect this is an issue with Seaside or Pharo; as this is exactly the same problem with Kom. Lukas -- Lukas Renggli www.lukas-renggli.ch
I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image.
Yes, the WAServerManager should bring them up again. I suspect this is an issue with Seaside or Pharo; as this is exactly the same problem with Kom.
Now I can fix the ZnZincServerAdaptor when I add the following methods: ZnZincServerAdaptor>>startUp self server isNil ifFalse: [ self server start ] ZnZincServerAdaptor>>shutDown self server isNil ifFalse: [ self server stop ] The strange thing though is that when the images comes up and I stop the server adaptor manually, the server continues to run :-S Lukas -- Lukas Renggli www.lukas-renggli.ch
On 28 Jul 2011, at 18:31, Lukas Renggli wrote:
I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image.
Yes, the WAServerManager should bring them up again. I suspect this is an issue with Seaside or Pharo; as this is exactly the same problem with Kom.
Now I can fix the ZnZincServerAdaptor when I add the following methods:
ZnZincServerAdaptor>>startUp self server isNil ifFalse: [ self server start ]
ZnZincServerAdaptor>>shutDown self server isNil ifFalse: [ self server stop ]
The strange thing though is that when the images comes up and I stop the server adaptor manually, the server continues to run :-S
There is something wrong, I just took the build #650 and loaded your commit Zinc-Seaside-lr.17.mcz, created a new Zn adaptor, saved the image and quit: now the image refuses to start! Did you see #basicStart and #basicStop, these are the ones called by WAServerManager>>#start: I am trying to figure out how this is supposed to work...
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I don't think that the server manager calls #basicStop/#basicStart on startup/shutdown (this is when you explicitly start/stop the server), only #startUp/#shutDown. I might be wrong though ... Lukas On 28 July 2011 20:50, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 28 Jul 2011, at 18:31, Lukas Renggli wrote:
I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image.
Yes, the WAServerManager should bring them up again. I suspect this is an issue with Seaside or Pharo; as this is exactly the same problem with Kom.
Now I can fix the ZnZincServerAdaptor when I add the following methods:
ZnZincServerAdaptor>>startUp    self server isNil        ifFalse: [ self server start ]
ZnZincServerAdaptor>>shutDown    self server isNil        ifFalse: [ self server stop ]
The strange thing though is that when the images comes up and I stop the server adaptor manually, the server continues to run :-S
There is something wrong, I just took the build #650 and loaded your commit Zinc-Seaside-lr.17.mcz, created a new Zn adaptor, saved the image and quit: now the image refuses to start!
Did you see #basicStart and #basicStop, these are the ones called by WAServerManager>>#start:
I am trying to figure out how this is supposed to work...
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On 28 Jul 2011, at 20:54, Lukas Renggli wrote:
I don't think that the server manager calls #basicStop/#basicStart on startup/shutdown (this is when you explicitly start/stop the server), only #startUp/#shutDown. I might be wrong though ...
Then why not implement #startUp/#shutDown by delegating to #basicStop/#basicStart Maybe Philippe knows the finer points. Sven
On 28 Jul 2011, at 21:43, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 20:54, Lukas Renggli wrote:
I don't think that the server manager calls #basicStop/#basicStart on startup/shutdown (this is when you explicitly start/stop the server), only #startUp/#shutDown. I might be wrong though ...
Then why not implement #startUp/#shutDown by delegating to #basicStop/#basicStart
Maybe Philippe knows the finer points.
OK, I went over the code looking for the relationship between WAServerManager and WAServerAdaptor. The difference between #startUp/#shutDown and #basicStop/#basicStart is intentional and necessary, and as far as I can see and understand it your patch fixes things. The start adaptor / stop adaptor logic from the control panel goes like this: adaptor start -> manager start: adaptor -> adaptor basicStart The manager's startUp/shutDown calls each adaptor's startUp/shutDown. There is no need for Zn managing this as a registered server since the manager does all the work already Thanks! Sven
There is something wrong, I just took the build #650 and loaded your commit Zinc-Seaside-lr.17.mcz, created a new Zn adaptor, saved the image and quit: now the image refuses to start!
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/ Lukas -- Lukas Renggli www.lukas-renggli.ch
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
ZnMultiThreadedServer does not currently hold onto the list of workers and/or connections that is spawns. So when you kill it, the server socket is stopped, but I could imagine that a kept alive connection in a browser still works until the browser closes it. Let's call this a feature ;-) Sven
lukas does it solve your problem? This is strange because if Kom is impacted there should be something else. On Jul 28, 2011, at 9:47 PM, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
ZnMultiThreadedServer does not currently hold onto the list of workers and/or connections that is spawns.
So when you kill it, the server socket is stopped, but I could imagine that a kept alive connection in a browser still works until the browser closes it. Let's call this a feature ;-)
Sven
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now. When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK. After several minutes the process stops by itself, quite strange. Sven
On 28 Jul 2011, at 22:34, Sven Van Caekenberghe wrote:
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
After several minutes the process stops by itself, quite strange.
I think this must be a build artifact. When I resave the image without the process, it does not come back. Sven
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo. Chers Philippe
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well. Cheers Philippe
Ok, then this is OB and the animation of the scroll pane :-/ Strange that such a process is running; and strange that this causes problems in Pharo 1.3 while it worked in Pharo 1.2? Lukas On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
As I understand this is due to the image built on the server. Could it somehow be related to opening OB in headless mode? Cheers, Doru On 29 Jul 2011, at 09:11, Lukas Renggli wrote:
Ok, then this is OB and the animation of the scroll pane :-/
Strange that such a process is running; and strange that this causes problems in Pharo 1.3 while it worked in Pharo 1.2?
Lukas
On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com "Sometimes the best solution is not the best solution."
I think I fixed the problem, the process should no longer stay around than necessary. On 29 July 2011 10:10, Tudor Girba <tudor@tudorgirba.com> wrote:
As I understand this is due to the image built on the server. Could it somehow be related to opening OB in headless mode?
Cheers, Doru
On 29 Jul 2011, at 09:11, Lukas Renggli wrote:
Ok, then this is OB and the animation of the scroll pane :-/
Strange that such a process is running; and strange that this causes problems in Pharo 1.3 while it worked in Pharo 1.2?
Lukas
On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
-- Lukas Renggli www.lukas-renggli.ch
Ok, problem solved. All server adaptors work now. A little benchmark for 500 requests (concurrency level 10): 1. Zinc -- 2073.80 [Kbytes/sec] received 2. Kom -- 1857.66 [Kbytes/sec] received 3. Swzoo -- 1662.48 [Kbytes/sec] received Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment. Glad that we have Zinc as the default server now :-) Lukas On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
Attached are the details. The command line was: ab -k -n 500 -c 10 "http://192.168.1.103:8080/files/WAWelcomeFiles/seasidestar.png" Lukas On 29 July 2011 11:06, Lukas Renggli <renggli@gmail.com> wrote:
Ok, problem solved. All server adaptors work now.
A little benchmark for 500 requests (concurrency level 10):
  1. Zinc -- 2073.80 [Kbytes/sec] received   2. Kom -- 1857.66 [Kbytes/sec] received   3. Swzoo -- 1662.48 [Kbytes/sec] received
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
Glad that we have Zinc as the default server now :-)
Lukas
On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On Jul 29, 2011, at 11:06 AM, Lukas Renggli wrote:
Ok, problem solved. All server adaptors work now.
A little benchmark for 500 requests (concurrency level 10):
1. Zinc -- 2073.80 [Kbytes/sec] received 2. Kom -- 1857.66 [Kbytes/sec] received 3. Swzoo -- 1662.48 [Kbytes/sec] received
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
Glad that we have Zinc as the default server now :-)
Yes We are waiting for SSL now :) And a little piece of text for the success story because this is nice to hear that pharo is also good for server side only manipulation.
Lukas
On 29 July 2011 07:51, Philippe Marschall <kustos@gmx.net> wrote:
On 29.07.2011 07:46, Philippe Marschall wrote:
On 28.07.2011 22:34, Sven Van Caekenberghe wrote:
On 28 Jul 2011, at 21:11, Lukas Renggli wrote:
I cannot reproduce, but one thing that seems strange with Zinc is that when I stop the server it actually takes 10 to 20 seconds for the site to stop responding ... :-/
Lukas
-- Lukas Renggli www.lukas-renggli.ch
I tried build #651 of seaside3-zinc and that seems to work OK now.
When I start the image, there is another issue though: CPU usage goes to 100% seemingly to a process stuck in ScrollBar>>#animateValue:duration: (priority 40, almost no stack trace, just 2 frames). Killing it brought the CPU usage to normal levels and seemed OK.
Killing that process also fixes Swazoo.
And Kom as well.
Cheers Philippe
-- Lukas Renggli www.lukas-renggli.ch
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
The server keeps the socket open after a request-response cycle and allows clients (browsers) to reuse the same socket for multiple requests. This is typically faster than to open a new socket for each request. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Fri, Jul 29, 2011 at 11:51 AM, Lukas Renggli <renggli@gmail.com> wrote:
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
The server keeps the socket open after a request-response cycle and allows clients (browsers) to reuse the same socket for multiple requests. This is typically faster than to open a new socket for each request.
What is the difference between that and a database connection pool ? -- Mariano http://marianopeck.wordpress.com
On 29 Jul 2011, at 11:56, Mariano Martinez Peck wrote:
What is the difference between that and a database connection pool ?
A connection pool goes a step further, it keeps on reusing multiple connections that each should be kept alive. The idea is always the same: do caching to avoid expensive setup costs. A higher resource usage is the price to pay. Sven
No idea Probably the same I will ask olivier when he is back from holidays On Jul 29, 2011, at 11:56 AM, Mariano Martinez Peck wrote:
On Fri, Jul 29, 2011 at 11:51 AM, Lukas Renggli <renggli@gmail.com> wrote:
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
The server keeps the socket open after a request-response cycle and allows clients (browsers) to reuse the same socket for multiple requests. This is typically faster than to open a new socket for each request.
What is the difference between that and a database connection pool ?
-- Mariano http://marianopeck.wordpress.com
Am 29.07.2011 um 11:56 schrieb Mariano Martinez Peck:
On Fri, Jul 29, 2011 at 11:51 AM, Lukas Renggli <renggli@gmail.com> wrote:
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
The server keeps the socket open after a request-response cycle and allows clients (browsers) to reuse the same socket for multiple requests. This is typically faster than to open a new socket for each request.
What is the difference between that and a database connection pool ?
Both are resource reusing techniques. But a database connection lies above a socket connection and is independent from it. You can send database request over an arbitrary socket connection to the database. This way you can't introduce a security problem. Pooling sockets is more difficult. If things communicating over the socket the authentication might going over that wire and authenticates the connection/socket instead of some abstracted session. In this scenario a socket pool would open a huge security problem giving access randomly to restricted sources. Norbert
Tx. I do not know if you saw but Olivier Auverlot built a Socket pool and he got really good results. Mariano told him that openDBX got one already and I should sync with Olivier to know its statuses but he was quite happy with the load he could support using Seaside-REST. Stef On Jul 29, 2011, at 11:51 AM, Lukas Renggli wrote:
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
what is keep-alive?
The server keeps the socket open after a request-response cycle and allows clients (browsers) to reuse the same socket for multiple requests. This is typically faster than to open a new socket for each request.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On 29 Jul 2011, at 11:06, Lukas Renggli wrote:
Ok, problem solved. All server adaptors work now.
A little benchmark for 500 requests (concurrency level 10):
1. Zinc -- 2073.80 [Kbytes/sec] received 2. Kom -- 1857.66 [Kbytes/sec] received 3. Swzoo -- 1662.48 [Kbytes/sec] received
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
Glad that we have Zinc as the default server now :-)
I am happy and smiling now! Sven
Us too :) On Jul 29, 2011, at 12:03 PM, Sven Van Caekenberghe wrote:
On 29 Jul 2011, at 11:06, Lukas Renggli wrote:
Ok, problem solved. All server adaptors work now.
A little benchmark for 500 requests (concurrency level 10):
1. Zinc -- 2073.80 [Kbytes/sec] received 2. Kom -- 1857.66 [Kbytes/sec] received 3. Swzoo -- 1662.48 [Kbytes/sec] received
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
Glad that we have Zinc as the default server now :-)
I am happy and smiling now!
Sven
On 07/29/2011 11:06 AM, Lukas Renggli wrote:
Ok, problem solved. All server adaptors work now.
A little benchmark for 500 requests (concurrency level 10):
1. Zinc -- 2073.80 [Kbytes/sec] received 2. Kom -- 1857.66 [Kbytes/sec] received 3. Swzoo -- 1662.48 [Kbytes/sec] received
Zinc can nicely play out the keep-alive. Kom doesn't support keep-alive. With Swazoo a lot of requests fail if keep-alive is enabled (so I disabled it). Details in the attachment.
I did some debugging and Swazoo does not seem to support keep-alive with HTTP 1.0, only with HTTP 1.1. ab unfortunately makes only HTTP 1.0 requests. There is a Seaside-Benchmark package in Seaside30Addons which is IMHO better suited for adapter benchmarks because it avoid dynamic allocation. Cheers Philippe
I did some debugging and Swazoo does not seem to support keep-alive with HTTP 1.0, only with HTTP 1.1. ab unfortunately makes only HTTP 1.0 requests.
Ok, but still a bit strange that this breaks Swazoo ... Anyway, I don't care.
There is a Seaside-Benchmark package in Seaside30Addons which is IMHO better suited for adapter benchmarks because it avoid dynamic allocation.
It doesn't matter here, the allocations are the same for every adaptor and also very stable. This was mostly a test to see if the server adaptors don't break with many concurrent request. Lukas -- Lukas Renggli www.lukas-renggli.ch
I'm trying to remember what we did with the startup logic. Igor I remember that we made sure that UI cannot start (startup) before UI primitives are allocated because before there was some really strange logic. And this makes sure that servers can work in headless. But I do not see how this can be related. Igor do you have any idea? Stef
We now have builds with Zinc, Kom and Swazoo.
Zinc is the default for all subsequent builds (Seaside One-Click, Magritte, Pier).
Strangely none of the server adaptors works when the image comes up (Kom and Zinc worked out of the box in Pharo 1.2). After stop and restart Kom and Zinc work though.
Swazoo seems to be broken.
Lukas
On 28 July 2011 13:20, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 28 Jul 2011, at 12:54, Lukas Renggli wrote:
What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images.
OK, please let me know ASAP if run into any issues.
Sven
-- Lukas Renggli www.lukas-renggli.ch
On Jul 28, 2011, at 12:54 PM, Lukas Renggli wrote:
Yep, here: https://twitter.com/renggli/status/96470364368023552
I haven't thoroughly tested everything yet, but unit tests pass and everything works smoothly.
What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images.
Excellent Let us know if you find problems because we can bullet profs Zn support for 1.3 Stef
Lukas
On 28 July 2011 12:41, Sven Van Caekenberghe <sven@beta9.be> wrote:
Yes, this is very cool indeed.
On 28 Jul 2011, at 11:59, Stéphane Ducasse wrote:
Hi lukas
this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool.
Stef
-- Lukas Renggli www.lukas-renggli.ch
Excellent Let us know if you find problems because we can bullet profs Zn support for 1.3
Not sure what is going on with Swazoo and Kom. Swazoo doesn't work at all, but doesn't throw an error either (I don't really care about that). Kom does work at startup, but manually starting it works. Stopping the server takes about a minute though. This is kind of strange. Did something with sockets change? Lukas -- Lukas Renggli www.lukas-renggli.ch
I know that with Sven we went over HTTPSocket or HTTPClient uses because some of them were crazy. Now I know that Chris muler found a bad behavior (pinging a server on failures) but we fixed that. I will go over the bug fixes to see if I see something.
Excellent Let us know if you find problems because we can bullet profs Zn support for 1.3
Not sure what is going on with Swazoo and Kom.
Swazoo doesn't work at all, but doesn't throw an error either (I don't really care about that).
Kom does work at startup, but manually starting it works. Stopping the server takes about a minute though. This is kind of strange. Did something with sockets change?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On 28 Jul 2011, at 12:41, Sven Van Caekenberghe wrote:
Yes, this is very cool indeed.
On 28 Jul 2011, at 11:59, Stéphane Ducasse wrote:
Hi lukas
this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool.
Stef
One request, Lukas: would you please consider loading 'Zinc-Seaside' from http://www.squeaksource.com/ZincHTTPComponents with Seaside builds ? Zinc is a default part of Pharo 1.3 and this small package (just two classes) adds another Seaside Server Adaptor alternative. Whether you use it (by default) or not, that is entirely up to you. But by including it, chances are more people will use and (stress) test it. Thx, Sven PS: And just for fun, have a look at how cool GLMOrangeUITheme looks on your background ;-)
participants (9)
-
Igor Stasenko -
Lukas Renggli -
Mariano Martinez Peck -
Norbert Hartl -
Philippe Marschall -
Philippe Marschall -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba