Don't get me wrong, I'm chuffed to mint balls about the D7 effort and the result, for many reasons, not least of which is the amazing talent represented by it. That said, I received a letter today from the hoster stating that my account was a performance problem because it had over 1000 tables. Eight Drupal sites coud be over 1000 tables. I have a hosting account with 'unlimited domains' and up to 25 databases. I use the account both for hosting several live domains, most multi site, as well as a test area that clients can access for testing changes to existing domains. 8 Drupal sites could be over 1000 tables with the typical array of add-on modules, let alone that most of these sites are doing e-commerce. I've let them know that they might want to consider a more meaningful indicator of performance issues than a script that counts tables, since probably none of these sites does more than 100 transactions per day. If they hold firm, I'll blog (and post here) their name. Jeff -- Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com <http://ayendesigns.com> Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns Ayen Designs is a tradename of the computer services division of
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-) On Dec 6, 2010, at 12:08 PM, jeff@ayendesigns.com wrote:
Don't get me wrong, I'm chuffed to mint balls about the D7 effort and the result, for many reasons, not least of which is the amazing talent represented by it.
That said, I received a letter today from the hoster stating that my account was a performance problem because it had over 1000 tables. Eight Drupal sites coud be over 1000 tables.
I have a hosting account with 'unlimited domains' and up to 25 databases. I use the account both for hosting several live domains, most multi site, as well as a test area that clients can access for testing changes to existing domains. 8 Drupal sites could be over 1000 tables with the typical array of add-on modules, let alone that most of these sites are doing e-commerce.
I've let them know that they might want to consider a more meaningful indicator of performance issues than a script that counts tables, since probably none of these sites does more than 100 transactions per day. If they hold firm, I'll blog (and post here) their name.
Jeff -- <ayenlogo.jpeg>Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com Drupal: j. ayen green IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of <acmelogo.jpeg>
For those who don't have the few minutes: it's an expression of joy! On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
Jeff, Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up. I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support. The amount I pay for a dedicated server is paid back to me many times in therapy bills I save. In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy. The host coming after you, however, is to be expected. best, Shai On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
It's my oft-stated opinion that no non-trivial site will ever live happily for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you. -Randy On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Discussions about shared vs. dedicated hosting aside... Why does a default Drupal "install" create all the tables for all the core modules at once, as opposed to when the modules are enabled? Maybe this has changed and I should go look again, but it seems to me that I have a lot of Drupal sites with, for example: | poll | | poll_choices | | poll_votes | tables that I have never once used. Is there a reason these aren't enabled on demand as opposed to on install? -Sam On Mon, 6 Dec 2010, Randy Fay wrote:
It's my oft-stated opinion that no non-trivial site will ever live happily for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you.
-Randy
On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Sam Tresler 646-246-8403
Poll module does not create tables unless it is enabled, and if you uninstall it, it should delete them. If you don't use poll, and you uninstall it before upgrading it, I don't think you'll see anything after upgrade. If you once had it enabled, then the update would try to update it (I think). My D7 blog (updated from D6) has 125 tables, including poll, poll_choices, and poll_votes, which is a fairly normal number for a simple D7 site. -Randy On Mon, Dec 6, 2010 at 9:02 PM, Sam Tresler <sam@treslerdesigns.com> wrote:
Discussions about shared vs. dedicated hosting aside...
Why does a default Drupal "install" create all the tables for all the core modules at once, as opposed to when the modules are enabled? Maybe this has changed and I should go look again, but it seems to me that I have a lot of Drupal sites with, for example:
| poll | | poll_choices | | poll_votes |
tables that I have never once used.
Is there a reason these aren't enabled on demand as opposed to on install?
-Sam
On Mon, 6 Dec 2010, Randy Fay wrote:
It's my oft-stated opinion that no non-trivial site will ever live happily
for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you.
-Randy
On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed
to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Sam Tresler 646-246-8403
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
A base install of D7 only has 75 tables. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 12/6/2010 11:20 PM, Randy Fay wrote:
Poll module does not create tables unless it is enabled, and if you uninstall it, it should delete them. If you don't use poll, and you uninstall it before upgrading it, I don't think you'll see anything after upgrade.
If you once had it enabled, then the update would try to update it (I think).
My D7 blog (updated from D6) has 125 tables, including poll, poll_choices, and poll_votes, which is a fairly normal number for a simple D7 site.
-Randy
On Mon, Dec 6, 2010 at 9:02 PM, Sam Tresler <sam@treslerdesigns.com <mailto:sam@treslerdesigns.com>> wrote:
Discussions about shared vs. dedicated hosting aside...
Why does a default Drupal "install" create all the tables for all the core modules at once, as opposed to when the modules are enabled? Maybe this has changed and I should go look again, but it seems to me that I have a lot of Drupal sites with, for example:
| poll | | poll_choices | | poll_votes |
tables that I have never once used.
Is there a reason these aren't enabled on demand as opposed to on install?
-Sam
On Mon, 6 Dec 2010, Randy Fay wrote:
It's my oft-stated opinion that no non-trivial site will ever live happily for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you.
-Randy
On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com <mailto:shai@content2zero.com>> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Sam Tresler 646-246-8403
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
I stand corrected, that must have changed with D7. However, I think you and I have different interpretations of the word 'only' ;) Thanks. Regards, Sam Tresler On Mon, 6 Dec 2010, Jamie Holly wrote:
A base install of D7 only has 75 tables.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
On 12/6/2010 11:20 PM, Randy Fay wrote:
Poll module does not create tables unless it is enabled, and if you uninstall it, it should delete them. If you don't use poll, and you uninstall it before upgrading it, I don't think you'll see anything after upgrade.
If you once had it enabled, then the update would try to update it (I think).
My D7 blog (updated from D6) has 125 tables, including poll, poll_choices, and poll_votes, which is a fairly normal number for a simple D7 site.
-Randy
On Mon, Dec 6, 2010 at 9:02 PM, Sam Tresler <sam@treslerdesigns.com <mailto:sam@treslerdesigns.com>> wrote:
Discussions about shared vs. dedicated hosting aside...
Why does a default Drupal "install" create all the tables for all the core modules at once, as opposed to when the modules are enabled? Maybe this has changed and I should go look again, but it seems to me that I have a lot of Drupal sites with, for example:
| poll | | poll_choices | | poll_votes |
tables that I have never once used.
Is there a reason these aren't enabled on demand as opposed to on install?
-Sam
On Mon, 6 Dec 2010, Randy Fay wrote:
It's my oft-stated opinion that no non-trivial site will ever live happily for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you.
-Randy
On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com <mailto:shai@content2zero.com>> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Sam Tresler 646-246-8403
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Sam Tresler 646-246-8403
Sam, I have a tendency to agree with you on the number of tables. I've kind of gotten used to it, but I sued to look at the database and say, "OMG, 125 tables?" That's one of the drawbacks to normalizing. The idea is that it allegedly ends up decreasing the count, I find that, in practice, it usually does not. In the olden days, before databases (now called NoSql), one could create a file with many different record layouts in it and still understand what one was working with. Just think of it as DBA job security. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Sam Tresler <sam@treslerdesigns.com> To: development@drupal.org Sent: Tue, December 7, 2010 10:24:19 AM Subject: Re: [development] D7 side effect I stand corrected, that must have changed with D7. However, I think you and I have different interpretations of the word 'only' ;) Thanks. Regards, Sam Tresler On Mon, 6 Dec 2010, Jamie Holly wrote:
A base install of D7 only has 75 tables.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
On 12/6/2010 11:20 PM, Randy Fay wrote:
Poll module does not create tables unless it is enabled, and if you uninstall it, it should delete them. If you don't use poll, and you uninstall it before upgrading it, I don't think you'll see anything after upgrade.
If you once had it enabled, then the update would try to update it (I think).
My D7 blog (updated from D6) has 125 tables, including poll, poll_choices, and poll_votes, which is a fairly normal number for a simple D7 site.
-Randy
On Mon, Dec 6, 2010 at 9:02 PM, Sam Tresler <sam@treslerdesigns.com <mailto:sam@treslerdesigns.com>> wrote:
Discussions about shared vs. dedicated hosting aside...
Why does a default Drupal "install" create all the tables for all the core modules at once, as opposed to when the modules are enabled? Maybe this has changed and I should go look again, but it seems to me that I have a lot of Drupal sites with, for example:
| poll | | poll_choices | | poll_votes |
tables that I have never once used.
Is there a reason these aren't enabled on demand as opposed to on install?
-Sam
On Mon, 6 Dec 2010, Randy Fay wrote:
It's my oft-stated opinion that no non-trivial site will ever live happily for long on shared hosting. Trivial sites do fine. I have my D7 blog on Dreamhost, which has unlimited everything. But you see, it's not really unlimited, because they kill long-running processes, etc., etc. So it's fine for a site that does not have many visitors or lots of modules. Dreamhost and some other hosts are even fine where you have lots and lots of databases or files. But it's the actual use where they get you.
-Randy
On Mon, Dec 6, 2010 at 2:49 PM, Shai Gluskin <shai@content2zero.com <mailto:shai@content2zero.com>> wrote:
Jeff,
Kudos to you for finding a shared host where you can get decent performance, from your perspective, for such a set-up.
I just had one bad experience after another with Drupal on shared hosting. I finally caved and got a dedicated box with support.
The amount I pay for a dedicated server is paid back to me many times in therapy bills I save.
In my case, I was always yelling at the shared host for lousy performance before they would come to me complaining I'm using too many resources. But all the power to ya' if you and your clients have been happy.
The host coming after you, however, is to be expected.
best,
Shai
On Mon, Dec 6, 2010 at 3:24 PM, <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:
For those who don't have the few minutes: it's an expression of joy!
On 12/06/2010 03:17 PM, Steve Edwards wrote:
As I side note, I just spent a few minutes googling the phrase "chuffed to mint balls", since I had never heard that before. Thanks for adding that phrase to the collective Drupal vocabulary, Jeff. :-)
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Sam Tresler 646-246-8403
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
Sam Tresler 646-246-8403
nan wich wrote:
Sam, I have a tendency to agree with you on the number of tables. I've kind of gotten used to it, but I sued to look at the database and say, "OMG, 125 tables?" That's one of the drawbacks to normalizing. The idea is that it allegedly ends up decreasing the count, I find that, in practice, it usually does not. In the olden days, before databases (now called NoSql), one could create a file with many different record layouts in it and still understand what one was working with. Just think of it as DBA job security.
Normalized data, yes, that is the way to go, one place to update one piece of information instead of hunt and find to change multiple pieces of the same information. Create a view to join the pieces together for the human reader. At least it isn't SAP where the business object code is stored in the database requiring an SAP provided editor to write ABAP (an SAP created language based on SQL). As was stated already, the number of tables in the DB isn't the measure of a performance issue. Someone claiming that it is just means they do not have an understanding of how to measure performance. -- Earnie -- http://progw.com -- http://www.for-my-kids.com
I'm using the Ajax module to submit a form in a block, Drupal 6.19. It works fine, but there's no animation displayed to indicate that something has happened. The only feedback is the status message it gets back. I've seen a clockface animation in some of the other forms, any way to get it to work here? Any ideas before I strike out on my own? Thanks. -Don-
Having recently started using the Ajax module, the way that I understand one gets such 'busy...' or 'something is happening...' animations is to do it yourself via something like: 1) logic that starts the asynchronous action puts an animating gif over the element(s) that will change. (Animation is spinning image designating 'action'.) 2) logic that ends the asynchronous action removes from the user's visibility the animating gif at the same time as revealing the newly changed element(s) Note that the gif handling aspect of this logic is better performed at the javascript level, and with something like JQuery. However, now that I'm happy with handling this via JQuery, I'm looking at the Ajax module and thinking "and what exactly are you for?" The Ajax module does not appear to handle updating UI elements that have their state changed by the asynchronous form submission, and on top of that the Ajax module appears to have changed the use pattern of the form/form_validate/form_submit callbacks. Without the Ajax module, the use pattern of the callbacks is to call the form callback once, and then repeated calls to form_validate until all UI elements pass validation, and then a single call to your form_submit callback. Under the Ajax module, the form callback is called after form_validate fails. This is minor, and probably caused by the Ajax module explicitly not caching the results from your form callback, whereas without the Ajax module your form callback results are probably cached - but the behavior is different and one should be aware of that. Also, performing Ajax loads via JQuery is so easy that as soon as I finish writing this email, I'm going to disable the Ajax module and add the minor amount of code to handle my Ajax loads myself. (I also happen to be reading "JQuery: Novice to Ninja" at the moment, in the specific chapter that walks one through doing Ajax loads.)(I recommend the book.) Sincerely, -Blake bsenftner@earthlink.net www.BlakeSenftner.com www.MissingUbercartManual.com On Dec 8, 2010, at 8:56 AM, Don wrote:
I'm using the Ajax module to submit a form in a block, Drupal 6.19. It works fine, but there's no animation displayed to indicate that something has happened. The only feedback is the status message it gets back. I've seen a clockface animation in some of the other forms, any way to get it to work here? Any ideas before I strike out on my own?
Thanks. -Don-
On Dec 7, 2010, at 8:07 AM, nan wich wrote:
Sam, I have a tendency to agree with you on the number of tables. I've kind of gotten used to it, but I sued to look at the database and say, "OMG, 125 tables?" That's one of the drawbacks to normalizing. The idea is that it allegedly ends up decreasing the count, I find that, in practice, it usually does not. In the olden days, before databases (now called NoSql), one could create a file with many different record layouts in it and still understand what one was working with. Just think of it as DBA job security.
I'm pretty sure you have the concept of normalization and de-normalization backwards. There are only a few Drupal modules that I know of that focus on de-normalization, such as http://drupal.org/project/tracker2 and http://drupal.org/project/materialized_view. Otherwise, normalization almost always causes and increase in the number of tables. For more info on normalization and it's different forms: http://en.wikipedia.org/wiki/Database_normalization http://en.wikipedia.org/wiki/Third_normal_form http://en.wikipedia.org/wiki/Denormalization http://en.wikipedia.org/wiki/Materialized_view -Mike __________________ Michael Prasuhn 503.512.0822 office mike@mikeyp.net http://mikeyp.net
"Chuffed to mint balls"! LOL Such a Jeff phrase. :-) Karyn Sent from my Phone On Dec 6, 2010, at 1:08 PM, jeff@ayendesigns.com wrote:
Don't get me wrong, I'm chuffed to mint balls about the D7 effort and the result, for many reasons, not least of which is the amazing talent represented by it.
That said, I received a letter today from the hoster stating that my account was a performance problem because it had over 1000 tables. Eight Drupal sites coud be over 1000 tables.
I have a hosting account with 'unlimited domains' and up to 25 databases. I use the account both for hosting several live domains, most multi site, as well as a test area that clients can access for testing changes to existing domains. 8 Drupal sites could be over 1000 tables with the typical array of add-on modules, let alone that most of these sites are doing e-commerce.
I've let them know that they might want to consider a more meaningful indicator of performance issues than a script that counts tables, since probably none of these sites does more than 100 transactions per day. If they hold firm, I'll blog (and post here) their name.
Jeff -- <ayenlogo>Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com Drupal: j. ayen green IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of <acmelogo>
Jeff, This is likely because of all the tables that the Field SQL storage module creates (2 tables for every field). You may be interested in checking into the Per-Bundle Storage module (http://drupal.org/project/pbs). Dave Reid dave@davereid.net On Mon, Dec 6, 2010 at 2:08 PM, <jeff@ayendesigns.com> wrote:
Don't get me wrong, I'm chuffed to mint balls about the D7 effort and the result, for many reasons, not least of which is the amazing talent represented by it.
That said, I received a letter today from the hoster stating that my account was a performance problem because it had over 1000 tables. Eight Drupal sites coud be over 1000 tables.
I have a hosting account with 'unlimited domains' and up to 25 databases. I use the account both for hosting several live domains, most multi site, as well as a test area that clients can access for testing changes to existing domains. 8 Drupal sites could be over 1000 tables with the typical array of add-on modules, let alone that most of these sites are doing e-commerce.
I've let them know that they might want to consider a more meaningful indicator of performance issues than a script that counts tables, since probably none of these sites does more than 100 transactions per day. If they hold firm, I'll blog (and post here) their name.
Jeff --
Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
participants (13)
-
Blake Senftner -
Dave Reid -
Don -
Earnie Boyd -
Jamie Holly -
jeff＠ayendesigns.com -
Karyn Cassio -
Michael Prasuhn -
nan wich -
Randy Fay -
Sam Tresler -
Shai Gluskin -
Steve Edwards