Yeah, I just noticed that on my jetty console. Bummer. On Mon, May 4, 2009 at 3:59 PM, David Pollak <feeder.of.the.be...@gmail.com>wrote:
> 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 -~----------~----~----~----~------~----~------~--~---
