Написание доклада подошло к своей финальной стадии. Но чтобы его завершить, мне нужно собрать немножко данных о производительности. А поэтому просьба зайти по следующий двум ссылкам и нажать Run tests. Если вы это сделаете из нескольких различных браузеров, я буду вообще счастлив.

Вот тесты: скорость определения классов и скорость создания объектов.

Заранее спасибо.

В апреле состоится Frontend DEV Conf ’13, на которую меня пригласили прочитать доклад. Я уже активно работаю над ним, чтобы многие смогли вынести для себя чего-нибудь полезное. Самое сложное — это уложить такую большую и сложную тему, как ООП в JavaScript, в связное повествование. В скором времени, когда я закончу активное написание, попрошу кого-нибудь проверить весь текст на адекватность.

Буду рад любым комментариям. И еще больше буду рад всем, кто соберется меня послушать.

Василий

Знакомьтесь, это дегу Василий. Он пока еще весьма юн. Но в скором времени он подрастет, станет крутым Haskell-программистом и станет соведущим этого блога.

Когда в из JavaScript отправляешься AJAX запрос¹, ставишь ему заголовок Content-Type: application/json, но при этом оставляешь само тело запроса пустым, то браузер самостоятельно заменяет Content-Type на тот, который кажется ему более подходящим. Причем для Google Chrome это application/xml, а для Firefox — plain/text. А сервер смотрит на это безобразие и отвечает — 415 Unsupported Media Type, у него-то стоит проверка на заголовок Content-Type.

Как вариант решения отправлять пустой объект {}. Ну или поправить сервер, если есть такая возможность.

Совершенно неожиданная проблема вылезла со стороны InnoDB. При записи реальных данных в таблицу сервер начал выдавать ошибку 1118 — «Row size too large».

Если кто не знает, MySQL хранит все данные вместе в одной строке-блоке, кроме данных типов TEXT и BLOB. Вместо них хранится ссылка на местоположение реальных данных. Вот и считаем сумму всех данных в строке — она не должна превышать некоторого значения. Если посмотреть в документации, можно увидеть, что максимальная длина строки для MyISAM — 64 килобайта, а для InnoDB — около 8000 байт.

Я как-то уже встречался с подобной проблемой, поэтому представлял, что делать: открываем таблицу, смотрим типы колонок, разбираемся, что можно заменить на TEXT или BLOB. Каково же было мое удивление, когда в нужной таблице оказалось 2 числовых поля и 40 полей с типом TEXT. Ну никак этот набор данных не может превышать 8Кб! Интерес добавляло еще то обстоятельство, что на тестовых небольших данных всё работало, данные записывались и гармония царила.

Оказывается, у InnoDB два формата хранения данных — Antelope и Barracuda. И у Antelope есть интересная особенность: текстовые поля хранятся не совсем так, как мы привыкли думать. У них первые 768 байт попадают в саму строку и только затем, если данных оказалось больше, ставится ссылка на остаток. Понятное дело, что 768*40 значительно превышает отведенные 8 килобайт. Так же понятно, почему всё хорошо работало на небольших объемах данных: все помещалось в строку и без всяких ссылок.

Мы решили эту проблему, выбросив все текстовые поля и заменив их одним, в котором все данных хранились в сериализованном виде. В интернете в качестве решения предлагался еще варианты разбить таблицу на несколько или сменить тип хранилица InnoDB.

Вот так живешь себе и не знаешь с какой стороны упадет сюрприз.