Re: These students are asking for help. Be nice to them.
If this idea catches on, some of us are going to have to change careers. ;-) Galactic Geek wrote: *** Please help a group of students gain practical experience *** We are a group of students with varying degrees of technical expertise. We are studying computer programming in an engineering college in India and want to gain some practical experience. In a bid to gain experience, we are offering to do web site development projects for free. What we ask in exchange is a "Certificate of Recommendation" if the project is completed successfully. Again, we charge no money for doing these web projects; we are doing this to gain "real life" programming experience. It is our belief that these kinds of projects will help us get "real" jobs when we graduate from college. The skills that we bring to table comprise HTML, JavaScript, style sheets, database programming, Oracle, SQL Server, Java, ASP, Unix, Windows 2000 and many many more. Please visit us at- http://Geeks4Free.com We don't want to turn this into your typical "get-rich-quick" chain-letter, but would humbly like to ask you to forward this e-mail to your friends and family members. If not you, maybe, they could use our services. What business doesn't need a well-designed, professional-looking web site? Now, they can get one for free. Just visit us at http://Geeks4Free.com and see what we can do for you. Thanks a lot for your attention. Geeks4Free.com Team Members Get free email and a permanent address at http://www.amexmail.com/?A=1 -- ***NOTE*** This entire message is confidential, and protected by copyright. If you are not the intended recipient, you are hereby notified that any review, dissemination or archiving of this message is strictly prohibited. ** www.RentZone.org
Re: number of pgsql childrens on persistant DBI connection
Wow! Are you sure no one else is going against your database using persistent connections? How many database handles are you using in your mod_perl apps? Each Apache child process will require one persistent connection to your database for each different database handle. If you have a database server that contains multiple databases, and you're accessing 2 different databases on the same server with your mod_perl/DBI/Apache-DBI apps, you're going to have double the number of persistent connections to your databases then you're going to have child processes. Additionally, if you use one database handle for normal interaction, and another database handle for transactions [to prevent committing a transaction across tables until all have been updated] you're going to end up with 1 persistent connection to your postgresql database for each DBI database handle, even though they are accessing the same database. I think... :) Emmanuel Pierre wrote: Hi all, on my DB server I have 245 "idle" postmasters process for 130 httpd persistant DB connections alive. can anyone give me a clue how to manage this number of unused/idleschildren and how to have them quickerly deallocated ? this way, I jumptoo quick on 'too much connection'... Emmanuel -- EDENJOB / APR-Job Email: [EMAIL PROTECTED]Home:www.apr-job.com Phone: +33 1 47 81 02 41 Tatoo: +33 6 57 60 42 17 Fax: +33 1 41 92 91 54 eFAX: +44 0870-122-6748 ** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither EDENJOB/APR-JOB or affiliates shall be liable for the message if altered, changed or falsified. ** -- ***NOTE*** This entire message is confidential, and protected by copyright. If you are not the intended recipient, you are hereby notified that any review, dissemination or archiving of this message is strictly prohibited. ** www.RentZone.org
Re: General Question
Yes, I remember Gunther recommending the javascript approach a while back, and I think
it is a good solution, but I just can't stand javascript. I always surf with it turned
off, because it frequently causes my browser to hang. It's a personal hang-up.
I was really interested in just learning how the server handled it, and Stas squared
me away. My fear was that it would cause my server to hang, which was my usual
experience under Windows NT, but my Linux box just slows to a crawl, and doesn't hang.
I can live with that. :)
Have a good night!
Mike Wojcikiewicz wrote:
If youre looking for a solution, i suggest putting in a little javascript
on the form..
FORM blah onSubmit="return submitme();"
...
script language="JavaScript"
!--
var clicked = 0;
function submitme() {
if(clicked == 0) { clicked = 1; }
else { return false; }
return true;
}
//--
/script
as for the other processes, its been my experience that they complete and
die off after apache is done... ie lagging your server to hell.. depends
on your configuration though
Michael Wojcikiewicz
Web Application Developer
E-Mail: [EMAIL PROTECTED]
ICQ: 944221
On Sun, 11 Feb 2001, Buddy Lee Haystack wrote:
Situation:
I press the submit button on a form 55 times in 15 seconds. Each request would
normally return data to the browser within ten seconds due to the time it takes the
database query to execute.
Question:
What happens to the 54 earlier processes, since I submitted the request 55 times?
How do Apache mod_perl handle the processes to nowhere?
Thanks!
General Question
Situation: I press the submit button on a form 55 times in 15 seconds. Each request would normally return data to the browser within ten seconds due to the time it takes the database query to execute. Question: What happens to the 54 earlier processes, since I submitted the request 55 times? How do Apache mod_perl handle the processes to nowhere? Thanks! -- ***NOTE*** This entire message is confidential, and protected by copyright. If you are not the intended recipient, you are hereby notified that any review, dissemination or archiving of this message is strictly prohibited. ** www.RentZone.org
Re: problems installing mod_perl when apache is already installed...
Try installing it DSO. The following link will provide some directions. http://perl.apache.org/guide/install.html#Installing_separate_Apache_and_m Webmaster wrote: I'm looking forward to start using Apache and mod_perl together...etc. The common E-commerce scenario. I will also be planning to put in Embperl, and use MySQL. I have a RH 7.0 system with Apache 1.3.12 already installed and previously configured by me. Now I'm trying to install mod_perl but I'm having problems cuz it seems like I can't find the Apache source anywhere!!! Obviously if it comes pre-installed, then it would be a RPM package. I queried...but stillI can't find the source... I'm looking at trying this with mod_perl installation: # cd /usr/src/mod_perl-1.25 # perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 # make make test make install but these seem to be instructions for installing Apache also...but I don't want to uninstall, for fear of dependency conflicts with modules Is there a way to solve this problem??? perhaps this problem can be solved if I find a mod_perl rpm packagebut I can't find one anywhere on the netcan anyone help with this???
Re: Perl / DBI Job - Telecommute - Full Time
A post office box in FL? CargoTel, Inc. PO Box 660572 Oviedo, FL 32766 Doesn't sound very professional... "Greg Balfanz, CargoTel" wrote: We have a ground floor opening for a perl programmer for a TELECOMMUTING situation for web/wireless/telecom system development. Thank you, Greg http://www.CargoTel.com/
Re: Perl / DBI Job - Telecommute - Full Time
I guess so, but I find it a bit difficult to imagine why someone successful enough to sell 3 sites for a total of $85M uses a PO Box; pays to list the domain name for only 1 year; is located in an area that is 98% rural where the median housing value is under $90,000; doesn't list an actual company address anywhere on the site, and lists himself as the administrative contact for the site. Shouldn't he have one of his toadies at least handle the administrative contact for the DNS name? I would... I must be a bit too jaded... "G.W. Haywood" wrote: Hi Buddy, On Tue, 30 Jan 2001, Buddy Lee Haystack wrote: A post office box in FL? CargoTel, Inc. PO Box 660572 Oviedo, FL 32766 Doesn't sound very professional... With $85M I guess he doesn't worry too much about that. 'Course if I had $85M I think I'd go on holiday for a while. 73, Ged. -- ***NOTE*** The information in this message (including attachments) is confidential, and protected by copyright. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. ** www.RentZone.org
Error message -- out of free buffers:
I receive the following error message in my Apache error_log after pressing the submit button in "machine-gun like fashion" on one of my forms that requires roughly a minute to process each request using Apache::DBI, mod_perl and PostgreSQL. [Sat Jan 27 15:03:07 2001] null: DBD::Pg::st execute failed: ERROR: out of free buffers: time to abort ! [Sat Jan 27 15:03:07 2001] null: [Sat Jan 27 15:03:07 2001] [error] [Sat Jan 27 15:03:07 2001] null: Couldn't execute statement: ERROR: out of free buffers: time to abort ! [Sat Jan 27 15:03:07 2001] null: I did it out of curiosity, and to see if it would hang the server [it didn't :) ], but was wondering if it is possible to increase the number of free buffers, and how I would go about doing it. I'm not even sure if they are operating system dependent, or application dependent, but there seems to be enough memory available on my Linux box... total used free sharedbuffers cached Mem:517176 254588 262588 115020 70368 92680 -/+ buffers/cache: 91540 425636 Swap: 530104 0 530104 Thanks!
Re: Error message -- out of free buffers:
Sorry for the post. It appears to be a PostgreSQL configuration issue, and not an Apache/mod_perl issue.
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory
I have a wide assortment of queries on a site, some of which take several minutes to execute, while others execute in less than one second. If understand this analogy correctly, I'd be better off with the current incarnation of mod_perl because there would be more cashiers around to serve the "quick cups of coffee" that many customers request at my dinner. Is this correct? Sam Horrocks wrote: I think the major problem is that you're assuming that just because there are 10 constant concurrent requests, that there have to be 10 perl processes serving those requests at all times in order to get maximum throughput. The problem with that assumption is that there is only one CPU - ten processes cannot all run simultaneously anyways, so you don't really need ten perl interpreters. I've been trying to think of better ways to explain this. I'll try to explain with an analogy - it's sort-of lame, but maybe it'll give you a mental picture of what's happening. To eliminate some confusion, this analogy doesn't address LRU/MRU, nor waiting on other events like network or disk i/o. It only tries to explain why you don't necessarily need 10 perl-interpreters to handle a stream of 10 concurrent requests on a single-CPU system. You own a fast-food restaurant. The players involved are: Your customers. These represent the http requests. Your cashiers. These represent the perl interpreters. Your cook. You only have one. THis represents your CPU. The normal flow of events is this: A cashier gets an order from a customer. The cashier goes and waits until the cook is free, and then gives the order to the cook. The cook then cooks the meal, taking 5-minutes for each meal. The cashier waits for the meal to be ready, then takes the meal and gives it to the customer. The cashier then serves another customer. The cashier/customer interaction takes a very small amount of time. The analogy is this: An http request (customer) arrives. It is given to a perl interpreter (cashier). A perl interpreter must wait for all other perl interpreters ahead of it to finish using the CPU (the cook). It can't serve any other requests until it finishes this one. When its turn arrives, the perl interpreter uses the CPU to process the perl code. It then finishes and gives the results over to the http client (the customer). Now, say in this analogy you begin the day with 10 customers in the store. At each 5-minute interval thereafter another customer arrives. So at time 0, there is a pool of 10 customers. At time +5, another customer arrives. At time +10, another customer arrives, ad infinitum. You could hire 10 cashiers in order to handle this load. What would happen is that the 10 cashiers would fairly quickly get all the orders from the first 10 customers simultaneously, and then start waiting for the cook. The 10 cashiers would queue up. Casher #1 would put in the first order. Cashiers 2-9 would wait their turn. After 5-minutes, cashier number 1 would receive the meal, deliver it to customer #1, and then serve the next customer (#11) that just arrived at the 5-minute mark. Cashier #1 would take customer #11's order, then queue up and wait in line for the cook - there will be 9 other cashiers already in line, so the wait will be long. At the 10-minute mark, cashier #2 would receive a meal from the cook, deliver it to customer #2, then go on and serve the next customer (#12) that just arrived. Cashier #2 would then go and wait in line for the cook. This continues on through all the cashiers in order 1-10, then repeating, 1-10, ad infinitum. Now even though you have 10 cashiers, most of their time is spent waiting to put in an order to the cook. Starting with customer #11, all customers will wait 50-minutes for their meal. When customer #11 comes in he/she will immediately get to place an order, but it will take the cashier 45-minutes to wait for the cook to become free, and another 5-minutes for the meal to be cooked. Same is true for customer #12, and all customers from then on. Now, the question is, could you get the same throughput with fewer cashiers? Say you had 2 cashiers instead. The 10 customers are there waiting. The 2 cashiers take orders from customers #1 and #2. Cashier #1 then gives the order to the cook and waits. Cashier #2 waits in line for the cook behind cashier #1. At the 5-minute mark, the first meal is done. Cashier #1 delivers the meal to customer #1, then serves customer #3. Cashier #1 then goes and stands in line behind cashier #2. At the 10-minute mark, cashier #2's meal is ready - it's delivered to customer #2 and then customer #4 is served. This continues on with the cashiers trading off between serving customers. Does the scenario with two cashiers go any more slowly than the one with 10 cashiers? No. When the 11th
Re: [OT] Availability of Jobs -- was Re: [SOLICITATION] Programmeravailable for contracting..
Most year-end bonuses should be paid by the end of this month, while many were already paid out EOY 2000. Since the US stock market is in decline, many people assume their EOY 2001 bonuses will pale in comparison to 2000's. What better time to look for greener pastures. [Not including the over-compensated dot com folks who were over-paid anyway.;-)] mehryar wrote: Im not sure about the contract positions but this is traditionally the time of the year when people decide its time for a change, its endemic to all other types of industries not just the software industry. And to alleviate your paranoia a little, a report I read last month said software jobs were actually on the increase, rivalling the ever hungry system administration job market. cheers, Mehryar On Thu, 11 Jan 2001, Gunther Birznieks wrote: I notice that there have been many more job postings from employment seekers have occurred in the last few weeks versus jobs. Whereas it used to be many more jobs wanting mod_perl vs seekers of jobs. Is this an odd time of year for many contractors where the contract ends around the holiday season? Or is this starting to be a symptom of dotcoms going bust and the development market starting to level out? Or perhaps I am being a bit paranoid. :) u -- www.RentZone.org
Re: Apache::SizeLimit for unshared RAM ???
IMHO, he has a point. I'd also benefit from memory usage based upon an application threshold. He has a good idea... Rob Bloodgood wrote: I have a machine w/ 512MB of ram. unload the webserver, see that I have, say, 450MB free. So I would like to tell apache that it is allowed to use at most 425MB. L8r, Rob -- www.RentZone.org
Re: DBI
Bad generic advice. You should use persistent connections when it makes sense to use them. BLH Whether or not you use mod_perl is irrelevant. It is relevent if you want to use Apache::DBI. Ouch! I was a bit more specific in my follow-up email which I sent direct since I didn't think it was necessary to post it to the list, but I may have been mistaken. It's difficult to provide detailed advice when you don't have all the information, so I did my best. Subject: Re: DBI Date: Fri, 05 Jan 2001 17:56:53 -0500 From: Buddy Lee Haystack [EMAIL PROTECTED] Organization: www.RentZone.org To: Joe Grastara [EMAIL PROTECTED] References: 1 When I first "migrated" from a Windows environment, I was absolutely amazed at how the Unix people cobbled together independent pieces of software to solve systems integration issues that plagued me in corporate americana. A couple of issues. When you use the Apache DBI module to maintain persistent connections to your database, each Apache child process inherits one of the database handles, and caches the connection. This means that your database will have to be able to have one database connection open for each Apache child process running. If you have Apache configured to spawn 20 child processes, the database your connecting to will have to be able to handle at least the number of connections opened by just the single webserver. I use PostgreSQL, which is compiled to handle just over 30 open connections. My website uses 20 of those connections, which allows just over 10 other people to open up connections to the database. There is some undocumented command in DBI that will allow you to open a connection with the Apache DBI module installed, but not cache the connection. I used this to connect to an HR database that was rarely ever accessed. ENJOY!!! -- www.RentZone.org
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory
Does this mean that mod_perl's memory hunger will curbed in the future using some of the neat tricks in Speedycgi? Perrin Harkins wrote: Sam Horrocks wrote: Don't agree. You're equating the model with the implemntation. Unix processes model concurrency, but when it comes down to it, if you don't have more CPU's than processes, you can only simulate concurrency. [...] This url: http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html says the default timeslice is 210ms (1/5th of a second) for Linux on a PC. There's also lots of good info there on Linux scheduling. Thanks for the info. This makes much more sense to me now. It sounds like using an MRU algrorithm for process selection is automatically finding the sweet spot in terms of how many processes can run within the space of one request and coming close to the ideal of never having unused processes in memory. Now I'm really looking forward to getting MRU and shared memory in the same package and seeing how high I can scale my hardware. - Perrin -- www.RentZone.org
Re: Measure of performance !!!
Didn't someone already mention that it takes longer to connect to an Oracle database? If you don't use the Apache::DBI module, the Oracle database will be slower because it takes longer to connect to it for each request. By using the Apache::DBI module you effectively negate the time it takes to re-connect to the database for subsequent requests. You really need to use Apache::DBI to test for the differences in database performance, otherwise the excessive time to connect to the Oracle will always result in Oracle handling fewer requests than other databases that handle connections more efficiently. Edmar Edilton da Silva wrote: Hi all, Some days ago I sent a question about performance of Oracle and MS SQL Server databases, but I don't got any answer that help me. I have installed on my machine: Linux Red Hat 6.2 Apache 1.3.14 (installed on machine 1 ) mod_perl 1.24-1 DBD::Oracle DBD::Sybase ( to access the MS SQL Server database ) Oracle (installed on machine 2 ) MS SQL Server (installed on machine 3 ) I know using the Apache::DBI module the connection time is reduced, but I need to make some tests of performance without Apache::DBI. The Oracle and SQL Server servers are running on different machines that Web server. I undestand one Oracle connection consumes more resources that SQL Server, but there is a thing that I don't undestand, when I ran the tests for SQL Server the machine 1 works properly, but when I ran the tests for Oracle the machine 1 works much more slow. Same with the database servers installed on different machines that Web server, does one connection Oracle consume more resources on the machine 1 that a SQL Server connection? Why? Why does the machine 1 work much more slow for Oracle? Please, if someone must help me I will be very thankful. Happy hollidays for everyone. Edmar Edilton da Silva Bacharel em Ciência da Computacão - UFV Mestrando em Ciência da Computacão - UNICAMP -- BLH www.RentZone.org
Re: recommendation for image server with modperl
Tell me more... How about memory leaks mod_perl issues? Justin wrote: Hi, I've been catching up on the modperl list archives, and would just like to recommend "mathopd" as an image web server. After having difficulties with the sheer number of front end apache processes necessary to handle 10 backend modperls, (difficulties: high load average and load spikes, kernel time wasted scheduling lots of httpds, higher than expected latency on simple requests), I switched all images to another IP address on the same box (extending their IMG SRC somewhat obviously), but now served by mathopd. Mathopd is a simple select based, http 1.1 (keep alive) compliant tiny webserver that is very configurable. I was doubtful that it would hold up (it comes with zero documentation .. the docs say "read the source"). But it has not crashed *once*, and its very nice to see just one 22mb process with 500+ minutes of cpu time (for several weeks of work), and have images come in fast and reliably. It uses select and as many file handles for a proc as you have. If load increases beyond (say) your limit of 1024 fds, it re-uses currently unused but kept-alive fds, meaning a graceful degradation. It is also exceedingly fast, much faster than apache serving images (that doesnt matter, but it does mean its frugal with your CPU). Of course I still have 120+ apache httpds (now just being front end for *page* requests), and my wish is that mathopd would add proxy and regexp rewrite capability, then I could do away with apache completely on the front end !! or I guess apache2 with mod_rewrite and mod_proxy would solve that, at the risk of thread related teething problems. Just a recommendation from left field. -Justin -- BLH www.RentZone.org
Re: load average: 24.07, 14.76, 9.20
How much of a performance penalty does using Apache::SizeLimit have? Is there some quantitative way of setting how often to check process size with the "Apache::SizeLimit::CHECK_EVERY_N_REQUESTS = 10;" that results in the best performance? Perrin Harkins wrote: I find Apache::SizeLimit is more effective than setting MaxRequests, because it won't kill off your well-behaved processes and thus spares you from extra process spawning, re-opening databases, etc. Make sure you don't set Apache::Resource to kill anything that's close to "normal". It does a harsh kill which can leave your users with a "document contains no data" and possibly mess up open dbm files, etc. It works well for catching runaways though. - Perrin
Re: memory leak in win32
I've had memory leak issues on Linux [so I don't know how appropriate this advise is for Windows], and the fix that worked the best for others myself was to actually kill the apache server restart it. The process takes seconds, and can be automated scheduled for off-hours. If you search the archives you'll even find a log-rotation program that someone was kind enough to post. Just change it to suit your needs. Son Chang wrote: Hi, I'm experiencing a memory leak with Apache 1.3.14 with mod_perl 1.23 and perl5.6.0 on Windows NT4.0 and Windows2000. I've been running some test with a very simple ModPerl handler which just outputs an HTML page with hello world in it. Also, I made sure to undef all variables that I use. In general, the child processes grow with each request. Also, if I set MaxRequestsPerChild to 20 so the child process dies and restarts after every 20 request, this fixes the problem for the child processes. However, with this configuration, there's a memory leak problem with the parent process. After the child process dies and restarts, the parent process grows in size. This happens every time the child process dies and restarts. So with either configuration, I have a memory leak problem. What can I do to fix this problem? -son
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I've always considered mod_perl similar to an artist's canvas, while Java is more like a craftsman's tool kit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Retrieve OID from newly added record
Be warned that the OID field for a PostgreSQL record may not always be a unique value.
Visit the PostgreSQL Hackers list for more information.
Consider creating your own unique value using a combination of time/IP/random number,
or using a sequence. Although the condition rarely arises, it has bitten a few people.
Don't make the same mistake I did.
Have Fun!
Tim Tompkins wrote:
According to the DBD::Pg docs,
$sth-pg_oid_status
Returns the OID of the last INSERT command.
See: http://theoryx5.uwinnipeg.ca/CPAN/data/DBD-Pg/dbd-pg.html
Thanks,
Tim Tompkins
--
Programmer / Staff Engineer
http://www.arttoday.com/
--
- Original Message -
From: "cbell" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 07, 2000 1:28 PM
Subject: Retrieve OID from newly added record
Hello everyone, does anyone know how to retrieve the Object Identifier
(OID) from a record that was just inserted into a postgres database from
within perl?
These are the commands I'm using to insert the record:
$sth = $dbh-prepare("Insert into inventory Values ($id)");
$rc = $sth-execute;
$rc will tell me whether or not the insert was successful or not, but
that's it.
If I insert records from the psql utility, the OID is returned on the
screen after the insert, so I know it's there. I just need to know how
to get it from within modperl. I want to get this number so I can
insert a bunch of records in another file using the OID as the key.
Thanks in advance!
--
BLH
www.RentZone.org
Re: Memory Usage
Actually, I did search through the archives for log rotation and memory leaks, but was not able to find any information specifically linking memory issues to log rotation. If it were not for all the helpful people on this list, I wouldn't have known about all the options I have to minimize the adverse effects of this bug. Some on this list even suggested that I was the only person suffering this issue, but evidently this is not so. Since I've just subscribed to the list, I wouldn't have any knowledge of your previous posts, which most assuredly would have helped me. I don't think it's an issue of RedHat, or any other distribution, not providing enough documentation that's the issue here. I just feel that many people could benefit from the inclusion of a warning about mod_perl, DSO Apache in the location that the Apache Group maintains for this on their website "Apache 1.3 Dynamic Shared Object (DSO) Support [http://www.apache.org/docs/dso.html]." It certainly can't hurt, and is were most people would logically go for information. Let's face it, many people who purchase a major distribution probably aren't going to use mod_perl; consequently, the vendors may not even be aware of any issues. The knowledge base of the contributors to this list can help many people, especially on this issue, because everyone has to rotate logs sooner or later. From the responses to this particular issue we have seen that quite a few people have had the same experience, even when mod_perl is compiled statically in Apache. Addressing an issue openly, thoroughly, quickly and responsibly is what separates open source projects from our poor, closed source brethren. If anyone feels offended or slighted by my somewhat ineloquent, or poorly considered posts, you have my sincerest apologies. Life is too short for conflict. I think this post has gone on a bit too long, and sapped too much time from everyone's schedule, so I'd like to end it now so that you all can get back to more productive endeavors. I'd like to thank everyone who helped me out, especially the following: Jens-Uwe Mager for pointing out the source of the issue; Christian Gilmore for the rotation scripts; G.W. Haywood for the perls of wisdom; Gunther Birznieks for yet another option; Ri?ardas ?epas for the piped rotatelogs program suggestion, and Roger Espel Llima for pointing out that the same issue exists with mod_perl compiled statically. Have a great Day! Douglas Leonard wrote: First off, the complaint about the lack of documentation for DSO being experimental is a bit offbase IMO. It isn't up to the mod_perl group to make sure RedHat includes complete documentation in their build of mod_perl. Also, this issue has been talked about many times on this mailing list. Sometime after mod_perl 1.20 was released there was talk that the DSO problems had been fixed. I can remember putting out a post myself on exactly how to cause the process size to grow using HUP or USR1 when using mod_perl 1.21 and 1.22-dev in order to disprove this. It is always best to check one of the archives first for this kind of problem IMO. I find it best to do a daily staggered shutdown/restart of each apache server and rotate the logs via a custom script. One minute of downtime per server per day isn't exactly noticeable when you have a load balancing system set up. On Tue, 7 Nov 2000, Buddy Lee Haystack wrote: Thanks, but as a RedHat [or other typical major distribution] user, I would never see the documentation you mentioned below. Since DSO is still experimental, would it not be an absolute necessity to include that information in the location where most users are directed to look for information about all things Apache? The first place I go to look for information is on the online documentation, and I know that the "experimental" nature of using DSO is not mentioned anywhere in "Apache 1.3 Dynamic Shared Object (DSO) Support" [http://www.apache.org/docs/dso.html]. It appears as if the "experimental" nature of DSO's under Apache is fairly well removed from view. Had the information you included below been clearly listed on Apache's website, in the proper location, many people would have made a choice not to use DSO. It appears as if the Apache Group has been a little less than candid in Apache's true support for DSO. IMHO There really needs to be a warning in the documentation on their website explicitly stating the info you've included below. snip -- Douglas Leonard [EMAIL PROTECTED] -- BLH www.RentZone.org
Re: Memory Usage
"G.W. Haywood" wrote: Hi there, On Mon, 6 Nov 2000, Buddy Lee Haystack wrote: The morning after "logrotate" runs on my system, the memory usage increases by about 30 megabytes, and continues to do so after each weekly run of the "logrotate" utility. What happens if you then do a graceful restart? The logrotate scripts use HUP to restart the server. I don't think the USR1 would be appropriate for log rotation - according to the Apache documentation: "At present there is no way for a log rotation script using USR1 to know for certain that all children writing the pre-restart log have finished. We suggest that you use a suitable delay after sending the USR1 signal before you do anything with the old log." Has anyone else had this experience? Nope. But then I don't do it that way. I'm all ears. ;-) -- BLH www.RentZone.org
Re: Memory Usage
Thank you very much! Now I know why most of the people on this list don't use DSO. Is there any other work around for this situation other than rotating my logs less frequently? Maybe a different method of rotating my logs like using the TERM signal instead of the HUP signal? Thanks! Jens-Uwe Mager wrote: On Mon, Nov 06, 2000 at 05:49:05PM -0500, Buddy Lee Haystack wrote: I'm using RedHat Linux v6.1 on an Intel PII SMP box Apache v1.3.14 mod_perl v 1.23 Apache::DBI 0.87 DBI v1.13 DBD Pg v0.93 PostgreSQL v6.5.3 The morning after "logrotate" runs on my system, the memory usage increases by about 30 megabytes, and continues to do so after each weekly run of the "logrotate" utility. Has anyone else had this experience? I'd like to rotate my logs weekly, but at this rate I'll run out of ram in a couple of months. This happens if mod_perl is compiled as a DSO, this will not happen if mod_perl is compiled statically into the httpd core. I believe that this has something to do with the way perl allocates variable and stashes them away in static or global variables. If mod_perl is compiled as a DSO, httpd will completely unload and reload all DSO's on a restart and cause all global/static variables to be reset to NULL, forgetting all traces about previously allocated memory. If mod_perl is built statically, it will not be reloaded and thus all global/static variables persist and perl will re-use the memory allocated. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED] -- BLH www.RentZone.org
Re: Memory Usage
What happens if you then do a graceful restart? The memory consumption increases by about 1 megabyte for each child process every time I issued the USR1 signal. Which is kind of what I expected given Jens-Uwe Mager's explanation of DSO's failings with mod_perl. I can always rotate my logs manually, or use the Apache rotatelogs program that Ri?ardas ?epas recommended, although if the "rotatelogs" program restarts the server I'll be back to square one - the program's man page just states that it doesn't kill the server, but does that mean that it doesn't restart it? I'm leaning along the lines of just killing the process, rotating the logs, and restarting it. It should take no more than 5 seconds once a week a 4:00am. What concerns me even more is the fact that I have Apache restart child processes after they each serve 100 requests [MaxRequestsPerChild 100] it's a RedHat default that is supposed to reduce memory leaks, but with mod_perl DSO it may actually have the opposite effect. I can easily increase the value, or remove it altogether. Any recommendations? I take it that by far the most prudent course of action would be to role my own, and compile mod_perl statically. I may have to do just that, but I won't have the time to do so until December; consequently, I need a temporary fix to last about a month. I'd like to thank everyone for helping me. Have a great day, and any additional input will be greatly appreciated! "G.W. Haywood" wrote: Hi there, What happens if you then do a graceful restart? -- BLH www.RentZone.org
Re: Memory Usage
I may have missed that, but it dosen't mention the "experimental" nature of DSO in the "DSO has the following disadvantages:" section of the documentation located at "http://www.apache.org/docs/dso.html" "G.W. Haywood" wrote: Hi again, On Tue, 7 Nov 2000, Buddy Lee Haystack wrote: Maybe someone should include this information in the Apache documentation covering the DSO issues. It would be very helpful to people starting out, such as myself. It *does* say in the docs that DSO is experimental. 73, Ged. -- BLH www.RentZone.org
Re: Memory Usage
Thanks, but as a RedHat [or other typical major distribution] user, I would never see the documentation you mentioned below. Since DSO is still experimental, would it not be an absolute necessity to include that information in the location where most users are directed to look for information about all things Apache? The first place I go to look for information is on the online documentation, and I know that the "experimental" nature of using DSO is not mentioned anywhere in "Apache 1.3 Dynamic Shared Object (DSO) Support" [http://www.apache.org/docs/dso.html]. It appears as if the "experimental" nature of DSO's under Apache is fairly well removed from view. Had the information you included below been clearly listed on Apache's website, in the proper location, many people would have made a choice not to use DSO. It appears as if the Apache Group has been a little less than candid in Apache's true support for DSO. IMHO There really needs to be a warning in the documentation on their website explicitly stating the info you've included below. "G.W. Haywood" wrote: Hi again, On Tue, 7 Nov 2000, Buddy Lee Haystack wrote: I may have missed that, but it dosen't mention the "experimental" nature of DSO in the "DSO has the following disadvantages:" section of the documentation located at "http://www.apache.org/docs/dso.html" Extract from my copy of the Guide source (install.pod): -- =head2 Build mod_perl as a DSO inside the Apache Source Tree via APACI BWarning: ITHIS IS STILL EXPERIMENTAL, SO BE WARNED! With Apache 1.3 there is support for building modules as Dynamic Shared Objects (DSO). So there is support for DSO in mod_perl now, too. Your mileage may vary. Almost certainly it will. BWarning: IYOU HAVE BEEN WARNED! -- 73, Ged. -- BLH www.RentZone.org
Re: Memory Usage
Thanks! I was under the mistaken impression that I was finally finished with the administration side of things... Oh well... "G.W. Haywood" wrote: Hi there, On Tue, 7 Nov 2000, Buddy Lee Haystack wrote: The memory consumption increases by about 1 megabyte for each child process every time I issued the USR1 signal. Ugh. I can always rotate my logs manually, I'm leaning along the lines of just killing the process, rotating the logs, and restarting it. It should take no more than 5 seconds once a week a 4:00am. Yup. What concerns me even more is the fact that I have Apache restart child processes after they each serve 100 requests [MaxRequestsPerChild 100] it's a RedHat default that is supposed to reduce memory leaks, It tends to reduce the effect of them. The leaks are still there. but with mod_perl DSO it may actually have the opposite effect. I can easily increase the value, or remove it altogether. Any recommendations? I'd say compile static and do that anyway. Definitely don't remove it nor set it to zero. You aren't out of the memory leak woods just because you don't use DSO. 100 is towards the upper limit of what I'd use, and towards the lower limit of what most other people will use. I take it that by far the most prudent course of action would be to role my own, and compile mod_perl statically. I may have to do just that, but I won't have the time to do so until December; It shouldn't take very long to compile. Takes me ten minutes using a file called makepl_args.mod_perl containing my configuration options, in the top level of the mod_perl directory. The command line goes: c2h5oh:/usr/src/mod_perl# perl Makefile.pl make make install Then I just stop the old server and start the new one. 73, Ged. -- BLH www.RentZone.org
Re: Memory Usage
Thanks Christian! Scripts would be nice.;-) I take it you've used DSO much more than I have, so I'm interested in any information in addition to that provided by the kind "G.W. Haywood" to the following: "What concerns me even more is the fact that I have Apache restart child processes after they each serve 100 requests [MaxRequestsPerChild 100] it's a RedHat default that is supposed to reduce memory leaks, but with mod_perl DSO it may actually have the opposite effect. I can easily increase the value, or remove it altogether. Any recommendations?" Christian Gilmore wrote: I'm leaning along the lines of just killing the process, rotating the logs, and restarting it. It should take no more than 5 seconds once a week a 4:00am. This is exactly what I do, except I have it scripted. The downside is that your service is unavailable for a few seconds (maybe more depending upon the length of time it takes for the parent to wipe out all the old children). I'd be happy to share the script, provided my boss doesn't mind. :) Regards, Christian -- BLH www.RentZone.org
Memory Usage
I'm using RedHat Linux v6.1 on an Intel PII SMP box Apache v1.3.14 mod_perl v 1.23 Apache::DBI 0.87 DBI v1.13 DBD Pg v0.93 PostgreSQL v6.5.3 The morning after "logrotate" runs on my system, the memory usage increases by about 30 megabytes, and continues to do so after each weekly run of the "logrotate" utility. Has anyone else had this experience? I'd like to rotate my logs weekly, but at this rate I'll run out of ram in a couple of months. Thanks! -- BLH www.RentZone.org -- BLH www.RentZone.org
Re: Want to work at a Game company?
Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer.
Re: Want to work at a Game company?
I don't think an apology is in order. According to Jason's reply, you did the right thing! IMHO, it would be really nice if there were a separate list [or website] tailored for mod_perl job opportunities. I know that I would subscribe / visit. ;-) Have a GREAT day! "Graf, Chris" wrote: This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject:Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
Re: [RFC] Benchmarking Apache::Registry and Perl Content Handler
Hello!
Can you please provide the technical specifications for the hardware that performed
these tests.
Thanks!
Stas Bekman wrote:
Disclaimer: the numbers here are too low for mod_perl, because my machine
is to slow :( I'll rerun the same tests on a much faster machine
before releasing the new version of the Guide.
=head1 Benchmarking Apache::Registry and Perl Content Handler
=head2 Empty scripts
First lets see the overhead that Apache::Regsitry adds. In order to do
that we will use an almost empty scripts, that only send a basic
header and one word as a content.
The Iregistry.pl script running under CApache::Registry:
registry.pl
---
use strict;
print "Content-type: text/plain\r\n\r\n";
print "Hello";
The Perl Content handler:
Benchmark/Handler.pm
package Benchmark::Handler;
use Apache::Constants qw(:common);
sub handler{
$r = shift;
$r-send_http_header('text/html');
$r-print("Hello");
return OK;
}
1;
with settings:
PerlModule Benchmark::Handler
Location /benchmark_handler
SetHandler perl-script
PerlHandler Benchmark::Handler
/Location
The benchmark:
% ab -n 1000 -c 10 http://localhost/perl/benchmarks/registry.pl
Requests per second:21.27
Time taken for tests: 43.924 seconds
Connnection Times (ms)
min avg max
Connect:0 3 218
Processing: 223 435 679
Total:223 438 897
% ab -n 1000 -c 10 http://localhost/benchmark_handler
Requests per second:49.03
Time taken for tests: 20.394 seconds
Connnection Times (ms)
min avg max
Connect:0 1 201
Processing:59 201 605
Total: 59 202 806
So we can see that the average added overhead is about:
438 - 202 = 236 milli-seconds
per script.
=head2 Heavy Scripts
Of course this overhead is insignificant when the code itself is
significantly heavier and slower. Let's leave the above code examples
umodified but add some CPU intensive processing operation (it can be
also an IO operation or a database query.)
my $x = 100;
my $y = log ($x ** 100) for (0..1);
% ab -n 1000 -c 10 http://localhost/perl/benchmarks/registry.pl
Time taken for tests: 121.944 seconds
Requests per second:8.20
Connnection Times (ms)
min avg max
Connect:011 950
Processing: 747 1204 888
Total:747 1215 1838
%ab -n 1000 -c 10 http://localhost/benchmark_handler
Time taken for tests: 41.166 seconds
Requests per second:24.29
Connnection Times (ms)
min avg max
Connect:0 3 150
Processing:73 407 1211
Total: 73 410 1361
META: something is wrong here! It shouldn't be that slower. Should try
run it on a faster machine!
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--
Re: Mod_Perl install - no apxs error
Some cut paste from previous messages... For RedHat DSO specific steps in the mod_perl guide see: http://perl.apache.org/guide/install.html#Installing_separate_Apache_and_m No need to recompile Apache. My DSO setup works quite well! **EDIT the "/etc/httpd/conf/httpd.conf" file #uncomment the line below under the section # Dynamic Shared Object (DSO) Support LoadModule perl_modulemodules/libperl.so #uncomment the line below under the section # Extra Modules AddModule mod_perl.c #add the following line ScriptAlias /perl/ "/home/httpd/cgi-bin/" #uncomment the following lines # If the perl module is installed, this will be enabled. IfModule mod_perl.c Alias /perl/ /home/httpd/cgi-bin/ Location /perl SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Location /IfModule * I use my setup to test, so I execute both mod_perl standard perl scripts from the same CGI directory... Now, anything that is accessed as http://mysite.com/perl/perlscript.cgi will run as a mod_perl script, and anything accessed as http://mysite.com/cgi-bin/perlscript.cgi will run as a non_mod_perl script. Use this setup only if you want to test scripts as both normal cgi mod_perl scripts, otherwise you'll need to point the "Alias /perl/ /home/httpd/cgi-bin/" line "ScriptAlias /perl/ "/home/httpd/cgi-bin/" line to point to another CGI directory of your choice. Hope this helps! Kenneth Frankel wrote: I have tried almost every variation of installation instructions, and all have failed. I can't find anything in the FAQs so please help me. Situation: Redhat 6.1 Linux 2.2.12, with pre-installed Apache httpd. Removed pre-existing httpd from PATH. Installing new Apache to different path. Source versions: apache_1.3.12, mod_perl-1.22. SNIP
Re: [slightly OT] redhat linux 6.1
I haven't built any rpms myself, but I am using Redhat v6.1, Apache v1.3.9-8, perl v5.00503-6, and mod_perl v1.21-2. They were all downloaded from RedHat's FTP site as rpms, and worked fine after installation. I think many people encounter difficulty in correctly modifying the httpd.conf file after installing mod_perl. If you wish, I can send you my httpd.conf file which also contains entries for the Apache DBI module. You may also want to have a look at: http://perl.apache.org/guide/index.html Bryan McGuire wrote: Has anyone built RPMs for redhat 6.1 with apache/1.3.9 and mod_perl 1.2.2 where DSO actually works. If not, I would like to know how to do it. It's a shame that redhat linux 6.1 is shipping with a broken mod_perl, and I believe it would help the cause for mod_perl if linux 6.1 users could simply download an easy to use, drop-in replacement for the apparently broken mod_perl-1.21-2.i386.rpm
Re: how to debug why apachedbi doesn't work?
I have RedHat v6.1 it is working fine, so I'll just send you my http.conf file for you to compare to your own. Adam Gotheridge wrote: env: redhat 6.2, apache, modperl installed from rpm. ApacheDBI-0.87 installed. If I put either PerlModule Apache::DBI PerlModule Apache::AuthDBI in httpd.conf, apache doesn't start, there are no errors to the screen, and there is nothing in the apache error log. How can I determine why this is not working? Thanks
Re: installing with apache
Depending on your particular setup this will probably vary a bit. I'm a RedHat user find that the mod_perl DSO module makes my life a bit easier, although a majority of mod_perl users roll their own, and swear by mod_perl's increased stability performance.;-) I checked the "Apache Bible," and you should get a good start on getting your system running by adding a couple of lines to your httpd.conf file, but use your own particular directory structure. **EDIT the "httpd.conf" file by adding the following lines... ScriptAlias /perl/ "/home/httpd/cgi-bin/" Alias /perl/ /home/httpd/cgi-bin/ Location /perl SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Location * I use my setup to test, so I execute both mod_perl standard perl scripts from the same CGI directory... Now, anything that is accessed as http://mysite.com/perl/perlscript.cgi will run as a mod_perl script, and anything accessed as http://mysite.com/cgi-bin/perlscript.cgi will run as a non_mod_perl script. Use this setup only if you want to test scripts as both normal cgi mod_perl scripts, otherwise you'll need to point the "Alias /perl/ /home/httpd/cgi-bin/" line "ScriptAlias /perl/ "/home/httpd/cgi-bin/" line to point to another CGI directory of your choice. Hope this helps! R Joseph Wright wrote: On Sat, 1 Apr 2000, Buddy Lee Haystack wrote: Have you had a chance to look over the excellent documentation located at [http://perl.apache.org/guide/install.html]? Yes, it's very good documentation, but nowhere do I find where it tells what line to put in httpd.conf and where. I get the sense from reading the docs that if you compile mod_perl statically into apache there is no extra configuration necessary. I just can't find it, maybe I'm too tired |-O. R Joseph Wright wrote: On Fri, 31 Mar 2000, Doug MacEachern wrote: After having compiled mod_perl and apache together, shouldn't mod_perl be enabled in httpd.conf? It isn't. Have I done things correctly? no, you need to add the mod_perl configuration to httpd.conf yourself. Then here is part II of the question: Where do I tell it to load mod_perl? I know the order in which modules are loaded is important.
Re: installing with apache
Have you had a chance to look over the excellent documentation located at [http://perl.apache.org/guide/install.html]? R Joseph Wright wrote: On Fri, 31 Mar 2000, Doug MacEachern wrote: After having compiled mod_perl and apache together, shouldn't mod_perl be enabled in httpd.conf? It isn't. Have I done things correctly? no, you need to add the mod_perl configuration to httpd.conf yourself. Then here is part II of the question: Where do I tell it to load mod_perl? I know the order in which modules are loaded is important.
Re: Installation
Why not try RedHat v6.1? Installing it is a snap! I had it up running in no time. After installing the rpm file for mod_perl, just follow the directions to activate it in the /etc/httpd/conf/httpd.conf then reboot to activate the changes if your a former Windows user.;-) No need to recompile Apache. My DSO setup works quite well! **EDIT the "/etc/httpd/conf/httpd.conf" file #uncomment the line below under the section # Dynamic Shared Object (DSO) Support LoadModule perl_modulemodules/libperl.so #uncomment the line below under the section # Extra Modules AddModule mod_perl.c #add the following line ScriptAlias /perl/ "/home/httpd/cgi-bin/" #uncomment the following lines # If the perl module is installed, this will be enabled. IfModule mod_perl.c Alias /perl/ /home/httpd/cgi-bin/ Location /perl SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Location /IfModule * Now, anything that is accessed as http://mysite.com/perl/perlscript.cgi will run as a perl script... Use this setup only if you want to test scripts as both normal cgi mod_perl scripts, otherwise you'll need to point the "Alias /perl/ /home/httpd/cgi-bin/" line "ScriptAlias /perl/ "/home/httpd/cgi-bin/" line to point to another directory of your choice. Hope this helps! Annette wrote: I have been trying to install mod_perl for the last couple of weeks and I still have not been successful. I am new to Linux and have installed RedHat 6. I used the Custom set-up and installed mod_perl during the installation. I entered the command 'perl -v' and it tells me that I have perl loaded but not mod_perl. Does anyone know what I have to do to enable mod_perl, tell if I have it enabled, or where I can read about the installation under RedHat 6. I have tried installing it using src files, followed the directions line by line and still nothing. Is this the right mailing list to ask this question? Where should I go if not? Apache is up and running just fine. Any input would be appreciated. Ann.
Re: How to keep Connection: Keep-Alive
If you're referring to a database connection, the Apache DBI module keeps the connection alive, not the mod_perl module. Jaime Teng wrote: Hi, How do you make perl script (either on Linux+Apache+Mod_perl or in NT+IIS4 environment) make a "Connection: Keep-Alive". On both environment, the connections always closes after the perl script finished execution. Any idea? Jaime
Re: How to keep Connection: Keep-Alive
Hello Dr. Frog! Any relation to Kermit? I'm not sure Jaime is referring to PostgreSQL [my favorite open source DB] in particular, or even database persistence in general. Clayton Cottingham aka DrFrog wrote: r u talking about db persistence? postgres does concurrent persistence checking what does this mean? it means it handles the whole db in such a way that coding persistence into your perl progs really isnt nessecary as postgres handles it all for youn automagically btw anyone notice how much mysql has been dropping out at freshmeat lately?! Buddy Lee Haystack wrote: If you're referring to a database connection, the Apache DBI module keeps the connection alive, not the mod_perl module. Jaime Teng wrote: Hi, How do you make perl script (either on Linux+Apache+Mod_perl or in NT+IIS4 environment) make a "Connection: Keep-Alive". On both environment, the connections always closes after the perl script finished execution. Any idea? Jaime
