Do not transfer sites to Drupal!
I will start my first post with a little note about Drupal, which I recently started using, and also in which I fell in love and at the same time became disillusioned. Fell in love because of the immense breadth of opportunities that this engine gives. A lot of modules, a pleasant architecture for a programmer (to modify a file or write your own module), incredible flexibility - all this will not leave indifferent, as, in other words, and how all this economy begins to slow down as it grows!
I had a website and I decided to refresh it with the help of a modern community-oriented engine, which is Drupal. The site was self-written, simple. He worked quickly, because used caching in statics and return of this statics on nginx. He had the dignity of human-readable URLs (CNC). When translating to Drupal, it was necessary to use the Path module, included in the standard distribution, to recreate the CNC on the site. This led to the fact that the formation of the page takes place: - for the main 400-600 requests to the database; - for nested 200-400 requests to the database. Drupal searches for each tag of the taxonomy its alias in the URL database.
With a small number of tags in the database, the situation can be corrected by editing the module code so that it receives the entire alias table in one request. But when the base grows and begins to include the entire vocabulary of the site's themes, there is nothing to be done ...
Additional problems appear in Drupal when fouling modules. On a shared hosting may not be enough limit in 16MB for PHP. If anyone knows virtual hosting with a limit of 32MB, let me know! On VPS, sprawling Drupal works slowly because of the MySQL database dangling on the same VPS. You can get out of the situation by posting Drupal and MySQL to different hosts (MySQL can be kept on a shared hosting - there is usually a separate server allocated for it). Someone will say that it is necessary to take a separate server, but for this project should at least pay off, and Drupal usually make amateur projects, sometimes not at all profitable, but existing for the soul.
')
Last resume
On Drupal, it’s best to do projects from scratch, while preserving its internal human-readable addressing. You need to think in advance about the structure of the site in order to understand which modules you will need to use. If you are planning a project with high attendance, then consider the option “write your own engine”, because You will spend no less time on optimizing Drupal afterwards.
I had a website and I decided to refresh it with the help of a modern community-oriented engine, which is Drupal. The site was self-written, simple. He worked quickly, because used caching in statics and return of this statics on nginx. He had the dignity of human-readable URLs (CNC). When translating to Drupal, it was necessary to use the Path module, included in the standard distribution, to recreate the CNC on the site. This led to the fact that the formation of the page takes place: - for the main 400-600 requests to the database; - for nested 200-400 requests to the database. Drupal searches for each tag of the taxonomy its alias in the URL database.
With a small number of tags in the database, the situation can be corrected by editing the module code so that it receives the entire alias table in one request. But when the base grows and begins to include the entire vocabulary of the site's themes, there is nothing to be done ...
Additional problems appear in Drupal when fouling modules. On a shared hosting may not be enough limit in 16MB for PHP. If anyone knows virtual hosting with a limit of 32MB, let me know! On VPS, sprawling Drupal works slowly because of the MySQL database dangling on the same VPS. You can get out of the situation by posting Drupal and MySQL to different hosts (MySQL can be kept on a shared hosting - there is usually a separate server allocated for it). Someone will say that it is necessary to take a separate server, but for this project should at least pay off, and Drupal usually make amateur projects, sometimes not at all profitable, but existing for the soul.
')
Last resume
On Drupal, it’s best to do projects from scratch, while preserving its internal human-readable addressing. You need to think in advance about the structure of the site in order to understand which modules you will need to use. If you are planning a project with high attendance, then consider the option “write your own engine”, because You will spend no less time on optimizing Drupal afterwards.
Source: https://habr.com/ru/post/15401/
All Articles