Slashdot Mirror

A better test would be http_load, since it tests multiple connections in parallel. I don't know of a test client that does multiple connections and utilizes persistent connections, but that would be ideal for load testing. But, of course, Apache's is inherently limited to the number of connections it can handle, due to using a separate thread/process for each connection.

Great. And unless you need to run something on the scale of slashdot (in terms of cgi dirty work/complexity) I would much rather run thttpd. It's faster and smaller, with much less overhead and much (much) more secure. I've never needed all the bells and whistles of apache, and I doubt 80% of the people who use apache do.

$OBSCURE_PORT_1 = obscure port # on your local machine
$OBSCURE_PORT_2 = obscure port # on machine outside firewall

On the machine where you have the shell account, download and compile the ucspi-tcp package, and micro_proxy. Put the tcpserver and micro_proxy binaries in your $PATH; throw everything else away.

To run the proxy:

From your local machine,
ssh -C -L $OBSCURE_PORT_1:127.0.0.1:$OBSCURE_PORT_2 -l [username] machine.where.you.have.shell.account.co.va
(or if you use some fancy Windoze SSH client, forward $OBSCURE_PORT_1 on your local machine to $OBSCURE_PORT_2 on the remote machine)

Once logged in, run tcpserver -DHlR 127.0.0.1 $OBSCURE_PORT_2 micro_proxy & on the remote machine

On your local machine, set your browser to use HTTP and HTTPS (IE)/SSL (Mozilla) proxies on host 127.0.0.1, port $OBSCURE_PORT_1

Surf to your heart's content.

Can't believe I didn't see this link: Free Punch Cards. I especially love the graphical punch your own card.

(let's call them ACME, because I don't want to be sued)

Have I got news for you!

