Derek, Please note that about half of the requests failed in Jetty. Jetty does not seem to be explicitly closing the NIO sockets leading to an out of IO descriptor problem... that's why I used Tomcat.
Thanks, David On Mon, May 4, 2009 at 2:47 PM, Derek Chen-Becker <dchenbec...@gmail.com>wrote: > Just to throw in another data point, I ran the tests on my AMD Phenom X2 > 720 (3 cores, 6GB of RAM): > > I generated the archetype exactly as you have it here. > > Ran "mvn -Drun.mode=production -Djetty.port=9090 jetty:run" > > Output from Apache Bench: > > $ ab -c 10 -n 20000 http://192.168.2.254:9090/user_mgt/login > This is ApacheBench, Version 2.3 <$Revision: 655654 $> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Licensed to The Apache Software Foundation, http://www.apache.org/ > > Benchmarking 192.168.2.254 (be patient) > Completed 2000 requests > Completed 4000 requests > Completed 6000 requests > Completed 8000 requests > Completed 10000 requests > Completed 12000 requests > Completed 14000 requests > Completed 16000 requests > Completed 18000 requests > Completed 20000 requests > Finished 20000 requests > > > Server Software: Jetty(6.1.16) > Server Hostname: 192.168.2.254 > Server Port: 9090 > > Document Path: /user_mgt/login > Document Length: 3635 bytes > > Concurrency Level: 10 > Time taken for tests: 37.110 seconds > Complete requests: 20000 > Failed requests: 10191 > (Connect: 0, Receive: 0, Length: 10191, Exceptions: 0) > Write errors: 0 > Total transferred: 79276096 bytes > HTML transferred: 72626584 bytes > Requests per second: 538.94 [#/sec] (mean) > Time per request: 18.555 [ms] (mean) > Time per request: 1.855 [ms] (mean, across all concurrent requests) > Transfer rate: 2086.18 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 0 0.0 0 1 > Processing: 1 18 40.8 11 1428 > Waiting: 1 18 39.9 11 1414 > Total: 1 19 40.8 11 1428 > > Percentage of the requests served within a certain time (ms) > 50% 11 > 66% 16 > 75% 20 > 80% 23 > 90% 36 > 95% 54 > 98% 78 > 99% 100 > 100% 1428 (longest request) > > > On Mon, May 4, 2009 at 3:16 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> Daniel, >> >> I did a little measurement of Lift and did some tuning. On my Core 920 >> machine with 12GB of RAM running Ubuntu 9.04 and the JDK 1.6.0_13 in 64 bit >> mode with Tomcat 6.0.18 (I ran into some bugs in Jetty while measuring with >> ab). My baseline running (both locally and across the network) >> >> ab -c 10 -n 20000 http://yak.local:8080/user_mgt/login >> >> I was seeing about 1,500 pages/second. I used YourKit to do some >> profiling and improved performance on my box to about 2,200 pages/second. >> Here are the steps I went through. I created a new project: >> >> d...@yak:~/benchmark$ mvn archetype:create -U >> -DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-archetype-basic >> -DarchetypeVersion=1.1-SNAPSHOT -DremoteRepositories= >> http://scala-tools.org/repo-snapshots -DgroupId=com.liftcode >> -DartifactId=benchmark >> >> I cd'ed into benchmark and typed "mvn clean install" I copied the >> "target/benchmark-1.0-SNAPSHOT" directory into Tomcat's webapps directory >> and renamed the directory "ROOT". I did export >> JAVA_OPTS="-Drun.mode=production" to make sure Lift runs in production >> mode. I started Tomcat with ./bin/startup.sh >> >> Then I ran: >> >> d...@yak:~/tmp$ ab -c 10 -n 20000 http://localhost:8080/user_mgt/login >> >> I did this and discarded the results because this will "warm up" the >> HotSpot compiler. At the end of this run, the JVM should have optimized >> most of the Lift-related classes. Next, I re-ran the command: >> d...@yak:~/tmp$ ab -c 10 -n 20000 http://localhost:8080/user_mgt/login >> This is ApacheBench, Version 2.3 <$Revision: 655654 $> >> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >> Licensed to The Apache Software Foundation, http://www.apache.org/ >> >> Benchmarking localhost (be patient) >> Completed 2000 requests >> Completed 4000 requests >> Completed 6000 requests >> Completed 8000 requests >> Completed 10000 requests >> Completed 12000 requests >> Completed 14000 requests >> Completed 16000 requests >> Completed 18000 requests >> Completed 20000 requests >> Finished 20000 requests >> >> >> Server Software: Apache-Coyote/1.1 >> Server Hostname: localhost >> Server Port: 8080 >> >> Document Path: /user_mgt/login >> Document Length: 3768 bytes >> >> Concurrency Level: 10 >> Time taken for tests: 9.156 seconds >> Complete requests: 20000 >> Failed requests: 0 >> Write errors: 0 >> Total transferred: 83620000 bytes >> HTML transferred: 75360000 bytes >> Requests per second: 2184.33 [#/sec] (mean) >> Time per request: 4.578 [ms] (mean) >> Time per request: 0.458 [ms] (mean, across all concurrent requests) >> Transfer rate: 8918.62 [Kbytes/sec] received >> >> Connection Times (ms) >> min mean[+/-sd] median max >> Connect: 0 1 0.9 0 8 >> Processing: 1 4 18.5 3 788 >> Waiting: 0 4 18.4 2 788 >> Total: 1 5 18.5 3 788 >> WARNING: The median and mean for the initial connection time are not >> within a normal deviation >> These results are probably not that reliable. >> >> Percentage of the requests served within a certain time (ms) >> 50% 3 >> 66% 4 >> 75% 4 >> 80% 5 >> 90% 6 >> 95% 8 >> 98% 11 >> 99% 16 >> 100% 788 (longest request) >> d...@yak:~/tmp$ >> >> I also ran the command remotely over a gigabit LAN: >> d...@horse:~$ ab -c 10 -n 20000 http://yak.local:8080/user_mgt/login >> This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 >> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >> Copyright 2006 The Apache Software Foundation, http://www.apache.org/ >> >> Benchmarking yak.local (be patient) >> Completed 2000 requests >> Completed 4000 requests >> Completed 6000 requests >> Completed 8000 requests >> Completed 10000 requests >> Completed 12000 requests >> Completed 14000 requests >> Completed 16000 requests >> Completed 18000 requests >> Finished 20000 requests >> >> >> Server Software: Apache-Coyote/1.1 >> Server Hostname: yak.local >> Server Port: 8080 >> >> Document Path: /user_mgt/login >> Document Length: 3768 bytes >> >> Concurrency Level: 10 >> Time taken for tests: 10.305721 seconds >> Complete requests: 20000 >> Failed requests: 0 >> Write errors: 0 >> Total transferred: 83620000 bytes >> HTML transferred: 75360000 bytes >> Requests per second: 1940.67 [#/sec] (mean) >> Time per request: 5.153 [ms] (mean) >> Time per request: 0.515 [ms] (mean, across all concurrent requests) >> Transfer rate: 7923.75 [Kbytes/sec] received >> >> Connection Times (ms) >> min mean[+/-sd] median max >> Connect: 0 0 0.6 0 4 >> Processing: 1 4 25.9 3 840 >> Waiting: 1 3 25.6 2 816 >> Total: 1 4 25.9 3 840 >> >> Percentage of the requests served within a certain time (ms) >> 50% 3 >> 66% 4 >> 75% 4 >> 80% 4 >> 90% 6 >> 95% 8 >> 98% 11 >> 99% 17 >> 100% 840 (longest request) >> >> >> I'm currently setting up a test machine with a 2 core AMD processor, 1GB >> of RAM and Ubuntu. I'll re-run the tests on this box and let you know. >> >> Thanks, >> >> David >> >> >> >> >> >> >> On Sat, May 2, 2009 at 1:32 PM, Dunsun <dun...@gmail.com> wrote: >> >>> >>> Hi, >>> >>> I'm very new to lift and scala. >>> >>> I have made some Grails intranet applications but sadly Grails or >>> better say GSP rendering part which is completely written in Groovy is >>> a very slow beast (even in comparison with Rails or Django). >>> >>> For my future big project (heavy loaded site) I need something much >>> faster. >>> >>> So I have made some quick and dirty Lift benchmarks using ApacheBench >>> + Tomcat, GlassFish (from netbeans) and even Jetty. >>> My machine - AMD X2 @ 2500Mhz, 4 GB RAM >>> >>> LIFT BASIC SAMPLE: >>> ab -c 10 -n 3000 >>> http://localhost:8080/liftbasic-1.0-SNAPSHOT/user_mgt/login >>> 50 req/s >>> >>> LIFT BLANK SAMPLE: >>> ab -c 10 -n 3000 http://localhost:8080/liftblank-1.0/ >>> 120 req/s >>> >>> Obtained numbers were similar for all 3 servers. >>> >>> Using Stripes and rendering similar simple pages I'm getting much much >>> higher scores (600 req/s). >>> Using Grails I'm getting little worse results but I would say it is >>> same league. >>> I would expect much better performance from Lift which is written in >>> scala. >>> >>> Why am I getting these low numbers ? >>> Am I doing something wrong ? >>> Any suggestion is very welcome. >>> >>> regards >>> Daniel >>> >>> >>> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Git some: http://github.com/dpp >> >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
