Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: PERL/CGI Performance

by Ryszard (Priest)
on Jul 30, 2002 at 08:25 UTC ( [id://186151]=note: print w/replies, xml ) Need Help??


in reply to Perl/CGI Performance for a Shopping Cart

The performance of your site isnt *only* related to perl. We're talking network latency, machine speed, ram, IO, disk speed et al. Much of the overhead with perl CGI's is related to brining up the perl interpreter. (one instance per CGI). Check out mod_perl, it is apache with the perl binary build into it at compile time (Only have to load perl when you start apache).

DONT USE FLAT FILES!, I'm thinking of several reasons:

  • Integrity - you may trash your "database" via a fatfingers (or late night) typo, very easy to do if you delete where you should have inserted.
  • Normalisation - much easier to do in an RDBMS than using flat files. If you're unsure as to what normalisation is, i reckon it could be a good research topic.. :-)
  • Scalability - It is much easier to preserve normalisation and extend your database using SQL than flatfiles.
  • Data integrity - Foreign key constraints. Enforcement of primary key, data typing, all native to an RDBMS you "should" use..

    Why use perl over ASP? Microsoft.. :-) completly irrational argument. TBH both may do the job, both platforms have quirks and the performance is highly dependant on application design. I'd choose perl as its easy, lots of support (you posted the question here didnt you?), and portable, (you can run it on solaris, linux, windows...). Also means your choice of host provider is not as limited.

    What makes MySQL better than others? Not much IMO. The latest stable release doesnt support transactions (Postgres, Oracle does). Both Postgres and MySQL are free, both have heaps of support... If youre leaning toward more of an "Enterprise" solution, Postgres may be the way to go as it is transaction based. If you're not particularly worried about this feature, MySQL might be the way to go.

    Of course if you have lots of cash, i'd say Oracle, which would probably be complete overkill for a small(ish) application.. :-)

    Anyways, good luck.

    Update: Whoops, i stand corrected on my ASP comments after reading IlyaM's post.

  • Replies are listed 'Best First'.
    Re: Re: Perl/CGI Performance
    by IlyaM (Parson) on Jul 30, 2002 at 10:49 UTC
      Integrity - you may trash your "database" via a fatfingers (or late night) typo, very easy to do if you delete where you should have inserted.

      I've heard so many horror stories about late night mistakes like forgetting about WHERE part of UPDATE or DELETE queries that I don't think that SQL database is any safer than filesystem in this respect. In reallity no matter what database backend you use backups are must have for important data.

      The latest stable release doesnt support transactions

      Not true (for quite long time) with InnoDB table type which is part of source MySQL distro and part of MySQL-Max binary distro.

      --
      Ilya Martynov (http://martynov.org/)

        I've heard so many horror stories about late night mistakes like forgetting about WHERE part of UPDATE or DELETE queries that I don't think that SQL database is any safer than filesystem in this respect. In reallity no matter what database backend you use backups are must have for important data.

        Jepp! Two years ago I damaged all ongoing projects of my company from home by forgetting a where-clause; the backups were not @home :-)

        pure luck I wasn't killed in a car-crash that day...while we hurried to the companys rooms

        So while typos aren't an argument for DBMS :-), an rdbms is the way to go if scaleabilty matters, and it matters for every project not typed at the console-prompt (and somtimes even there...)


        regards,
        tomte
          Agreed, however I was thinking the integrity of the structure of the database, as opposed to the integrity of the data in database.

          For example a badly formed "query" may remove data partway across fields, damage the data definition (if there is one) etc etc...

          With an RDMBS you're looking at a standard interface to your data that wont corrupt the framework of your RDBMS.

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Domain Nodelet?
    Node Status?
    node history
    Node Type: note [id://186151]
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this?Last hourOther CB clients
    Other Users?
    Others sharing their wisdom with the Monastery: (4)
    As of 2024-03-28 22:41 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found