Kryptronic Software Support Forum

You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.

#1 12-23-2003 09:49:35

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19511
Website

CCP6 Codebase (Perl Vs. PHP) CONTINUED

Please refer to this post for the intial discussion:



This new poll is in response to user requests for a new poll because the discussion of the topic has resulted in changed opinions.


Nick Hendler

Offline

 

#2 12-23-2003 10:57:54

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19511
Website

Re: CCP6 Codebase (Perl Vs. PHP) CONTINUED

To continue the discussion here, I would first like to again thank everyone for their input thus far.  To address the latest round of comments:

From TerryA:



If the cart can be developed in Perl and be made to run faster and use less resources through the use of multi-threading or mod-perl, I am all for it! The ultimate goal is for a secure, dependable shopping cart that isn't bloated beyond reason by a bunch of unneeded features or faulty code.

Speed and scalability are two main priorities with this release.  If done in Perl, mod_perl will be supported but not required.  I believe support for mod_perl will be done under the Apache::Registry module.  I have also been doing a lot of thinking about where bottlenecks are in the current codebase - and have determined that the best way to increase speed is to eliminate use of CSV SQL calls wherever possible.

The new codebase will support full-blown CSV implementations - have no worries.  But, if you choose to run *everything* in MySQL, we should be able to accomodate that.  Right now every script load calls the settings and altrdbms tables in CSV to figure out what we can do as far as MySQL.  I'm planning on building a Cache module that handles gathering that data from data structures rather than CSVs if the CSVs haven't been updated.  We should see a significant load decrease and performance increase from this alone.

From kingdavidK:



I think when it comes right down to it, Terry says it all!
We will all eventually defer to your best judgement.

I appreciate your confidence.  My purpose here is only to guage what the community feels may be the better implementation.

From morvak:



Stick with perl. PHP is grade school stuff. Ecommerce and Perl are for the big dogs

The more and more I get into PHP, the more and more this statement seems valid.

From Uncletim:



So whatever you can use to give me more control over the entire process (from a marketing person's perspective) as fast as possible, gets my vote. I will learn whatever I need to do this (within reason). I think these types of needs and improvements will be changing for quite some time to come. And they drive the reason we all come together in the first place.

I agree with this too.  The reason we've been using Perl for so long is because of what it provides.  Another main goal of the new version will be to make ongoing administration and upgrade as simple as possible for everyone so you can concentrate on marketing rather than administration.

From Jasonw22:



Thanks Nick for your latest comments. It seems you've come to the same conclusion I came to after working with both PHP and Perl for several years. Personally, I'm extremely excited about the potential of Perl 6. Perl has the advantage of being both relatively easy to learn while being a "real" programming language, unlike PHP. I'm really excited to hear that you are considering a mod_perl version of ccp, and providing the option of doing away with csv files altogether. I'd also love to see some thought put into allowing the use of other databases such as PostgreSQL or SQLite, and Perl's DBI should make that a snap, no?

One caveat with regard to mod_perl: Will there also be a non-mod_perl version of ccp 6? Sadly, many webhosts do not support mod_perl apps, although the number of those that do is constantly increasing.

I've got to admin that I am leaning towards Perl right now for these very reasons.  Also, as I indicated above, mod_perl will be supported in some fashion, but will by no means be required.

From m_j:



I would recommend Nick looking into using Apache::Registry because it offers some of the best speed while still being able to write code that would be interoperable with a CGI environment. O'Reilly has a very nicely publsihed book called "Practical mod_perl" which is a must read if you are going to be programming in a mod_perl environment.

Thanks for the recommendation.  I'll be buying that on Amazon later today.

From Will:



Nick, you need to nix this poll and start a new one based on your new views and insights in to php vs perl. I for one voted for PHP, but would now want to change my vote to Perl.

Done and done smile


Nick Hendler

Offline

 

#3 12-30-2003 03:01:56

m j
Member
From: Carthage, MO
Registered: 12-12-2003
Posts: 71
Website

Re: CCP6 Codebase (Perl Vs. PHP) CONTINUED

Looks like things are headed in the right direction, and the new poll seems to indicate quite a swing towards Perl now.

Have you looked into HTML::Mason any in regards to its parsing abilities similar to the way that PHP manages code and HTML together? I was reading about Mason and although it has like some huge mod for Apache, I would just like to have the parsing ability so you could interweave HTML and Perl like you can with PHP. I'm going to see if I can't use it in some way on my next project in order to make some of the design work easier to manipulate when working with code in the environment.


Perl, MySQL, XHTML, CSS, Web Usability, XML
Matt Johnson

Offline

 

#4 01-06-2004 13:14:49

vrinsight
Member
Registered: 01-31-2003
Posts: 54

Re: CCP6 Codebase (Perl Vs. PHP) CONTINUED


I prefer the Perl codebase to PHP. The speed and scalability can be achieved with mod_perl, as many people already stated, here is one of the exaple,

[QUOTE]
If the program is written in Perl, it will be written using the strict pragma and will run under mod_perl - so it will be fast - as fast as PHP. I've also documented so optimizations that will speed things up such as calling a .pl file to read in settings rather than doing an SQL call to a CSV file. Other optimizations include only calling CPAN modules when used rather than having them available all the time (as in the case of Mail::Sendmail and the Cryt::HCE_MD5 module).

I can make a Perl version run about 25% faster out of the box as a separate process - and mod_perl if used can make it at least 50% faster. That matches if not beats the speed of PHP. We can also do things to optimize CPU and memory usage like never calling CSV files at all when MySQL is in full use.

Frank

Offline

 

Board footer