Call for help: Seaside performances

>
>
> On 17 janv. 07, at 07:49, Lukas Renggli wrote:
>
>>> I just finished benchmarking of Aida/Web web app server and if someone
>>> repeats benchmarking of Seaside, then we'll have something to compare.
>>
>> <rant>
>> I just finished benchmarking Seaside. I measured the time and the
>> lines of code to implement a dynamically generated login web
>> application which has 1KB of HTML.
>>
>> A development environment named Squeak was used to implement the task.
>> First I created a new component (including the rendering code),
>> registered it as an application entry point and then I counted the
>> lines of code:
>>
>> - 6 lines of code (renderContentOn:)
>> - 1 do it (application registration)
>>
>> I could do all this in less than 2 minutes, including the startup of
>> Squeak. I think that could further be optimized by using a ready made
>> component.
>>
>> Benchmarking was done on 2.16 GHz Intel Core Duo with 2 GB memory
>> running Mac OS X 10.4 on Squeak 3.9.
>> </rant>
>>
>> Cheers,
>> Lukas
>>
>> --Lukas Renggli
>> http://www.lukas-renggli.ch
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>

> Hi Stef,
>
> on Wed, 17 Jan 2007 11:53:23 +0100, you wrote:
>> Hi lukas
>>
>> I still think that this is important to recognize that people like
>> vincent has serious concerns about
>> seaside scalability. Vincent seemed to be really enthousiast about
>> seaside. Now they will certainly
>> switch to PhP because of speed.
>
> In the commercial world this does not happen, Stef. If they choose PhP
> then they do so because that was set right from the beginning. Even when
> someone wishes to do something else, nobody hires (+educates +trains)
> 3-13 Smalltalk programmers just because the existing PhP team failed to
> win the performance challenge.
>

