5 ms·

Could you clarify on which design decisions prevents you from scaling to these numbers?

by hippich 14y ago

byoung2 14y ago
I'd like to know as well...the bottleneck with those numbers is likely to be the database, not Drupal, so if you switch to Rails and keep the same database, not much will change.
- TylerE 14y ago
  The DB setup in Drupal is very join heavy - on the new site many things that are joins in Drupal will be single table - many things drupal offers one-to-many on we only need one-to-one, so can avoid the join. Plus, with the modules we're using we're more or less forced to use MySQL. Rails site will be using Postgres.
  - hippich 14y ago
    So basically, because default Drupal's database schema is too normalized and generic you experience problems. As for Postgresql - you are going to write new code anyway - either in Rails or patch Drupal modules to work correctly with Postgresql. So this one is definitely not a deal breaker. I would advise also to look into option of upgrading to Drupal 7 and using its DB stuff. While it is still join-heavy by default, you have more power to manipulate schema and for example to have flat tables for your content types or store some stuff in MongoDB. And all of it with still Drupal's flexibility and mostly configuring stuff instead of writing it.
    - TylerE 14y ago
      We've made the corporate decision - after many bad experiences - to purge PHP from production, for the sake of our sanity. We are not doing this lightly. The current codebase has ~2.5 man years invested in it.
      - sedev 14y ago
        I strongly endorse this idea. The faster and more completely the development community moves away from using PHP in production, the better. I've started telling people not that PHP is bad, but that PHP is the avatar of technical debt. No matter what you personally do with PHP, the creators of the language and the other participants in the PHP ecosystem make it impossible to create a significant project in PHP without taking on ruinous amounts of technical debt - some of which takes the form of critical security problems! Python and Ruby, despite their faults, are more secure by default and have better security teams. So in summary, I bet that purging PHP was tough, and I think you made the right choice.
        hippich 14y ago
        From my experience technology is a big factor, but not ultimate. Ultimate factor is community around particular project. I truly believe Drupal community at this point is just right mix of following standrds and being focused on innovating in the same time. Whenever you custom code - you loose this huge leverage otherwise you could have by re-using existing UI/code/architecture (where architecture might be first and most important in the list.) Anyway, I truly wish you luck with you project, but I would advise not to drop any particular technology just for sake of dropping it. (I am not PHP fan, I am Drupal and Drupal community fan)

Could you clarify on which design decisions prevents you from scaling to these numbers?

by hippich 14y ago

Could you clarify on which design decisions prevents you from scaling to these numbers?

I'd like to know as well...the bottleneck with those numbers is likely to be the database, not Drupal, so if you switch to Rails and keep the same database, not much will change.

TylerE 14y ago
The DB setup in Drupal is very join heavy - on the new site many things that are joins in Drupal will be single table - many things drupal offers one-to-many on we only need one-to-one, so can avoid the join. Plus, with the modules we're using we're more or less forced to use MySQL. Rails site will be using Postgres.
- hippich 14y ago
  So basically, because default Drupal's database schema is too normalized and generic you experience problems. As for Postgresql - you are going to write new code anyway - either in Rails or patch Drupal modules to work correctly with Postgresql. So this one is definitely not a deal breaker. I would advise also to look into option of upgrading to Drupal 7 and using its DB stuff. While it is still join-heavy by default, you have more power to manipulate schema and for example to have flat tables for your content types or store some stuff in MongoDB. And all of it with still Drupal's flexibility and mostly configuring stuff instead of writing it.
  - TylerE 14y ago
    We've made the corporate decision - after many bad experiences - to purge PHP from production, for the sake of our sanity. We are not doing this lightly. The current codebase has ~2.5 man years invested in it.
    - sedev 14y ago
      I strongly endorse this idea. The faster and more completely the development community moves away from using PHP in production, the better. I've started telling people not that PHP is bad, but that PHP is the avatar of technical debt. No matter what you personally do with PHP, the creators of the language and the other participants in the PHP ecosystem make it impossible to create a significant project in PHP without taking on ruinous amounts of technical debt - some of which takes the form of critical security problems! Python and Ruby, despite their faults, are more secure by default and have better security teams. So in summary, I bet that purging PHP was tough, and I think you made the right choice.
      - hippich 14y ago
        From my experience technology is a big factor, but not ultimate. Ultimate factor is community around particular project. I truly believe Drupal community at this point is just right mix of following standrds and being focused on innovating in the same time. Whenever you custom code - you loose this huge leverage otherwise you could have by re-using existing UI/code/architecture (where architecture might be first and most important in the list.) Anyway, I truly wish you luck with you project, but I would advise not to drop any particular technology just for sake of dropping it. (I am not PHP fan, I am Drupal and Drupal community fan)