I was looking at lighttpd performance
(at http://trac.lighttpd.net/trac/wiki/Docs%3APerformance )
Considering how well AOLserver stands up to lighttpd, my question was why does
lighttpd do better?
For sending small files AOLserver is slightly better, but then performance
goes down.
One
On 2007.09.27, Tom Jackson [EMAIL PROTECTED] wrote:
Another reason might be that lighttpd doesn't write an access.log by
default. I wonder if you can turn this off in AOLserver?
Yes, you can. If you don't load the nslog module, you turn off access
logging.
-- Dossy
--
Dossy Shiobara
Tom Jackson wrote:
I was looking at lighttpd performance
(at http://trac.lighttpd.net/trac/wiki/Docs%3APerformance )
Considering how well AOLserver stands up to lighttpd, my question was why does
lighttpd do better?
I was wondering if it had something to do with how aolserver does its
On 2007.09.27, John Buckman [EMAIL PROTECTED] wrote:
Lighthttpd is *not* using the system call to send a file to a socket
(I forget the name) as this call was taken out of the Linux kernel, I
believe with 2.4. I remember reading a note about this from Linus,
that the performance for
On Thursday 27 September 2007 09:55, John Buckman wrote:
When comparing lighthttpd vs aolserver, notice that aolserver only
does worse than lighthttpd for large files, and on the same file
system/hardware. Thus, the difference in benchmarks is not likely to
be the access logs or disk.
Yeah,
On 2007.09.27, Jeff Rogers [EMAIL PROTECTED] wrote:
[...] It seems at first glance that it would make more sense to hand
the task of writing to the connection back to the driver thread once
the connection thread is done with it, [...]
Since this is such an obvious change, would I be correct
On Thursday 27 September 2007 11:08, Dossy Shiobara wrote:
It might be possible to push static file processing further up the chain
into the DriverThread and get better performance on larger static
files--or, have one dedicated I/O thread separate from the main driver
thread to handle async
Hmm--I'm not sure what you're thinking of or referring to, but the
common optimization is to use sendfile(2), which seems to be
alive and well in the 2.6 tree.
Whoops, you're right, I just remembered a sysadmin email about
sendfile not existing on the kernel we're using. Hmm...
Sendfile
Does a module exist that does this:
- register a Tcl function for a given URL, ie /photo/*
- and specifying an ns_cache for the resulting rendered page
- so that C code completely handles successive requests for that URL
- and so that if the back-end data changes, the ns_cache can be
marked as
This reminds me of the Smarty for PHP. Has anyone looked at porting
Smarty to ADP? It's pretty PHP-specific but the syntax, like Tom's
stuff below, is pretty convenient.
http://smarty.php.net/
-Jim
On Sep 25, 2007, at 10:50 AM, Tom Jackson wrote:
Jeff,
I developed a templating
On 2007.09.27, Jim Davidson [EMAIL PROTECTED] wrote:
This reminds me of the Smarty for PHP. Has anyone looked at porting
Smarty to ADP? It's pretty PHP-specific but the syntax, like Tom's
stuff below, is pretty convenient.
http://smarty.php.net/
Wow, Jim--I'm surprised to hear that
On 2007.09.28, Bas Scheffers [EMAIL PROTECTED] wrote:
I would suspect Linux being faster on a box like this than OS X (BSD)
because of better threading support. Or am I wrong in that assumption?
I'm only guessing, but I doubt there would be a significant performance
difference between OS X's
On 28/09/2007, at 9:28 AM, Dossy Shiobara wrote:
Yes! Finally, someone else who uses the 404-handler-as-request-
processor
pattern! Indeed, you can't beat static file serving performance.
And,
My first inspiration for this came way back in the last century, from
working with Vignette
Wow that is pretty interesting, lots of good ideas.
In my example below, there are places where you see a tag like [/if/],
the ending /] means that following whitespace should be removed completely. It
looks like smarty has a tag {strip} which is essentially an html type
normalization. All
On 28/09/2007, at 3:38 AM, Dossy Shiobara wrote:
I bet with just a few minutes of tweaking and tuning, we can get
between
4k-8k simple dynamic req/sec out of your hardware.
Hear, hear. I just blasted my brand-spanking-new Quad 2.6 Mac Pro
using ab. I was testing my ns_session, so it was
On 28/09/2007, at 5:04 AM, John Buckman wrote:
I've been looking at C-caching of Tcl dynamic content, with dirty
cache support. For example, replacing the Tcl code that returns a
user's uploaded photo with C code.
I wrote C code to do this, and got 14k/second vs 240/s for the same
tcl
Yeah, I do this too. To dirty the cache you can just delete the
file. I do regular rounds to delete old files.
I don't use the 404 though, that's a neat idea. Instead I register a
proc that ns_returnfiles the cache file if it exists, otherwise it makes
it and then returns it.
Bas
On 2007.09.28, Bas Scheffers [EMAIL PROTECTED] wrote:
My solution to that problem was simply caching in the filesystem and
serving static files. The way this works in a multi-server
environment is that the custom 404 handler figures out the request
was for /photo/123/axbcgsfdt.jpg and
On 2007.09.27, Rusty Brooks [EMAIL PROTECTED] wrote:
Yeah, I do this too. To dirty the cache you can just delete the
file. I do regular rounds to delete old files.
I don't use the 404 though, that's a neat idea. Instead I register a
proc that ns_returnfiles the cache file if it exists,
19 matches
Mail list logo
