?

Log in

About this Journal
Links:
Website Mailing List SourceForge Project Page Wiki
Current Month
 123456
78910111213
14151617181920
21222324252627
282930
Sep. 3rd, 2008 @ 04:17 am freebsd 7 port of aolserver 4.5 work nicely
http://localhost:8000/

Welcome. You have made it. Aolserver has started.

woo haa
About this Entry
bootiack:
Sep. 2nd, 2008 @ 07:31 pm what is up party people? nginx cherokee aolserver lighty oh my
Well I have seen some stats online of lighttpd beating aolserver on static content.

What we are all of course interested in is Dynamic content....

I am not sure howto setup benchmarks well but I have a p4 1.6ghz 768ram running freebsd 7.0-release -p2 ready for punishment if anyone wishes to guide me. I will document anything anyone guides em todo and rerun the benchmarks anytime for anyone and post them.

The contenders as I see it are:
www.aolserver.com
http://wiki.codemongers.com/Main
http://www.cherokee-project.com/
http://www.lighttpd.net/
www.apache.org [event]
http://www.sun.com/software/products/web_srvr/index.xml
http://www.mathopd.org/
http://www.boa.org/

Anyone care to chime in?
opinions?

Also does squid or varnish caching change all this?
About this Entry
bootiack:
Oct. 14th, 2007 @ 09:55 pm aolserver vs apache event worker
Current Location: terra
Current Mood: bouncybouncy

Is this apache copying aolserver?

lighttpd vs aolserver any charts?

is aolserver still the best free webserver?

About this Entry
bootiack:
Sep. 29th, 2007 @ 11:58 am aolserver lighttpd cherokee
Current Location: terra
Current Mood: optimisticoptimistic
I have been reading over lighttpd's site adn a bit on the cherokee site.
http://www.lighttpd.net/
http://www.cherokee-project.com/
I read from Philip greenspuns essays that aolserver handles far more than webserving......but lighttpd seesm to be pushing for improvements with soemthign called fastcgi.
I did also read greenspuns stuff on memoization, saving resutl of a calcualtion so it doesn't have to be repeated 10,000 times by same operation.
That seems awesome.
So how does on measure total throughput of dynamic content?

I wonder can anyone comment on these servers v aolserver?

Also what are the big diferences between aolserver vs the fork called naviserver?
About this Entry
bootiack:
Jun. 9th, 2007 @ 11:11 am Los angeles aolserver group?
Current Location: prime material plane, orion arm of milky way, sol p3
Current Mood: bouncybouncy
ANy aolserver groups in LA?
About this Entry
bootiack:
Apr. 7th, 2005 @ 01:51 am Tcl 8.4.7 introduced memory leak in Tcl threaded memory allocator

(x-posted)

Today, Zoran Vasiljevic confirmed that there is a leak in the threaded Tcl memory allocator [1] (affectionately known as "Zippy" by the AOLserver crowd). I unfortunately already knew about this (see comments) because Qiong Wei told me about it back in December 2004, but didn't really act on it because I originally thought that it was something in his application code that may have been causing the leak, not something in the Tcl core itself. Today, I verified that it was indeed a leak in the Tcl core, introduced in Tcl 8.4.7 [2].

Here's my test run against Tcl 8.4.6 (no leak):

$ LD_LIBRARY_PATH=`pwd` ./tclsh
% info patchlevel
8.4.6
% lappend auto_path /usr/lib/tcl8.4; package require Thread
2.6.1
% exec ps -p [pid] -o pid,vsz,rss,args
  PID   VSZ  RSS COMMAND
 8317 12704 1996 ./tclsh
% for {set i 0} {$i < 1000} {incr i} {
    thread::join [thread::create -joinable {}]
}
% exec ps -p [pid] -o pid,vsz,rss,args
  PID   VSZ  RSS COMMAND
 8317 21192 2272 ./tclsh

Here's my test run against Tcl 8.4.7 (has leak):