(But it seems to be a personal company, so maybe he won't sue :)

-Don

Apache would be MUCH faster if the Apache developers would give up on the outdated and innefficient method of using a separate process per connection, and went with a non blocking I/O model like Boa, thttpd or Zeus. A non blocking I/O model is much better, from many standpoints. It places the I/O handling back in the kernel where it belongs, reduces memory usage and drastically increases speed.

I've talked to a lot of people about this issue, and spent a lot of time reading through the Apache developer mailing list. The main reasons that come up is that Apache is meant to be correct first, fast second, and that it is harder for people to extend Apache because it makes the code more complicated. The first reason is invalid, because it's quite possible to make a web server correct and fast at the same time. The three web servers I mentioned prove this. And there are several more non blocking web servers out there. The I/O is a very small part. Given a proper design, everything else can easily work with that model. Extending it is not made any more difficult, because one would very rarely, if ever, modify the base I/O model. You have normal HTTP and HTTPS, and that's it. Anyone who would be extending that critical portition of the web server should be able to understand the conceptually simple concept of non blocking I/O, especially as it is explained very well in a variety of sources.

One thing that does seem to work against the onslaught is a throttling webserver. If you haven't got the bandwidth etc to serve a sudden onslaught of requests, probably the best thing to do is to just start 503'ing -- at least people get a quick message 'come back later' instead of just dead air.

Once upon a time, we had 1 web server that did everything, so it needed to be able to do everything. Now everytime we do something new we toss out a new webserver (or 2 or 10 of 'em). And they all basically need to do one thing (webmail, portal, whatnot) and do it well and that's it.

So we've got a whole bunch of Apache servers which a bucket load of apache processes who basically spend all day doing little more than exec'ing the same CGI over and over (and copying the data around a couple of extra times).

I'm pretty much now convinced that would my next step is going to be to franken-meld my cgi with something like mini-httpd so it is a single, persistant, app.

I'm certainly not redoing the whole thing in Java though! :)

i know, i know, rtfm, but does apache 2.x still serve pages by forking a new process (i know, it preforks, blah blah, still you end up with dozens of processes)? until apache is a multithreaded server like AOLServer (don't laugh, it's open source and very, very good) or even a non-blocking IO server like thttpd it is just unusable for truly scalable or database-centric stuff. i love all the mods for apache, and would love the apache API to evolve to a single process, advanced server instead of the 'patchy' mess on top of NCSA it started as.

for background on why things like non-blocking IO or multithreaded instead of forking is good, check out thttpd's section on non-blocking io or Philip Greenspun's own Introduction to AOLServer, part 1.

-sam

i know, i know, rtfm, but does apache 2.x still serve pages by forking a new process (i know, it preforks, blah blah, still you end up with dozens of processes)? until apache is a multithreaded server like AOLServer (don't laugh, it's open source and very, very good) or even a non-blocking IO server like thttpd it is just unusable for truly scalable or database-centric stuff. i love all the mods for apache, and would love the apache API to evolve to a single process, advanced server instead of the 'patchy' mess on top of NCSA it started as.

for background on why things like non-blocking IO or multithreaded instead of forking is good, check out thttpd's section on non-blocking io or Philip Greenspun's own Introduction to AOLServer, part 1.

-sam

I too encounterd that book in my youth .. and found it again here in the local library. So don't complain about high internet prices before checking out the free options!

I'm hoping to animate it some time - and make up a few more poems myself. I could even put out an edition of THE SIGNS OF MOTHER GOOSE: Semiotic Rhymes for Children...or some book where all the poetry is in M68K assembler,FORTH or JCL or whatever.

[bottles of beer on the wall, anyone?]

Fans of this book can pop over to Jef Poskanzer's home page to hear ALL off the Singing Science records (not just Space Songs, whence TMBG copped "Why Does The Sun Shine?".) visit: http://www.acme.com/jef/science_songs/. GLory to Tom Glazer, Dottie Collins, Marias and Miranda educating you with folk songs of Space, Weather, Nature and More Nature, Experiments and Energy & Motion!

The other books I read a lot in this vein as a child were the two anthologies "Mathematical Magpie" and "Fantasia Mathematica", books of short stories, poems, cartoons,jokes and songs with a Mathematical theme, edited by Clifton Fadiman.

You may have read a lot of these before, but there they are all in one place. (Nine Billion Names Of God, The Feeling Of Power,--And he built a Crooked House, The No-Sided Professor .. )

Rudy Rucker edited a similar (mostly inferior and a little redundant) collection called The Mathenauts much later.

http://www.acme.com/software/http_load/

Microsoft Software is more popular and so it gets hit more. If linux was just as popular you would see the same thing happen.

You wish. The MSFT-toadying media thought that x.c , a FreeBSD and Linux worm, was going to be the "Next Code Red". My machine got more hits from sadmind/IIS worm (Solaris) than x.c. C'mon, shill-boy, why aren't you toeing the Wagg-Ed line? The truth of the matter lies more in the fact that Windows is more-or-less a software and hardware monoculture. Any flaw in IIS affects *all* of the population. The Linux/Unix/BSD/Solaris population has much greater diversity: a flaw in the WN web server isn't going to affect sites using thttpd. Similarly, there are dozens of Linux email clients in use, from mailx to Pine to mh. I don't think there's a common scripting language amongst the diversity of Linux email clients, and I don't think *any* of them are dopey enough to execute "readme.eml" files.

People that dislike windows and love linux are the reason for this attack. Its these people that are writing the viruses and worms. You've got to be kidding, right? Have you got any evidence whatsoever to back that up?

Seriously, though, I think the requirement is that the party being infringed upon needs to send a letter in writing [snail mail] to the infringing site stating that they have a link to an illegal program and that they must remove it or they will be shut down. Once the site is aware of it (as in 2600's case) they need to follow through and remove the link or face legal action. Because of the written letter part, search engines can remove that site if required.

Don't quote me on legal mumbo jumbo tho - I sold my soul to a company, not the devil (I'm a programmer, not a lawyer :)

Yes, we need the number. Not only are the specific claims relevant, but the application date is key to finding prior art that will defeat it. However ther really isn't much doubt it's bogus.

My own thumbnail index generator has a copyright date of 1995. eBay wasn't founded until September of that year, and didn't do thumbnails until much later. In fact, their CTO Michael Wilson actually asked me to program their thumbnail code, based on my version, but I was too busy. I might still have the email to document this.

I have MP3s of the Science Songs albums on my web page.

If you want a really fast (and simple!) web server for Unix, try Jef Poskanzer's thttpd. thttpd is entirely select based, single thread, memory mapped IO. Really fast. mini_httpd is also great if you want a zero-configuration web server, but it's not as fast. Jef's a brilliant old school hacker.

A common configuration on big web sites is to use Apache to serve the complex stuff, and thttpd to serve static images.

As for the bulk sales, though, it doesn't look like a very good deal. Assuming the 10% discount I get:

• 100 2x2 bricks for $6.29 = 6.3 cents/brick
• 50 2x4 bricks for $6.29 = 12.6 cents/brick

Compare to Tyco Superblocks, an excellent quality Lego-compatible brick, which were recently on sale at Toys R Us for $10 / 900 bricks = 1.1 cents/brick.

Furthermore eBay usually has plenty of auctions for bulk Lego-brand bricks, in single colors, for less that Lego wants. E.g. 500 assorted black bricks for $10 = 2 cents/brick.

I've ordered parts from Lego when I needed specific rare pieces, but for bulk bricks this is not a good deal.

To avoid security holes in shell scripts the main trick is to always put argument expansions inside double quotes. Doing this would fix the abovementioned reverse-DNS hack, among others.

Blocking the .. snooping would also be pretty easy - just add a little switch statement.

Along the same lines as these servers, here's my web server in 150 lines of C. It's more featureful than these - it does index.html, and even directory listings.

And yes, a plain old pee cee can easily serve those 1100 hits/second and saturate a 100baseT card. My old 200MHz Pentium Pro does it quite easily, with CPU cycles to spare. Of course, it runs thttpd and FreeBSD 3, not Apache and Linux. According to my measurements, running Linux would slow it down by a factor of two, and Apache would slow it down by a factor of five. Running both, with a factor of ten less performance, my old machine would indeed not be able to saturate its network card. No doubt this is where people got the idea that they needed multiple machines to serve mid-sized web sites - when they run inefficient software, they are right!

And yes, a plain old pee cee can easily serve those 1100 hits/second and saturate a 100baseT card. My old 200MHz Pentium Pro does it quite easily, with CPU cycles to spare. Of course, it runs thttpd and FreeBSD 3, not Apache and Linux. According to my measurements, running Linux would slow it down by a factor of two, and Apache would slow it down by a factor of five. Running both, with a factor of ten less performance, my old machine would indeed not be able to saturate its network card. No doubt this is where people got the idea that they needed multiple machines to serve mid-sized web sites - when they run inefficient software, they are right!

WAY better than Schoolhouse Rock. Plus, it's, well.... ACME.

WAY better than Schoolhouse Rock. Plus, it's, well.... ACME.

Well, our favorite Patent Office lists 149 trademarks on ACME.

Interstingly enough acme.com seems to be owned by yet another nerd from Berkley, who has an interesting solution to the domain-name disputes.

Well, our favorite Patent Office lists 149 trademarks on ACME.

Interstingly enough acme.com seems to be owned by yet another nerd from Berkley, who has an interesting solution to the domain-name disputes.

• ACME Laboratories
• Acme Express, Inc.
• Acme Technologies
• Acme Markets
• Acme Brick
• Etc etc etc...

--

I would *kill* to have acme.com - heh heh.(I wonder who's there..)

Jef Poskanzer. The ACME Laboratories home page says:

So far, ACME Laboratories is merely the business name for Jef Poskanzer doing software development and consulting. Perhaps someday it will be more.

(and has a pile of other stuff on it as well - stuff quite possibly of interest to much of the Slashdot audience).

anyway, if the gist of the idea is to make most of their pages entirely static, I'd say it's a good idea. government agencies aren't in the business of building online communities with forums and stuff like that. in order to present themselves and their information to the public, static pages should be more than enough.

while we're at it: how to build a secure static server in a few minutes: set up a Linux box with only httpd and sshd running, and sshd firewalled at the internet-connecting router. install thttpd for the web server, chrooted to its document root, running under an uid that can't write to any of the files or directories inside of the chroot. then you have exactly two attacks to worry about: 1) kernel networking bugs (nothing much you can do about these except trust that they are rare, and that fixes are available very quickly), and buffer overflows in the webserver (which crash the process, but don't let the attacker actually do anything with the system, like write anywhere or run any programs).

The benchmarking tools can be found here.

Http_load can be found here.

Moderators, please refrain from flagging information "Informative" unless you actually know it's correct. MNG is the new PNG-like standard for animation, while PNM is "portable anymap" - the simple truecolor format for Jef Poskanzer's pbmplus package.

For true proxying you don't even need the SSL libs, you can do it without decrypting the session. See for example micro_proxy, which handles http and https in 260 lines of code.

And (back to previous topic) if you want a really tiny http server, see micro_httpd, only 150 lines of code.

-Jef

For true proxying you don't even need the SSL libs, you can do it without decrypting the session. See for example micro_proxy, which handles http and https in 260 lines of code.

And (back to previous topic) if you want a really tiny http server, see micro_httpd, only 150 lines of code.

-Jef

I have noticed that a number of people have mentioned Zeus and thttpd as alternatives to Apache. I know a few people who say they have also had success with the Roxen Challenger server. Does anyone know how Roxen performes in comparison to the other three? From what I've heard it is excellent for static pages, which sounds like what is on the art site described here.

Secondly, consider the BSDs. (Moderators: this is not flamebait. I have a valid point). Their TCP/IP implementation is a good deal faster than the Linux equivalent, and while the Linux stack is maxing out on concurrent TCP/IP connections (which is a possibility, especially with lots of images, etc. on your site) BSD will keep on chugging. I'm not sure how much of an issue this will be here, though. I think for the most part, unless you're Yahoo.com, you should be okay with Linux. But hey, you're the judge.

Finally, be sure to think outside the box when it comes to HTTP servers. There are other servers besides Apache, believe it or not. And in your case, there are ones that are a lot more optimized than Apache for serving up static content (I think it's static, save the webcam. You didn't really say). thttpd and Zeus (it's not free, shoot me) come to mind.

Apache kicks ass, but it IS slow! If you don't need all of Apache's functionality, don't use it. You might want to look at thttpd. I found that with a 2.2.x kernel I could do 1,000 concurrent connections on my P133 laptop w/ 16MB ram! I used Jeff's http_load for the test, which will throttle down to emulate a 28.8 client.
More performance info can be found here.

Apache kicks ass, but it IS slow! If you don't need all of Apache's functionality, don't use it. You might want to look at thttpd. I found that with a 2.2.x kernel I could do 1,000 concurrent connections on my P133 laptop w/ 16MB ram! I used Jeff's http_load for the test, which will throttle down to emulate a 28.8 client.
More performance info can be found here.

Apache kicks ass, but it IS slow! If you don't need all of Apache's functionality, don't use it. You might want to look at thttpd. I found that with a 2.2.x kernel I could do 1,000 concurrent connections on my P133 laptop w/ 16MB ram! I used Jeff's http_load for the test, which will throttle down to emulate a 28.8 client.
More performance info can be found here.

That is what I get for not checking them, and assuming the /. discussion code would handle it the way I expect. They were:

• Vernor Vinge (the Singularity paper): http://meltingpot.fortuneci ty.com/kuwait/557/vinge.html
• Greg Egan (Permutation City):http://www.acme.com/~jef/reviews/g_ega n.html
• John Brunner (Shockwave Rider):http://www.scifi.com/sfw/issue48/class ic.htm

Jack

Cell phones, satellite communications, the Internet, the Space Shuttle, mass murders supposedly caused by overuse of video games... Hell, look at what I do for a living! Computer programming as a vocation was SF fifty years ago.

Vernor Vinge was right all along (not that I ever doubted him). The real problem with writing SF these days is not that your ideas and predictions are too far out, but that they are probably not far enough. Some, like Greg Egan, make up for this by going all out and creating new physics and related cosmologies. Others descend into psuedo-science and write fantasies set on spaceships. (You know what I am talking about, no need to include a link to some trekkie site.)

The point is simple, there is nothing in this 'Smart Dust' - or any other new technology - that should surprise anyone who has been paying attention the last ten years. It is all going to happen, and probably sooner than anyone expects. Those of us who are mentally flexible enough to handle the changes are the new elite. Everyone else will be (or are now) left spinning in the shockwave.

Jack

If you want to use server-side Java, at least use the Servlet API. There are plenty of open source implementations of it, and it means you'll be able to port your code to other web servers if you need to.

thttpd, a small web server for linux (~7000 lines source) should easily outperform the iis on the
mindcraft "benchmark" due to its non forking
behaviour. See the comparison chart on this page.

thttpd, a small web server for linux (~7000 lines source) should easily outperform the iis on the
mindcraft "benchmark" due to its non forking
behaviour. See the comparison chart on this page.

I really wish people would not start beliving this delusion. Apache is slower than IIS on a high-end machine, but Apache was never meant to scale to that level of performance.

If you need that kind of web server performance in Linux, you don't use Apache. You use Zeus, thttpd, or mathopd. Here is a UNIX web server performance comparison.

As for the Samba vs. NT numbers, Samba does better than NT when all the clients are NT workstation, NT does better than Samba when all the clients are Windows95/98. The SMB server to use depends on what kind of clients you have in your enterprise.

- Sam

It uses Apache for page serving (including PHP), and thttpd for image serving.. Right tools for the job. :)

Here's an interesting graph. It may not be all that scientific, but it gives a good idea.

thttpd is not a threaded web server. In fact, due to its design (as I understand it), the thread implementation makes no difference to thttpd. If you're running a multi-processor system, Apache will probably be better because it will take advantage of the multiple processors; thttpd, because it is only a single process, will not.
ned

Does anyone know if MindCraft is going to continue to take Web Benchmarks only against Apache/Linux or if they will also be testing the performance of thttpd or mathop. I get the feeling that Mindcraft only wants Apache used to match their goal of producing the negative results for Linux.

... and a very interesting thing about this graph is that a number of different servers (including apache, roxen, boa and others) have performance which drops dramatically at a level of about 125 simultaneous requests - similar to that reported.

(that's the graph mentioned in the previous post).

whether this is caused by the fd maximum of 1024 or not is left as an exercise to readers...

In my travels, I've come across a page that illustrates that. It's here on thttpd's site It's a bit dated, but it does illustrate Zeus' (and thttpd's) speed.