Ticketmaster, rather than paying some techies to FIX the problem, paid some lawyers to file a frivoulous suit that had no merit, and which could have set a very dangerous precedent, had the judge and appeals court been clueless (this is ENTIRELY possible; read a random sampling of early decisions related to the internet).
Actually, it's very difficult to solve this problem with technology. Things like User-agent, Referer, and other HTTP headers are trivial to forge, which leaves you with blocking specific IPs. If the offending site is using frames, then it becomes impossible to tell "real" traffic from the tickets.com links. If you don't allow any legitimate customers to frame your site, you can use frame-busting javascript, but the ticketmaster.com site uses frames.
It's an odd quirk of fate that made this woman famous. When Netscape put out the first version of Navigator, they chose to handle displaying multiple images with different color palettes on 8-bit color systems by dithering everything to a 6X6X6 color cube. This information was freely available in the support section of their site, although it wasn't obvious to look for it there. Check out the date on this technote:
Big-time designers fresh out of classes in multimedia made 32-bit images on their enormous Macintosh monitors and then wondered why they looked so bad on the web.
In the multimedia company where I worked, I was the techie who learned about the web, figured out what worked by reading usenet and Netscape's technotes, and then taught the designers about it.
After I'd been doing this for a year or so, Lynda's first book came out. It wasn't great, and contained a few technical mistakes about image formats and when to use which one (I don't think she knew much about how JPEG compression worked), but it gave some simple advice about color palettes that Photoshop jockeys could understand, so I happily let the designers learn the ropes from her book instead of me. A few months later, everyone had a copy of her book.
These days, they all know this stuff cold. Of course, most people have better than 8-bit color now too.
Sad to hear that she's promoting something as evil as Flash now. Maybe she should do a nostalgia tour with Laura Lemay, destroyer of trees.
20% as fast? No way. 20% slower maybe. But either way all you're saying is that your proxy server isn't as good at talking HTTP as your FastCGI server is at talking its own protocol. Naked HTTP communication doesn't add much to the content except a few headers, so this should be fixable just by improving the HTTP proxy code to be as efficient as the FastCGI networking code.
If separating content from presentation is what you're after, take a look at the Perl module "Template Toolkit" on CPAN, or look at http://www.freemarker.org/ or http://www.webmacro.org/ for Java.
Don't fall into the application server trap. Think about what they're telling you. If you load-balance your Java servlet runners, you will still have to come up with a separate solution for load-balancing your web servers in front of them.
Ultimately the proof is in the pudding. None of the big sites use commercial application servers for anything they really care about. I know people who work at Yahoo, Amazon, and others, and they use home grown stuff, often with Apache, and often in C or Perl. You can make a fast system with any number of open source tools like PHP, mod_perl, Resin, AOLServer, etc.
Your search speed issues can be fixed if you put MySQL on a box with enough RAM to keep most of your data in memory and use proper indexing. For full text searching, you want to build an inverted word index of your documents. There are plenty of examples in Perl that you can steal from if you need help. Try looking up the module Search::InvertedIndex on CPAN, or search the Dr. Dobb's Journal archives for an article about this subject.
Now, you need to do some load-balancing. For a good overview and some possible options, read this: http://www.engelschall.com/pw/wt/loadbalance/
Then check out some of the links to IP-level load-balancers at http://perl.apache.org/guide/download.html#High_Av ailability_Linux_Project.
There are probably some good FreeBSD-based projects as well, since products like big/ip and Coyote Point's Equalizer are based on it.
FastCGI is a good technology, but the problems you describe with mod_perl have a pretty simple solution. You just use mod_perl as an application server and put a reverse proxy (like Squid or Apache + mod_proxy) in front of it to serve static requests.
I was involved in this test. As someone else pointed out, we didn't write the Java; the guys at caucho.com did. All we did was fix the Perl code. I have to assume the Java code was written with speed in mind, since it was used to highlight the speed of their JSP tool.
This was simply a test between two programming environments we were considering. The results came out close enough that we decided we couldn't make a decision based on performance and ended up making it based on other factors.
Caucho's Resin is great, but don't underestimate the performance of mod_perl.
It will be very interesting to see if we get a bunch of posts here condemning DoS attacks, after the huge number of people who posted instructions and even scripts for executing these attacks on the Slashdot stories about eToys. If Yahoo did something you didn't agree with, would you consider it ethical to DoS them? Personally, I have a hard time thinking of any reason whys omeone would hate Yahoo.
Women (stereotypically, but also truthfully) like conversations, complex rewards, stories, and... thinking.
I've read this kind of statement before in interviews with people who claim to be experts on female gaming, but I have observed just the opposite. Women don't often like games that require a great investment of time just to get started on. The games I've seen women go crazy for are not social simulations, but very abstract games like Tetris or Minesweeper or solitaire.
Anyway, my girlfriend loves Soul Calibur and she can kick my ass at it.
Well, actually, etoy did do some things to increase the confusion of visitors who got there by accident. They did that whole faux stock thing and they put pictures of toys on their homepage. So, they were trying to gain something from confusion with the eToys trademark, which is basically what that whole lawsuit was about.
Well, it was supposed to be all of those things, but instead it turned out to be the most diappointing movie of all time.
Who cares about whether it was a crappy movie? That's hardly relevant - after all, by that same measuring stick, the original trilogy was just about as crappy!
Hardly. Even the wost of the earlier films, Return of the Jedi, was many times better than TPM.
Maybe, if it comes on cable some night, and I have nothing else to do, and my computer is broken, I'll watch it again, but until then I'll stick with the originals.
You will also see that servlets (and Java Server Pages) only fit in the presentation layer. To create a scalable application, you will want to abstract the business logic from the presentation. There are many solutions for business logic, and the Java universe promotes EJB.
Have you ever used EJB? If not, you might want to read this report on the current EJB servers: http://www.techmetrix.com/. It pretty much rips them apart. Point being, just because Sun and a bunch of other app server vendors tell you the technology they're pushing is great doesn't make it so. You may be better off using a more traditional OO development style, even if your project is in Java.
Oh, I see. So, it's okay to use violence if you think the judge who made the ruling isn't smart enough. Thanks for clarifying. I guess the judicicary system can all go home and get some rest now, since you've made them uneccessary.
Seriously, if you think the system is broken, fix the system. Don't just throw it out when you don't like what it produces.
At my company, we benchmarked mod_perl (handlers written to the apache API, not Apache::Registry scripts) against the fastest servlet runner out there, which is currently Resin from http://www.caucho.com/. The guy at Caucho had some benchmarks that showed servlets beating mod_perl and PHP, and we wanted to see if it was true.
What we found was that the perl code in his benchmark didn't take much advantage of mod_perl. When we tried it ourselves, mod_perl beat servlets handily, and servlets actually fell apart doing database access under high loads.
I have a lot of respect for what the Caucho effort and other projects like it are trying to do, but I'm afraid that on Linux the JVMs just aren't fast or stable enough to compete yet.
We tested using the final released IBM JVM on a dual P450 machine with Red Hat 6.
Perhaps I'm missing something here, but how does execute the perl code on a different machine from the web server when using mod_perl? After all, mod_perl is an apache module.
You are missing something here. Tiers do not necessarily mean separate machines. They simply mean separate subsystems. Building your code in a model-view-controller style with objects modeling your data is no harder in Perl than it is in Java, and it doesn't need to split across many machines to make it multi-tier.
This does a lot for the scalability of the application; no matter how big your application, you can simply add more java server machines, and your web server sees no more compute load.
The preferred configuration of mod_perl works exactly the same way, with a vanilla apache server up front serving static pages and images and proxying requests that require processing to backend servers running mod_perl. Even if you don't bother to separate things like this, adding more machines is no harder with mod_perl than it is with JServ.
I've yet to see the technical community (outside of technology corporations) effectively organize on any particular issue. Instead, it tends to rely on civil disobedience to protest poorly written laws (e.g., DeCSS, denial of service attacks on Etoys, etc.). Don't get me wrong, I'm not criticizing the technical community. I'm just pointing out what I think the fundamental disconnect is.
Well, I am criticizing the technical community. Denial of service attacks are a violent and criminal abuse which put their perpetrators in the same league with people who bomb abortion clinics. You don't have the right to use vigilante tactics to enforce your personal political views. Advocacy, education, and working through the judicial system are the right response to these kinds of problems.
You might also want to look at IPC::MM, which implements a hash in shared memory using C code. Should be faster for apps with a lot of read/write access.
Clone it? let's not. I've used NAS and it absolutely sucks. This kind of expensive junkware should be left to die. If you really want to run a website on java on linux (not a good idea with the current state of VMs on linux) you should look at Enhydra, Locomotive, or GSP. All of these are more useful than NAS.
"And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you. The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent."
That's completely untrue. I've used Netscape's "application server" and it's just junk. We were running on big Sun hardware with the latest optimized JVM, and it still didn't perform well or reliably. The clustering features are no replacement for a load-balancer in front of the webservers, and it's not difficult to share session/state information between machines using a database. There is no reason to buy this stuff. Just use the good open source stuff (mod_jserv, mod_perl, PHP) as a base and write your app on top of it. Most people end up hacking lots of stuff onto these app servers anyway to get them to work.
There's nothing magic about JavaBeans. You can program a perfectly good, scalable app using simpler stuff like Gnu Server Pages from http://www.bitmechanic.com/. This won't prevent you from using JavaBeans, but it won't force you to use a certain methodology for your development, and I like that.
You should also keep in mind that Java on Linux is dog slow and probably will be for a while. Java is solid on Solaris and NT, but Perl is currently in better shape on Linux, IMHO.
Slashdot Mirror
Actually, it's very difficult to solve this problem with technology. Things like User-agent, Referer, and other HTTP headers are trivial to forge, which leaves you with blocking specific IPs. If the offending site is using frames, then it becomes impossible to tell "real" traffic from the tickets.com links. If you don't allow any legitimate customers to frame your site, you can use frame-busting javascript, but the ticketmaster.com site uses frames.
So, there is no simple technical solution.
It's an odd quirk of fate that made this woman famous. When Netscape put out the first version of Navigator, they chose to handle displaying multiple images with different color palettes on 8-bit color systems by dithering everything to a 6X6X6 color cube. This information was freely available in the support section of their site, although it wasn't obvious to look for it there. Check out the date on this technote:
4 .html
http://help.netscape.com/kb/consumer/19960513-1
Big-time designers fresh out of classes in multimedia made 32-bit images on their enormous Macintosh monitors and then wondered why they looked so bad on the web.
In the multimedia company where I worked, I was the techie who learned about the web, figured out what worked by reading usenet and Netscape's technotes, and then taught the designers about it.
After I'd been doing this for a year or so, Lynda's first book came out. It wasn't great, and contained a few technical mistakes about image formats and when to use which one (I don't think she knew much about how JPEG compression worked), but it gave some simple advice about color palettes that Photoshop jockeys could understand, so I happily let the designers learn the ropes from her book instead of me. A few months later, everyone had a copy of her book.
These days, they all know this stuff cold. Of course, most people have better than 8-bit color now too.
Sad to hear that she's promoting something as evil as Flash now. Maybe she should do a nostalgia tour with Laura Lemay, destroyer of trees.
20% as fast? No way. 20% slower maybe. But either way all you're saying is that your proxy server isn't as good at talking HTTP as your FastCGI server is at talking its own protocol. Naked HTTP communication doesn't add much to the content except a few headers, so this should be fixable just by improving the HTTP proxy code to be as efficient as the FastCGI networking code.
If separating content from presentation is what you're after, take a look at the Perl module "Template Toolkit" on CPAN, or look at http://www.freemarker.org/ or http://www.webmacro.org/ for Java.
Don't fall into the application server trap. Think about what they're telling you. If you load-balance your Java servlet runners, you will still have to come up with a separate solution for load-balancing your web servers in front of them.
v ailability_Linux_Project.
Ultimately the proof is in the pudding. None of the big sites use commercial application servers for anything they really care about. I know people who work at Yahoo, Amazon, and others, and they use home grown stuff, often with Apache, and often in C or Perl. You can make a fast system with any number of open source tools like PHP, mod_perl, Resin, AOLServer, etc.
Your search speed issues can be fixed if you put MySQL on a box with enough RAM to keep most of your data in memory and use proper indexing. For full text searching, you want to build an inverted word index of your documents. There are plenty of examples in Perl that you can steal from if you need help. Try looking up the module Search::InvertedIndex on CPAN, or search the Dr. Dobb's Journal archives for an article about this subject.
Now, you need to do some load-balancing. For a good overview and some possible options, read this:
http://www.engelschall.com/pw/wt/loadbalance/
Then check out some of the links to IP-level load-balancers at http://perl.apache.org/guide/download.html#High_A
There are probably some good FreeBSD-based projects as well, since products like big/ip and Coyote Point's Equalizer are based on it.
FastCGI is a good technology, but the problems you describe with mod_perl have a pretty simple solution. You just use mod_perl as an application server and put a reverse proxy (like Squid or Apache + mod_proxy) in front of it to serve static requests.
Hey, how much money did Perl make for CmdrTaco and friends?
I was involved in this test. As someone else pointed out, we didn't write the Java; the guys at caucho.com did. All we did was fix the Perl code. I have to assume the Java code was written with speed in mind, since it was used to highlight the speed of their JSP tool.
This was simply a test between two programming environments we were considering. The results came out close enough that we decided we couldn't make a decision based on performance and ended up making it based on other factors.
Caucho's Resin is great, but don't underestimate the performance of mod_perl.
It will be very interesting to see if we get a bunch of posts here condemning DoS attacks, after the huge number of people who posted instructions and even scripts for executing these attacks on the Slashdot stories about eToys. If Yahoo did something you didn't agree with, would you consider it ethical to DoS them? Personally, I have a hard time thinking of any reason whys omeone would hate Yahoo.
I've read this kind of statement before in interviews with people who claim to be experts on female gaming, but I have observed just the opposite. Women don't often like games that require a great investment of time just to get started on. The games I've seen women go crazy for are not social simulations, but very abstract games like Tetris or Minesweeper or solitaire.
Anyway, my girlfriend loves Soul Calibur and she can kick my ass at it.
Well, actually, etoy did do some things to increase the confusion of visitors who got there by accident. They did that whole faux stock thing and they put pictures of toys on their homepage. So, they were trying to gain something from confusion with the eToys trademark, which is basically what that whole lawsuit was about.
Well, it was supposed to be all of those things, but instead it turned out to be the most diappointing movie of all time.
Who cares about whether it was a crappy movie? That's hardly relevant - after all, by that same measuring stick, the original trilogy was just about as crappy!
Hardly. Even the wost of the earlier films, Return of the Jedi, was many times better than TPM.
Maybe, if it comes on cable some night, and I have nothing else to do, and my computer is broken, I'll watch it again, but until then I'll stick with the originals.
from the presentation. There are many solutions for business logic, and the Java universe promotes EJB.
Have you ever used EJB? If not, you might want to read this report on the current EJB servers: http://www.techmetrix.com/. It pretty much rips them apart. Point being, just because Sun and a bunch of other app server vendors tell you the technology they're pushing is great doesn't make it so. You may be better off using a more traditional OO development style, even if your project is in Java.
Oh, I see. So, it's okay to use violence if you think the judge who made the ruling isn't smart enough. Thanks for clarifying. I guess the judicicary system can all go home and get some rest now, since you've made them uneccessary.
Seriously, if you think the system is broken, fix the system. Don't just throw it out when you don't like what it produces.
At my company, we benchmarked mod_perl (handlers written to the apache API, not Apache::Registry scripts) against the fastest servlet runner out there, which is currently Resin from http://www.caucho.com/. The guy at Caucho had some benchmarks that showed servlets beating mod_perl and PHP, and we wanted to see if it was true.
What we found was that the perl code in his benchmark didn't take much advantage of mod_perl. When we tried it ourselves, mod_perl beat servlets handily, and servlets actually fell apart doing database access under high loads.
I have a lot of respect for what the Caucho effort and other projects like it are trying to do, but I'm afraid that on Linux the JVMs just aren't fast or stable enough to compete yet.
We tested using the final released IBM JVM on a dual P450 machine with Red Hat 6.
Use the straight apache API. Or use something like HTML::Mason, which is implemented on top of the apache API.
You are missing something here. Tiers do not necessarily mean separate machines. They simply mean separate subsystems. Building your code in a model-view-controller style with objects modeling your data is no harder in Perl than it is in Java, and it doesn't need to split across many machines to make it multi-tier.
This does a lot for the scalability of the application; no matter how big your application, you can simply add more java server machines, and your web server sees no more compute load.
The preferred configuration of mod_perl works exactly the same way, with a vanilla apache server up front serving static pages and images and proxying requests that require processing to backend servers running mod_perl. Even if you don't bother to separate things like this, adding more machines is no harder with mod_perl than it is with JServ.
Well, I am criticizing the technical community. Denial of service attacks are a violent and criminal abuse which put their perpetrators in the same league with people who bomb abortion clinics. You don't have the right to use vigilante tactics to enforce your personal political views. Advocacy, education, and working through the judicial system are the right response to these kinds of problems.
Actually, the tech team here at eToys all reads Slashdot already.
You might also want to look at IPC::MM, which implements a hash in shared memory using C code. Should be faster for apps with a lot of read/write access.
http://www.arsdigita.com/ has an open-source e-commerce system built on open-source AOLServer.
Clone it? let's not. I've used NAS and it absolutely sucks. This kind of expensive junkware should be left to die. If you really want to run a website on java on linux (not a good idea with the current state of VMs on linux) you should look at Enhydra, Locomotive, or GSP. All of these are more useful than NAS.
You should use rsync instead. It's faster, and support SSH.
"And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you.
The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent."
That's completely untrue. I've used Netscape's "application server" and it's just junk. We were running on big Sun hardware with the latest optimized JVM, and it still didn't perform well or reliably. The clustering features are no replacement for a load-balancer in front of the webservers, and it's not difficult to share session/state information between machines using a database. There is no reason to buy this stuff. Just use the good open source stuff (mod_jserv, mod_perl, PHP) as a base and write your app on top of it. Most people end up hacking lots of stuff onto these app servers anyway to get them to work.
There's nothing magic about JavaBeans. You can program a perfectly good, scalable app using simpler stuff like Gnu Server Pages from http://www.bitmechanic.com/. This won't prevent you from using JavaBeans, but it won't force you to use a certain methodology for your development, and I like that.
You should also keep in mind that Java on Linux is dog slow and probably will be for a while. Java is solid on Solaris and NT, but Perl is currently in better shape on Linux, IMHO.