$ LD_LIBRARY_PATH=`pwd` ./tclsh
% info patchlevel
8.4.7
% lappend auto_path /usr/lib/tcl8.4; package require Thread
2.6.1
% exec ps -p [pid] -o pid,vsz,rss,args
  PID   VSZ  RSS COMMAND
 9358 12692 2000 ./tclsh
% for {set i 0} {$i < 1000} {incr i} {
    thread::join [thread::create -joinable {}]
}
% exec ps -p [pid] -o pid,vsz,rss,args
  PID   VSZ  RSS COMMAND
 9358 48272 29432 ./tclsh

As I said in email to the AOLSERVER mailing list, if you're using Tcl >= 8.4.7, I strongly suggest you roll back to Tcl 8.4.6, and hope that the yet-to-be-released Tcl 8.4.10 contains the necessary fix for this leak issue.

(dossy.org)

About this Entry
from behind
dossy:
Apr. 1st, 2005 @ 01:51 am tcl-coredumper 0.1 released

(x-posted)

I recently blogged about Google releasing some of their code as open source projects. What I didn't explicitly say in that previous entry was how cool it would be if there were a Tcl interface to the Google coredumper library. Well, now there is!

Thanks to Nathan Folkman who had the same great idea, he started working on what is now being called tcl-coredumper. I assisted by doing the autoconf stuff, hacking on the Makefile, and writing the automated tests for it, as well as working on the code itself.

See the official announcement on the AOLSERVER-ANNOUNCE mailing list that was also crossposted to the AOLSERVER mailing list. It includes a link to download the source: tcl-coredumper-0.1-src.tar.gz.

(dossy.org)

About this Entry
from behind
dossy:
Mar. 29th, 2005 @ 07:01 pm LiteSpeed benchmarks include AOLserver 4.0.7

(x-posted)

The folks at LiteSpeed apparently included AOLserver 4.0.7 in their latest Web Server Performance Comparison benchmarks. (Unfortunately, they don't include a date on the benchmarks so it's not easy to tell when these benchmarks were performed, but according to their home page at the moment, it looks as though it was updated today.)

On one hand, it's great that they included us in their list of servers for benchmarking. On the other hand, their published results show AOLserver performing poorly, which could very well be true but from anecdotal evidence of my own personal experiences, the numbers they show seem out of line with what I would have expected from their benchmark server, a 2.4 GHz Xeon running on Fedora Core 3 with a 2.6.10 kernel. Their small static file tests show AOLserver maxing out under 4,000 req/sec for non-keepailve and under 8,000 req/sec with keep-alive. This still puts AOLserver performance ahead of Apache, but less than half the throughput of LiteSpeed's server. The echo CGI tests show AOLserver maxing out just under 300 req/sec, which is comparable to Apache, but again less than half the throughput of LiteSpeed.

What's remarkable is the wide gap in throughput between traditional user-space HTTP servers and the Red Hat Content Accelerator (nee TUX HTTP Server). Granted, kernel-space HTTP servers can get some unfair advantages, but what's interesting is the fact that the Litespeed Web Server 2.0 Pro (LSWS 2.0 Pro in the benchmarks) is comparable to TUX, but according to Litespeed's features it "[runs] completely in the user space" -- so, how do they get the kind of performance they get? I'd love to see a whitepaper describing what design techniques they use, but all I could find was this item from their FAQ:

Why LiteSpeed web server is so fast?

Good architecture and heavily optimized code.

(The seemingly Engrish phraseology was theirs, not mine.)

Looking around for various web server design improvement ideas similar to Matt Welch's Staged Event-Driven Architecture (SEDA), or the USENIX 2004 paper accept()able Strategies for Improving Web Server Performance, I stumbled across this paper by Vsevolod V. Panteleenko and Vincent W. Freeh titled Web Server Performance in a WAN Environment (PDF). Here's the abstract:

Abstract--This work analyzes web server performance under simulated WAN conditions. The workload simulates many critical network characteristics, such as network delay, bandwidth limit for client connections, and small MTU sizes to dial-up clients. A novel aspect of this study is the examination of the internal behavior of the web server at the network protocol stack and the device driver. Many known server design optimizations for performance improvement were evaluated in this simulated environment.

