Почему это бот обязательно заполнит? :) Чуть более продвинутый бот проверит все CSS-наследования и запросто поймёт, что туда писать не надо. С другой стороны — против лома нет приёма :)
И, кстати, было бы здорово потратить пару тысяч долларов из этого фонда для того, чтобы уже сделать нормальный WYSIWYG-wiki-редактор, а то только энтузиасты этим пока занимаются :)
Не вижу противоречия с тем, что написал я.
Безусловно, по сокету будет в целом будет работать быстрее (откуда, кстати, цифра 10%? И что будет происходить на 10% быстрее — передача данных, видимо, не запрос же в целом?), но чаще всего skip-network используется для безопасности, а не для ускорения.
Обе опции, конечно, не относятся к производительности, но skip-network действительно нужно обязательно использовать на «боевых» серверах. использовать skip-innodb — только если вообще нигде не используется InnoDB, лучше всего на слейвах в отношениях «InnoDB мастер — MyISAM слейв».
Программа замечательная, но по сути она делает тоже самое, что Вы бы сделали руками — вот только если пользоваться только ей, Вы не поймёте, для чего она и что рекомендует. Не спорю, как отправную точку её стоит использовать :)
Огого, куда забрались. Тогда уж смерти боятся из-за неизвестности, что будет после неё. Или боятся, что после неё ничего не будет. Но уж никак не из-за боли, умереть и во сне можно, и от ядерного взрыва, когда, теоретически, и почувствовать-то особо будет нечего.
Не передёргивайте. Я своё «я» ассоциирую и с сознательным, и с бессознательным, Вы же предполагаете, что когда работает только бессознательное, то в принципе человек уже умер. Тысячи людей, побывавших в коме, с Вами не согласятся.
Согласитесь, что во время сна отключается сознательная часть, бессознательная же продолжает бодрствовать, прослушивая окружающий мир и упорядочивая информацию. При гипотетической телепортации того вида, о которой говориться в статье, происходит полное разрушение личности, физической оболочки, сознания и подсознания — уничтожается сам объект.
А что будет, например, если что-то пойдёт не так и информация будет передана, клон создан, а на старом месте — не уничтожен? Или (о ужас!) уничтожен не полностью? :)
Конечно, однако это не ToDo-лист. Это обзор особенностей движка Falcon от стороннего человека, даже не от его разработчика. Никто и нигде не говорил, что какие-то из перечисленных минусов будут решены, более того — некоторые из них являются особенностями движка.
Если подобные вашему предложения рассматривать всерьёз, то остаётся вопрос — что же делать добросовестным пассажирам, которые шли до или после зайца, и которых обрызгало такой водой? :)
Поступил бы аналогично. Стремление соответствовать стандартам похвально, но с учётом того, что IE (всё-таки ещё самый популярный браузер) не поддерживается — реализацию можно рассматривать как эдакий просмотр далёкого будущего, когда у всех пользователей будут совместимые с данным способом браузеры.
В любом случае, за статью и за старания — большое спасибо, было интересно :)
Более того, ускорение достигается даже в случае выполнения запросов, затрагивающих все данные во всех партициях — ведь в этом случае сначала происходит первичная «обработка» таблиц по меньше, потом данные объединяются и производятся финальные вычисления.
По-моему далеко не всегда это будет быстрее. Насколько я понимаю, индексы строятся тоже для отдельной партиции таблицы. Получается, что при объединении результатов выборок из нескольких партиций дальше mySQL будет искать уже по временной таблице без индексов.
С другой стороны, это ускорит выборку, если никаких дальнейших действий с выбранными из партиций данных производить уже не надо.
А мне интересно — программа обращается к указанным адресам, загружая только саму HTML-страницу (или файл, ясное дело) или производит анализ и загружает ещё и всё, что есть на этой странице (картинки, скрипты, внешние CSS и т.п.)?
По-моему не слишком получается объективное тестирование, если программа долбится и скачивает только сами HTML-файлы, ведь любой высоконагруженный проект разделяет нагрузку между серверами (вроде Apache + nginx + кэш сверху), и хотелось бы оценивать всю систему в целом. Кто-нибудь знает что-нибудь подобное? :)
Безусловно, по сокету будет в целом будет работать быстрее (откуда, кстати, цифра 10%? И что будет происходить на 10% быстрее — передача данных, видимо, не запрос же в целом?), но чаще всего skip-network используется для безопасности, а не для ускорения.
Кстати, по-моему этот вопрос где-то в отечественной фантастике поднимался, нет?
А что будет, например, если что-то пойдёт не так и информация будет передана, клон создан, а на старом месте — не уничтожен? Или (о ужас!) уничтожен не полностью? :)
В любом случае, за статью и за старания — большое спасибо, было интересно :)
По-моему далеко не всегда это будет быстрее. Насколько я понимаю, индексы строятся тоже для отдельной партиции таблицы. Получается, что при объединении результатов выборок из нескольких партиций дальше mySQL будет искать уже по временной таблице без индексов.
С другой стороны, это ускорит выборку, если никаких дальнейших действий с выбранными из партиций данных производить уже не надо.
По-моему не слишком получается объективное тестирование, если программа долбится и скачивает только сами HTML-файлы, ведь любой высоконагруженный проект разделяет нагрузку между серверами (вроде Apache + nginx + кэш сверху), и хотелось бы оценивать всю систему в целом. Кто-нибудь знает что-нибудь подобное? :)