- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Jet D., стоп. какая еще медлительность? Обратите внимание что поддержки innodb нет там где хостинг наиболее массовый - агава, мастерхост. Если вы начитались разных тестов TPC, так они не имеют отношения к веб-строительству и движкам.
mendel, есть хорошая таблица, дающая представление о количестве хостингов без поддержки InnoDB - http://www.umi-cms.ru/support/umi_cms_php5_hosting/
ИМХО, смысл есть - пусть лучше движок не будет работать без InnoDB (с выводом соответствующей ошибки при установке), чем по форумам люди будут писать о его медлительности, думая что проблема в самом движке. Но многое зависит от того, на какую аудиторию нацелен этот фреймворк.
Спасибо. Полезная ссылка.
Правда отсутствие InnoDB скорее не на скорость повлияет а на надежность :)
mendel добавил 03.02.2010 в 19:24
Jet D., стоп. какая еще медлительность? Обратите внимание что поддержки innodb нет там где хостинг наиболее массовый - агава, мастерхост. Если вы начитались разных тестов TPC, так они не имеют отношения к веб-строительству и движкам.
Агава это мазохизм.
мастерхост не знаю дела не имел...
FYI, Drupal 7 при установке для всех таблиц выбирает InnoDB, c откатом до MyISAM в случае недоступности.
А погуглить? Не?
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
И у меня 2 вопроса:
1. На кой в ЦМС быстрые modification операции?
2. На кой в массовой ЦМС заморачиваться с целостностью данных?
А погуглить? Не?
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
Спасибо, полезно. В реальной жизни правда будет не так, но общая картина ясна.
1. На кой в ЦМС быстрые modification операции?
Ну вдруг кто-то на ней второй вконтакте сделает? :)
А если серьезно то нафиг не нужно.
2. На кой в массовой ЦМС заморачиваться с целостностью данных?
Хочется при минимальном размере ядра дать максимальную защиту от дурака и простоту проектирования.
Santyago, какой-то спорный тест - там памяти 16гб и всего 350 мб данных. Больше похоже на сравнение методов параллельного программирования в разных движках mysql, а не на тест вебсервера. Одни и те же данные в innodb могут занимать в несколько раз больше, а значит в реальной жизни где используются диски, эффективность кеша в памяти может существенно отличаться.
Ну вдруг кто-то на ней второй вконтакте сделает? :)
:) Хе-хе...
ВКонтакте на ЦМС не делают...
А если серьезно то нафиг не нужно.
Отож.
Хочется при минимальном размере ядра дать максимальную защиту от дурака и простоту проектирования.
Лучшая защита от дурака - это сделать ядро, зазендить его и отдать разрабам внешний АПИ. Да и то... Скажи дураку богу молиться - он и лоб разобьёт. ))
На самом деле, если реально нет необходимости в транзакциях (а в ЦМС этой необходимости ТОЧНО нет), то все вопросы целостности данных решаются через data-layer ядра ЦМС. Понятное дело, что найдутся умники, которые захотят работать с БД напрямую, но это уже будут их личные проблемы.
Santyago добавил 04.02.2010 в 01:55
Santyago, какой-то спорный тест - там памяти 16гб и всего 350 мб данных. Больше похоже на сравнение методов параллельного программирования в разных движках mysql, а не на тест вебсервера. Одни и те же данные в innodb могут занимать в несколько раз больше, а значит в реальной жизни где используются диски, эффективность кеша в памяти может существенно отличаться.
Да, согласен. Тест спорный. table-cache=512 и после прогревки сервака почти весь объём ложится в кеш. Неплохо было бы запустить пяток запросов c SQL_NO_CACHE и оценить разницу.
Но в любом случае, посыл у поста правильный: производительность на чтение у них почти одинакова. Дальше уже идёт шаманство с настройками под конкретную задачу для обеспечения максимальной производительности с выбранным движком БД.
Но в любом случае, посыл у поста правильный: производительность на чтение у них почти одинакова
если в innodb объем данных тупо больше, как она может быть одинакова?
если в innodb объем данных тупо больше, как она может быть одинакова?
Не совсем понял, что значит "в innodb объем данных тупо больше"?
http://dev.mysql.com/doc/refman/5.0/en/converting-tables-to-innodb.html