On Sun, Sep 11, 2016 at 11:08 AM, Ruben Safir <ru...@mrbrklyn.com> wrote:
> On 09/11/2016 11:38 AM, Igor Chudov wrote: > > About maybe half of those responses are images generated by > mod_perl/CGI.pm > > scripts that draw pictures of math formulas like x/(x+1) etc. > > > > I agree that running CGI.pm inside true CGI scripts (one process per > every > > web object) is expensive. Running it inside mod_perl seems to be > extremely > > efficient. > > > interesting. How big are those graphics. Examples of graphics are here: https://www.algebra.com/services/rendering/ I draw these pictures on the fly using GD::Graph, by parsing formulas and rendering them in proper notation. > We had to pull modperl from > service at about.com because of the ram foot print and the contact > limitations, even with semiphores pulled way up. About.com has about 19M monthly visitors, according to quantcast. Algebra.com about 2.4 million, about 8 times less. I had similar problems of all kinds when my traffic grew, including, as I clearly recall, RAM and semaphores, and also a lot of sql performance problems. The semaphores I had to clean up often from cron using a script that I found online. I also specify restart of apache children after so many requests etc. Had to do a lot of sql optimization. The result it that everything functions smoothly. My analogue is that there are typical pets like a dog, a cat or a parrot. But a pet elephant is a special pet, you need a truck just to bring food and the flor would cave in so you need to do a lot more if you have a pet elephant. Same with having any large site, there is work that a small site does not have to do. If your producing > images like gnuplot, then your approach has many advantages, not the > least of which is flexibility. If your doing something like my images > gallery, it would be less efficient, although I still run it under > modperl in the hopes that I'm caching a good percentage of my images in > the apache server. > > I chose not to cache any images and I render every single image on the fly. This actually scales better than caching them. > Regardless, the point that you made that I felt was condensing and > inaccurate was the efficiency of CGI.pm was superior, and that embedded > coding was inefficient and disorganized. I can go straight to the > Lincoln Stein book and quote his opinions on CGI.pm's bloat. No matter > what you are using, your making some templates and reoccurring HTML. Or > maybe not, maybe each of your pages are unique, completely. > > OK with that o/o. > > Ruben, I understand that, for example, PHP is an embedded language. But if you look at almost any big php project, such as mediawiki or whatever, most of them immediately revert to "make HTML inside PHP code" as opposed to "embed PHP code in HTML". Look at mediawiki php source files. This is how these projects evolve. > Ruben > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 >
