1. Свободная оперативка используется для кеширования на уровне файловой системы.
2. HDD добавит не кеш, а iops.
3. У меня стоят эти контроллеры с SSD на нескольких серверах, но увы, ответить на этот вопрос я не смогу, т.к. собирал их не я, да и видал только из консоли... =)
Так вполне конкретный ответ - при вашем варианте нагрузки вам не нужен в принципе raid контроллер, разве что, для использования его как экспендера sata. Соотвественно, в вашем случае, заметного выигрыша от большего кол-ва памяти не будет, а установка кеша на ssd будет просто выкинутыми на ветер деньгами.
Лучшим решением будет добавления винтов и/или оперативки для кеширования уровня файловой системы.
А вообще да, бывают нагрузки, где больший размер кеша влияет довольно сильно - частая случайная запись, где большой кеш с батарейкой позволяет заметно оптимизировать нагрузку на винты. Или частое случайное чтение одних и тех же данных когда они имеют довольно большой объём где ssd кеш весьма хорошо себя ведёт - БД, например. Но вам же не этот ответ нужен.
И совершенно зря - для вашей задачи оправдано взять больше винтов при том же бюджете, чем контроллер, который даст вам выигрыш по сравнению с софтовым рейдом только на большом количестве случайной записи.
Ну и выбор линукса как основы для такого хранилища опять же более оправдан - надёжнее и меньше накладных расходов.
@zds "Меня смущает, что это все вытесняет профессии дизайнера/программиста. "
Это иллюзия. Конструкторы и CMS есть давно, и у них есть своя ниша.
А програмирование, и тем более качественный уникальный дизайн будут нужны всегда.
Программирование там, где нужно что-то работающее быстро, масштабируемое, нестандартное.
Дизайн тем, у кого что-то большее бложика или домашней страички.
Я как раз дал вопрос на ваши ответы, где в моих словах что-то из вашего вопроса?
Если хотите больше конкретики - пожалуйста.
Вы спрашивали "куда рости" и "как больше зарабатывать". Если вы считаете, что как дизайнер вы уже хороши, то надо работать над своим именем. Это даст возможность стабильнее получать вкусные заказы, и поднимать при этом цену за заказ.
Инструменты - публикации, участие в публичных событиях, конкурсах, возможно создание какого-нить курса, видео уроков и.т.п. Всё, что позволит узнать о вас как о профессионале в своей области.
Второе - изучать юзабилити, чтобы делать дизайны не только красивые, но и удобные и отвечающие задаче. Инструменты: книги, статьи по данной тематике, и.т.п.
@fornit1917 Вам надо определить, что тормозит, для начала. И там будет видно, что делать. Хранение кеша в memcached нужно прежде всего тогда, когда у вас работает несколько бекэндов и нужен один общий кеш. В обычной ситуации файловый кеш, который по умолчанию используется, вполне справляется со своими задачами.
@Masterme Да, это можно сделать либо написав свой модуль, либо, что в данной ситуации правильнее, использовав готовый функционал Drupal. Естественно руками добавлять поле в таблицу, ни в коем случае не надо - делая так, вы делаете не поддрживаемый проект. А в drupal сделано много как раз для того, чтобы такими отвратительными вещами не заниматься.
Видимо, вы просто не пробовали и не понимаете.
@inkvizitor68sl Там, уж простите, и диски совсем не те же. Внимательно перечитайте ответ.
Тут не в интерфейсе дело, а в куда более древних и медленных дисках.
Ну и "медленее шаред хостинга" часто от неправильной настройки.
Каждому инструменту своё место. Такой подход уместен, в разработке приложения с нуля, и я им пользуюсь при разработке проектов на yii, например. И в этом случае миграции нужны, вполне согласен.
Но зачем вам менять структуру БД Drupal?
Если вы разрабатываете свой модуль, со своими таблицами, вы можете воспользоваться таким подходом, в принципе, написать скрипт из нескольких строк кода, для применения/отмены изменений в БД не сложно. Но это делается отдельным проектом, а потом модуль уже устанавливается, разворачивается готовая схема данных, и возможно, начальные данные.
И, кстати, у модулей Drupal есть install, update, uninstall коллбеки, которые автоматически срабатывают при установке, обновлении, удалении соответствующего модуля...
Т.е. на уровне необходимом для такой работы миграции всё же поддерживаются. А тащить лишние инструменты в ядро не стоит.
Кстати, посмотрите на schema. (https://drupal.org/project/schema)
На SATA3, те же диски, не будут работать заметно быстрее , за исключением некоторых шустрых SSD, которые в SATA2 действительно упираются.
Скорость доступа к памяти в общем-то тоже не так уж тут заметно будет влиять.
А вот "числодробилка" в современных процессорах, конечно, заметно круче. И если узкое место будет в вычислительных нагрузках, тогда да - заметно уделает.
@issssrt Посыл верный, и тут писалось всё это уже. Вот только modx, отнюдь не чудо и не супер, это странное поделие дизайнера является CMS второго эшелона, и то с натяжкой...
А фреймворк xPDO, который вы называете богатым API, не сильно функционален и крайне неудобен.
Если у вас в багаже только джумла, простите, но вы просто "не в теме", и не видели ничего приличного. Вам обязательно надо посмотреть другие варианты - есть куда более сложные и многофункциональные инструменты.
И сразу отпадёт желание, делать странное и писать велосипеды, которые ведь потом и поддерживать придётся, а это тоже будет нетривиально...
@Masterme А зачем CMS общего назначения миграции? Они нужны там, где вы меняете структуру БД, и вам нужна версионность этой структуры. А тут, структура базы данных создаётся не вами, и вы принимаете её как данность.
Зато в drupal есть более актуальные для разработки сайта на CMS инструменты - devel, помогающий отладке, features, помогающий вторично использовать готовые части функционала, и кстати, с поддержкой версионности и.т.п. Т.е. довольно развитый инструмент поддержки разработки.