TimTowdy

Если посылка не дошла за 44 дня — открывайте диспут, Он может затянуться на пару недель. Если за это время посылка не дойдет — вернут деньги. Если дойдет уже после успешного диспута — можете договориться с продавцом как вернуть ему деньги (если есть такое желание).
А вообще посылки из Китая действительно могут долго идти. Открывать диспут вы опоздали, так что деньги вам уже вряд ли вернут. Надейтесь на то, что она действительно в пути.

Реальные примеры медленных запросов, их explain, какой тип таблицы (innodb/myisam), какие индексы, как меняется производительность под нагрузкой, пробовали ли профилирование запросов?
Удивляют здешние телепаты, которые дают советы, не зная условий.

Какие ещё слеши в обратом порядке? \xHH — это hex-представление байта. Вебсерверу передаются бинарные данные, поэтому в логах нет метода и выводится их hex-представление.
Только что попробовал телнетом передать себе какую-нибудь белиберду, вот что появилось в логах:
127.0.0.1 — - [22/Apr/2012:07:14:33 +0000] "\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd" 501 299 "-" "-"

Хоть внешне это и похоже на атаку типа buffer overflow, я сомневаюсь что это эксплоит. Возможно эти запросы вообще не предназначены для вебсервера, но по какой-то причине они приходят именно вам на 80 порт.
Правда смущает что статусы ответа разные. Кстати размер главной страницы случайно не 4892 байта?

Покажите EXPLAIN запроса по таблице без VARCHAR(8000). Или попробуйте FORCE INDEX на этой таблице. Есть подозрение что индекс не используется, т.к. фулскан быстрее. Замена TEXT на VARCHAR(8000) замедляет фулскан и включается индекс, что и приводит к замедлению.

Считает не быстро, ибо считать это всё будет однопоточный джаваскрипт. К тому же агрегация в монго обычно не рассчитана на realtime. Если нужна агрегация и кластеризация, смотрите в сторону column-oriented dbms или hadoop. Либо оставайтесь на SQL и не мучайтесь.

А зачем вы постоянно делаете

var html = this.outerHTML;
$(this).remove();
$('#select2').append(html);

Разве такой код

$('#select2').append($(this));

не аналогичен ему?

Когда я смотрел на эти контролы в ASP.NET я тоже был ошеломлён, правда по другой причине. Внутри этих контролов творился лютый ппц: куча грязных хаков, избыточности, отсутствие логики, проблемы с кроссбраузерностью. Признаюсь, это было много лет назад, сейчас наверняка всё гораздо лучше. И всё же перспектива зависеть от майкрософта, и ждать пока он соизволит исправить какие-то баги/ввести какие-то фичи — не радует. Используя opensource-фреймворки как-то поспокойнее себя чувствуешь.

www.reportlab.com/software/opensource/rl-toolkit/

Почитайте этот блог, там есть и про учёбу.

На мой взгляд, бы правильно, если бы на возможность публиковать статью влияла не карма, а рейтинг. Поскольку рейтинг со временем стремится к карме, это не приведёт к публикациям тонн шлака, но временно даст возможность адекватным, но заминусованным людям писать статьи. Т.о. если заминусованный хабраюзер на комментариях/ответах набирает рейтинг — он автоматически получает временную возможность опубликовать статью (до тех пор пока рейтинг автоматически не уменьшится). Напишет что-то полезное — получит и карму, и ещё рейтинг, и либо выйдет из минуса, либо продлит срок, в течение которого он сможет публиковаться. Напишет шлак — сольёт рейтинг обратно и карму еще ниже — заново получить возможность опубликовать статью ему будет сложнее. Таким образом и статей будет больше, и саморегуляция будет проявляться гораздо сильнее (сейчас-то она вообще практически не работает). Я например без труда могу выйти из минуса по рейтингу, но клянчить карму или делать ресет — не хочу. Думаю таких людей немало, и многие из них могли бы писать на хабр.
Недостатки конечно тоже есть — петросяны, резко получившие рейтинг на смешном комметарии получат возможность публиковаться — но саморегуляция свёдет этот вред к минимуму. Текущая система ведь тоже не лишена недостатков — всякие бумбурумы могут публиковать рекламу и прочий шлак, не боясь что их заминусуют (просто нет достаточного количества минусаторов). Чем они периодически и пользуются.
P.S. А ведь самый торт хабр был тогда, когда регистрация была открыта…

Не извращайтесь. Вы пытаетесь эмулировать мастер-мастер репликацию средствами PHP.

Попробуйте посмотреть в сторону Dokan или WinFUSE.

Проблема EAV в том, что каждое поле лежит независимо от объекта. Т.е. выборка 10-ти объектов, из 10-ти полей, сделает около 100 random seek. Варианты решения:
1. Memory таблицы — быстрый random seek, ограниченный размер и необходимость синхронизации с реальными данными.
2. Sphinx и ему подобные. Дополнительно храним данные в формате, более удобном для фасеточного поиска.
3. nosql — легче масштабировать, данные зачастую хранятся в памяти, отсутствие схемы, но при этом с возможностью создания индексов по полям.

Кроме вышеупомянутого кауча, вряд ли можно посоветовать что-то еще, готовое для продашкена, и работающее на VDS.
Вообще польза от NoSQL на VDS весьма сомнительна. NoSQL востребован там, где необходима неограниченная горизонтальная масштабируемость. Если такой потребности нет — MySQL/Postgres прекрасно подойдут практически для любой задачи. Не стоит гнаться за модными buzzwords, каждой задаче — свой инструмент.

Сделали бы отдельной настройкой в профиле. Или мне теперь в каждый браузер ставить отдельные стили для хабра? Нет пути.

Потому что IEEE 754
Очевидно, что при хранении чисел в двоичной системе, абсолютно точно можно хранить только те дробные числа, которые состоят из степеней двойки. Остальные числа хранятся с точностью до машинной эпсилон.

Речь, как я понимаю, идёт о EAV.
Теоретически, в случае использования MEMORY-таблиц, прирост должен быть, т.к. в EAV чтение каждого поля вызывает позиционирование головки винчестера, поэтому чтение из памяти должно быть быстрее.
В целом, РСУБД плохо подходят для реализации фасеточного поиска. Обычно тормоза такого поиска исправляют поисковыми движками, типа сфинкса, но лучше посмотреть в сторону nosql — mongodb, couchdb, etc.

При перемещении товаров перевозчиком в адрес физического лица в течение календарного месяца в адрес одного получателя можно беспошлинно ввезти товаров, таможенная стоимость которых не превышает сумму, эквивалентную 1000 евро, и весом не более 31 кг.

Что значит отжирает память? Это вы в Task Manager увидели? Вы уверены что он именно ест, а не резервирует память?
Можете поставить расширение, потрясающим образом уменьшающее расходование памяти в Firefox. Памяти в Task Manager будет показываться меньше, вот только реальное потребление вряд ли изменится.