We discovered that WAN network characteristics may significantly change the behavior of the web server compared to the LAN-based simulations and make many of optimizations of the server design irrelevant in this environment. Particularly, we found out that small MTU size of the dial-up user connections can increase the processing overhead several times. At the same time, the network delay, connection bandwidth limit, and usage of HTTP/1.1 persistent connections do not have a significant effect on the server performance. We have found there is little benefit due to copy and checksum avoidance, optimization of request concurrency management, and connection open/close avoidance under a workload with small MTU sizes, which is common for dial-up users.

Granted, as more and more users move from narrowband (dial-up) to broadband, the interesting points of this paper will become less and less relevant, but it's still interesting to see the outcome of this kind of research. Of course, with more and more Service-oriented Architecture (SOA) designs and systems being built today, the majority of HTTP traffic over the WAN could already be between servers on broadband links than to clients on narrowband links. That would be an interesting fact to research and prove.

In the meantime, I guess the bar for AOLserver performance has been raised. Lets see what we can do to reach it!

(dossy.org)

About this Entry
from behind
dossy:
Mar. 17th, 2005 @ 09:10 pm Google Code: google-coredumper, google-sparsehash, google-goopy, google-perftools

(x-posted)

Chris DiBona, previously an editor at Slashdot, now the Open Source Program Manager at Google, announced today that Google has launched its Google Code site, where it has placed some of its contributions back into the Open Source community at SourceForge!

The initial list consists of four projects:

  • google-coredumper: CoreDumper -- "The coredumper library can be compiled into applications to create core dumps of the running program, without termination. It supports both single- and multi-threaded core dumps, even if the kernel doesn't natively support for multi-threaded core files."
  • google-sparsehash Sparse Hashtable -- "This project contains several hash-map implementations in use at Google, similar in API to SGI's hash_map class, but with different performance characteristics, including an implementation that optimizes for space and one that optimizes for speed."
  • google-goopy: Goopy/Functional -- "Goopy Functional is a python library that brings functional programming aspects to python."
  • google-perftools: Perftools -- "These tools are for use by developers so that they can create more robust applications. Especially of use to those developing multi-threaded applications in C++ with templates. Includes TCMalloc, heap-checker, heap-profiler and cpu-profiler."

Three of the four are of interest to me: coredumper, sparsehash, and perftools.

For a long time, I've wanted better coredump capability in Linux, especially for multi-threaded applications such as AOLserver. Google's contribution could "solve" that problem for me, which would be fantastic. Right now, it's very difficult to troubleshoot a multi-threaded application on Linux because of this lack of capability, and gdb's "gcore" just doesn't cut it. Perhaps the Linux and GDB teams can integrate Google's contribution back into their respective codebases; we'll see.

Google's sparse hashtable implementation could yield some performance improvement to Tcl which makes extensive use of hashtables. I'd like to see if I can use the Google sparsehash implementation as a drop-in replacement for the Tcl implementation and see what the benchmarks say. This could be big.

Google's perftools is somewhat of a misnomer, since the big selling point is their improved memory allocator which is supposedly "[the] fastest malloc we've seen[, and] works particularly well with threads and STL." This could displace the Tcl threaded memory allocator, if performance really is superior, or could be used by the Tcl threaded memory allocator for an additional performance boost. It should be fun experimenting and benchmarking it.

It's nice to see Google publish some really valuable stuff back to the Open Source community instead of just lamely throwing us a bone like IBM. This is definitely consistent with Google's "do no evil" philosophy.

Man, this is just awesome. It gives me a whole new range of toys to play with. It's like Christmas in March!

(dossy.org)

About this Entry
from behind
dossy:
Mar. 11th, 2005 @ 08:29 pm Boston-area OpenACS users meeting, Friday March 11, 2005

(x-posted)

Andrew Grumet blogs about today's Boston-area OpenACS users meeting at the MIT Sloan School of Management. Wish I could have been there; maybe I'll be able to attend the next one, if it's at the same place next time.

(dossy.org)

About this Entry
from behind
dossy: