Hopbot log for 2009-07-15 - Helma IRC channel: #helma on irc.freenode.net

2009-07-15:

[16:38] <olegp> hey guys
[16:39] <olegp> just wondering: how does one access the servletcontext in helmang ?
[16:39] <olegp> Im trying to cache some stuff across requests using the setAttribute call
[17:02] <olegp> I guess the serlvetcontext isnt really something that's part of the serverjs spec
[17:02] <olegp> what I've come up with so far ends up exposing the native session inside request.js and going from there
[17:30] <irc> hello
[17:30] <irc> something disconcerting to me
[17:31] <mykes> we installed helma 1.6.3
[17:31] <mykes> ran a benchmark test
[17:31] <mykes> 1 connection, 1000 requests
[17:31] <mykes> did the same thing to apache server
[17:31] <mykes> and apache is many many many times faster
[17:31] <mykes> I'm wondering if there's something in my configuration of helma that's making it so slow
[17:31] <mykes> it is doing 26 request/sec
[17:32] <mykes> I'm thinking maybe it's interpreted, including jetty
[17:32] <mykes> vs. JIT
[17:32] <mykes> any ideas?
[18:33] <mykes> I'll hang around in case someone wakes up :)
[19:30] * zumbrunn is waking up
[19:30] <mykes> zumbrunn ;)
[19:30] <zumbrunn> I've never done any benchmark testing like that, so have no numbers to share/compare
[19:31] <mykes> well, it's considerably slower
[19:31] <zumbrunn> 26/sec seems low, though
[19:31] <mykes> it does a few out.println()
[19:31] <zumbrunn> how are you testing this?
[19:31] <mykes> in main_action()
[19:31] <zumbrunn> is it a test I can easily duplicate here?
[19:31] <mykes> sure
[19:31] <mykes> I'm using linux
[19:31] <mykes> (Ubuntu)
[19:32] <mykes> sudo apt-get install httperf
[19:32] <mykes> command line
[19:32] * zumbrunn is googling httperf
[19:32] <mykes> httperf --server=hostname --port=8080 --uri=/appname/ --num-conns=1 --num-calls=1000
[19:33] <mykes> I'll paste the output here
[19:33] <mykes> it's still running...
[19:33] <mykes> Request rate: 28.0 req/s (35.7 ms/req)
[19:33] <mykes> Request size [B]: 81.0
[19:33] <mykes> Reply rate [replies/s]: min 27.2 avg 28.0 max 29.4 stddev 0.7 (7 samples)
[19:34] <mykes> CPU time [s]: user 7.71 system 22.39 (user 21.6% system 62.7% total 84.3%)
[19:34] <mykes> so like 8 seconds for 1000 requests
[19:34] <mykes> and for apache and php script:
[19:35] <mykes> Request rate: 191.5 req/s (5.2 ms/req)
[19:35] <mykes> Request size [B]: 89.0
[19:35] <zumbrunn> and what does the main_action do that you are calling?
[19:35] <mykes> it prints a very small HTML page
[19:35] <mykes> some <script> tags
[19:35] <mykes> you want to see it?
[19:35] <mykes> function main_action() {
[19:36] <mykes> }
[19:36] <mykes> eh
[19:36] <mykes> didn't paste so well ;(
[19:36] <mykes> var page = new WebPage('CMS');
[19:36] <mykes> page.addScriptDirectory('/Core');
[19:36] <zumbrunn> use the pastebin
[19:36] <mykes> maybe 10 of those
[19:36] <zumbrunn> http://helma.pastebin.com/
[19:36] <mykes> then a page.start()
[19:37] <mykes> and page.end()
[19:37] <mykes> it is scanning recursively a few subdirectories
[19:37] <mykes> but that should be very fast
[19:37] <zumbrunn> well, it may not be as fast as you think
[19:37] <mykes> you know ctags?
[19:38] <mykes> it recursively does about 5,000 files on this machine in < 1 second
[19:38] <mykes> that's scanning each file
[19:38] <zumbrunn> the first test I would do is to see what kind of numbers you get with a main_action that does nothing
[19:38] <mykes> easy
[19:38] <mykes> hang on
[19:38] <zumbrunn> or just res.write('foo')
[19:38] <mykes> done
[19:38] <mykes> let's see the speed test
[19:39] <mykes> still slow
[19:39] <mykes> running
[19:39] <zumbrunn> hmm, ok
[19:39] <mykes> runnning
[19:39] <mykes> running
[19:39] <mykes> running
[19:39] <mykes> heh
[19:39] <mykes> Request rate: 32.8 req/s (30.5 ms/req)
[19:40] <mykes> CPU time [s]: user 7.01 system 18.96 (user 23.0% system 62.1% total 85.1%)
[19:40] <mykes> so .7 seconds faster
[19:40] <mykes> for 1000 requests
[19:40] <mykes> more info...
[19:40] <mykes> I am using jetty.xml setup like on the helma.org WWW site/wiki
[19:41] <mykes> java -version
[19:41] <mykes> java version "1.6.0_14"
[19:41] <mykes> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
[19:41] <mykes> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
[19:41] <mykes> perhaps it would be slow if it weren't JIT compiled (jetty)
[19:41] <mykes> oh
[19:41] <mykes> my start.sh
[19:41] <mykes> JAVA_OPTIONS="-server -d64 -Xbatch -Xmx1024m -XX:+UseParallelGC -Djava.awt.headless=true"
[19:42] <mykes> I have helma console commented out
[19:42] <mykes> it's not writing stats to the console
[19:43] <mykes> when it was, I'd see 8ms, 8ms, 8ms, 10ms, 125ms, 8ms, 8ms
[19:43] <mykes> kinds of page times
[19:44] <zumbrunn> you can see the current values if you check inside the log files
[19:44] <zumbrunn> (inside the log directory)
[19:45] <mykes> [2009/07/15 12:52:38] [INFO] [cms-2] get:/ done in 0 millis
[19:45] <mykes> [2009/07/15 12:52:38] [INFO] [cms-2] get:/ done in 0 millis
[19:45] <mykes> [2009/07/15 12:52:38] [INFO] [cms-2] get:/ done in 0 millis
[19:46] <mykes> so I am thinking it is jetty that is slow
[19:46] <mykes> even 10ms times to execute seems fast enough
[19:47] <mykes> those 0 seconds is
[19:47] <mykes> main_action() { res.write('hello, world'); }
[19:48] <mykes> this is 1.6.3, not NG
[19:48] <mykes> if that helps
[19:49] <zumbrunn> I have a hard time believing that jetty would add that much overhead
[19:51] <zumbrunn> how are the numbers if you test with a simple text file inside a static jetty context?
[19:51] <mykes> how do I set up a static jetty context?
[19:51] <zumbrunn> like /static/test.txt in the default install
[19:52] <mykes> lemme try that
[19:52] <mykes> I do have 10 .js files in Global, about 554 lines total, with onStart method
[19:53] <zumbrunn> that shouldn't matter, since it doesn't run on each request
[19:53] <zumbrunn> (and the code doesn't get compiled on each request either)
[19:53] <mykes> ok
[19:53] <mykes> getting /welcome/static/helmaheader.png
[19:53] <mykes> still very slow
[19:54] <mykes> Request rate: 30.2 req/s (33.1 ms/req)
[19:54] <mykes> realize
[19:54] <mykes> I am running Apache on this same machine
[19:54] <mykes> it's the same hardware
[19:54] <mykes> using localhost
[19:56] <zumbrunn> well, at least we've established that helma's dynamic request handling doesn't slow things down
[19:57] <zumbrunn> (because the static requests run in a separate servlet context)
[19:58] <mykes> I agree
[19:58] <mykes> but what to do to make Jetty go a reasonable speed?
[19:59] <mykes> it seems I am running sun JDK 1.6
[19:59] <mykes> 64 bit
[19:59] <mykes> server version
[19:59] <mykes> it should be doing JIT compiling
[19:59] <mykes> I'd think no JIT would make Jetty slow
[20:00] <mykes> in the jetty.xml file
[20:00] <mykes> requestsPerGC set to 1
[20:00] <mykes> seems really frequent
[20:01] <mykes> minthreads 5
[20:01] <mykes> maxthreads 255
[20:01] <mykes> maxidletimems 30000
[20:01] <mykes> lowresourcepersisttimems 5000
[20:01] <zumbrunn> just to make sure it's not your jetty.xml... have you tried this test with a plain vanilla helma-1.6.3 install?
[20:02] <mykes> sure, let's try that
[20:02] <mykes> ding ding
[20:02] <mykes> that is the problem!
[20:03] <mykes> Request rate: 224.5 req/s (4.5 ms/req)
[20:03] <mykes> !
[20:03] <mykes> ok, so maybe you should warn people on that page at helma.org
[20:03] <mykes> I wanted to be able to use SSL/https sometimes
[20:04] <mykes> that XML file seemed the way to do it
[20:04] <zumbrunn> I assume it's a matter of tweaking the settings appropriately
[20:05] <mykes> sure
[20:05] <mykes> have you ever benchmarked helma vs. php?
[20:05] <zumbrunn> nope
[20:05] <mykes> with/without something like eAccelerator
[20:05] <mykes> it's probably a good thing to have on helma.org
[20:05] <zumbrunn> I've never used php, lucky me :-)
[20:05] <mykes> it's the next best thing to javascript if you don't want a typed language
[20:06] <mykes> but I'm not a big fan of php
[20:06] <mykes> thing is, if you had benchmarks on helma.org, it might convince way more people to consider using it instead of php
[20:06] <mykes> another thing I found missing on helma.org is a simple "features of helma" page
[20:07] <zumbrunn> yeah, my arguments against php are over ten years old and hence outdated
[20:07] <zumbrunn> features like what?
[20:07] <mykes> * Compiles Javascripts into Java Classes
[20:07] <mykes> (I think that's true)
[20:08] <mykes> * Java classes JIT compiled into machine native code by the VM
[20:08] <mykes> * Full access to every Java class on classpath
[20:08] <zumbrunn> it compiles to jvm bytecode
[20:08] <mykes> * Extensible by writing Java classes
[20:08] <mykes> (ok, so correct that)
[20:08] <mykes> I think bytecode is JIT compiled anyway
[20:08] <mykes> * E4X, Javascript 1.7
[20:08] <mykes> * Rich server side JS library
[20:09] <mykes> * Client, Server, Public facing code can be shared
[20:09] <mykes> * Runs on Windows, Unix, Macintosh
[20:09] <mykes> * Built in firebug-like debugger
[20:09] <zumbrunn> helma compiles the code once and caches it
[20:09] <mykes> * Choice of several templating solutions
[20:09] <zumbrunn> (it doesn't compile on each request)
[20:09] <mykes> it shouldn't
[20:10] <zumbrunn> so the just-in-time compilation isn't really relevant I think
[20:10] <mykes> but at some point, it is easy to translate bytecodes into native assembly/machine instructions
[20:10] <mykes> from reading Yegge's blogs, he seems to indicate it will or does already JIT compile
[20:10] <mykes> but I may be misreading it
[20:10] <mykes> (from this transcript, you are getting a features page ;)
[20:11] <mykes> * Option to use CouchDB
[20:11] <mykes> * Server clustering via simple configuration
[20:11] <mykes> * Application model (/app, /app2, shared objects for whole app)
[20:12] <mykes> * Built in cron/scheduler with full access to server side functions
[20:12] <mykes> * Small footprint: 4MB .zip contains everything. Unzip, cd helma, ./start.sh
[20:12] <mykes> * Simple configuration via small number of brief text files
[20:12] <mykes> * Lucene for search
[20:12] <mykes> that's my list
[20:13] <zumbrunn> at that rate, the feature lists will get long :-)
[20:13] <mykes> I think people wanting to evaluate it want to see such a list, even if long
[20:13] <zumbrunn> yeah, might be a good idea
[20:13] <mykes> it's IDE agnostic
[20:13] <zumbrunn> (an obvious one too, I must admit)
[20:13] <mykes> I use VIM
[20:14] <mykes> I'd love to use a real IDE, but they're really slow
[20:15] <mykes> though komodo edit has some potential - it's on top of mozilla and uses JS for macros
[20:15] <zumbrunn> speaking of "servlet context" earlier...
[20:16] <zumbrunn> olegp, in case you check the channel log, have you looked at /modules/helma/httpserver.js ? maybe you can expose what you need there
[20:16] <mykes> anyway, thank you zumbrunn
[20:16] <mykes> I am a big fan of Helma
[20:16] <mykes> I talk it up wherever possible
[20:17] <zumbrunn> mykes, feel free to add pages of suggested documentation to the wiki
[20:17] <zumbrunn> I won't forget your "feature list" suggestion either, though
[20:17] <mykes> sure
[20:18] <mykes> I promise you that people want to see the features
[20:18] <mykes> once they find those appealing, they dig into the online docs
[20:19] <zumbrunn> maybe we should start such a page in the wiki and ask people on the mailing list to fill in features they think of
[20:20] <mykes> sure
[20:21] <mykes> http://codeigniter.com/
[20:22] <mykes> to see a PHP framework site, how they try to attract users
[20:22] <mykes> http://cakephp.org/#hot_features
[20:22] <mykes> (has features page)
[20:27] <mykes> hey, check this out
[20:27] <mykes> http://www.mozilla.org/rhino/ScriptingJava.html
[20:27] <mykes> Behind the scenes, Rhino generates the bytecode for a new Java class that implements Runnable and forwards all calls to its run method over to an associated JavaScript object. The object that implements this class is called a Java adapter.
[20:27] <mykes> so maybe it does do JIT
[20:32] <mykes> one other thing that might be too much work
[20:32] <mykes> the rhino debugger
[20:32] <mykes> it's nice, but nowhere near as good as firebug
[20:33] <mykes> in theory, if it talked the firebug or DBG or whatever protocol it is, you could debug server (and client, too) using any old IDE
[20:33] <mykes> netbeans
[20:33] <mykes> aptana
[20:33] <mykes> eclipse
[20:34] <mykes> another link
[20:34] <mykes> http://www.terminally-incoherent.com/blog/2008/01/08/rhino-scripting-java-with-javascript/
[20:59] <mykes> and one more
[20:59] <mykes> http://iablog.sybase.com/efarrar/2009/06/using-rhino-to-write-stored-procedures-in-javascript-part-1/

 

 

In the channel now:

Logs by date: