stas 02/05/19 01:46:17
Modified: src/outstanding/success_stories config.cfg
Added: src/outstanding/success_stories callcenter.pod
callcenter.txt edds.pod edds.txt m4m4sex.com.pod
m4m4sex.com.txt www.termium.com.pod
www.termium.com.txt
Log:
4 more success stories
Submitted by: Per Einar Ellefsen <[EMAIL PROTECTED]>
Revision Changes Path
1.3 +5 -1 modperl-docs/src/outstanding/success_stories/config.cfg
Index: config.cfg
===================================================================
RCS file: /home/cvs/modperl-docs/src/outstanding/success_stories/config.cfg,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- config.cfg 28 Apr 2002 15:10:42 -0000 1.2
+++ config.cfg 19 May 2002 08:46:16 -0000 1.3
@@ -16,12 +16,15 @@
'adultad.pod',
'allakhazam.com.pod',
'bsat.pod',
+ 'callcenter.pod',
'calmaeth.maths.uwa.edu.au.pod',
'colbychem.pod',
'dslreports.com.pod',
+ 'edds.pod',
'iagore.com.pod',
'idl-net.pod',
'imdb.com.pod',
+ 'm4m4sex.com.pod',
'openscape.org.pod',
'presto.pod',
'rent.com.pod',
@@ -35,7 +38,8 @@
'www.afp-direct.com.pod',
'www.bivio.com.pod',
'www.lind-waldock.com.pod',
- 'www.mobile.de.pod'
+ 'www.mobile.de.pod',
+ 'www.termium.com.pod'
],
);
1;
1.1
modperl-docs/src/outstanding/success_stories/callcenter.pod
Index: callcenter.pod
===================================================================
###################################################
# WARNING: Do not edit this file!
# If you do the changes will be lost!
# Instead edit the corresponding .txt file and run make.pl
#
# Don't forget to commit the changes to both .txt and the generated
# .pod to cvs, since others won't run the local make.pl
####################################################
=head1 NAME
Internal Call Center Database
=head1 Steven Lembark E<lt>lembark (at) wrkhors.comE<gt> exclaimed:
=over
=item *
Date: Sat, 15 Dec 2001 05:19:49 -0600
=back
The URL is on an internal LAN for a company whose name
I cannot use. The site gets up to a few hundred hits
per second supporting a telephone call center database.
My company was asked to develop a web
front end onto a TB data warehouse. The existing system
(carefully crafted in C) was so slow people couldn't
get their work done (e.g., 45-minute query times). We
re-did the back end and slapped an interface on it using
mod_perl.
The first time the users saw it they asked for a "Stop"
button like the existing system had so they could abort
long-running queries. Then we went over where to put it
with me running queries. They gave up on the idea because
the data was returned too fast for them to hit a button.
Through 4+ weeks of User Acceptance Testing ("UAT") they
asked for a few dozen changes in the reports. Few of them
took loger than 20 minutes to implement. In several cases
they got annoyed that the company email took longer to
deliver the fix notice than make the change.
Using Perl we were also able to handle the database
manglement software for tablespace and table creation,
web site auth. and reporting code and most of the ETL
process management code in one language. That also
saved us quite a bit of work.
=cut
1.1
modperl-docs/src/outstanding/success_stories/callcenter.txt
Index: callcenter.txt
===================================================================
From: Steven Lembark <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2001 05:19:49 -0600
Subject: Internal Call Center Database
The URL is on an internal LAN for a company whose name
I cannot use. The site gets up to a few hundred hits
per second supporting a telephone call center database.
My company was asked to develop a web
front end onto a TB data warehouse. The existing system
(carefully crafted in C) was so slow people couldn't
get their work done (e.g., 45-minute query times). We
re-did the back end and slapped an interface on it using
mod_perl.
The first time the users saw it they asked for a "Stop"
button like the existing system had so they could abort
long-running queries. Then we went over where to put it
with me running queries. They gave up on the idea because
the data was returned too fast for them to hit a button.
Through 4+ weeks of User Acceptance Testing ("UAT") they
asked for a few dozen changes in the reports. Few of them
took loger than 20 minutes to implement. In several cases
they got annoyed that the company email took longer to
deliver the fix notice than make the change.
Using Perl we were also able to handle the database
manglement software for tablespace and table creation,
web site auth. and reporting code and most of the ETL
process management code in one language. That also
saved us quite a bit of work.
1.1 modperl-docs/src/outstanding/success_stories/edds.pod
Index: edds.pod
===================================================================
###################################################
# WARNING: Do not edit this file!
# If you do the changes will be lost!
# Instead edit the corresponding .txt file and run make.pl
#
# Don't forget to commit the changes to both .txt and the generated
# .pod to cvs, since others won't run the local make.pl
####################################################
=head1 NAME
EDDS Tax Management System for Canadian CCRA
=head1 Jay Lawrence E<lt>jay (at) lawrence.netE<gt> exclaimed:
=over
=item *
Date: Tue, 08 Jan 2002 14:08:27 -0800 (PST)
=back
There are few things more sure in life than death and taxes. Ok, well
I can think of one more - tax forms!
The Canada Customs and Revenue Agency (CCRA - our Federal tax
collection agency - like the infamous IRS) has a collection of
approximate 10,000 forms, guides and other publications that require
management and control.
For the past 6 or 7 years these forms were managed using a proprietary
database software that was costly to maintain and difficult to
extend. As well the system was housed on aging SPARC processors. In
order to meet on going and changing business requirements the system
would need to be upgraded or replaced. It turns out that by using
mod_perl, Linux and MySQL plus some contracting time the entire system
was replaced for the cost of 1 years operation costs.
A customized document management system was created to meet the unique
business requirements of the forms management group at CCRA. This
includes document versioning and multiple document formats for each
document name. The filing and classification methods are continuously
evolving and so the addition and decomission of some metadata fields
is necessary.
New documents are created by either starting a new version of an
existing form or document or creating a new document header
record. Then each document format, PDF, MS Word, Form Flow, etc., is
uploaded using the file upload feature and the libapreq module to
decode the uploaded files.
Since security is a concern - we cannot place access to this document
collection on the internet. Instead we must report out files and then
use rsync to move our data to a staging server. By using Perl we have
been able to change from a weekly reporting cycle to a daily reporting
cycle. As well, by using Perl we have been able to fix some really
nasty decisions that were made 6 or 7 years ago when publishing to the
web was an unknown process to most. Finally, by dumping the old
software CCRA and its clients were able to chuck out all those modems
and go via the web.
Perl is practical for extracting and reporting - the turnaround time
and cost effectiveness of this project is a testimony to that claim!
=cut
1.1 modperl-docs/src/outstanding/success_stories/edds.txt
Index: edds.txt
===================================================================
Subject: EDDS Tax Management System for Canadian CCRA
From: Jay Lawrence <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2002 14:08:27 -0800 (PST)
There are few things more sure in life than death and taxes. Ok, well
I can think of one more - tax forms!
The Canada Customs and Revenue Agency (CCRA - our Federal tax
collection agency - like the infamous IRS) has a collection of
approximate 10,000 forms, guides and other publications that require
management and control.
For the past 6 or 7 years these forms were managed using a proprietary
database software that was costly to maintain and difficult to
extend. As well the system was housed on aging SPARC processors. In
order to meet on going and changing business requirements the system
would need to be upgraded or replaced. It turns out that by using
mod_perl, Linux and MySQL plus some contracting time the entire system
was replaced for the cost of 1 years operation costs.
A customized document management system was created to meet the unique
business requirements of the forms management group at CCRA. This
includes document versioning and multiple document formats for each
document name. The filing and classification methods are continuously
evolving and so the addition and decomission of some metadata fields
is necessary.
New documents are created by either starting a new version of an
existing form or document or creating a new document header
record. Then each document format, PDF, MS Word, Form Flow, etc., is
uploaded using the file upload feature and the libapreq module to
decode the uploaded files.
Since security is a concern - we cannot place access to this document
collection on the internet. Instead we must report out files and then
use rsync to move our data to a staging server. By using Perl we have
been able to change from a weekly reporting cycle to a daily reporting
cycle. As well, by using Perl we have been able to fix some really
nasty decisions that were made 6 or 7 years ago when publishing to the
web was an unknown process to most. Finally, by dumping the old
software CCRA and its clients were able to chuck out all those modems
and go via the web.
Perl is practical for extracting and reporting - the turnaround time
and cost effectiveness of this project is a testimony to that claim!
1.1
modperl-docs/src/outstanding/success_stories/m4m4sex.com.pod
Index: m4m4sex.com.pod
===================================================================
###################################################
# WARNING: Do not edit this file!
# If you do the changes will be lost!
# Instead edit the corresponding .txt file and run make.pl
#
# Don't forget to commit the changes to both .txt and the generated
# .pod to cvs, since others won't run the local make.pl
####################################################
=head1 NAME
Gay personals system
=head1 Michael Bacarella E<lt>mbac (at) netgraft.comE<gt> exclaimed:
=over
=item *
Date: Sun, 6 Jan 2002 19:01:59 -0600
=item *
URL: http://m4m4sex.com
=back
http://m4m4sex.com/ is a gay personals system that targets local gay
communities in a number of cities. The site is written exclusively in
mod_perl and uses mysql as a backend. The only purpose of the site is
to ensure that people find sex partners as efficiently as possible.
I'm impressed with how well mod_perl and mysql have held up under
considerable load as more cities were added and as more users joined.
It also continued to please as we re-worked the site to allow users to
switch between languages (4 at this point) on-the-fly.
It all happens on vanilla x86 hardware. Everything from user signups,
account maintenance, online chat, secure payment options, renewing
subscriptions, reports, etc.
Hooray for mod_perl!
=cut
1.1
modperl-docs/src/outstanding/success_stories/m4m4sex.com.txt
Index: m4m4sex.com.txt
===================================================================
From: Michael Bacarella <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2002 19:01:59 -0600
Subject: Gay personals system
URL: http://m4m4sex.com
http://m4m4sex.com/ is a gay personals system that targets local gay
communities in a number of cities. The site is written exclusively in
mod_perl and uses mysql as a backend. The only purpose of the site is
to ensure that people find sex partners as efficiently as possible.
I'm impressed with how well mod_perl and mysql have held up under
considerable load as more cities were added and as more users joined.
It also continued to please as we re-worked the site to allow users to
switch between languages (4 at this point) on-the-fly.
It all happens on vanilla x86 hardware. Everything from user signups,
account maintenance, online chat, secure payment options, renewing
subscriptions, reports, etc.
Hooray for mod_perl!
1.1
modperl-docs/src/outstanding/success_stories/www.termium.com.pod
Index: www.termium.com.pod
===================================================================
###################################################
# WARNING: Do not edit this file!
# If you do the changes will be lost!
# Instead edit the corresponding .txt file and run make.pl
#
# Don't forget to commit the changes to both .txt and the generated
# .pod to cvs, since others won't run the local make.pl
####################################################
=head1 NAME
TERMIUMplus trilingual database
=head1 Jay Lawrence E<lt>jay (at) lawrence.netE<gt> exclaimed:
=over
=item *
Date: Tue, 08 Jan 2002 13:55:07 -0800 (PST)
=item *
URL: http://www.termium.com/
=back
TERMIUMplus (www.termium.com) is a trilingual application that
allows translators and terminologists to search a collection of
1.5 million entries in English, French and Spansih. The system is
freely available to any employee of the Canadian Federal government as
well as by subscription to individuals and organizations outside. The
terms and the user interface are both trilingual.
mod_perl plays an integral role in the success of this system.
Because the server experiences significant amounts of traffic during
the middle of the day effecient request handling is of paramount
concern. It is not uncommon to be servicing over 100 concurrent
requests at 2pm. Not only does the system perform very well but it is
also very stable. I don't think our httpd's have ever crashed - and
almost all requests are in the sub-second response range.
If great performance and stability were not enough - mod_perl (Perl) -
has allowed us to provide a very easy to use and enjoyable interface
to our database servers. The servers are actually on NT running a
proprietary database software package. The database software is very
good at performing both full text and exact term searches of the term
data. However, the software interface to the databse engines is weak
and unusable at best. By using Perl to talk to the database server's
HTTP interface we were able to extract the desired results data and
then use Perl's power to reformat the results into something pleasing
and tailored to the user's preferences. Because each record has over
100 fields and each field can have a number of sub components - I
don't think the job would be doable in any other language than Perl!
In addition to reformatting the output of the database we also employ
some processing of search terms. This processing is unique to our data
collection but helps increase recall by eliminating stopwords such as
"a", "an", "le", "les", etc.
In addition to the fancy user interface TERMIUMplus also offers a
server-to-server term translation service. This allows other search
engines to offer on-the-fly term translation as part of their
service. An excellent feature when dealing with a bi or tri-lingual
document corpus. You are welcome to see this yourself by visiting:
http://strategis.ic.gc.ca/engdoc/search.html
Check on Bilingual search and try a word such as "turbofan". As a
note, I am not aware of what software the Strategis search system was
built with.
The entire system runs on a dual processor Sun 250 with 2G of RAM (We
discovered how important lots of RAM is for this level of concurrent
user activity) for the front end of the request processing. For the
database queries we have 2 quad Xeon NT boxes which we divide between
Extranet and Internet traffic. We will be replacing the Sun 250 with a
quad processor Sun 450 with 8G of RAM.
In addition to mod_perl we use MySQL as our user sessions database and
intend to start replacing many functions of our proprietary back end
database with functions developed using mod_perl and MySQL. Linux is
our front-line development system and CVS is our versioning management
system. We use CVS to then move our work on to a Sun staging system
for pre-release testing and then finally rsync to push final code on
to production servers. All of our code runs as well on Linux as it
does on Solaris - with no modifications other than compile time
options for the major packages of the application.
I feel that using mod_perl to build TERMIUMplus has allowed for the
construction of a high quality service which is capable of handling a
significant user load. It is very rare (never?) that we experienced
any major problems with the Apache, mod_perl, and Perl portion of our
system. Most of our operational difficulties are coming from our
vendor supplied software at the database backend where daily server
problems are experienced.
Software costs aside I wouldn't build this appliation using
anything but mod_perl, Apache and MySQL!
=cut
1.1
modperl-docs/src/outstanding/success_stories/www.termium.com.txt
Index: www.termium.com.txt
===================================================================
Subject: TERMIUMplus trilingual database
From: Jay Lawrence <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2002 13:55:07 -0800 (PST)
URL: http://www.termium.com/
TERMIUMplus (www.termium.com) is a trilingual application that
allows translators and terminologists to search a collection of
1.5 million entries in English, French and Spansih. The system is
freely available to any employee of the Canadian Federal government as
well as by subscription to individuals and organizations outside. The
terms and the user interface are both trilingual.
mod_perl plays an integral role in the success of this system.
Because the server experiences significant amounts of traffic during
the middle of the day effecient request handling is of paramount
concern. It is not uncommon to be servicing over 100 concurrent
requests at 2pm. Not only does the system perform very well but it is
also very stable. I don't think our httpd's have ever crashed - and
almost all requests are in the sub-second response range.
If great performance and stability were not enough - mod_perl (Perl) -
has allowed us to provide a very easy to use and enjoyable interface
to our database servers. The servers are actually on NT running a
proprietary database software package. The database software is very
good at performing both full text and exact term searches of the term
data. However, the software interface to the databse engines is weak
and unusable at best. By using Perl to talk to the database server's
HTTP interface we were able to extract the desired results data and
then use Perl's power to reformat the results into something pleasing
and tailored to the user's preferences. Because each record has over
100 fields and each field can have a number of sub components - I
don't think the job would be doable in any other language than Perl!
In addition to reformatting the output of the database we also employ
some processing of search terms. This processing is unique to our data
collection but helps increase recall by eliminating stopwords such as
"a", "an", "le", "les", etc.
In addition to the fancy user interface TERMIUMplus also offers a
server-to-server term translation service. This allows other search
engines to offer on-the-fly term translation as part of their
service. An excellent feature when dealing with a bi or tri-lingual
document corpus. You are welcome to see this yourself by visiting:
http://strategis.ic.gc.ca/engdoc/search.html
Check on Bilingual search and try a word such as "turbofan". As a
note, I am not aware of what software the Strategis search system was
built with.
The entire system runs on a dual processor Sun 250 with 2G of RAM (We
discovered how important lots of RAM is for this level of concurrent
user activity) for the front end of the request processing. For the
database queries we have 2 quad Xeon NT boxes which we divide between
Extranet and Internet traffic. We will be replacing the Sun 250 with a
quad processor Sun 450 with 8G of RAM.
In addition to mod_perl we use MySQL as our user sessions database and
intend to start replacing many functions of our proprietary back end
database with functions developed using mod_perl and MySQL. Linux is
our front-line development system and CVS is our versioning management
system. We use CVS to then move our work on to a Sun staging system
for pre-release testing and then finally rsync to push final code on
to production servers. All of our code runs as well on Linux as it
does on Solaris - with no modifications other than compile time
options for the major packages of the application.
I feel that using mod_perl to build TERMIUMplus has allowed for the
construction of a high quality service which is capable of handling a
significant user load. It is very rare (never?) that we experienced
any major problems with the Apache, mod_perl, and Perl portion of our
system. Most of our operational difficulties are coming from our
vendor supplied software at the database backend where daily server
problems are experienced.
Software costs aside I wouldn't build this appliation using
anything but mod_perl, Apache and MySQL!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
