Slashdot Mirror

Take a look at the Popular Perl Complaints and Myths doc compiled by Adam Pisoni and docs to get you started with mod_perl at perl.apache.org

However, one thing is abundantly clear: starting new processes for CGI is hugely expensive, and the larger the binary you have to load to start the process, the more expensive it becomes. The PERL interpreter is huge, and consequently, run as CGI, PERL scripts perform comparatively very badly. THe situation must be very different with mod_perl, but I haven't tested this.

Mind you, this is not really a reason not to use PERL if you like it. Unless you have shedloads of bandwidth or run your website in a 386 box, or are doing some really complex backend processing, your CGI performance is not going to be your primary bottleneck.

Embperl

Isn't CGI (common gateway Interface) a protocol/standard? Cause a Java Servlet is still a CGI-like program, it just doesn't use Perl. I think too many people think CGI == web-based Perl.

Anyway, I think that for large scale, robust web applications, servlets are the way to go, especially once you build a library of classes from which you can use over and over again in your servlets.
Plus, things important to website growth, such as the ability to easily load balance with too many coding changes are extremely easy to do using Java servlets (check out http://java.apache.org/jserv /howto.load-balancing.html for a cool how-to on load balancing/failover with servlets under Apache JServ)

However, if you are doing a smaller application, especially a form input-type program/script, I don't think even the fastest Java coder could beat the ease of Perl.

The Apache mod_perl module does all kinds of fun insane pre-compilation and caching of Perl for you automagically. You can write Perl modules or CGI to be run in the Apache::Registry wrapper which will be compiled once and cached by Apache until you run it again. This keeps systems running slick and smooth, and is largely what Slashdot uses to the best of my knowledge. I've deployed it on a somewhat large scale myself for totally dynamic content, and it has worked great. Just about every page of a specific portion of my site is generated on the fly with information users have authenticated with and corresponding information from an SQL database with very little performance loss. I couldn't be happier!

You can find mod_perl information in a number of places, including perl.apache.org.

---
Tim Wilde
Gimme 42 daemons!

another link:

• GNUJSP, which is compatible with Apache JServ 1.0 and 1.1b3.
• Apache JServ, with links to other servlet aids in java.

An even better solution is the extension of servlets called JSP -- Java Server Pages. In this case, you (like w/ an embeded scripting language like server-side javascript or w3-msql), write HTML with embedded java code, and the JSP engine translates that into a java servlet (or in gnujsp's case a "Template" instance) w/ html embeded as "out.println()" instructions.

The current standard now has support for "tag libraries" where the JSP programmer can write html/xml-like tags to support doing the "logic" of the page, then the presentation guy can use the provided tags, in combination w/ html, to do the layout and make it look nice/consistent. the presentation person doesn't need to know any java at all.

Links on jsp

• Java Server Pages at javasoft
• Jakarta -- the reference implementation

...when the Web took off back in '95 or abouts, Perl was a robust, well-understood language with tons of ready, freely available scripts to process enormous amounts of text. And since HTTP is text-centric, it was a natural first choice for CGI implementations. But I doubt it is any longer.

The Web and the technologies around it have matured enough to enable us to use custom-made tools for Web applications. For straight Web-only applications I'd go with the very impressive PHP4. For deployments that need to be tied in to a larger infrastructure (DBs, legacy code, uncoventional hardware), my personal choice would be the Apache Java Tools. Apache JServ, Apache Cocoon, and soon, Apache Jakarta should cover all your needs.

Both PHP4 and Apache Java have session management, pre-compilation to portable byte code, platform independence, and work well with most popular DBs (JDBC covers more of them though).

YMMV. As one of my ole engineering profs says: "50% of successful engineering is picking the right tool for the job" or something like that ;-)

n

For more information on servlets, pick up the O'Reilly Programming Java Servlets book, as well as checking out Apache JServ and the JRun Servlet Engine.

(And really, if you know Perl and C++, Java is but a small step to learn, and provides nice resume fodder. :-> )

If you're going to follow up on the study, why don't you try to find out what you can from the authors list of the CPAN archive for contributions to Perl? It's a large list, and although it does not include information about their locations, most of them at least provide their email addresses.

There is public biographical info about many of the contributors to the Apache server.

But above all, please try to include more projects next time. I'm bothered that the headlines on ZDNet and Slashdot said "Open Source", when in fact the study was just about Linux.

We currently have the following on our Intranet.
Web based email - IMP
Global address book - Openldap
Search engine - htdig
Discussion groups - Hypernews

PHP and Apache will need to be installed to get things going.

You can view M$Word documnets with mswordview which is installed with IMP.

A lot of what you may need is on SuSe 6.2 which may make it easier to be sure that the right libraries etc exist

I am suprised that no one else has mentioned them yet...(maybe I missed someone's comments!..forgive me if I did)

I gather that your goal is to support thin Clients using a simple, common architecture...

Java Servlets combined with HTML/JavaScript and JSP(Java Server Pages) and JSSI(Java Server Side Includes) provide a large amount of power and flexibilty and in my opinion, achieve excellent thin-client support rather nicely.

Further, Servlets are specifically designed to support HTML and the Thin-Client paradigm.

After writing C/C++ CGI database apps, dabbling in Perl with CGI, using Oracle's app server solution, and writing Applets(I detest applets...), I decided that Servlets are SOOOO much better than any other solution.

There are many implementations(Open Source too!) of the Servlet architecture including my favorite: Apache JServ

To give an idea of the capabilities, I have written servlets which allow password/account maintenance in databases, an entire travel agency system, and even a servlet which acts as a fully-enabled SQL client.

One of these days I'll write that telnet servlet...(hehe) I don't remember the location, but somewhere I saw a survey which showed that over 40% of all new Java applications were based on servlets.

Since Java XML intergration/interaction is increasing rapidly, I suspect that Servlets will gain an even larger part of web computing as XML becomes more widely used and accepted.

Im my opinion, Sun should have been pushing Java for the server long ago...and they should stop shoving Linux aside and accept it as the future.

In any case, check out Java Servlets. I don't think you will be disappointed.

Christopher Fitch

Zope is extensible in Python. The ACS is a large package of tcl code that accesses the AOLserver API (AOLserver is now also free as in speech). Both encourage a style of programming that is more maintainable than Perl. If you knew Perl already, I strongly doubt you'd have asked your question. That's actually a good thing -- the same things that make Perl great for simple one-shots make it tough for novices to maintain. Python (and to a lesser extent, tcl) is a great deal cleaner.

I didn't mention Java or Jserv -- there is a package called JetSpeed which the Java-Apache group has put out, but my initial reaction was that it was very slow. Don't take my word for it, though -- take a look and decide for yourself.

Don't be an idiot and lock yourself into Yet Another Uncaring Vendor. You can get support for Zope or the ACS direct from the developers (Digital Creations or ArsDigita respectively). If you choose to use mod_perl and postgres, you still can get professional support. With Lotus you can look forward to servers that don't write log files, proprietary APIs, flat file "databases", and other such niceties.

Don't buy into it.

Zope is extensible in Python. The ACS is a large package of tcl code that accesses the AOLserver API (AOLserver is now also free as in speech). Both encourage a style of programming that is more maintainable than Perl. If you knew Perl already, I strongly doubt you'd have asked your question. That's actually a good thing -- the same things that make Perl great for simple one-shots make it tough for novices to maintain. Python (and to a lesser extent, tcl) is a great deal cleaner.

I didn't mention Java or Jserv -- there is a package called JetSpeed which the Java-Apache group has put out, but my initial reaction was that it was very slow. Don't take my word for it, though -- take a look and decide for yourself.

Don't be an idiot and lock yourself into Yet Another Uncaring Vendor. You can get support for Zope or the ACS direct from the developers (Digital Creations or ArsDigita respectively). If you choose to use mod_perl and postgres, you still can get professional support. With Lotus you can look forward to servers that don't write log files, proprietary APIs, flat file "databases", and other such niceties.

Don't buy into it.

Have a look at JetSpeed (http://java.apache.org/jetspeed). It is still work in progress, but it is nice.

Jakarta was contributed last weekend to the Apache project under the Apache license (Open Source).

It's a servlet 2.2 engine. Runs by itself as a web server. Works fine with Linux 2.3 KHTTPD. Will plug into Apache soon too. Supports JSP.

SCSL isn't the entirety of Sun's thought on interacting with developers. The fact that executives tout it (Bill Joy is not a real developer any more!) is why it gets so much noise; too bad the other opinions don't seem to have any real visibility.

Of course, I happen to believe that Sun donated this code to Apache since they wanted to be "out" of the really Open end of the biz. By doing this they ensure that a good open source servlet engine exists, and can take the development resources that were doing a web server and apply them to areas where it'll be a lot harder for someone else to create a technology, like an EJB distributed transaction framework.

Have you tried MySQL ? or Postgresql ? They both match the criteria of mid-sized SQL database backend.

You should also have a look at Apache/PHP.

I also regurarly see postings on Freshmeat of a tool to translate ASP scripts to PHP. The tool is called ASP2PHP

The uptime of apache and apache/php can be considered a non-issue. They are at least as stable as IIS/ASP and probably even more stable and faster.

RedHat 5.2 is ancient, apache 1.3.3 is buggy (insecure? quite possibly)... so thanks for the information!

Just an idea... I wouldn't have let loose what it was running on, myself - but then again, it would be interesting to see if they have crack-attempt logs in the manner of antionline, and so on...

I recently have been hacking with Apache JServ and GNUJSP.

The combined force of Java servlets on one hand, and content/presentation separation of JSP (and maybe XML with Cocoon, which I haven't really played with yet) seem to me like an ideal e-commerce solution, as any existing infrastructure can be tied to a Java API these days.

But, as much as I appreciate the work of the Apache Java people, I believe an extra layer of abstraction is needed, a web-application Java API. Wouldn't be nice if any score of developers and small companies could sell/license specialized Java classes that could be dropped in the same web-application framework?

I'd really like to see a company that would support such a standard, collect and standardize the different classes, and compensate the developers appropriately. So, for example, a small company could develop a shopping-cart class. Then, the 'brokerage' company would tie in this class with the rest of the application and sell the entire application to a client, providing support: the developers of the shopping cart class would get a pre-agreed-upon share of the sale and support fees. And of course, to create more competition they could also license the same class to any number of 'brokerage' companies...

Does anybody else out there want something like this? It's not exactly open source, it's more like open API/standards, but hey, small-time developers have to eat too ;-)...

Using this standard, you can write the logic of your app and use the app server's tools to deploy it, and not spend time worrying about partial failures, network synchronization, how fine grained access control is managed, and all the other problems associated with distributed programming. And it doesn't mean you have to be a java fanatic -- the latest ejb spec isn't even based on rmi, it aims for iiop compliance instead.

A couple of open source ejb app servers to consider:
EJBoss
JOnAS

Also take a look at the ejb-friendly xml work at Enhydra and of course, the world's greatest servlet engine, Apache JServ.

Really? If that is true, why hasn't apache always run on NT? From http://www.apache.org/info/apache_nt.html:

(December 22nd 1996)

Apache has been ported to a very wide array of Unix boxes - in fact, we're not aware of any Unix boxes which Apache can't run on. This has been possible by making conservative architecture decisions, by modularizing the code as much as possible, and sticking to POSIX and ANSI wherever possible (and functional).

However, due to the code's legacy, and use of metaphors and systems which are Unix-specific (such as, having multiple processes all accept()ing connections to the same port), the road to porting to Windows NT has not been a pretty one.

Things are better now, but if C were completely portable (and useful in its entirely portable form) then this would never have happened, would it? Even now, I'd be highly surprised if the apache source code didn't have a few #IFDEFs in...

Having been involved in porting a commercial product from Tru64 Unix to Solaris and Linux (which shouldn't be nearly as hard as going to NT), I can say that it's not as easy as you might think - especially when intricate optimisation (not to mention multithreading) is involed.

Jon

I have been hosting www.exaflop.org with Alabanza for several years and I've generaly found them to be pretty good. When we first signed up with them they were far nicer, it was a small outfit and they would bend over backwards to make us happy. These days they are huge and we have had a couple of troubles with them. We asked recently for a couple of new Apache modules to be installed, primarily mod_expires and we were told it just wasn't possible.

Can anybody tell me why mod_expires isn't compiled in by default, it seems like a pretty fundamental peice of functionality to me.

In my opinion, any web page generation technology that does not use XML and XSL to seperate content, design, and logic is a short-term solution at best. The benefits of using XML and XSL are too profound to ignore - seperation of content from design means that it's easy to produce views of your site tailored for the client - be it lynx, Netscape, Palm, even a Flash movie player if SVG ever achieves widespread support.

Conversly, it's a breeze to maintain multilingual sites. Using XML as both the input and output format for dynamic page creation modules means much more reusable modules and, ideally, language independence when choosing modules. Since XML/XSL aware clients are on the way, it will soon be possible to offload page rendering to intelligent clients and do the processing server-side for dumb ones. Oh, and did I mention that it's open source and uses an open source XML parser, open source XSLT processor, open source source XSL FO renderer, and optionally an open source ECMAScript interpreter? :)

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

I found the C API to be very well documented, and the examples I found on the web were fairly concice and illustrative.

Then could you share with us where on the web you have found useful documentation for the C API? I sure would like to find such a thing, and do not believe that it exists until someone proves otherwise. The part of the API spec in the online manual that are finished are fine; but there are very large and important areas that are not covered at all. In some places, the author evidently did not get past his outline (here's an example).

This is a gap that evidently needs to be filled in by the book.

Why anyone would want to burden their server with modules written in Perl is beyond me though.

I have written an Apache module in C and quite a few handlers in mod_perl, and the advantage of mod_perl is just as the same as any Perl programming over C -- you get a lot more done a lot more quickly. I can get a handler done in mod_perl in an hour that would probably take me all day if I wrote it in C. A C module forces you to spend too much time memory management, string twiddling and core-dumping, and Perl is a great relief from all that.

To be sure, sometimes you need to squeeze every last bit of speed out of your software, and that's when you probably need C instead of Perl. That's why I wrote the Apache module. But if you need to program to the Apache API in a hurry, mod_perl's the thing.

I found the C API to be very well documented, and the examples I found on the web were fairly concice and illustrative.

Then could you share with us where on the web you have found useful documentation for the C API? I sure would like to find such a thing, and do not believe that it exists until someone proves otherwise. The part of the API spec in the online manual that are finished are fine; but there are very large and important areas that are not covered at all. In some places, the author evidently did not get past his outline (here's an example).

This is a gap that evidently needs to be filled in by the book.

Why anyone would want to burden their server with modules written in Perl is beyond me though.

I have written an Apache module in C and quite a few handlers in mod_perl, and the advantage of mod_perl is just as the same as any Perl programming over C -- you get a lot more done a lot more quickly. I can get a handler done in mod_perl in an hour that would probably take me all day if I wrote it in C. A C module forces you to spend too much time memory management, string twiddling and core-dumping, and Perl is a great relief from all that.

To be sure, sometimes you need to squeeze every last bit of speed out of your software, and that's when you probably need C instead of Perl. That's why I wrote the Apache module. But if you need to program to the Apache API in a hurry, mod_perl's the thing.

I found the C API to be very well documented, and the examples I found on the web were fairly concice and illustrative.

Then could you share with us where on the web you have found useful documentation for the C API? I sure would like to find such a thing, and do not believe that it exists until someone proves otherwise. The part of the API spec in the online manual that are finished are fine; but there are very large and important areas that are not covered at all. In some places, the author evidently did not get past his outline (here's an example).

This is a gap that evidently needs to be filled in by the book.

Why anyone would want to burden their server with modules written in Perl is beyond me though.

I have written an Apache module in C and quite a few handlers in mod_perl, and the advantage of mod_perl is just as the same as any Perl programming over C -- you get a lot more done a lot more quickly. I can get a handler done in mod_perl in an hour that would probably take me all day if I wrote it in C. A C module forces you to spend too much time memory management, string twiddling and core-dumping, and Perl is a great relief from all that.

To be sure, sometimes you need to squeeze every last bit of speed out of your software, and that's when you probably need C instead of Perl. That's why I wrote the Apache module. But if you need to program to the Apache API in a hurry, mod_perl's the thing.

As much as I like Apache, I doubt their license will be acceptable as "free software" by FSF's definition. 'Tis really a shame, though...

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.

Try jmeter from the apache group. You can find it at the Java Apache site

Sections books
ask slashdot
features
radio

This page was generated by a Swarm of Psycho Chickens for justo (2858).

Slashdot Load Testing (Continues) Posted by CmdrTaco on Mon August 30, 02:13 PM EDT
from the ain't-this-fun? dept.
Fixed so far:

• Dropped http MaxClients down to 75
• increased mysql max_connections to to 250

( Read More... | 190 of 190 comments )

Help Test Our New Server! Posted by CmdrTaco on Mon August 30, 12:51 PM EDT
from the load-testing-is-cool dept.
So here it is: A mirror of Slashdot (as of a week or so ago). It exists now for testing: So feel free to post comments and help test the new load balancer. For the curious, the new system has 3 http machines (P2s) and one mysql box (a dual P2) with a load balancer trying to keep everyone all equally busy. And its about time: the old setup has been really stressed out trying to keep up with everyone. Anyway, don't get to attached to any of your comments here, when we're satisfied that the new setup is stable, I'm gonna mirror over Slashdot and make the final switcheroo.

( Read More... | 335 of 335 comments )

Interview: Mandrake Answers Posted by Roblimo on Fri August 20, 12:00 PM EDT
from the x-leads-to-enlightenment dept.
Monday a whole bunch of people had questions for Mandrake, one of the heavies behind Enlightenment. Slashdot Moderators picked the best ones. We forwarded them, unedited, to Mandrake on Tuesday. His (excellent) answers appear below.

( Read More... | 11562 bytes in body | 9 of 9 comments )

Geeks in the Space: The Attack of 5 Posted by Hemos on Thu August 19, 04:10 AM EDT
from the more-stuff-to-listen-to dept.
Well, we've done it again. Yes, Geeks in Space, Episode 5 has been released. In it, we lament the lack of good news, talk about anti-matter, and the hiring of hacks by companies. You can also become...educated in my long-term plan for the hostile takeover of a certain Redmond-based company.

( Read More... | 14 of 17 comments )

Apple announces Darwin 0.3 Posted by Hemos on Thu August 19, 12:24 AM EDT
from the more-to-download dept.
J. FoxGlov writes "Macintouch reports that v0.3 of Darwin, the open-source foundation for Mac OS X Server is available on Apple's Public Source site. Apple Developer Connection members can get it on CD for $29. Check Public Source for more about the Darwin SDK and the new Darwin. "

( Read More... | 67 of 68 comments )

Microsoft's New Audio Format Cracked Posted by Hemos on Wed August 18, 05:23 PM EDT
from the secure-this-buddy dept.
Barcode (JPB) was one of the first to send us the word from Wired that the new audio format Microsoft introduced (Two days ago), supposed to be a secure format (resricting playback) has already been cracked. Dimension Music first carried the news-and what a name the crack has *grin*.

( Read More... | 238 of 240 comments )

Find your Star Wars Twin Posted by Hemos on Wed August 18, 05:16 PM EDT
from the what-freud-really-wanted-to-do dept.
The_Monk writes "Ever wanted to know your Star Wars twin? Now this incredibly important information can be verified. It placed me the likes of Astro Mech Droids, 'Tarkin, and R2-D2. " Ahem-as the lost twin of Lando (extraversion), I have a Cloud City I'd like to sell someone. But I'm about as agreeable as Boba, always a bonus.

( Read More... | 94 of 94 comments )

Now Police Can 'See' Through Walls Posted by Roblimo on Wed August 18, 12:40 PM EDT
from the move-along-there's-nothing-to-see-here dept.
Bram writes "Just found an article about another way to invade privacy." He's talking about hand-held radar systems police can use to detect breathing, beating hearts or other motion through walls and other obstacles. Sounds like a declassified version of the Ground Support Radar [GSR] units we used years ago in the Army. I can see why police would want them, and I can also see why Bram considers them a privacy threat. Depends on how they're used, I suppose.

( Read More... | 205 of 205 comments )

FreeType posts patent warning Posted by Hemos on Wed August 18, 11:53 AM EDT
from the i-want-my-verdonna dept.
Anonymous Coward writes "According to the the FreeType web page, there have been some new concerns raised about Apple's patents on TrueType. I hope this doesn't affect the planned TrueType support in XF86 4. " It appears that they are still checking into the issue, but I'd really like TrueType support. A lot. Let's hope Apple responds nicely.

( Read More... | 202 of 206 comments )

Microsoft to "publish code" to Instant Messenger Posted by Hemos on Wed August 18, 09:49 AM EDT
from the want-more-market-share dept.
VFVTHUNTER writes "According to this article at cnet, MS, in an attempt to gain a share of AOL's Instant Messenger Service Market, announced today it is going to publish the protocol to its own messenger service. " It's important to note it's NOT the source code, just the protocol.

( Read More... | 192 of 192 comments )

natelinx

ai

bsi

cnn

smug

garden

taco hell

superbad

mod_perl

everything

space ghost

oostendorp.net

Be News

Unisys gif-lzw-license Model Changed

YMF724 Driver Patch

Guidelines for Sane Advocacy

BeNews Is Moving - Outages Planned

Audio Buzz "Fixes" Announced

Austin BUG Meeting This Wednesday

Wacom Driver Goes Open Source

3dsound Secrets Revealed

ACE Bot, Devastation for Quake2

Be.com Frontpage Layout Updated Get more Be...

Alta Vista Search Alta Vista

any language Chinese Czech Danish Dutch English Estonian Finnish French German Greek Hebrew Hungarian Icelandic Italian Japanese Korean Latvian Lithuanian Norwegian Polish Portuguese Romanian Russian Spanish Swedish

Q3Arena.com

Quake3 Launcher

Site Movement

New Carmack Worklog

NMS v3.0

NOP v2.1 Released

etc.

Game Name Builder v1.32

John Carmack Updated His .plan

Voice Actors Needed

KOTS Mod Needs Servers

More Ass Kicking Quake Action...

Dr. Dobb's TechNetCast

Open Source At Work

LIVE From LinuxWorld

What's Wrong with HTTP and Why It Doesn't Matter

Inside the BeOS

A Brief History of Unix and the Internet

Author of sendmail on open-source and early days of email

Linus Torvalds on State of Linux

Creator of Tcl/Tk: Open-Source Creates Commercial Opportunities

Inside the Netscape Gecko Open Source Browser Team More TechNetCast

Hollywood Bitchslap

Review: Bowfinger - 'Funniest Eddie Murphy movie in a decade. Steve Martin showed...'

Review: Mickey Blue-Eyes - 'Not as funny as it could have been'

Feature: Robert Towne - From Chinatown to Hollywood. More from Hollywood Bitchslap

Slashdot Poll Preferred Compression
zip
gzip
bzip
compress
arj
other
[ Results | Polls ]
Comments:383 | Votes:24104

Crazy Person

Lunch

The Funnies (?)

User Friendly

Red Meat

Dilbert

Sluggy Freelance

Bastich

Punc & Mark

Helen

Goats

Pokey the Penguin

Superosity

Kevin & Kell

Doonesbury

The Fifth Wave

Features The latest installment of Geeks in Space is up at The Sync. We talk about the Red Hat IPO, crazy naming schemes, and much more.

Perhaps you are seeking Jon Katz's series of articles related to recent events in Colorado. These articles include Voices from the Hellmouth, More Stories from the Hellmouth or The Price of Being Different,

With all the hype about the recent MindCraft Linux/NT benchmarks, you might be interested in reading ESR's Response to the Mindcraft Fiasco

For something different, try reading my little essay Thoughts from the Furnace about the internet, and flame.

Update: 05/03 01:48 by CT : Past Features

Mozilla.org

PerLDAP v1.4 Released

M9 Released

Mozilla BOF at O'Reilly OSS Convention

cvs-mirror.mozilla.org Is (no longer) Sick

Mozilla Birds-Of-A-Feather Session

Getting Involved

Blackwood

Bugathon Needs JavaScripters

News From The Front

M8 On The Wire

Mozilla for BeOS

Mozilla is Alive and Well

BugAThon 300

New Newsgroup Announcements

M7 Binaries Released

Slashdot

Load Test the New Slashdot Setup

Microwave T1 Service

Internet Tax Moratorium Over?

Feature: Is Open Source for Windows Less Important?

Interview: Ask Alan Cox

3rd State of the Perl Onion

LinuxPPC challenge rides again

Review: The First 20 Million is Always the Hardest

Star Office to become Open Source?

Palm Gameboy Emulator update & screens

Linuxnewbie.org

Your Hotmail Account Has Been Exposed

Securing The Home Linux System: Updated

Glibc2 Slackware is here!

Segfault.org: South Park Story

TWO New Slackware Mailing Lists More LinuxNewbie.org...

Freak Tech

Molecular-based logic gates

10 Gbps optical though air.

Magnetic spacecraft propulsion

Linuxdev.net

Interview with Borland Sr. Product Mgr

Gizmo3D v0.92 Released

CORBA 3 News

More On XHTML 1.0

Oracle Offer Linux Technology Track More LDN...

Wired Webmonkey

Webmonkey Guides

Cheap and Cool Photos

Hiring a Site Developer

Searching for Mr. Burrito

Introduction to Apache

Why Ask Why?

PHP/MySQL Tutorial

Wait for It More Webmonkey

Older Stuff

Wednesday August 18

Scientists create digital bug-life (131)

New Space Propulsion System Uses Sun's Magnetic Field (120)

Cassini visits Earth (175)

Descent 3 Linux Client (71)

Tuesday August 17

Playstation 2 Outperforms Everything? (240)

SIGGRAPH '99 OpenGL/Linux BOF Minutes (37)

Dell Belgium forced to install Windows only? (75)

Relativity Used to Devise New Form of Crypt (24)

Robots Battle to the Death! (124)

Will PPC Become the Preferred Linux Platform? (277)

IBMs 15 hour Laptop Batteries (72)

Feature: After the Red Hat IPO Ball is Over (236)

Feature:Obscurity as Security (194)

l0pht develops Sniffer Sniffer (101)

NASA collecting anti-matter with giant ballon (109)

CIA releases its own X-Files (111)

Packet Storm Security is back (36)

Monday August 16

Sun Claims MS Steals Vision (162)

Scientists Find Evidence of Black Holes Sucking (163)

MS Dirty Pool Against AOL? (204)
Older Articles
Yesterday's Edition

Weather24.com
(city, state or zip)

Don't kid yourself. Little is relevant, and nothing lasts forever. All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-99 Andover.Net. [ home | awards | supporters | rob's homepage | contribute story | older articles | Andover.Net | advertising | past polls | about | faq ]

-=-=-=-=-

Yes, I forgot about www.apache.org. Indeed, their server run FreeBSD. In addition, FreeBSD is (or at least was the last time I checked) their main development platform. As for that M$-owned company, I did not include it due to flamers/ac's/etc.

• Web Server: FreeBSD 3.2-STABLE with Apache 1.3.9 / PHP 3.0.9 on a PII-400 w/128 Meg RAM, IBM 4.55G U2W Drive. Due to FreeBSD's proven track record for Web/Network performance, stability, and security (e.g. Yahoo, wcarchive, and others), it's a natural.
• SQL Server: Linux 2.2.x with MySQL 3.22.25 on a PII-400 w/256 Meg RAM, IBM 4.55G U2W System Drive and a Mylex AcceleRAID 250 w/4 IBM 4.55G U2W Drives in a RAID-5 configuration. Linux was the obvious choice when considering MySQL performance and driver availability wrt RAID controllers.

• Apache: Ensure you have adequate spare servers to handle the connections (StartServers, MaxSpareServers, MaxClients, and MaxRequestsPerClient in the config); nothing sucks more than clients not being able to connect. Also, if you are using embedded script of some sort (PHP, Perl, etc.), use modules compiled into Apache (mod_perl, etc.); this should significantly increase speed and decrease the overhead of reloading the module for each access.
• MySQL: Tweak the applicable setting as appropriate. We increased (usually doubled in most cases) the following: Join Buffer, Key Buffer, Max Connections, Max Join Size, Max Sort Length, Sort Buffer, and Sort Buffer). If possible, depending on the amount of data, get as much memory in the system as possible. If the OS can maintain frequently used data cached, disk access won't be required which significantly increases the speed of queries, etc. In addition, get rid of that pre-compiled MySQL and compile it yourself. If possible, optimize using egcs/pgcc for your platform. Also, compile mysqld statically; this will increase it's memory overhead a bit but can increase it's speed by 5 - 10% by not using shared libraries.
• Storage: For optimum speed, use SCSI (of course). For our data, we require RAID 5 for redundancy. If that is not required, RAID 0 (striping) can be used for increased speed. The optimal way is to use hardware RAID (external RAID or RAID controller). Luckily, Linux has drivers for quite a few different RAID controllers that are available for a reasonable price.
• Linux: Beware of Redhat's security problems, disable all unnecessary services, et. al. Seek out security-oriented and Linux performance-tuning sites for more suggestions.
• General: Don't skimp on hardware. A cheap component, be it a drive, network card, motherboard, or whatever, if it fails, will cause unrecoverable downtime. We decided on Intel NL440BX boards (serial console/BIOS support is nice), PII-400's, and IBM SCSI drives in both boxes. If one box were to have a catastrophic failure, the other is able to perform both webserver and SQL server functions if necessary. We can also simply replace a failed component with one pulled from a similarly-configured non-production (test) box, or just swap boxes altogether.

Some other ideas, are to split image serving onto it's own apache, not necessarily it's own box. This apache can be completely pared down to absolute minimum modules, since all it will be doing is serving up static images. It also let's cache be used efficiently, since mostly the common images will be stored. As opposed to common images contending with common text files for cache space if images and content are served from the same apache.

Also, what are you using in apache to create dynamic pages and connect to the db? Use long running processes where possible, which means pick mod_perl, php, fastCGI, servlets, etc... over plain cgi scripts. This will save you lots of cycles and also let you have persistent db connections. Always a very good thing.

Taking the splitting out of machines to the next level, you could also try splitting all of your dynamic content to it's own machine, mod_proxied through your front end apache's. This makes the front ends very small since they barely need any modules installed at all. It also gets some extra performance out of your dynamic content apaches. Of course you're running a lot of boxes now. :)

Read this if you're running mod_perl. And read this to optimize your db.

The apache website does have news about 1.3.9 here. Rikard

There is an ASP to PHP converter, and an ASP addon for mod_perl.
Also, Apache does support servlets with the jserv module available from java.apache.org. There is even JSP, and GSP which i like better. Available from www.bitmechanic.com/gsp -Lkb

• portability library
  
• DAV
  
• multiprotocol support
  
• performance improvements
  

Try Apache's own notes on performance, by Dean Gaudet. Hope that helps.

You're wrong. Servlet supports been in there for some time as a module. It's available at this site. It works fairly well, despite Java running like a dog under Linux.

There's even a JSP site out there. I just can't be bothered right now to find it. I'm sure someone else will.

The changelog is at ftp://ftp.apache.org/dist/CHANGES_1.3, for those of you too lazy to look for it.

Apache does not currently support Servlets (much to my personal dismay). There is currently the Jakarta project which is developing a free (speech) %100 Pure Java Servlet and JavaServer Pages implementation. This is planning on merging eventually w/ the apache project. If I am wrong about servlets w/ apache PLEASE correct me.

It's official: Reading Slashdot is actually better than relying on primary sources.

I recently began coding a module for Apache for the first time, and thus got to find out how well the API is documented. I'd say about half of what a programmer needs to know is formally documented, and the rest you have to get by looking through the include directories and at other people's code.

The HTML manual pages in the distribution include a section about the module API, which is quite thorough in some areas, but some of the sections have so far not got past the author's outline. Naturally, some of those incomplete sections cover topics I needed to know more about over the course of my project. I'd say this document is a pretty common specimen in software engineering: The author probably spent as much time as he could with it, and did a very good job in some parts but didn't have time to finish the rest, and it had to get distributed with the software in this incomplete state, or else the distribution never would have happened at all.

There's also a mod_example.c with illustrations of the various handlers. Working sample code like this is a great help, obviously, but mod_example.c isn't perfect either, particularly because it doesn't seem to have been updated for API version 1.3.

All of this helps you understand the general architecture and philosophy of Apache server configuration and request handling, but you'll never get a module written without looking at other module code and perusing include/*.h. For one thing, most of the really useful explanations I've found are programmer comments in the source code. Also, this is the only way you can find out about the useful and tested function calls in the package. Apache has a rich supply of useful code, for everything from MD5 hashing to output formatting to iterating over the request headers and who knows what all, and I've often caught myself trying to re-invent some wheel or another before I realized that another Apache developer had already got the job done.

So what can we conclude about this? The Apache documentation for programmers could clearly be much better, but that has evidently not prevented it from being a remarkably successful project -- and the module API is one of the principal reasons for its success. I guess this is just a fact of life. Good software cannot be completely undocumented, but in all likelihood the documentation will be spotty, very good in some areas, incomplete and out of date in others. The project programmers will always view documentation as a secondary priority. If you really need to know exacly what's going on, there is no substitute for reading the source code.

I recently began coding a module for Apache for the first time, and thus got to find out how well the API is documented. I'd say about half of what a programmer needs to know is formally documented, and the rest you have to get by looking through the include directories and at other people's code.

The HTML manual pages in the distribution include a section about the module API, which is quite thorough in some areas, but some of the sections have so far not got past the author's outline. Naturally, some of those incomplete sections cover topics I needed to know more about over the course of my project. I'd say this document is a pretty common specimen in software engineering: The author probably spent as much time as he could with it, and did a very good job in some parts but didn't have time to finish the rest, and it had to get distributed with the software in this incomplete state, or else the distribution never would have happened at all.

There's also a mod_example.c with illustrations of the various handlers. Working sample code like this is a great help, obviously, but mod_example.c isn't perfect either, particularly because it doesn't seem to have been updated for API version 1.3.

All of this helps you understand the general architecture and philosophy of Apache server configuration and request handling, but you'll never get a module written without looking at other module code and perusing include/*.h. For one thing, most of the really useful explanations I've found are programmer comments in the source code. Also, this is the only way you can find out about the useful and tested function calls in the package. Apache has a rich supply of useful code, for everything from MD5 hashing to output formatting to iterating over the request headers and who knows what all, and I've often caught myself trying to re-invent some wheel or another before I realized that another Apache developer had already got the job done.

So what can we conclude about this? The Apache documentation for programmers could clearly be much better, but that has evidently not prevented it from being a remarkably successful project -- and the module API is one of the principal reasons for its success. I guess this is just a fact of life. Good software cannot be completely undocumented, but in all likelihood the documentation will be spotty, very good in some areas, incomplete and out of date in others. The project programmers will always view documentation as a secondary priority. If you really need to know exacly what's going on, there is no substitute for reading the source code.

Here's what Netcraft has to say about it: www.alltheweb.com is running Apache/1.3.6 (Unix) PHP/3.0.11 on FreeBSD .

Both Apache and FreeBSD are well-proven OpenSource software projects. I imagine this is going to be very stable ;)

So long as the 2.0 servlet API suits your needs, you can use JServ with apache. I'm pretty happy with it so far.

One thing that might make the circle even more complete is the fact that Hyperreal is on the same server as http://www.apache.org/. Hyperreal has a lot of information on electronica and I believe the Aphex Twin FAQ lives there too. It also hosts the IDM (Intelligent Dance Music) mailinglist on which Richard James or many of his other names gets mentioned.

About my only contribution to open source software has been adding Solaris support to XMMS; I've put a fair bit of work into it, but others have been forthcoming with patches, modifications and rewrites. Nobody has tried to claim excess credit for work or tried to fork it off, perhaps because I've been willing to accept that (a) I am not a brilliant programmer and (b) others can do it better. Noone has insulted me or called me names (one person said the code was a mess, but I agreed with him; he was one of the coders who supplied fixes). In short, my only experience within open source software has been good.

Open source projects can be very successful; just look at Apache, which has scores (hundreds?) of developers. However, the larger the project, the larger the requirement for a core developer or small core team to coordinate efforts.

In this case above, the maintainer perhaps couldn't devote as much time as he would have liked to the project (or as much as it deserved?) resulting in Mr J. trying to take over.

The world is full of jerks, and unfortunately some of them use computers. Try to make the world a better place by not being one of them.
--

claims theoretical support for 4 gigs at http://www.freebsd.org/FAQ/FAQ51.html. Cdrom.com has some impressive stats too on their new box. The problem with trying ultra high-end stuff on PC hardware is the best you can really say to your boss is that it should work. Companies like Sun or SGI have already deployed hundreds (if not thousands) so you shouldn't end up with any suprises along the way.

Another alternative could be to buy a bunch of smaller (high end P2 and moderate memory+disk) clones and set a bunch of those up. New videos would be added to the servers in round-robin order and more popular videos could be placed on multiple servers. Now you would have one (or maybe more for reliability) redirectors which could redirect the request to the right server using mod_rewrite. Through the use of an external program (which would do a database lookup most likely), the user could be redirected to the proper server based on regular expression patern grabbing from the URL. See the "External Rewriting Engine" part in the Rewrite guide. It is also possible to transparently proxy the request so the user never sees http://www19.example.com/ugly/url/movie.xyz, but you probably aren't http streaming your movies anyway.