stas 02/04/13 23:40:14
Modified: src/outstanding/success_stories adultad.pod
allakhazam.com.pod bsat.pod
calmaeth.maths.uwa.edu.au.pod colbychem.pod
iagore.com.pod idl-net.pod imdb.com.pod make.pl
openscape.org.pod presto.pod rent.com.pod
seds.org.pod singlesheaven.com.pod sms_server.pod
tamu.pod tgix.pod winamillion.msn.com.pod
wmboerse.pod www.afp-direct.com.pod
www.bivio.com.pod www.lind-waldock.com.pod
www.mobile.de.pod
Log:
- fixup the txt2pod converter for success stories, so the new line will
appear (after changing the way a left bar is added in the pre section)
Revision Changes Path
1.2 +31 -28 modperl-docs/src/outstanding/success_stories/adultad.pod
Index: adultad.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/adultad.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- adultad.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ adultad.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,34 +21,37 @@
=back
- Lincoln Stein wrote:
- >
- > Hi All,
- >
- > I'm looking for more mod_perl success stories like the one that Jeff
- > posted the other day. They will be used for vignettes in an
- > introductory chapter of the book that Doug and I are writing. If you
- > have a story you'd like to share (particularly one in which mod_perl
- > "defeats" one of its competitors) could you mail it to me or post it
- > to the list? For the vignettes we need some sort of identifying
- > information, either along the lines of "a major Southwestern
- > University" or "Kulturbox company of Berlin, Germany".
- >
- > Jeff, do you mind us using your story and identifying Texas A&M
- > directly?
- >
- > Lincoln
-
- You may not want to touch this one, but adultad.com contracted me to fix
- their adult banner exchange to where it could throw more than 1.5
- banners a second. I put it under mod_perl, and it now tops out at
- slightly over 20 banners per second. It is now throwing approximately
- 10 Million banners a week solid without a problem. The banner exchange
- (both banner throwing/logging and click-thru redirection/logging) is
- running 100% under mod_perl.
-
- Marshall
-
+ Lincoln Stein wrote:
+ >
+ > Hi All,
+ >
+ > I'm looking for more mod_perl success stories like the one that Jeff
+ > posted the other day. They will be used for vignettes in an
+ > introductory chapter of the book that Doug and I are writing. If you
+ > have a story you'd like to share (particularly one in which mod_perl
+ > "defeats" one of its competitors) could you mail it to me or post it
+ > to the list? For the vignettes we need some sort of identifying
+ > information, either along the lines of "a major Southwestern
+ > University" or "Kulturbox company of Berlin, Germany".
+ >
+ > Jeff, do you mind us using your story and identifying Texas A&M
+ > directly?
+ >
+ > Lincoln
+
+
+ You may not want to touch this one, but adultad.com contracted me to fix
+ their adult banner exchange to where it could throw more than 1.5
+ banners a second. I put it under mod_perl, and it now tops out at
+ slightly over 20 banners per second. It is now throwing approximately
+ 10 Million banners a week solid without a problem. The banner exchange
+ (both banner throwing/logging and click-thru redirection/logging) is
+ running 100% under mod_perl.
+
+
+ Marshall
+
+
=cut
1.2 +53 -46
modperl-docs/src/outstanding/success_stories/allakhazam.com.pod
Index: allakhazam.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/allakhazam.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- allakhazam.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ allakhazam.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -29,52 +29,59 @@
=back
- Almost everything on the site runs in mod_perl. We have 4 systems
- running the site, one static server (PIII 450, Linux,
- Apache/mod_proxy). Two database servers (Dual P800, FreeBSD, Mysql)
- which are replicated, and the one mod_perl server (PIII 800, FreeBSD,
- Apache/mod_perl). The idea to use the proxy server to intercept any
- requests for text or images which was not dynamic came directly from
- the mod_perl guide (http://perl.apache.org/guide/).
-
- It's been a rough ride sometimes, as I've been in the process of
- learning the guts of Apache and more about perl than I ever thought
- I'd need to know. Since the site first started, I've migrated from a
- Module based system, to Apache::Registry (I wasn't writing good enough
- perl for the module based system to work well), and more recently have
- been migrating high volume scripts back to the Module/Handler based
- system.
-
- That's been the true benefit of mod_perl in developing this site.
- It's been a learning process as we roll out a new application or area
- of the site, watching our hit load go up and up, and then spending
- hours looking for performance bottlenecks in code which was never
- intended to run as often as it does.
-
- mod_perl gives us an incredibly fast development time. Sometimes, the
- speed of development does mean than lower quality code creeps into the
- production environment, but it allows us (me) to get things done which
- would take much much longer in another application environment. Perls
- "there are many ways to do it" extends into mod_perl, meaning that I
- can try something new quickly, and come back later to optimize it.
-
- Amoung the features we have on the site:
-
- Application layer security, based on a custom written Session tracking
- system. A recursively threaded forum system on every page, this
- system accounts for the bulk of the page views. It's also real time
- in tems of both comments being added, and ratings to the messages
- propigating through. User uploaded data through out the site, we
- allow players to track their characters, add meta information to
- database entries. Detailed web based administration system based on
- the Application security layer.
-
- The speed of development of perl, coupled with the rich resources of
- CPAN, and the incredible power of mod_perl have made this site
- possible.
-
- Running the same site in other technologies would have been possible,
- but would either require more hardware, or more time to develop.
+ Almost everything on the site runs in mod_perl. We have 4 systems
+ running the site, one static server (PIII 450, Linux,
+ Apache/mod_proxy). Two database servers (Dual P800, FreeBSD, Mysql)
+ which are replicated, and the one mod_perl server (PIII 800, FreeBSD,
+ Apache/mod_perl). The idea to use the proxy server to intercept any
+ requests for text or images which was not dynamic came directly from
+ the mod_perl guide (http://perl.apache.org/guide/).
+
+
+ It's been a rough ride sometimes, as I've been in the process of
+ learning the guts of Apache and more about perl than I ever thought
+ I'd need to know. Since the site first started, I've migrated from a
+ Module based system, to Apache::Registry (I wasn't writing good enough
+ perl for the module based system to work well), and more recently have
+ been migrating high volume scripts back to the Module/Handler based
+ system.
+
+
+ That's been the true benefit of mod_perl in developing this site.
+ It's been a learning process as we roll out a new application or area
+ of the site, watching our hit load go up and up, and then spending
+ hours looking for performance bottlenecks in code which was never
+ intended to run as often as it does.
+
+
+ mod_perl gives us an incredibly fast development time. Sometimes, the
+ speed of development does mean than lower quality code creeps into the
+ production environment, but it allows us (me) to get things done which
+ would take much much longer in another application environment. Perls
+ "there are many ways to do it" extends into mod_perl, meaning that I
+ can try something new quickly, and come back later to optimize it.
+
+
+ Amoung the features we have on the site:
+
+
+ Application layer security, based on a custom written Session tracking
+ system. A recursively threaded forum system on every page, this
+ system accounts for the bulk of the page views. It's also real time
+ in tems of both comments being added, and ratings to the messages
+ propigating through. User uploaded data through out the site, we
+ allow players to track their characters, add meta information to
+ database entries. Detailed web based administration system based on
+ the Application security layer.
+
+
+ The speed of development of perl, coupled with the rich resources of
+ CPAN, and the incredible power of mod_perl have made this site
+ possible.
+
+
+ Running the same site in other technologies would have been possible,
+ but would either require more hardware, or more time to develop.
=cut
1.2 +8 -8 modperl-docs/src/outstanding/success_stories/bsat.pod
Index: bsat.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/bsat.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- bsat.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ bsat.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,14 +21,14 @@
=back
- At my former employer (Aaaahh . . . Sorry, just feels good
- to say that :), I rewrote a commercial interface to a defect tracking
- system. The original product was a bunch of Bourne shell scripts
- that all sourced one humoungus configuration script. It took on the
- order of 10-12 seconds to return some pages (and some of those weren't
- even excuting any queries against the defect database) on a mostly
- idle SS20. Under mod_perl, that dropped to approximately 2-4 seconds
- for everything but really large queries (i.e. everything in the db).
+ At my former employer (Aaaahh . . . Sorry, just feels good
+ to say that :), I rewrote a commercial interface to a defect tracking
+ system. The original product was a bunch of Bourne shell scripts
+ that all sourced one humoungus configuration script. It took on the
+ order of 10-12 seconds to return some pages (and some of those weren't
+ even excuting any queries against the defect database) on a mostly
+ idle SS20. Under mod_perl, that dropped to approximately 2-4 seconds
+ for everything but really large queries (i.e. everything in the db).
=cut
1.2 +21 -17
modperl-docs/src/outstanding/success_stories/calmaeth.maths.uwa.edu.au.pod
Index: calmaeth.maths.uwa.edu.au.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/calmaeth.maths.uwa.edu.au.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- calmaeth.maths.uwa.edu.au.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ calmaeth.maths.uwa.edu.au.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,23 +21,27 @@
=back
- At the Mathematics Department at the University of Western Australia I
- have a web-based computer aided teaching system using mod_perl. The
- students have individual weekly assignments in calculus, statistics,
- linear algebra with diagnostics and assessment built in. The system
- relieves academic staff of the burden of assignment marking and provides
- more personal interaction with students. The system requires database
- management and connection to a computer algebra engine. The transfer from
- a slow/unreliable/Macintosh/Hypercard/Mathematica system to a
- fast/reliable/web system took a couple of months and I had never
- programmed in perl before. The whole excersize was amazingly painless and
- it was entirely mod_perl's doing.
-
- http://CalMaeth.maths.uwa.edu.au
-
-
- Kevin
-
+ At the Mathematics Department at the University of Western Australia I
+ have a web-based computer aided teaching system using mod_perl. The
+ students have individual weekly assignments in calculus, statistics,
+ linear algebra with diagnostics and assessment built in. The system
+ relieves academic staff of the burden of assignment marking and provides
+ more personal interaction with students. The system requires database
+ management and connection to a computer algebra engine. The transfer from
+ a slow/unreliable/Macintosh/Hypercard/Mathematica system to a
+ fast/reliable/web system took a couple of months and I had never
+ programmed in perl before. The whole excersize was amazingly painless and
+ it was entirely mod_perl's doing.
+
+
+ http://CalMaeth.maths.uwa.edu.au
+
+
+
+
+ Kevin
+
+
=cut
1.2 +114 -98
modperl-docs/src/outstanding/success_stories/colbychem.pod
Index: colbychem.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/colbychem.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- colbychem.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ colbychem.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,104 +21,120 @@
=back
- Dear mod_perl gang,
-
- The following is somewhat late in the "success story" thread of a few
months
- ago, but I think there might be some interest for the database crowd.
Below is
- a brief summary of a talk that I gave at a meeting in Philadelphia last
week.
- Sponsored by Molecular Designs Limited (MDL), the meeting was attended by
- several hundred representatives of industry and government, and was
concerned
- with the problems related to large molecular and reaction databases, and
their
- use in combinatorial chemistry, drug discovery, etc. (These are databases
- consisting of molecular structures and their models, and reactions. A
database
- user can pose an sql in the language of chemistry - molecular structures
- drawn with ISIS/Draw or ChemDraw - to find data that have substructure
- similarity, conformationally flexible similarity, reaction similarity,
- and much more. The structures, models, and reactions are displayed using
- MDL's chime plugin, itself based on RASMOL, which renders 'live' 3-D
drawings
- that can be rotated and displayed in a number of ways from within the web
page.)
-
-
*******************************************************************************
-
-
-
- Last November, Dr. Shattuck proposed that we build a reaction database of
- reaction mechanisms studied by Dr. Mundy and his colleagues, using MDL's
- reaction database software. Furthermore, it was his idea that we make
- this a web project open to all. Our first idea was to buy a license for
MDL's
- ChemScape server, which links NetScape Enterprise server to MDL's database
- library. Unfortunately, the upgrade from our current MDL license to include
- ChemScape server was too expensive, not to mention NetScape Enterprise
server.
-
- I started working on a web server based on Apache and mod_perl that would
act
- as a gateway to MDL's database software.
-
- Although MDL's database server protocol is not public, they do provide a
- command line interface called hostcli, which has most of the functionality
- of the proprietary server. The use of hostcli is restricted to one machine,
- but within that machine one may run any number of hostcli processes.
-
- ColbyChem, the project that I presented at the meeting, makes use of
hostcli
- by opening it on a pseudoterminal for each database user. The novel aspect
- of ColbyChem is its use of the integrated Apache/perl server running in
- single user (-X) mode for each database user.
-
- Because perl is embedded in Apache, dynamic variables are retained between
- calls to the server children. Certain Apache packages use this to open a
- persistent database connection to industry standard databases such as
Oracle,
- but this is not an option with proprietary interfaces, such as MDL's.
-
- In order to adapt this to the idea of opening hostcli on a pty for each
user,
- I run a dedicated Apache/perl daemon for each user, in single-mode (-X),
on a
- separate port. That way, each Apache daemon caches the perl program and
- retains dynamic variables between calls. In essence, it becomes a new
- application, composed of Apache and perl, running under my program. The
- effect is similar to an X client. The browser is like the X server.
-
- Entrance to ColbyChem is through a dedicated login daemon running on port
9000.
- Upon receiving a valid login name, the daemon forks an Apache/perl daemon
on
- a port specified in a password-like file, and transfers the browser to this
- new port. Authentication, which is very important here, is carried out
entirely
- on this new daemon. The user supplies a password. ColbyChem encrypts it
- and compares with the encrypted password assigned to the user. If
successful,
- ColbyChem forks and execs hostcli on the pty. It then records the IP number
- and sends back a cookie for secondary authentication upon browser
reconnect.
- The cookie is different for each session, is not based only on an easily
guessed
- system parameters like time or checksums, and does not reveal, to within
the
- limitations of crypt(), the original or encrypted password. My solution for
- the cookie is to take the password, which is secret, and permute it using
- rand() seeded by time. The permuted cleartext password is then encrypted
and
- sent back as the cookie. Thus, even if one knew the permutation order and
- cookie, it would still be impossible to recover the original password.
-
- ColbyChem presents side-by-side frames. The left frame contains a query
- builder and controls for hit-list logic and display. The right frame
displays
- the data indented in the natural hierarchy of the database. Models,
structures,
- and reactions are displayed using MDL's chime plugin.
-
- Essentially, ColbyChem is nothing more than a graphical front-end for
hostcli,
- written in 1200 lines of perl. The heart of ColbyChem is two routines, each
- a page of code. The first routine, rd2perl, translates an export file from
- hostcli into a perl data structure that has the hierarchy of the original
- database, i.e. it imports the database into perl. The second routine
- recursively descends the branches of this structure until it reaches the
- tips, whereupon it prints out the data indented to reflect the database
- hierarchy.
-
- MDL has just delivered an Oracle interface to its molecular and reaction
- databases. This opens the possibility of using established packages for
- persistent database connnections that offer the flexibility of ChemScape
- server from within Apache/perl, without the novel hack of running dedicated
- daemons on separate ports for each user.
-
- John Kuehne, Ph.D.
- Information Technology Services
- Colby College
- 4200 Mayflower Hill Drive
- Waterville ME 04901
-
- [EMAIL PROTECTED]
- 207-872-3652
+ Dear mod_perl gang,
+
+
+ The following is somewhat late in the "success story" thread of a few months
+ ago, but I think there might be some interest for the database crowd. Below
is
+ a brief summary of a talk that I gave at a meeting in Philadelphia last
week.
+ Sponsored by Molecular Designs Limited (MDL), the meeting was attended by
+ several hundred representatives of industry and government, and was
concerned
+ with the problems related to large molecular and reaction databases, and
their
+ use in combinatorial chemistry, drug discovery, etc. (These are databases
+ consisting of molecular structures and their models, and reactions. A
database
+ user can pose an sql in the language of chemistry - molecular structures
+ drawn with ISIS/Draw or ChemDraw - to find data that have substructure
+ similarity, conformationally flexible similarity, reaction similarity,
+ and much more. The structures, models, and reactions are displayed using
+ MDL's chime plugin, itself based on RASMOL, which renders 'live' 3-D
drawings
+ that can be rotated and displayed in a number of ways from within the web
page.)
+
+
+
*******************************************************************************
+
+
+
+
+
+
+ Last November, Dr. Shattuck proposed that we build a reaction database of
+ reaction mechanisms studied by Dr. Mundy and his colleagues, using MDL's
+ reaction database software. Furthermore, it was his idea that we make
+ this a web project open to all. Our first idea was to buy a license for
MDL's
+ ChemScape server, which links NetScape Enterprise server to MDL's database
+ library. Unfortunately, the upgrade from our current MDL license to include
+ ChemScape server was too expensive, not to mention NetScape Enterprise
server.
+
+
+ I started working on a web server based on Apache and mod_perl that would
act
+ as a gateway to MDL's database software.
+
+
+ Although MDL's database server protocol is not public, they do provide a
+ command line interface called hostcli, which has most of the functionality
+ of the proprietary server. The use of hostcli is restricted to one machine,
+ but within that machine one may run any number of hostcli processes.
+
+
+ ColbyChem, the project that I presented at the meeting, makes use of hostcli
+ by opening it on a pseudoterminal for each database user. The novel aspect
+ of ColbyChem is its use of the integrated Apache/perl server running in
+ single user (-X) mode for each database user.
+
+
+ Because perl is embedded in Apache, dynamic variables are retained between
+ calls to the server children. Certain Apache packages use this to open a
+ persistent database connection to industry standard databases such as
Oracle,
+ but this is not an option with proprietary interfaces, such as MDL's.
+
+
+ In order to adapt this to the idea of opening hostcli on a pty for each
user,
+ I run a dedicated Apache/perl daemon for each user, in single-mode (-X), on
a
+ separate port. That way, each Apache daemon caches the perl program and
+ retains dynamic variables between calls. In essence, it becomes a new
+ application, composed of Apache and perl, running under my program. The
+ effect is similar to an X client. The browser is like the X server.
+
+
+ Entrance to ColbyChem is through a dedicated login daemon running on port
9000.
+ Upon receiving a valid login name, the daemon forks an Apache/perl daemon on
+ a port specified in a password-like file, and transfers the browser to this
+ new port. Authentication, which is very important here, is carried out
entirely
+ on this new daemon. The user supplies a password. ColbyChem encrypts it
+ and compares with the encrypted password assigned to the user. If
successful,
+ ColbyChem forks and execs hostcli on the pty. It then records the IP number
+ and sends back a cookie for secondary authentication upon browser reconnect.
+ The cookie is different for each session, is not based only on an easily
guessed
+ system parameters like time or checksums, and does not reveal, to within the
+ limitations of crypt(), the original or encrypted password. My solution for
+ the cookie is to take the password, which is secret, and permute it using
+ rand() seeded by time. The permuted cleartext password is then encrypted and
+ sent back as the cookie. Thus, even if one knew the permutation order and
+ cookie, it would still be impossible to recover the original password.
+
+
+ ColbyChem presents side-by-side frames. The left frame contains a query
+ builder and controls for hit-list logic and display. The right frame
displays
+ the data indented in the natural hierarchy of the database. Models,
structures,
+ and reactions are displayed using MDL's chime plugin.
+
+
+ Essentially, ColbyChem is nothing more than a graphical front-end for
hostcli,
+ written in 1200 lines of perl. The heart of ColbyChem is two routines, each
+ a page of code. The first routine, rd2perl, translates an export file from
+ hostcli into a perl data structure that has the hierarchy of the original
+ database, i.e. it imports the database into perl. The second routine
+ recursively descends the branches of this structure until it reaches the
+ tips, whereupon it prints out the data indented to reflect the database
+ hierarchy.
+
+
+ MDL has just delivered an Oracle interface to its molecular and reaction
+ databases. This opens the possibility of using established packages for
+ persistent database connnections that offer the flexibility of ChemScape
+ server from within Apache/perl, without the novel hack of running dedicated
+ daemons on separate ports for each user.
+
+
+ John Kuehne, Ph.D.
+ Information Technology Services
+ Colby College
+ 4200 Mayflower Hill Drive
+ Waterville ME 04901
+
+
+ [EMAIL PROTECTED]
+ 207-872-3652
=cut
1.2 +62 -48
modperl-docs/src/outstanding/success_stories/iagore.com.pod
Index: iagore.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/iagore.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- iagore.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ iagore.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -29,54 +29,68 @@
=back
- iAgora was started in mid-1998, as a community site for
- internationally minded people. After investigating the major
- existing web development systems, we chose to go with Linux, Apache
- and mod_perl. Three years later, we're very happy with this choice.
-
- At iAgora we are constantly adding features and sections to our
- site, and refining the ones we have. For us it was very important
- to have a flexible platform, that would give us complete freedom in
- organizing our code, and customizing how the pages are generated.
-
- We have found the combination of Linux, Apache and mod_perl to be:
-
- * cost-effective
-
- There are no software licences to pay, the programs are easy enough
- to install and configure, and many free support and middleware
- modules can be obtained from CPAN.
-
- * stable
-
- The running servers have had very few crashes, and generally not
- needed much maintenance. We have also found it very useful to be
- able to administer the servers remotely.
-
- * flexible
-
- Since mod_perl lets perl access low-level hooks within Apache, it is
- possible to have complete control over any aspect of its operation.
-
- For instance, we found it easy and convenient to create virtual
- URLs, where some path elements were matched to database queries
- rather than directories on disk, while still basically serving an
- HTML file.
-
- * adapted for large site creation
-
- Mod_perl gives us complete control over how HTML and perl code
- interface to each other. By using a templating to the fullest
- extent, we minimize the amount of duplication both in HTML and perl.
- This also lets us have common navigation and design accross the
- whole site, while separately maintaining the various form-based
- applications that make the site.
-
- Contact Person:
-
- * Technical: Roger Espel Llima <[EMAIL PROTECTED]>
- * Business: Philippe Negre <[EMAIL PROTECTED]>
-
+ iAgora was started in mid-1998, as a community site for
+ internationally minded people. After investigating the major
+ existing web development systems, we chose to go with Linux, Apache
+ and mod_perl. Three years later, we're very happy with this choice.
+
+
+ At iAgora we are constantly adding features and sections to our
+ site, and refining the ones we have. For us it was very important
+ to have a flexible platform, that would give us complete freedom in
+ organizing our code, and customizing how the pages are generated.
+
+
+ We have found the combination of Linux, Apache and mod_perl to be:
+
+
+ * cost-effective
+
+
+ There are no software licences to pay, the programs are easy enough
+ to install and configure, and many free support and middleware
+ modules can be obtained from CPAN.
+
+
+ * stable
+
+
+ The running servers have had very few crashes, and generally not
+ needed much maintenance. We have also found it very useful to be
+ able to administer the servers remotely.
+
+
+ * flexible
+
+
+ Since mod_perl lets perl access low-level hooks within Apache, it is
+ possible to have complete control over any aspect of its operation.
+
+
+ For instance, we found it easy and convenient to create virtual
+ URLs, where some path elements were matched to database queries
+ rather than directories on disk, while still basically serving an
+ HTML file.
+
+
+ * adapted for large site creation
+
+
+ Mod_perl gives us complete control over how HTML and perl code
+ interface to each other. By using a templating to the fullest
+ extent, we minimize the amount of duplication both in HTML and perl.
+ This also lets us have common navigation and design accross the
+ whole site, while separately maintaining the various form-based
+ applications that make the site.
+
+
+ Contact Person:
+
+
+ * Technical: Roger Espel Llima <[EMAIL PROTECTED]>
+ * Business: Philippe Negre <[EMAIL PROTECTED]>
+
+
=cut
1.2 +56 -46 modperl-docs/src/outstanding/success_stories/idl-net.pod
Index: idl-net.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/idl-net.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- idl-net.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ idl-net.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,52 +21,62 @@
=back
- Hi,
-
- I saw that there were requests for success stories, so here is
ours.
- We had to create 21 websites that basically had the same textual content
- (but different ads+clickthroughs, different designs, different acces
rights,
- etc...), that needed to sometimes remain unseen and act as gateways to
other
- sites, and sometimes show up, with changing content and links according to
- user rights. Also, it had to answer search engine bots with different
- content using yet another database of robot user agents, as well as
(coupled
- with LWP stuff) try to relate automatic posting to search engine databases
- to bots that came visiting (I know this isn't really good, but then, food
is
- sometimes more important, :-( ) and to optimise meta tags, resubmission,
- etc...
-
- It's all done in mod_perl, and in three days time it served a bit
- more than 4 million mod_perl hits, and submitted 180.000 forms to search
- engines. Everything's running on a 300mhz x86, with 128megs of ram. As a
- comparison, the early development tests were done using CGI on the same PC,
- and ASP on a more powerful one running IIS. We also tried using java
- servlets but the results were so desperate that I will not mention them
here
- in respect for those people that use them. Given the time it took either
for
- the CGI to be finished, or for the ASP to connect to it's SQL Server 6.5 to
- yield the right results or send the right page, we had been planning to buy
- 5 other PCs to get the job done with those solutions. Our benchmarks run
- with about 15.000 iterations of a series of calls to the servers that were
- under no other load show that ASP is hardly faster than CGI when database
- access is used (and then you have to take into account the fact that the
ASP
- PC was fairly stronger, (I don't remember the CPU but it had 512megs of
- ram), but that mod_perl induces a performance increase of around 1100% !!!
- Also, it seems to be using less ressources (though I haven't tested that
- fully), or using them for so short time lapses that one doesn't even
notice.
-
- The mod_perl development of the whole project was done by one
person
- in less than three weeks (stress-testing included) , and it is running
- flawlessly.
-
-
- I am looking for something stronger, but all that comes to mind is a deeply
- heart-felt "Thanks !".
-
-
-
- Abigaël Duesberg
- ASP - Lotus - LiveWire - Perl - Java
-
-
+ Hi,
+
+
+ I saw that there were requests for success stories, so here is ours.
+ We had to create 21 websites that basically had the same textual content
+ (but different ads+clickthroughs, different designs, different acces rights,
+ etc...), that needed to sometimes remain unseen and act as gateways to other
+ sites, and sometimes show up, with changing content and links according to
+ user rights. Also, it had to answer search engine bots with different
+ content using yet another database of robot user agents, as well as (coupled
+ with LWP stuff) try to relate automatic posting to search engine databases
+ to bots that came visiting (I know this isn't really good, but then, food is
+ sometimes more important, :-( ) and to optimise meta tags, resubmission,
+ etc...
+
+
+ It's all done in mod_perl, and in three days time it served a bit
+ more than 4 million mod_perl hits, and submitted 180.000 forms to search
+ engines. Everything's running on a 300mhz x86, with 128megs of ram. As a
+ comparison, the early development tests were done using CGI on the same PC,
+ and ASP on a more powerful one running IIS. We also tried using java
+ servlets but the results were so desperate that I will not mention them here
+ in respect for those people that use them. Given the time it took either for
+ the CGI to be finished, or for the ASP to connect to it's SQL Server 6.5 to
+ yield the right results or send the right page, we had been planning to buy
+ 5 other PCs to get the job done with those solutions. Our benchmarks run
+ with about 15.000 iterations of a series of calls to the servers that were
+ under no other load show that ASP is hardly faster than CGI when database
+ access is used (and then you have to take into account the fact that the ASP
+ PC was fairly stronger, (I don't remember the CPU but it had 512megs of
+ ram), but that mod_perl induces a performance increase of around 1100% !!!
+ Also, it seems to be using less ressources (though I haven't tested that
+ fully), or using them for so short time lapses that one doesn't even notice.
+
+
+ The mod_perl development of the whole project was done by one person
+ in less than three weeks (stress-testing included) , and it is running
+ flawlessly.
+
+
+
+
+ I am looking for something stronger, but all that comes to mind is a deeply
+ heart-felt "Thanks !".
+
+
+
+
+
+
+ Abigaël Duesberg
+ ASP - Lotus - LiveWire - Perl - Java
+
+
+
+
=cut
1.2 +34 -28 modperl-docs/src/outstanding/success_stories/imdb.com.pod
Index: imdb.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/imdb.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- imdb.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ imdb.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,34 +21,40 @@
=back
- On Fri, 6 Mar 1998, Lincoln Stein wrote:
-
- > Hi All,
- >
- > I'm looking for more mod_perl success stories like the one that Jeff
- > posted the other day. They will be used for vignettes in an
- > introductory chapter of the book that Doug and I are writing. If you
- > have a story you'd like to share (particularly one in which mod_perl
- > "defeats" one of its competitors) could you mail it to me or post it
- > to the list? For the vignettes we need some sort of identifying
- > information, either along the lines of "a major Southwestern
- > University" or "Kulturbox company of Berlin, Germany".
-
- We use mod_perl for just about everything and then some too; serving
- around 1.25 million pageviews per day. All database lookups are handled
- inside Apache via mod_perl. Each request also goes through several
- mod_perl handlers and is then reformated on the fly with mod_perl SSI
- to embed advertising banners and give different views of the site depending
- on the hostname used.
-
- --
- Rob Hartill Internet Movie Database (Ltd)
- http://www.moviedatabase.com/ .. a site for sore eyes.
-
- The Internet Movie Database (as we all know, a mod_perl driven site) won a
- 1997 Webby as the best Film site on the web.
-
-
+ On Fri, 6 Mar 1998, Lincoln Stein wrote:
+
+
+ > Hi All,
+ >
+ > I'm looking for more mod_perl success stories like the one that Jeff
+ > posted the other day. They will be used for vignettes in an
+ > introductory chapter of the book that Doug and I are writing. If you
+ > have a story you'd like to share (particularly one in which mod_perl
+ > "defeats" one of its competitors) could you mail it to me or post it
+ > to the list? For the vignettes we need some sort of identifying
+ > information, either along the lines of "a major Southwestern
+ > University" or "Kulturbox company of Berlin, Germany".
+
+
+ We use mod_perl for just about everything and then some too; serving
+ around 1.25 million pageviews per day. All database lookups are handled
+ inside Apache via mod_perl. Each request also goes through several
+ mod_perl handlers and is then reformated on the fly with mod_perl SSI
+ to embed advertising banners and give different views of the site depending
+ on the hostname used.
+
+
+ --
+ Rob Hartill Internet Movie Database (Ltd)
+ http://www.moviedatabase.com/ .. a site for sore eyes.
+
+
+ The Internet Movie Database (as we all know, a mod_perl driven site) won a
+ 1997 Webby as the best Film site on the web.
+
+
+
+
=cut
1.2 +3 -2 modperl-docs/src/outstanding/success_stories/make.pl
Index: make.pl
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/make.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- make.pl 13 Apr 2002 17:42:10 -0000 1.1
+++ make.pl 14 Apr 2002 06:40:13 -0000 1.2
@@ -71,8 +71,9 @@
# cleanup for pod
_encode(\%data);
- # keep the body as is
- $body =~ s/^/ /mg;
+ # keep the body as is (though break the paras or ps2pdf chokes on
+ # huge <pre> sections within a table cell)
+ $body =~ s/^(.?)/$1 ? " $1" : " \n"/emg;
$data{body} = $body;
return \%data;
1.2 +75 -59
modperl-docs/src/outstanding/success_stories/openscape.org.pod
Index: openscape.org.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/openscape.org.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- openscape.org.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ openscape.org.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,65 +21,81 @@
=back
- I have put up a site that's a true testament to mod perl's power. (He
- said humbly).
-
- http://openscape.org now contains the new site that I've been writing
- over the last 2 weeks.
-
- The site is generated 100% dynamically by my module Obelisk.pm. Apache
- 1.2.6 and mod_perl 1.10 are used, and the module is inserted to run on
- <Location />. MySQL and DBD::MySQL provide the back end object store.
-
- I keep all text, news items, and the like in the SQL database. at
- request time, the module takes the following steps.
-
- $method = $r->method;
- $loc = $r->uri;
-
- $loc is then parsed out. Depending on the "page" requested the module
- generates a page based on several SQL calls, and prints the result
- back out. I pass args on to the subrequests this way too, such as
- http://openscape.org/rnews/12 will read news item 12. It's all
- handled in the URL parsing. For the forms handling when you post a
- news item, I use CGI_Lite to grab things off POST. (If $method is
- POST), since Apache:: cant grab POST by default. I plan to implement
- my own POST handler, I just havent gotten around to it.
-
- You can post comments on news items, and those will be generated
- dynamically too. (a-la slashdot.org if you're familiar).
-
- The amazing part of all this is twofold. First, it's all done in 427
- lines of perl and 6 SQL tables. Slashdot is 2500 lines of code.
- Second, while I dont have any definitive numbers, this looks like it's
- going to scale very large. I've thrown a few large parallel requests
- at it (just simple LWP gets, in many parallel processes) and it doesnt
- seem to slow down. This box is just a P5/166 with 64megs RAM and Linux
- 2.0.31.
-
- This all occurs with no CGI.pm, no Apache::Registry, no on disk
- content but the Obelisk.pm. I am so spoiled by this method that I dont
- think I can go back. I'm writing a Doc on the process and I'll have it
- up soon. I know I'm not the first person to do this, but the process
- doesnt seem to be exceedingly documented. Oh, and Obelisk will be
- GPL'ed as soon as I gather it into a form that's fit for human
- consumption.
-
- Thanks Doug and crew for mod_perl.
-
- -Chris
-
-
-
- ===
- ------------------------------------------------------------
- Chris Thompson |I do not wish it to be misconstrued that
- [EMAIL PROTECTED] | at no time was I not in total
- [EMAIL PROTECTED] | Disagreement --Anonymous
- ------------------------------------------------------------
-
-
-
+ I have put up a site that's a true testament to mod perl's power. (He
+ said humbly).
+
+
+ http://openscape.org now contains the new site that I've been writing
+ over the last 2 weeks.
+
+
+ The site is generated 100% dynamically by my module Obelisk.pm. Apache
+ 1.2.6 and mod_perl 1.10 are used, and the module is inserted to run on
+ <Location />. MySQL and DBD::MySQL provide the back end object store.
+
+
+ I keep all text, news items, and the like in the SQL database. at
+ request time, the module takes the following steps.
+
+
+ $method = $r->method;
+ $loc = $r->uri;
+
+
+ $loc is then parsed out. Depending on the "page" requested the module
+ generates a page based on several SQL calls, and prints the result
+ back out. I pass args on to the subrequests this way too, such as
+ http://openscape.org/rnews/12 will read news item 12. It's all
+ handled in the URL parsing. For the forms handling when you post a
+ news item, I use CGI_Lite to grab things off POST. (If $method is
+ POST), since Apache:: cant grab POST by default. I plan to implement
+ my own POST handler, I just havent gotten around to it.
+
+
+ You can post comments on news items, and those will be generated
+ dynamically too. (a-la slashdot.org if you're familiar).
+
+
+ The amazing part of all this is twofold. First, it's all done in 427
+ lines of perl and 6 SQL tables. Slashdot is 2500 lines of code.
+ Second, while I dont have any definitive numbers, this looks like it's
+ going to scale very large. I've thrown a few large parallel requests
+ at it (just simple LWP gets, in many parallel processes) and it doesnt
+ seem to slow down. This box is just a P5/166 with 64megs RAM and Linux
+ 2.0.31.
+
+
+ This all occurs with no CGI.pm, no Apache::Registry, no on disk
+ content but the Obelisk.pm. I am so spoiled by this method that I dont
+ think I can go back. I'm writing a Doc on the process and I'll have it
+ up soon. I know I'm not the first person to do this, but the process
+ doesnt seem to be exceedingly documented. Oh, and Obelisk will be
+ GPL'ed as soon as I gather it into a form that's fit for human
+ consumption.
+
+
+ Thanks Doug and crew for mod_perl.
+
+
+ -Chris
+
+
+
+
+
+
+ ===
+ ------------------------------------------------------------
+ Chris Thompson |I do not wish it to be misconstrued that
+ [EMAIL PROTECTED] | at no time was I not in total
+ [EMAIL PROTECTED] | Disagreement --Anonymous
+ ------------------------------------------------------------
+
+
+
+
+
+
=cut
1.2 +28 -25 modperl-docs/src/outstanding/success_stories/presto.pod
Index: presto.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/presto.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- presto.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ presto.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,31 +21,34 @@
=back
- At the risk of this becoming a giant mod_perl lovefest, I'll second that.
- I've learned more about perl & apache in my dozen months or so of mod_perl
- than in my many years of work with apache & perl. mod_perl has definately
- forced me to improve the quality of my perl coding manyfold & taught me
more
- than I ever thought I wanted to know about Apache.
-
- On Fri, Mar 06, 1998 at 06:53:36PM +0100, Eric Cholet wrote:
- > We've a mod_perl web site that allows subscribers to view news stories
and
- > news photographs from a major news agency. All content is received via a
- > satellite link and users can view it in real time, as well as search
- > through a huge archive database.
- >
- > What I like about mod_perl is its "double" reward: not only is it fast
and
- > efficient, but it has been an enlightening experience working with such
an
- > elegant tool and reading this list.
- >
- > ----
- > Eric CHOLET - LOGILUNE
- > email: [EMAIL PROTECTED]
- > I am Pentium of Borg. Division is Futile. You will be approximated.
-
- --
- Patrick Michael Kane
- <[EMAIL PROTECTED]>
-
+ At the risk of this becoming a giant mod_perl lovefest, I'll second that.
+ I've learned more about perl & apache in my dozen months or so of mod_perl
+ than in my many years of work with apache & perl. mod_perl has definately
+ forced me to improve the quality of my perl coding manyfold & taught me more
+ than I ever thought I wanted to know about Apache.
+
+
+ On Fri, Mar 06, 1998 at 06:53:36PM +0100, Eric Cholet wrote:
+ > We've a mod_perl web site that allows subscribers to view news stories and
+ > news photographs from a major news agency. All content is received via a
+ > satellite link and users can view it in real time, as well as search
+ > through a huge archive database.
+ >
+ > What I like about mod_perl is its "double" reward: not only is it fast and
+ > efficient, but it has been an enlightening experience working with such an
+ > elegant tool and reading this list.
+ >
+ > ----
+ > Eric CHOLET - LOGILUNE
+ > email: [EMAIL PROTECTED]
+ > I am Pentium of Borg. Division is Futile. You will be approximated.
+
+
+ --
+ Patrick Michael Kane
+ <[EMAIL PROTECTED]>
+
+
=cut
1.2 +6 -5 modperl-docs/src/outstanding/success_stories/rent.com.pod
Index: rent.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/rent.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- rent.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ rent.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,11 +21,12 @@
=back
- http://www.rent.com/
-
- Rent.com is a dynamic, database driven web site built on mod_perl.
- Initial development took 3 months to replace an NT/IIS/ASP
- implementation.
+ http://www.rent.com/
+
+
+ Rent.com is a dynamic, database driven web site built on mod_perl.
+ Initial development took 3 months to replace an NT/IIS/ASP
+ implementation.
=cut
1.2 +18 -16 modperl-docs/src/outstanding/success_stories/seds.org.pod
Index: seds.org.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/seds.org.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- seds.org.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ seds.org.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,22 +21,24 @@
=back
- I run a web site for approximately 1200 students of introductory astronomy
- here at the U of Arizona. The server is an old Sun Sparc 1 and we use
- lots of perl CGI's to connect to a database on the backend and create
- custom pages. Before mod_perl, the site was unacceptable slow. Now, with
- the scripts re-written to use mod_perl, the dynamically created pages load
- faster than regular HTML files.
-
- Mr. Guy Smiley
- --
- e-mail: ( smiley at seds dot org )
- website: ( double u double u double u dot seds dot org slash tilde smiley )
- phone: ( five two zero three two one one nine six four )
- --
- "I root for a big comet or asteroid as a way of cleansing the planet."
- George Carlin
-
+ I run a web site for approximately 1200 students of introductory astronomy
+ here at the U of Arizona. The server is an old Sun Sparc 1 and we use
+ lots of perl CGI's to connect to a database on the backend and create
+ custom pages. Before mod_perl, the site was unacceptable slow. Now, with
+ the scripts re-written to use mod_perl, the dynamically created pages load
+ faster than regular HTML files.
+
+
+ Mr. Guy Smiley
+ --
+ e-mail: ( smiley at seds dot org )
+ website: ( double u double u double u dot seds dot org slash tilde smiley )
+ phone: ( five two zero three two one one nine six four )
+ --
+ "I root for a big comet or asteroid as a way of cleansing the planet."
+ George Carlin
+
+
=cut
1.2 +19 -16
modperl-docs/src/outstanding/success_stories/singlesheaven.com.pod
Index: singlesheaven.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/singlesheaven.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- singlesheaven.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ singlesheaven.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,22 +21,25 @@
=back
- <STRONG>Singles Heaven</STRONG> - http://singlesheaven.com is a
- <STRONG>Match Maker</STRONG> site with 34,000+ members and
- growing. The site is driven by mod_perl, DBI, <CODE>Apache::DBI</CODE>
- (which provides a persistence to DB connections) and mysql. The speed
- is enormous, chatting with mod_perl is a pleasure of experience.
- Every page is being generated by about 10 SQL queries, for it does
- many dynamic checks every time - like checking for new emails,
- watching the users who registered in their watchdog and many more. You
- don't feel these queries are actually happen, the speed is of the
- ``Hello World'' script.
-
- Development path was very short, I have converted plain CGI scripts to
- run under mod_perl (Apache::Registry) almost in no time!!! If you are
- into a database driven service, give mod_perl a try !!!
-
-
+ <STRONG>Singles Heaven</STRONG> - http://singlesheaven.com is a
+ <STRONG>Match Maker</STRONG> site with 34,000+ members and
+ growing. The site is driven by mod_perl, DBI, <CODE>Apache::DBI</CODE>
+ (which provides a persistence to DB connections) and mysql. The speed
+ is enormous, chatting with mod_perl is a pleasure of experience.
+ Every page is being generated by about 10 SQL queries, for it does
+ many dynamic checks every time - like checking for new emails,
+ watching the users who registered in their watchdog and many more. You
+ don't feel these queries are actually happen, the speed is of the
+ ``Hello World'' script.
+
+
+ Development path was very short, I have converted plain CGI scripts to
+ run under mod_perl (Apache::Registry) almost in no time!!! If you are
+ into a database driven service, give mod_perl a try !!!
+
+
+
+
=cut
1.2 +311 -248
modperl-docs/src/outstanding/success_stories/sms_server.pod
Index: sms_server.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/sms_server.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- sms_server.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ sms_server.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,254 +21,317 @@
=back
- Preface
-
- This is a story about how about I've used a combination of perl,
- Apache and mod_perl to create a component-based service architecture
- that implements a platform for building SMS applications. By reusing
- capabilities offered by Apache/mod_perl I saved a lot of time
- developing the system. The strong OO features of perl that I used
- enabled me to build a very flexible system as well to cope with future
- requirements. We had the platform in place in about 6 weeks, starting
- with absolutely nothing: no hardware, no development environment, no
- technology choices made beforehand.
-
- Introduction
-
- The purpose of the system to be developed was to provide a server
- platform on top of which arbitrary SMS (Short Message Service)
- applications can be developed quickly. It should be built using a
- stable and scalable architecture with room for future enhancements
- such as integrated billing and reporting options.
-
- An SMS application can be characterized by subscribers sending
- text-based commands to the platform and have the platform dispatch to
- the right application instance. The application instance handles the
- command, executing whatever application-logic defined by that
- particular application, and usually generate one or more responses. It
- should also be possible that the platform initiates messages to
- subscribers as a result of a request sent by another subscriber as
- well as be able to generate messages based on timers
-
- There also was a requirement to have the framework publish
- application-specific data in XML to allow customers to display this
- data on other media channels such as a website.
-
- Connecting the platform to external entities for the transmission and
- reception of SMS messages such as SMSC's (SMS Centers distribute SMS
- messages to and from mobile subscribers) and SMS Gateways (smart
- front-end to one or more SMSC's unifying the method to reach
- subscribers from multiple telecom operators) should be flexible enough
- to be able to "plug-in" different protocols such as
- HTTP/SMTP/CIMD/SMPP as needed.
-
- Component architecture
-
- Early on in the project I decided to go for a distributed component
- architecture. Individual components should be deployable on multiple
- physical machines. This offers the required scalability and the
- ability to define a convenient security scheme by running components
- on segments of a network with differing outside visibility
- requirements.
-
- As I started modelling this "world", I ended up with the following
- components:
-
- 1. Application server
-
- Within this application server, multiple instances of multiple SMS
- application instances should be running. The actual application-logic
- is running within this component. This component provides two external
- services:
-
- - handleMessage(CommandRequest)
-
- This service takes an instance of a CommandRequest object and runs the
- command in the appropriate application instance.
-
- - handleTimer(Timer)
-
- This services handles expiry of a timer set by the application-logic
- of an SMS application.
-
- - getView
-
- This service allows a client to retrieve application-defined views in
- XML.
-
-
- 2. Timer service
-
- A persistent service that maintains timers set by application
- instances within the game application server and invokes the
- handleTimer service of the game application services upon expiry of a
- timer.
-
- External service offered:
-
- - setTimer(Timer)
-
-
- 3. Virtual SMS gateway (VSMSC)
-
- This component handles communication with the outside world (the
- external entities such as SMSC's and SMS gateways). This component is
- split up in 2 subcomponents, one that handles input from mobile
- subscribers and one that handles output to mobile subscribers. Each
- subcomponent provides one service:
-
- - handleMessage(Message)
-
- The input component receives requests from the outside world using
- pluggable subcomponents that handle protocol details, the output
- component transmits requests to the outside world using pluggable
- subcomponents that handle protocol details.
-
-
- 4. XML Views service
-
- This component offers an HTTP interface to retrieve
- application-specific views in XML. It uses customer-specific XSLT
- stylesheets to transform the XML data. This component is largely based
- on Matt Sergeant's AxKit. AxKit allow the source of your "document" to
- be delivered by your own provider class by subclassing off of
- AxKit::Provider. My provider class talks to the application server's
- getView service while AxKit performs its miracles with all kinds of
- transformation options.
-
-
-
- Components Figure 1 System components
-
-
- Apache/mod_perl as a component container
-
- When thinking about how to implement all this I was tempted to look
- into doing it with some J2EE-thingy. However, there was this
- time-constraint as well as a constraint on available programmer-hands:
- I had one freelance programmer for 20 days and I had to arrange the
- whole physical part (get the hardware, a co-location site etc.). Then
- it struck me that this application server really looked like a vanilla
- regular mod_perl web application: receive request from user, process,
- send back reply. No html though, but Message objects that could be
- serialized/deserialized from text strings. There were of course some
- differences: the reply is not sent back inline (i.e. upon reception of
- a request via SMS, you can't "reply"; you have to create a new message
- and send that to the originator of the request) and there also was the
- timer service: I can't make Apache/mod_perl do work without having it
- received a user-initiated request.
-
- The good thing was I've been doing Apache/mod_perl for some years now
- so I knew beforehand I could create a schedule acceptable from the
- business point of view that was also feasible based on experience with
- the technology.
-
- So, for each component except the timer service, I defined separate
- Apache/mod_perl instances, one for the application server, one for the
- SMS output component, one for the SMS input component and one for the
- XML Views component.
-
- Each instance defines a URL for each service that the component
- running in the instance provides.
-
- Component communication
-
- I took a shortcut here. I wanted to go for SOAP here as it seems a
- natural fit. It will allow me to move components to other languages
- (management and marketing still seems hung up on java) fairly easy. My
- personal experiences with SOAP on earlier projects weren't too good
- and I just couldn't fit playing with SOAP into my schedule. So I took
- my old friends LWP::UserAgent, HTTP::Request and Storable to handle
- this part (perl object instance -> Storable freeze -> HTTP post ->
- Storable thaw -> perl object instance).
-
- The good thing is that this actually is a minor part of the whole
- system and I know I can put SOAP in easily when the need arises.
-
- "Breaking the chain"
-
- I did make one mistake in the beginning: all service calls were
- synchronous. The initial HTTP request would not return until after the
- whole chain of execution was done. With possibly long running actions
- in the server component, this was not good. I had to find a way to
- execute the actual code *after* closing the connection to the
- client. Luckily, Apache/mod_perl came to the rescue. It allows you to
- set a callback that executes after the HTTP responses are sent back to
- the client and after it closes the TCP/IP connection.
-
- Result
-
- We had the platform in place in about 6 weeks, starting with
- absolutely nothing: no hardware, no development environment, no
- technology choices made beforehand. Based on former experience, the
- decision to go with a LAMP architecture (Linux, Apache, MySQL, Perl)
- running on fairly cheap intel boxen was made quickly. MySQL was, and
- is, not on my wishlist, but the whole battle of moving Oracle in would
- have been both a time as well as a money killer, either of which we
- didn't have a lot of at the time.
-
- Aside from having one production SMS application (a mobile SMS game),
- I've done a prototype SMS application on this platform to check if it
- really is easy to create new apps. It took me about 4 hours to
- implement a "SMS unix commandline" application: I can login to the
- application server using SMS, send Unix commands with my mobile phone
- and receive their output (make sure your command doesn't generate more
- than 160 characters though). The application also maintains state such
- as the working directory I'm in at any given time.
-
- Performance is 'good enough' with the platform running on 2 fairly
- cheap Intel boxen, it handles 40 to 60 incoming request per second. As
- I haven't spent one second on optimization yet (anyone know the
- command to create an index in MySQL?), that number is fine for me. I
- did put 1 gigabyte in each machine though as the Apache child
- processes eat up quite some memory.
-
-
- Future enhancements and considerations
- SOAP
-
- I really want SOAP. It just seems to make sense to do so: it was
- invented for doing stuff like this and I like the concept of WSDL. It
- allows you to define the interface in an XML file so clients "know"
- what type of parameters the service needs as well as the return
- parameter types.
-
- SOAP will also allow new components that are not perl. SOAP is
- available in a lot of languages and integration of the various SOAP
- implementations is getting better every day (see here ).
-
-
- Framework for service-based architecture
-
- I'd like to extract the code that handles the communication between
- the components in the current system and create a generic framework
- that allows one to easily create an Apache/mod_perl-based components
- container. The available services would be registered in httpd.conf
- and there shoud be a service-discovery mechanism. On the client side,
- I'm thinking about something that makes it easy to create client-side
- stubs. Stay tuned...
-
-
- Apache/mod_perl 2.0
-
- This looks very promising to create generic components containers. It
- is very easy to create non-HTTP based services with Apache 2.0 with
- mod_perl's 2.0 support for writing protocol modules in perl. Also, the
- various multi-process models (most notably threading) available in
- Apache 2.0 should result in better performance or at least more
- choices as far as the process model is concerned.
-
-
- Lamp
-
- I'm still a little unsure about LAMP. Can we move to relatively cheap
- hardware and a free OS when we were used to (very) expensive HP, Sun
- or IBM hardware and get away with it? Personal experience and what
- I've read from others seems to indicate we can. Experience will tell,
- and if it breaks, moving the platform to either of the above three
- should be a no-brainer. We live in interesting times.
-
-
+ Preface
+
+
+ This is a story about how about I've used a combination of perl,
+ Apache and mod_perl to create a component-based service architecture
+ that implements a platform for building SMS applications. By reusing
+ capabilities offered by Apache/mod_perl I saved a lot of time
+ developing the system. The strong OO features of perl that I used
+ enabled me to build a very flexible system as well to cope with future
+ requirements. We had the platform in place in about 6 weeks, starting
+ with absolutely nothing: no hardware, no development environment, no
+ technology choices made beforehand.
+
+
+ Introduction
+
+
+ The purpose of the system to be developed was to provide a server
+ platform on top of which arbitrary SMS (Short Message Service)
+ applications can be developed quickly. It should be built using a
+ stable and scalable architecture with room for future enhancements
+ such as integrated billing and reporting options.
+
+
+ An SMS application can be characterized by subscribers sending
+ text-based commands to the platform and have the platform dispatch to
+ the right application instance. The application instance handles the
+ command, executing whatever application-logic defined by that
+ particular application, and usually generate one or more responses. It
+ should also be possible that the platform initiates messages to
+ subscribers as a result of a request sent by another subscriber as
+ well as be able to generate messages based on timers
+
+
+ There also was a requirement to have the framework publish
+ application-specific data in XML to allow customers to display this
+ data on other media channels such as a website.
+
+
+ Connecting the platform to external entities for the transmission and
+ reception of SMS messages such as SMSC's (SMS Centers distribute SMS
+ messages to and from mobile subscribers) and SMS Gateways (smart
+ front-end to one or more SMSC's unifying the method to reach
+ subscribers from multiple telecom operators) should be flexible enough
+ to be able to "plug-in" different protocols such as
+ HTTP/SMTP/CIMD/SMPP as needed.
+
+
+ Component architecture
+
+
+ Early on in the project I decided to go for a distributed component
+ architecture. Individual components should be deployable on multiple
+ physical machines. This offers the required scalability and the
+ ability to define a convenient security scheme by running components
+ on segments of a network with differing outside visibility
+ requirements.
+
+
+ As I started modelling this "world", I ended up with the following
+ components:
+
+
+ 1. Application server
+
+
+ Within this application server, multiple instances of multiple SMS
+ application instances should be running. The actual application-logic
+ is running within this component. This component provides two external
+ services:
+
+
+ - handleMessage(CommandRequest)
+
+
+ This service takes an instance of a CommandRequest object and runs the
+ command in the appropriate application instance.
+
+
+ - handleTimer(Timer)
+
+
+ This services handles expiry of a timer set by the application-logic
+ of an SMS application.
+
+
+ - getView
+
+
+ This service allows a client to retrieve application-defined views in
+ XML.
+
+
+
+
+ 2. Timer service
+
+
+ A persistent service that maintains timers set by application
+ instances within the game application server and invokes the
+ handleTimer service of the game application services upon expiry of a
+ timer.
+
+
+ External service offered:
+
+
+ - setTimer(Timer)
+
+
+
+
+ 3. Virtual SMS gateway (VSMSC)
+
+
+ This component handles communication with the outside world (the
+ external entities such as SMSC's and SMS gateways). This component is
+ split up in 2 subcomponents, one that handles input from mobile
+ subscribers and one that handles output to mobile subscribers. Each
+ subcomponent provides one service:
+
+
+ - handleMessage(Message)
+
+
+ The input component receives requests from the outside world using
+ pluggable subcomponents that handle protocol details, the output
+ component transmits requests to the outside world using pluggable
+ subcomponents that handle protocol details.
+
+
+
+
+ 4. XML Views service
+
+
+ This component offers an HTTP interface to retrieve
+ application-specific views in XML. It uses customer-specific XSLT
+ stylesheets to transform the XML data. This component is largely based
+ on Matt Sergeant's AxKit. AxKit allow the source of your "document" to
+ be delivered by your own provider class by subclassing off of
+ AxKit::Provider. My provider class talks to the application server's
+ getView service while AxKit performs its miracles with all kinds of
+ transformation options.
+
+
+
+
+
+
+ Components Figure 1 System components
+
+
+
+
+ Apache/mod_perl as a component container
+
+
+ When thinking about how to implement all this I was tempted to look
+ into doing it with some J2EE-thingy. However, there was this
+ time-constraint as well as a constraint on available programmer-hands:
+ I had one freelance programmer for 20 days and I had to arrange the
+ whole physical part (get the hardware, a co-location site etc.). Then
+ it struck me that this application server really looked like a vanilla
+ regular mod_perl web application: receive request from user, process,
+ send back reply. No html though, but Message objects that could be
+ serialized/deserialized from text strings. There were of course some
+ differences: the reply is not sent back inline (i.e. upon reception of
+ a request via SMS, you can't "reply"; you have to create a new message
+ and send that to the originator of the request) and there also was the
+ timer service: I can't make Apache/mod_perl do work without having it
+ received a user-initiated request.
+
+
+ The good thing was I've been doing Apache/mod_perl for some years now
+ so I knew beforehand I could create a schedule acceptable from the
+ business point of view that was also feasible based on experience with
+ the technology.
+
+
+ So, for each component except the timer service, I defined separate
+ Apache/mod_perl instances, one for the application server, one for the
+ SMS output component, one for the SMS input component and one for the
+ XML Views component.
+
+
+ Each instance defines a URL for each service that the component
+ running in the instance provides.
+
+
+ Component communication
+
+
+ I took a shortcut here. I wanted to go for SOAP here as it seems a
+ natural fit. It will allow me to move components to other languages
+ (management and marketing still seems hung up on java) fairly easy. My
+ personal experiences with SOAP on earlier projects weren't too good
+ and I just couldn't fit playing with SOAP into my schedule. So I took
+ my old friends LWP::UserAgent, HTTP::Request and Storable to handle
+ this part (perl object instance -> Storable freeze -> HTTP post ->
+ Storable thaw -> perl object instance).
+
+
+ The good thing is that this actually is a minor part of the whole
+ system and I know I can put SOAP in easily when the need arises.
+
+
+ "Breaking the chain"
+
+
+ I did make one mistake in the beginning: all service calls were
+ synchronous. The initial HTTP request would not return until after the
+ whole chain of execution was done. With possibly long running actions
+ in the server component, this was not good. I had to find a way to
+ execute the actual code *after* closing the connection to the
+ client. Luckily, Apache/mod_perl came to the rescue. It allows you to
+ set a callback that executes after the HTTP responses are sent back to
+ the client and after it closes the TCP/IP connection.
+
+
+ Result
+
+
+ We had the platform in place in about 6 weeks, starting with
+ absolutely nothing: no hardware, no development environment, no
+ technology choices made beforehand. Based on former experience, the
+ decision to go with a LAMP architecture (Linux, Apache, MySQL, Perl)
+ running on fairly cheap intel boxen was made quickly. MySQL was, and
+ is, not on my wishlist, but the whole battle of moving Oracle in would
+ have been both a time as well as a money killer, either of which we
+ didn't have a lot of at the time.
+
+
+ Aside from having one production SMS application (a mobile SMS game),
+ I've done a prototype SMS application on this platform to check if it
+ really is easy to create new apps. It took me about 4 hours to
+ implement a "SMS unix commandline" application: I can login to the
+ application server using SMS, send Unix commands with my mobile phone
+ and receive their output (make sure your command doesn't generate more
+ than 160 characters though). The application also maintains state such
+ as the working directory I'm in at any given time.
+
+
+ Performance is 'good enough' with the platform running on 2 fairly
+ cheap Intel boxen, it handles 40 to 60 incoming request per second. As
+ I haven't spent one second on optimization yet (anyone know the
+ command to create an index in MySQL?), that number is fine for me. I
+ did put 1 gigabyte in each machine though as the Apache child
+ processes eat up quite some memory.
+
+
+
+
+ Future enhancements and considerations
+ SOAP
+
+
+ I really want SOAP. It just seems to make sense to do so: it was
+ invented for doing stuff like this and I like the concept of WSDL. It
+ allows you to define the interface in an XML file so clients "know"
+ what type of parameters the service needs as well as the return
+ parameter types.
+
+
+ SOAP will also allow new components that are not perl. SOAP is
+ available in a lot of languages and integration of the various SOAP
+ implementations is getting better every day (see here ).
+
+
+
+
+ Framework for service-based architecture
+
+
+ I'd like to extract the code that handles the communication between
+ the components in the current system and create a generic framework
+ that allows one to easily create an Apache/mod_perl-based components
+ container. The available services would be registered in httpd.conf
+ and there shoud be a service-discovery mechanism. On the client side,
+ I'm thinking about something that makes it easy to create client-side
+ stubs. Stay tuned...
+
+
+
+
+ Apache/mod_perl 2.0
+
+
+ This looks very promising to create generic components containers. It
+ is very easy to create non-HTTP based services with Apache 2.0 with
+ mod_perl's 2.0 support for writing protocol modules in perl. Also, the
+ various multi-process models (most notably threading) available in
+ Apache 2.0 should result in better performance or at least more
+ choices as far as the process model is concerned.
+
+
+
+
+ Lamp
+
+
+ I'm still a little unsure about LAMP. Can we move to relatively cheap
+ hardware and a free OS when we were used to (very) expensive HP, Sun
+ or IBM hardware and get away with it? Personal experience and what
+ I've read from others seems to indicate we can. Experience will tell,
+ and if it breaks, moving the platform to either of the above three
+ should be a no-brainer. We live in interesting times.
+
+
+
+
=cut
1.2 +27 -23 modperl-docs/src/outstanding/success_stories/tamu.pod
Index: tamu.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/tamu.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tamu.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ tamu.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,29 +21,33 @@
=back
- I'd like to share my recent success story. Over the last four days,
- students living on campus here at Texas A&M University have had to go
- through what is called "contract renewal," where they indicate whether
- or not they will continue to live on campus in the coming academic
- year. In the past, this has all been done very tedioulsy with
- scantron forms and human-eye error correction. This year, the system
- was moved to the web. The code was user-proofed to prevent the usual
- mistakes, with the addition of some fancy authentication and session
- tracking mechanisms.
-
- The system was originally written using ActiveWare PerlScript on IIS
- 4.0, but when I was done, it was glaringly obvious that it was far too
- slow. In only 14 days, we ported the code to Apache and mod_perl,
- with the same NT platform underneath. The performance
- (transactions/sec) was more than 60 times better!!!
-
- The system went online Friday night, and in the course of its 4-day run,
- it served 400,000 documents, the bulk of which were generated on the
- fly. Ten thousand people used the system, and all went without a hitch.
-
- Here's to mod_perl!
- Jeffrey
-
+ I'd like to share my recent success story. Over the last four days,
+ students living on campus here at Texas A&M University have had to go
+ through what is called "contract renewal," where they indicate whether
+ or not they will continue to live on campus in the coming academic
+ year. In the past, this has all been done very tedioulsy with
+ scantron forms and human-eye error correction. This year, the system
+ was moved to the web. The code was user-proofed to prevent the usual
+ mistakes, with the addition of some fancy authentication and session
+ tracking mechanisms.
+
+
+ The system was originally written using ActiveWare PerlScript on IIS
+ 4.0, but when I was done, it was glaringly obvious that it was far too
+ slow. In only 14 days, we ported the code to Apache and mod_perl,
+ with the same NT platform underneath. The performance
+ (transactions/sec) was more than 60 times better!!!
+
+
+ The system went online Friday night, and in the course of its 4-day run,
+ it served 400,000 documents, the bulk of which were generated on the
+ fly. Ten thousand people used the system, and all went without a hitch.
+
+
+ Here's to mod_perl!
+ Jeffrey
+
+
=cut
1.2 +39 -30 modperl-docs/src/outstanding/success_stories/tgix.pod
Index: tgix.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/tgix.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tgix.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ tgix.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,36 +21,45 @@
=back
- I have 2 success stories to share:
-
- 1. I'm finishing a web-based mod_perl/javascript (client side) contact
- management system with heavy Apache::DBI and Registry use. This system
- is for a "fortune-500 pharmaceudical (sp?) giant". It is replacing an
- unmanageable (their description) Lotus Domino application.
-
- 2. It production, a mod_perl server for gathering web traffic statistics
- for an up and coming web traffic reporting company. The mod_perl
- enhanced server gathers data from thousands of client and server based
- proxies around the world. Data is stored in Oracle using Apache::DBI.
- This replaced a poorly designed PHP server (poor choice using php in
- this scenario imho).
-
-
- Rick
-
-
-
- --
- _______________________________________________________________
-
- Rick Mangi Tel: (212) 972-2030
- Thaumaturgix, Inc. Fax: (212) 972-2003
- 317 Madison Avenue, Suite 1615 [EMAIL PROTECTED]
- New York, NY 10017 http://www.tgix.com
- thau'ma-tur-gy, n. the working of miracles
- "Perl is a state of mind as much as it is a language grammar"
- _______________________________________________________________
-
+ I have 2 success stories to share:
+
+
+ 1. I'm finishing a web-based mod_perl/javascript (client side) contact
+ management system with heavy Apache::DBI and Registry use. This system
+ is for a "fortune-500 pharmaceudical (sp?) giant". It is replacing an
+ unmanageable (their description) Lotus Domino application.
+
+
+ 2. It production, a mod_perl server for gathering web traffic statistics
+ for an up and coming web traffic reporting company. The mod_perl
+ enhanced server gathers data from thousands of client and server based
+ proxies around the world. Data is stored in Oracle using Apache::DBI.
+ This replaced a poorly designed PHP server (poor choice using php in
+ this scenario imho).
+
+
+
+
+ Rick
+
+
+
+
+
+
+ --
+ _______________________________________________________________
+
+
+ Rick Mangi Tel: (212) 972-2030
+ Thaumaturgix, Inc. Fax: (212) 972-2003
+ 317 Madison Avenue, Suite 1615 [EMAIL PROTECTED]
+ New York, NY 10017 http://www.tgix.com
+ thau'ma-tur-gy, n. the working of miracles
+ "Perl is a state of mind as much as it is a language grammar"
+ _______________________________________________________________
+
+
=cut
1.2 +38 -29
modperl-docs/src/outstanding/success_stories/winamillion.msn.com.pod
Index: winamillion.msn.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/winamillion.msn.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- winamillion.msn.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ winamillion.msn.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,35 +21,44 @@
=back
- >>>>> "LS" == Lincoln Stein <[EMAIL PROTECTED]> writes:
-
- LS> I'm looking for more mod_perl success stories like the one that Jeff
- LS> posted the other day. They will be used for vignettes in an
-
-
- The Microsoft Network promotion running to increase subscribership
- located at http://winamillion.msn.com/ is run on mod_perl. The
- contest ends at the end of the month, so check it out before then ;-)
-
- Anyhow, the system is currently pounding nearly 10 million hits per
- week to the web pages, of which about 1 million go through mod_perl.
- Each of those accesses runs through on averate 3 SQL queries to a
- MySQL database and 2 references to DB_File databases.
-
- There is no way in heck it would have run without mod_perl. By the
- way, this is using Squid in accelerator mode, as I described in the
- tuning docs. Squid handles about 93% of the content (the static and
- mostly static stuff).
-
- v.
-
- --
- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Vivek Khera, Ph.D. Khera Communications, Inc.
- Internet: khera@kciLink.com Rockville, MD +1-301-258-8292
- PGP/MIME spoken here http://www.kciLink.com/home/khera/
-
-
+ >>>>> "LS" == Lincoln Stein <[EMAIL PROTECTED]> writes:
+
+
+ LS> I'm looking for more mod_perl success stories like the one that Jeff
+ LS> posted the other day. They will be used for vignettes in an
+
+
+
+
+ The Microsoft Network promotion running to increase subscribership
+ located at http://winamillion.msn.com/ is run on mod_perl. The
+ contest ends at the end of the month, so check it out before then ;-)
+
+
+ Anyhow, the system is currently pounding nearly 10 million hits per
+ week to the web pages, of which about 1 million go through mod_perl.
+ Each of those accesses runs through on averate 3 SQL queries to a
+ MySQL database and 2 references to DB_File databases.
+
+
+ There is no way in heck it would have run without mod_perl. By the
+ way, this is using Squid in accelerator mode, as I described in the
+ tuning docs. Squid handles about 93% of the content (the static and
+ mostly static stuff).
+
+
+ v.
+
+
+ --
+ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+ Vivek Khera, Ph.D. Khera Communications, Inc.
+ Internet: khera@kciLink.com Rockville, MD +1-301-258-8292
+ PGP/MIME spoken here http://www.kciLink.com/home/khera/
+
+
+
+
=cut
1.2 +50 -40 modperl-docs/src/outstanding/success_stories/wmboerse.pod
Index: wmboerse.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/wmboerse.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wmboerse.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ wmboerse.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,46 +21,56 @@
=back
- Hello,
-
- another mod_perl success story:
-
- Have a look at www.wmboerse.de - it's a german real-time
- stock exchange simulation game for the soccer world championship.
- Participation is free and there are some nice prices to be won.
-
- The technology used is Apache, mod_perl, DBI and DB::Adabas. The
- project is sponsored by Sun Microsystems (they are supplying
- a Sun Ultra Enterprise 450 with 3 CPUs @ 300Mhz and 1GByte RAM at
- the moment), UUNET Germany (bandwidth) and Software AG
- (Adabas-D database).
-
- The server is a real beast. It's amazingly fast. The game is running
- since Sunday. At the moment, there are 2344 players, 183 of them
- have been active in the last 10 minutes. We are expecting a large
- increase in players as soon as national television reports about
- the game.
-
- The load is at 0.80, there are 123 processes, still 400MB RAM free
- (we plugged in 512 MB today, previously the box had 512MB).
- We will increase the maximum number of child processes if we get
- close to the current limit (100).
-
- Here's some data from the Apache status page:
- Server uptime: 4 hours 10 minutes 58 seconds
- Total accesses: 254671 - Total Traffic: 902.9 MB (!)
- CPU Usage: u27.68 s10.98 cu2.03 cs.63 - .274% CPU load
- 16.9 requests/sec - 61.4 kB/second - 3717 B/request
- 18 requests currently being processed, 14 idle servers
-
- Anyway, grab a browser and have a look. The project is a great success
- so far, and it couldn't have been done this easily and quickly without
- mod_perl and the other great free software out there.
-
- Thanks and enjoy!
-
- -Sven Neuhaus
-
+ Hello,
+
+
+ another mod_perl success story:
+
+
+ Have a look at www.wmboerse.de - it's a german real-time
+ stock exchange simulation game for the soccer world championship.
+ Participation is free and there are some nice prices to be won.
+
+
+ The technology used is Apache, mod_perl, DBI and DB::Adabas. The
+ project is sponsored by Sun Microsystems (they are supplying
+ a Sun Ultra Enterprise 450 with 3 CPUs @ 300Mhz and 1GByte RAM at
+ the moment), UUNET Germany (bandwidth) and Software AG
+ (Adabas-D database).
+
+
+ The server is a real beast. It's amazingly fast. The game is running
+ since Sunday. At the moment, there are 2344 players, 183 of them
+ have been active in the last 10 minutes. We are expecting a large
+ increase in players as soon as national television reports about
+ the game.
+
+
+ The load is at 0.80, there are 123 processes, still 400MB RAM free
+ (we plugged in 512 MB today, previously the box had 512MB).
+ We will increase the maximum number of child processes if we get
+ close to the current limit (100).
+
+
+ Here's some data from the Apache status page:
+ Server uptime: 4 hours 10 minutes 58 seconds
+ Total accesses: 254671 - Total Traffic: 902.9 MB (!)
+ CPU Usage: u27.68 s10.98 cu2.03 cs.63 - .274% CPU load
+ 16.9 requests/sec - 61.4 kB/second - 3717 B/request
+ 18 requests currently being processed, 14 idle servers
+
+
+ Anyway, grab a browser and have a look. The project is a great success
+ so far, and it couldn't have been done this easily and quickly without
+ mod_perl and the other great free software out there.
+
+
+ Thanks and enjoy!
+
+
+ -Sven Neuhaus
+
+
=cut
1.2 +9 -8
modperl-docs/src/outstanding/success_stories/www.afp-direct.com.pod
Index: www.afp-direct.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/www.afp-direct.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- www.afp-direct.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ www.afp-direct.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,14 +21,15 @@
=back
- http://www.afp-direct.com hosts the Agence France-Presse's online
- database of news stories and photographs. Agence France-Presse is the
- world's third largest news agency. The online database, available
- through subscription, contains over 6.5 million stories and
- photographs in a full-text searchable database. The web site makes the
- most of mod_perl and its array of modules such as persistent
- connections to back-end servers and custom authentication.
-
+ http://www.afp-direct.com hosts the Agence France-Presse's online
+ database of news stories and photographs. Agence France-Presse is the
+ world's third largest news agency. The online database, available
+ through subscription, contains over 6.5 million stories and
+ photographs in a full-text searchable database. The web site makes the
+ most of mod_perl and its array of modules such as persistent
+ connections to back-end servers and custom authentication.
+
+
=cut
1.2 +11 -10
modperl-docs/src/outstanding/success_stories/www.bivio.com.pod
Index: www.bivio.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/www.bivio.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- www.bivio.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ www.bivio.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -29,16 +29,17 @@
=back
- bivio.com is a web-delivered application written entirely in perl
- which provides complete accounting, tax preparation, automatic
- downloads of broker transactions, message boards, file sharing, email
- aliases, and more. Apache/mod_perl on Linux has functioned incredibly
- reliably with +99% uptime.
-
- Our declarative MVCF application framework (250 perl classes) is
- available under the Artistic License from http://www.bivio.net
- This includes a demo application http://petshop.bivio.net which
- is a more concise implementation of J2EE's Blueprint Architecture.
+ bivio.com is a web-delivered application written entirely in perl
+ which provides complete accounting, tax preparation, automatic
+ downloads of broker transactions, message boards, file sharing, email
+ aliases, and more. Apache/mod_perl on Linux has functioned incredibly
+ reliably with +99% uptime.
+
+
+ Our declarative MVCF application framework (250 perl classes) is
+ available under the Artistic License from http://www.bivio.net
+ This includes a demo application http://petshop.bivio.net which
+ is a more concise implementation of J2EE's Blueprint Architecture.
=cut
1.2 +58 -50
modperl-docs/src/outstanding/success_stories/www.lind-waldock.com.pod
Index: www.lind-waldock.com.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/www.lind-waldock.com.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- www.lind-waldock.com.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ www.lind-waldock.com.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -21,56 +21,64 @@
=back
- 30000 customers looking at live quotes, dynamic charts and news.
- "[...] More importantly, mod_perl allowed us to work the webserver and
- code around our design--not the other way around."
-
- > I'm looking for more mod_perl success stories like the one that Jeff
- > posted the other day. They will be used for vignettes in an
- > introductory chapter of the book that Doug and I are writing. If you
- > have a story you'd like to share (particularly one in which mod_perl
- > "defeats" one of its competitors) could you mail it to me or post it
- > to the list? For the vignettes we need some sort of identifying
- > information, either along the lines of "a major Southwestern
- > University" or "Kulturbox company of Berlin, Germany".
-
- We just completed a website for Lind-Waldock & Co.
- (http://www.lind-waldock.com/), the world's largest discount commodities
- trading firm. The site is to be used by their customers (>30,000) for
- live and delayed quotes, dynamic charts, and news pertaining to the
- futures industry, as well as access to their online order entry
- system. The site will take quite a beating once all of their customers
- transition to it from Lind's previous Windows application--plenty of live
and
- delayed data is auto-refreshed.
-
- Scenario: Client needed to develop a website that could authenticate
- off their existing customer database, and many links needed to be
- dynamically generated to reflect the level of service that the
- customer subscribed to (this info also kept in the database). The
- customer area had to be SSL enabled, fast, and support a slew of Perl
- scripts that the quote vendor had already written. And of course, they
- needed the whole thing yesterday.
-
- They already had Netscape Enterprise Server and we investigated some NSAPI
- solutions but were terribly disappointed with what Netscape had to
- offer. We did some tests and decided to run with Stronghold and
- mod_perl. We wrote less than 10 lines of code to get the site
- authenticating off the database using Apache_DBI and just a few more
- to handle the dynamic URL generation.
-
- We began analysis on Dec 1, and delivered the completed site on Mar
- 4--with 2 weeks off for Christmas, no less! Two days after release,
- the site is averaging about 3 requests a second--and that is certain
- to grow exponentially as more customers make the switch from the old
- Windows application.
-
- More importantly, mod_perl allowed us to work the webserver and code
- around our design--not the other way around.
-
- -Fitz
- ___________________________________________________________________________
- Brian W. Fitzpatrick [EMAIL PROTECTED]
http://www.onShore.com/
-
+ 30000 customers looking at live quotes, dynamic charts and news.
+ "[...] More importantly, mod_perl allowed us to work the webserver and
+ code around our design--not the other way around."
+
+
+ > I'm looking for more mod_perl success stories like the one that Jeff
+ > posted the other day. They will be used for vignettes in an
+ > introductory chapter of the book that Doug and I are writing. If you
+ > have a story you'd like to share (particularly one in which mod_perl
+ > "defeats" one of its competitors) could you mail it to me or post it
+ > to the list? For the vignettes we need some sort of identifying
+ > information, either along the lines of "a major Southwestern
+ > University" or "Kulturbox company of Berlin, Germany".
+
+
+ We just completed a website for Lind-Waldock & Co.
+ (http://www.lind-waldock.com/), the world's largest discount commodities
+ trading firm. The site is to be used by their customers (>30,000) for
+ live and delayed quotes, dynamic charts, and news pertaining to the
+ futures industry, as well as access to their online order entry
+ system. The site will take quite a beating once all of their customers
+ transition to it from Lind's previous Windows application--plenty of live
and
+ delayed data is auto-refreshed.
+
+
+ Scenario: Client needed to develop a website that could authenticate
+ off their existing customer database, and many links needed to be
+ dynamically generated to reflect the level of service that the
+ customer subscribed to (this info also kept in the database). The
+ customer area had to be SSL enabled, fast, and support a slew of Perl
+ scripts that the quote vendor had already written. And of course, they
+ needed the whole thing yesterday.
+
+
+ They already had Netscape Enterprise Server and we investigated some NSAPI
+ solutions but were terribly disappointed with what Netscape had to
+ offer. We did some tests and decided to run with Stronghold and
+ mod_perl. We wrote less than 10 lines of code to get the site
+ authenticating off the database using Apache_DBI and just a few more
+ to handle the dynamic URL generation.
+
+
+ We began analysis on Dec 1, and delivered the completed site on Mar
+ 4--with 2 weeks off for Christmas, no less! Two days after release,
+ the site is averaging about 3 requests a second--and that is certain
+ to grow exponentially as more customers make the switch from the old
+ Windows application.
+
+
+ More importantly, mod_perl allowed us to work the webserver and code
+ around our design--not the other way around.
+
+
+ -Fitz
+ ___________________________________________________________________________
+ Brian W. Fitzpatrick [EMAIL PROTECTED] http://www.onShore.com/
+
+
=cut
1.2 +18 -15
modperl-docs/src/outstanding/success_stories/www.mobile.de.pod
Index: www.mobile.de.pod
===================================================================
RCS file:
/home/cvs/modperl-docs/src/outstanding/success_stories/www.mobile.de.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- www.mobile.de.pod 13 Apr 2002 17:42:10 -0000 1.1
+++ www.mobile.de.pod 14 Apr 2002 06:40:13 -0000 1.2
@@ -25,21 +25,24 @@
=back
- All pages are dynamically created by a Linux cluster running Apache
- with mod_perl from a MySQL database (even though some pages look
- static).
-
- 151 Mio banner ads served from a small Linux cluster with Apache +
- mod_perl connecting to a MySQL database
-
- mobile.de is one of the biggest online carmarkets in Germany. Its
- services are aimed at both professional car dealers and private buyers
- and sellers. Under the company's URL - www.mobile.de - individuals can
- offer and search for cars free of charge. Professional dealers pay a
- fee of EUR 101.24 per month. The fee entitles each dealer to list up
- to 250 vehicles in the database.
-
- --Jan
+ All pages are dynamically created by a Linux cluster running Apache
+ with mod_perl from a MySQL database (even though some pages look
+ static).
+
+
+ 151 Mio banner ads served from a small Linux cluster with Apache +
+ mod_perl connecting to a MySQL database
+
+
+ mobile.de is one of the biggest online carmarkets in Germany. Its
+ services are aimed at both professional car dealers and private buyers
+ and sellers. Under the company's URL - www.mobile.de - individuals can
+ offer and search for cars free of charge. Professional dealers pay a
+ fee of EUR 101.24 per month. The fee entitles each dealer to list up
+ to 250 vehicles in the database.
+
+
+ --Jan
=cut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