> Only _after_ a (commercial) project fails (fails b/o hw, fails b/o sw =>
> failure reason almost irrelevant) then the speed comparision is taken a
> bit more seriously into account. Remember that Google started with (and
> still has) Perl scripts:
>
> - http://www.google.com/search?q=perl+job&gl=US
>
> then view the Google entry under "Sponsored Links".
>
> OT: repeat the same search but with other languages, hit refresh
> frequently (3-13 times per language should show you all the
> advertisers). [still OT]: this one hindered me using $$ AdWords to
> promote Squeak, cannot bid more or equal to what Google bids for their
> own ads :(
>
>> Vincent could you let us know.
>
> Yes, please.
>
> /Klaus
>
>> Stef
>
>>
>>
>> On 17 janv. 07, at 07:49, Lukas Renggli wrote:
>>
>>>> I just finished benchmarking of Aida/Web web app server and if someone
>>>> repeats benchmarking of Seaside, then we'll have something to compare.
>>>
>>> <rant>
>>> I just finished benchmarking Seaside. I measured the time and the
>>> lines of code to implement a dynamically generated login web
>>> application which has 1KB of HTML.
>>>
>>> A development environment named Squeak was used to implement the task.
>>> First I created a new component (including the rendering code),
>>> registered it as an application entry point and then I counted the
>>> lines of code:
>>>
>>> - 6 lines of code (renderContentOn:)
>>> - 1 do it (application registration)
>>>
>>> I could do all this in less than 2 minutes, including the startup of
>>> Squeak. I think that could further be optimized by using a ready made
>>> component.
>>>
>>> Benchmarking was done on 2.16 GHz Intel Core Duo with 2 GB memory
>>> running Mac OS X 10.4 on Squeak 3.9.
>>> </rant>
>>>
>>> Cheers,
>>> Lukas
>>>
>>> --Lukas Renggli
>>> http://www.lukas-renggli.ch
>>> _______________________________________________
>>> 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 Stef,
>
> on Wed, 17 Jan 2007 11:53:23 +0100, you wrote:
>> Hi lukas
>>
>> I still think that this is important to recognize that people like  
>> vincent has serious concerns about
>> seaside scalability. Vincent seemed to be really enthousiast about  
>> seaside. Now they will certainly
>> switch to PhP because of speed.
>
> In the commercial world this does not happen, Stef. If they choose  
> PhP then they do so because that was set right from the beginning.

> Even when someone wishes to do something else, nobody hires  
> (+educates +trains) 3-13 Smalltalk programmers just because the  
> existing PhP team failed to win the performance challenge.
>
> Only _after_ a (commercial) project fails (fails b/o hw, fails b/o  
> sw => failure reason almost irrelevant) then the speed comparision  
> is taken a bit more seriously into account. Remember that Google  
> started with (and still has) Perl scripts:
>
> - http://www.google.com/search?q=perl+job&gl=US
>
> then view the Google entry under "Sponsored Links".
>
> OT: repeat the same search but with other languages, hit refresh  
> frequently (3-13 times per language should show you all the  
> advertisers). [still OT]: this one hindered me using $$ AdWords to  
> promote Squeak, cannot bid more or equal to what Google bids for  
> their own ads :(
>
>> Vincent could you let us know.
>
> Yes, please.
>
> /Klaus
>
>> Stef
>
>>
>>
>> On 17 janv. 07, at 07:49, Lukas Renggli wrote:
>>
>>>> I just finished benchmarking of Aida/Web web app server and if  
>>>> someone
>>>> repeats benchmarking of Seaside, then we'll have something to  
>>>> compare.
>>>
>>> <rant>
>>> I just finished benchmarking Seaside. I measured the time and the
>>> lines of code to implement a dynamically generated login web
>>> application which has 1KB of HTML.
>>>
>>> A development environment named Squeak was used to implement the  
>>> task.
>>> First I created a new component (including the rendering code),
>>> registered it as an application entry point and then I counted the
>>> lines of code:
>>>
>>> - 6 lines of code (renderContentOn:)
>>> - 1 do it (application registration)
>>>
>>> I could do all this in less than 2 minutes, including the startup of
>>> Squeak. I think that could further be optimized by using a ready  
>>> made
>>> component.
>>>
>>> Benchmarking was done on 2.16 GHz Intel Core Duo with 2 GB memory
>>> running Mac OS X 10.4 on Squeak 3.9.
>>> </rant>
>>>
>>> Cheers,
>>> Lukas
>>>
>>> --Lukas Renggli
>>> http://www.lukas-renggli.ch
>>> _______________________________________________
>>> 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
>

>> I still think that this is important to recognize that people like
>> vincent has serious concerns about seaside scalability.
>
> What I wanted to show is that a benchmark like this makes no sense:
>
> VisualWorks <--> Squeak
> - should it benchmark the speed of my machine?
> - should it benchmark the speed of VMs?
> - should it benchmark the socket implementation?
> - should it benchmark the stream implementation?
> - ...
>
> Aida/Web <--> Seaside
> - should it benchmark the memory usage?
> - should it benchmark the response time?
> - should it benchmark the maximum number of sessions?
> - should it benchmark the scalability?
> - should it benchmark the development speed?
> - should it benchmark the simplicity to use?
> - should it benchmark the optimization possibilities?
> - should it benchmark the size of the generated html?
> - should it benchmark the validity of the generated benchmark?
> - should it benchmark the composition of the application?
> - ...
>
> Janko <--> Me (just as an example)
> - should it benchmark the HTTP knowledge?
> - should it benchmark the software engineering skills?
> - should it benchmark how we implemented the login application?
> - should it benchmark the optimization skills?
> - ...
>
> I am no expert in benchmarking. However I do know that for each of
> these questions you need a special benchmark. The one provided by the
> original poster does a fuzzy and incomparable mixture of all of them.
>
> Cheers,
> Lukas
>

>> I still think that this is important to recognize that people like
>> vincent has serious concerns about seaside scalability.
>
> What I wanted to show is that a benchmark like this makes no sense:
>
> VisualWorks <--> Squeak
> - should it benchmark the speed of my machine?
> - should it benchmark the speed of VMs?
> - should it benchmark the socket implementation?
> - should it benchmark the stream implementation?
> - ...
>
> Aida/Web <--> Seaside
> - should it benchmark the memory usage?
> - should it benchmark the response time?
> - should it benchmark the maximum number of sessions?
> - should it benchmark the scalability?
> - should it benchmark the development speed?
> - should it benchmark the simplicity to use?
> - should it benchmark the optimization possibilities?
> - should it benchmark the size of the generated html?
> - should it benchmark the validity of the generated benchmark?
> - should it benchmark the composition of the application?
> - ...
>
> Janko <--> Me (just as an example)
> - should it benchmark the HTTP knowledge?
> - should it benchmark the software engineering skills?
> - should it benchmark how we implemented the login application?
> - should it benchmark the optimization skills?
> - ...
>
> I am no expert in benchmarking. However I do know that for each of
> these questions you need a special benchmark. The one provided by the
> original poster does a fuzzy and incomparable mixture of all of them.
>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> > I think it is honest to potential users of our web app
> servers to have
> > a concrete info about strengths and weaknesses of each offering.
>
> Yes, I completely agree.
>
> I doubt that a generic benchmark (or a set of generic
> benchmarks) can help you to evaluate the perfect web solution
> for your problem. That needs to be done on a per  
> project/problem bases and there are people
> (consultants) that can help with that.
>
> It is well known that Seaside is hungry on resources and that
> you need to do load balancing earlier than with other
> approaches; it is also well known that Seaside provides an
> incredibly productive level of abstraction and makes it
> possible to build complex applications in days where others
> needs months to get the same thing.
>
> To use Seaside for a web application with 1'000'000 users I
> would say 'no' at first. Later on it comes clear that there
> are only 10'000 sessions expected at once. Probably I would
> still say 'no'. If you count 4 MB a session for a really
> complex web application with lots of state, this would mean
> you are required to have 40 GB of memory. If you now
> distribute that on 15 machines this becomes already
> reasonable and I would probably say 'yes'. Of course it also
> depends on what the customer wants: Probably this is cheaper
> to by a couple of linux boxes and get the application in half
> a year than to pay the salary of a whole army to develop a
> less powerful application during the 2 years.
> Maybe the project can be further split down as only the 1'000
> administrators require complex application logic and the rest
> are more or less static pages. I think this is where Seaside
> starts to be strong ...
>
> What I want to show is that there are so many factors and
> things to consider that cannot be caught with a generic
> benchmark. Therefor I see no benefit in doing that.
>
> Lukas

> On 17 janv. 07, at 12:53, Klaus D. Witzel wrote:
>
>> Hi Stef,
>>
>> on Wed, 17 Jan 2007 11:53:23 +0100, you wrote:
>>> Hi lukas
>>>
>>> I still think that this is important to recognize that people like  
>>> vincent has serious concerns about
>>> seaside scalability. Vincent seemed to be really enthousiast about  
>>> seaside. Now they will certainly
>>> switch to PhP because of speed.
>>
>> In the commercial world this does not happen, Stef. If they choose PhP  
>> then they do so because that was set right from the beginning.
>
> Apparently this is not the case in the situation of vincent.
> So we should not generalize.

>> Even when someone wishes to do something else, nobody hires (+educates  
>> +trains) 3-13 Smalltalk programmers just because the existing PhP team  
>> failed to win the performance challenge.
>>
>> Only _after_ a (commercial) project fails (fails b/o hw, fails b/o sw  
>> => failure reason almost irrelevant) then the speed comparision is  
>> taken a bit more seriously into account. Remember that Google started  
>> with (and still has) Perl scripts:
>>
>> - http://www.google.com/search?q=perl+job&gl=US
>>
>> then view the Google entry under "Sponsored Links".
>>
>> OT: repeat the same search but with other languages, hit refresh  
>> frequently (3-13 times per language should show you all the  
>> advertisers). [still OT]: this one hindered me using $$ AdWords to  
>> promote Squeak, cannot bid more or equal to what Google bids for their  
>> own ads :(
>>
>>> Vincent could you let us know.
>>
>> Yes, please.
>>
>> /Klaus
>>
>>> Stef
>>
>>>
>>>
>>> On 17 janv. 07, at 07:49, Lukas Renggli wrote:
>>>
>>>>> I just finished benchmarking of Aida/Web web app server and if  
>>>>> someone
>>>>> repeats benchmarking of Seaside, then we'll have something to  
>>>>> compare.
>>>>
>>>> <rant>
>>>> I just finished benchmarking Seaside. I measured the time and the
>>>> lines of code to implement a dynamically generated login web
>>>> application which has 1KB of HTML.
>>>>
>>>> A development environment named Squeak was used to implement the task.
>>>> First I created a new component (including the rendering code),
>>>> registered it as an application entry point and then I counted the
>>>> lines of code:
>>>>
>>>> - 6 lines of code (renderContentOn:)
>>>> - 1 do it (application registration)
>>>>
>>>> I could do all this in less than 2 minutes, including the startup of
>>>> Squeak. I think that could further be optimized by using a ready made
>>>> component.
>>>>
>>>> Benchmarking was done on 2.16 GHz Intel Core Duo with 2 GB memory
>>>> running Mac OS X 10.4 on Squeak 3.9.
>>>> </rant>
>>>>
>>>> Cheers,
>>>> Lukas
>>>>
>>>> --Lukas Renggli
>>>> http://www.lukas-renggli.ch
>>>> _______________________________________________
>>>> 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
>>

>
> I totally agree with you on the fact that Seaside greatly improves  
> development cost - and maintenance cost too, because Seaside's code  
> is soooo much clearer as PHP.... However I have to fight with  
> people who want numbers, and are quite difficult to convince  
> without raw benchmarks results. From the beginning, my point is to  
> find how, with my 1.000.000 users application (OK for the 10.000  
> sessions) with many many paths, to build an efficient solution with  
> Seaside.
> We had problems reaching good performances with our prototype -  
> however I did not know the load balancing tops you provided  
> already. I think if we want to see massive applications developped  
> with Seaside - and I'm convinced it is possible, we definitely need  
> to gather the best practices, as we've begun in this thread.