Если проект без нагрузки/сложных вычислений, то и на KVM SSD Ferrum работает прекрасно — проверено. Ну а те кто растет, запросом в ТП, свободно переводят на старшие тарифы без каких то телодвижений со стороны проекта.---------- Добавлено 10.01.2017 в 19:22 ----------
Точно не меньше, а то не по феншую:
Это сравнивать теплое с мягким. Если с MySQL выкинуть реляции и сделать табличку вида key\value, где key уникальный индекс и выбирать только по key, то думаю по скорости она будет не сильно отставать, а если при этом взять что то что тредится, ту же Maria/PostgreSQL, или что то типо Oracle например, то я думаю тут даже NoSQL отдохнут в уголке. Только там, где в реляционной базе можно вытащить все одним запросом, в NoSQL придется собирать по крупицам. Тут дело архитектуры хранения самих данных, и сравнивать их надо по удобству пользования, а не по скорости. NoSQL это не серебрянная пуля, вроде бум прошел и время все расставило на свои места, каждому так сказать свои задачи.
seovisor,Не буду врать, но по моему индексы ограничены длинной, то есть varchar(255), так как длинна на один столбец для индекса не должна превышать 767 байт, 3 байта на utf8 итого 255*3 = 765
а зачем вам такие индексы там, в такой табличке?---------- Добавлено 10.01.2017 в 18:37 ----------
Индексами ограничивают выборку в большой таблице когда она не влазит вся в оперативку, по другому вы никак не оптимизируете. Если вам не достает скорости MySQL, переложите горячие данные в оперативку, например в memcached или redis
И тут Яндекс придумал БЭМ
Если у вас валидная верстка (да и не валидная тоже), то пауки её вырежут 2-3 строками кода. Одним из факторов ранжирования является общий вес страницы, в который вкладывается множество параметров и уж что что, а код там явно наименьший параметр из них (как правило). Да и если включить голову, как размер кода может влиять на полезность документа запросу пользователя? Мне кажется в seo главное не перейти ту грань, когда логика перестает дружить с действиями.
silicoid, Вы не забывайте что это ноут и скорее всего там еще и видео отжирает гиг оперативки, а то и поболее. И вот так примерно работает БД на 8Мб памяти на 2кк строк :))))
seovisor, нельзя юзать индекс UNIQUE на полях типа Text
A10 так то нормальный проц, не ксеон конечно, но 15 мин для него на 2кк записей это что то запредельное.
Скорее всего косяки где то со стыковкой ПО и конфигами. Денвер вообще г.. (он еще живой? там mysql 5.1?!). Поставьте MySQL 5.5 (а лучше 5.7) чистый с сайта, дайте кешу ему от оперативки процентов 60-70% и с консольки попробуйте сделать вашу операцию. Да может все дело еще упереться в винт, расширьте буферы по максимому, чтобы сервер меньше сбрасывал на диск. (работал с ним)
Еще бы входные данные, ну там например размер всей БД, тип хранилища, если innodb то он файлом одним или все таки разбит, пишутся ли логи и так далее.
Zevss, Другой хостинг, другие настройки окружения. По умолчанию в php.ini timezone пустой
Подымите версию php ))) Поставьте дефолтный timezone Europe/Moscow
Обновите Joomla :)
Человек наверное и имел ввиду показ ошибок, но все таки на пролакшене я бы оставил только фатальные, все остальное ловил бы исключениями а не убивая процесс. И то сейчас и фатальные по моему неплохо ловятся.
Да и логи я не пишу, как то привык уже к баг трекерам, типо rollbar, который кстати не плохо интегрируется с monolog, но это все круто для своих продуктов, как обстоят дела с CMS я хз.
