http://www.infoworld.com/t/java-programming/surprise-java-fastest-server-side-web-apps-230565?source=IFWNLE_nlt_daily_pm_2013-11-11
It doesn't look as if Seaside was even considered. L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Mon, Nov 11, 2013 at 11:01 PM, Lawson English <[hidden email]> wrote:
> http://www.infoworld.com/t/java-programming/surprise-java-fastest-server-side-web-apps-230565?source=IFWNLE_nlt_daily_pm_2013-11-11 > > It doesn't look as if Seaside was even considered. I don't think we have a shot. On Pharo we become CPU limited a about 10k empty requests/s. That's more than an order of magnitude slower. And let's be honest, you don't chose Seaside for throughput. Maybe SiouX on VW would be able to work some magic. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by LawsonEnglish
You'd need to submit a pull request to them with code that performs their tests to be considered.
I looked at it one time and they also require that in memory databases not be used for the database test. On Nov 11, 2013, at 2:01 PM, Lawson English <[hidden email]> wrote: > http://www.infoworld.com/t/java-programming/surprise-java-fastest-server-side-web-apps-230565?source=IFWNLE_nlt_daily_pm_2013-11-11 > > It doesn't look as if Seaside was even considered. > > > L > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan > > _______________________________________________ > 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 |
On Mon, Nov 11, 2013 at 11:17 PM, Paul DeBruicker <[hidden email]> wrote:
> You'd need to submit a pull request to them with code that performs their tests to be considered. > > I looked at it one time and they also require that in memory databases not be used for the database test. You should be able to skip that test since things like undertow, vertx, netty, grizzly, … don't come with an ORM. You don't want to run the test unless you have a socket based db driver and a connection pool (I believe PostgreS does these days). Also if we could run 8 images on each of the 3 servers (if I understand their set up correctly), the results may not be terrible. But a single image on a single machine is not going to be competitive. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 11.11.2013, at 23:36, Philippe Marschall <[hidden email]> wrote:
> On Mon, Nov 11, 2013 at 11:17 PM, Paul DeBruicker <[hidden email]> wrote: >> You'd need to submit a pull request to them with code that performs their tests to be considered. >> >> I looked at it one time and they also require that in memory databases not be used for the database test. > > You should be able to skip that test since things like undertow, > vertx, netty, grizzly, … don't come with an ORM. You don't want to run > the test unless you have a socket based db driver and a connection > pool (I believe PostgreS does these days). > > Also if we could run 8 images on each of the 3 servers (if I > understand their set up correctly), the results may not be terrible. > But a single image on a single machine is not going to be competitive. (possibly even with gem-traversal enabled, if we ask the gemtalk folks) For example, 3x (1 stone with 8 vms), or even (if gemtalks allows to) 1 stone with (3x8) 24 vms… best -Tobias _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside signature.asc (1K) Download Attachment |
On Tue, Nov 12, 2013 at 11:59 AM, Tobias Pape <[hidden email]> wrote:
> On 11.11.2013, at 23:36, Philippe Marschall <[hidden email]> wrote: > >> On Mon, Nov 11, 2013 at 11:17 PM, Paul DeBruicker <[hidden email]> wrote: >>> You'd need to submit a pull request to them with code that performs their tests to be considered. >>> >>> I looked at it one time and they also require that in memory databases not be used for the database test. >> >> You should be able to skip that test since things like undertow, >> vertx, netty, grizzly, … don't come with an ORM. You don't want to run >> the test unless you have a socket based db driver and a connection >> pool (I believe PostgreS does these days). >> >> Also if we could run 8 images on each of the 3 servers (if I >> understand their set up correctly), the results may not be terrible. >> But a single image on a single machine is not going to be competitive. > > Would a glass setup competitive? I don't know. For starters I don't know why we're CPU bound on Pharo/Sqeak. I assume it's a combination of allocation and GC but can't prove it. It's unlikely GemStone has the some limitations (since the VM is different) but may very well have others. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |