[wp-hackers] lots of category items
halukkaramete at gmail.com
Fri Apr 6 16:43:56 UTC 2012
Excellent advise mike. But the problem is there is no such database. The current db is in mssql and the current site is in asp. We are migrating 15k records (videos and articlsr and news links etc )from various mssql tables to Wordpress. The old system got some categorization/classification/taxonomization whatever we want to call it) but one table's classification is not the same as the other one.
We wanted to put an end to this and bring a law and order. We came up with a simpler classification system where we group items by media type, audience group intended, collection type (tutorials, debates,interviews etc) And topics etc etc. Well the old table's don't have those but somehow similar classifications. We want to do the migration programmatically.
The new db may be implemented differently. That's where my original question stemmed from.
So to test/measure, I need to do two migrations right? Which won't happen. I was seeking the community's gut feeling as to how much of a concern is this speed thing all about so I pick the proper taxonomy style.
If the category boxes had a way to be splitted up from the top levels and appear like sep taxonomies, I would not question this and I would go for one taxonomy=category approach.
But such an option does not exists as gas as I know.
Sent from iPhone
On Apr 6, 2012, at 2:11 AM, Mike Little <wordpress at zed1.com> wrote:
> On Fri, Apr 6, 2012 at 01:24, Haluk Karamete <halukkaramete at gmail.com>wrote:
>> The question is if the speed concerns you raised in your article warrants
>> that we go with one taxonomy and live with the "lots of category items" or
> Why don't you just try it? Instead of trying to estimate or predict, why
> not measure?
> Take a copy of your live database/site, and run some tests against it with
> the actual queries. You can get them by defining define('SAVEQUERIES',
> true); in wp-config and then the queries will be in $wpdb->queries. That
> array includes the execution time of those queries. There may be enough of
> a difference between them to give you your answer straight away. But those
> execution times include some WordPress processing time. So you could
> perhaps take those queries and run them directly against your database,
> (1000 times and take the average or something).
> The most important thing about optimising for speed is to measure.
> Measuring will tell you whether you even have a problem that needs
> optimising, measuring will tell you how big the problem is, and measuring
> (often in the form of profiling) will tell you where the problem is.
> It is often not where you think. I once sat through a wonderful
> demonstration that showed the difference between two pieces of PHP code
> that had the same functionality: one did everything in a couple of
> extremely complex multi-part statements, and the other made about 9 or 10
> nested function calls to do the same thing. The audience, myself included,
> assumed the latter would be slower, we guessed by as much as 10%.
> The lecturer demonstrated that after a million iterations the total time
> diference between the two methods was still less than 10 milliseconds. Yes
> the latter method was slower, but the difference was negligible. The
> advantage of the slower method was legibility, maintainability,
> debug-ability, etc.
> A few years ago, I managed to stop a multisite ecommerce website (not
> WordPress!) serving 10,000s of transactions a day, from grinding to a halt
> by *reducing* the amount of memory allocated to the engine! No amount of
> logic would have got me to that solution, but measurement did. (It turned
> out the Java VM had a poorly coded garbage collector, and the more free
> memory it had, the worse it performed!)
> Measuring, is the only way to be sure.
> Mike Little
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers