primus has asked for the wisdom of the Perl Monks concerning the following question:

greetings and salutations fellow monks,

currently i am using mySQL and the perl DBI to pull links for my website's navigation menu, and also to pull news from a database.

i was thinking of using the DBI to XML and then reading the XML for the links and the news and if the links were updated, then i would recreate the XML links file, and if the news was updated, then i would recreate the news XML file.

do you fellows believe that the wesite would run more efficiently or faster if i were to use the XML, or just go straight from the database?

at first i thought that the XML would be faster because really, how often will links need to be changed? but the news on the other-hand, will be updated probably everyday, so i dont really know what i should do.

thanks for the help monks!

Replies are listed 'Best First'.
Re: speed and efficiency XML/DBI vs DBI
by perrin (Chancellor) on Jan 13, 2003 at 18:00 UTC
    It sounds like you're trying to build a cache. XML is a poor choice for that because of all the parsing overhead. You should look at using Cache::Cache or MLDBM::Sync instead.
[reply]
Re: speed and efficiency XML/DBI vs DBI
by dws (Chancellor) on Jan 13, 2003 at 18:23 UTC
    do you fellows believe that the wesite would run more efficiently or faster if i were to use the XML, or just go straight from the database?

    It is almost always better to cache, unless the mechanism you've chosed for caching is itself expensive. XML is flexible, but it carries some overhead, including the additional modules you need to load at runtime to convert it to HTML. An XML cache is probably going to save substantially over going to the database each time, but you're still leaving some performance opportunities on the table.

    Why not cache links in an HTML fragment?

[reply]

      well, i was thinking about caching with a regular text, or HTML file, but then i remembered about the prepare_cached() method for the DBI... do you guys think that there would really be a huge difference from using that, to reading say an HTML file...

      the table with the links is not very big and also i will have established a connection to the database for other reasons, so it's not like i need to 'connect' to the database everytime i want to pull the links... i just have to run the SQL query...

[reply]
        it's not like i need to 'connect' to the database everytime i want to pull the links... i just have to run the SQL query...

        It's considerably more expensive to ship a query over the wire, compile it, execute it, then marshal the results to ship back over the wire to an application that then needs to unmarshal those results than it is to open a local file and suck some bytes into memory. Perhaps, though, that performance difference isn't significant in your application.

        A perfectly reasonable approach it to consider the likely upper bound on traffic that your site will need to support, then do the simplest thing that will satisfy that performance requirement. If executing a query (or several queries) per page view works for you, go for it.

[reply]
        The prepare_cached method prevents the statement handle from being created more than once (in a persistent environment like mod_perl), but that's all it does. The query still has to be executed by the database. It should be faster to pull the data from a cache.

        Maybe you're getting ahead of yourself here. Is the site slow now? Have you profiled it to find out where the bottlenecks are? It could be that this particular query runs so fast that it's not worth caching.

[reply]

Back to Seekers of Perl Wisdom