До этого момента думал, что счётчик бенчмарка ограничен сверху сотней - ан нет. На EC2 выдал 102 попугая! Особо ничего не настраивал, поставил только мускул и zend ce.
Предыстория: звонит клиент, и говорит: "Не могу значит оформить заказ в вашем интернет магазине, я его оформляю..., а он никак...". Спрашиваю - "Какой браузер?" - и с удивлением слышу ответ: "Интернет Эксплерер 9". Пауза... как же так... Лезу выяснять и действительно в компоненте "bitrix:sale.order.ajax", при изменении свойства типа "[LOCATION] Местоположение" происходит аяксный запрос, обновляющий страницу. Вот во время него в ie9 происходит ошибка в javascript'е "Исключение брошено и не поймано".
Блог ни о чем. А вот книгу прочел на одном дыхании, легко читается (250 страниц всего). Никакой воды, все четко. Мнение такое: если что-то не получатся со своими проектами, то следует обязательно прочесть ее, это опускает на землю и задает нужный вектор. Заказывал в озоне, 425 рублей (+ 200 р. доставка по Питеру). http://www.ozon.ru/context/detail/id/5111230/
Задача- в каталоге у элементов есть большие картинки, нужно выводить несколько их превьюшек разного размера(для каждого элемента по три штуки). Обойти весь каталог скриптом и на генерировать маленькие картинки не вариант(по политическим причинам).
Решение - resize на лету.
Проблемы - нагрузка на железо.
Как выкручивался:
В качестве точки старта выбрал готовую функцию CIBlock::ResizePicture(). Создал скрипт resize.php который будет возвращать браузеру уменьшенную картинку:
i - id картинки в b_file h - высота w - ширина
В этот скрипт помещаем нашу функцию, вокруг которой и будут происходить танцы с бубном. Перво-наперво, на всякий случай выключим всё не нужное - define("SM_SAFE_MODE", true) и очистим вывод $APPLICATION->RestartBuffer(). Для каждого типа изображения добавляем хедер - header("Content-type: image/jpeg") - для каждого свой! Теперь уменьшим нагрузку (только если есть frontend) -
header("Pragma: public");//может кэшироваться всеми (прокси-серверами тоже)
header("Cache-Control: max-age=100000000");//закэшируем на сто тысяч мильонов лет
Нюансы: злоумышленники перебирая параметры i и h и w могут заполнить кэш проксирующего сервера, да и вообще сделать не нужную нагрузку на сервер. Решение проблемы - кодировать передаваемые параметры (двустороннее кодирование!):
- ещё хорошо бы ограничить максимальные значения h и w.
пример можно взять здесь, а красиво посмотреть здесь
ИМХО, генерировать картинки на лету, можно исключительно ради баловства. На рабочем проекте этого быть не должно. При запросе мелкой картинки с сервера допустима только проверка на её существование. Если нет - создаём и кидаем например в папку temp_pic, которую вы по своим "политическим" причинам можете иногда целиком удалять.
P.S. В скрипте нет проверки на максимум, т.е. если я укажу resize.php?i=7840&h=12000000000000000000&w=400 серверу может поплохеть.
Ура! Мы это сделали! - наконец открыли сайт missrussia.ru, учитывая, что конкурс будет проходить 6го марта, то можно сказать впрыгнули в последний вагон!
Если будет интересно, то напишу мануальчик как сделать эффект плавного проявления изображений, после их загрузки, который будет нормально работать в опере.
Поздравляю! Молодцы, успели! Хорошо постарались. Мне сайт понравился.
Что касается XSS уязвимостей: Все современные фрэймворки (а по словам Сергея Рыжикова, Битрик тоже в первую очередь фрэймворк) имеют модуль XSS-фильтрации. Такой подход вселяет уверенность и облегчает работу разработчикам. Если я не ошибаюсь, функции XSS-фильтрации выполняет модуль проактивной защиты.
Что касается цветов сайта, то мне кажется, что решать в данном случае должны женщины, ведь это их цветовая гамма.
Есть несколько небольших замечаний по интерфейсу: 1)В разделе Пресс-центре при перемещении по подразделам галереи, а также при переходе на детальные страницы материалов галереи, сам пункт меню Галерея продолжает оставаться некликабельным. 2)Например возьмем раздел http://missrussia.ru/press/media/ Тут фильтр по категориям и дате отдает данные постом, в результате нет возможности передать кому-то ссылку на результат фильтра. Есть подозрение, что при возможной постраничной навигации (будет ли она), при переходе на очередную страницу будут теряться параметры фильтра.
Есть предложение улучшить схему проезда в контактах, т.е. сделать ее в виде масштабируемой и прокручиваемой карты гугл с наложением на нее собственной (в стиле дизайна сайта) карты. Предлагаю делать тили в png, чтобы сделать прозрачное наложение. Вот один из примеров использования: http://www.labnol.org/internet/design...ewer/2606/
Сначала оцените грядущие возможности - http://www.chromeexperiments.com/, оценили? Html5 всё больше вытесняет flash, единственное что пока защищает позиции flash'a так это ie, но всё изменится когда придёт он - ie9 (если и в нём не будет поддержки html5 draft, тогда я первый microsoft придам анафеме, выкину свой thinkpad и куплю macbook).
Забавно наблюдать со стороны, как ещё вчера, передовая и доминирующая, в своём секторе, технология может завтра устареть, а послезавтра просто исчезнуть.
Что может спасти adobe? поддержка web-камер и микрофона? аппаратное ускорение? - не думаю, всё это очень быстро может быть навёрстано производителями браузеров, путём добавления в javascript дополнительного api, аппаратное ускорение графики в браузерах обещает даже microsoft, что говорить о webkit'e и gecko. В довершении google анонсировал технологию websoket, которую тут же все поддержали, начиная от apache'a и заканчивая mozilla'ой, и включили её в черновую версию html5. Youtube и Vimeo уже запустили бета-тестирование своих сервисов с поддержкой потокового видео h.264 - flash потеряла главный козырь! Зачем нам ActionScript, если уже есть Javascript?
Какое будущие может быть у flash'а как у технологии? НИКАКОГО! всем надоели эти прослойки, дополнения, плагины, расширения, в Опу их всех! я за единый стандарт!
Как то раз наткнулся я на забугорную статью про светлое будущие canvas и WebGL, и была в этой статье картинка с "3d чайничком" нарисованном c помощью canvas'a, поразила она меня ну прям ващеее, понял я что должен сделать нечто подобное, и сделал.
Экспорт модели происходит прямо из 3ds max, через ASCII Scene Export.
Должно работать во всех последних браузерах. В демку добавил "спидометр" или "FPSмометр" или "FPSметр", ну вы поняли - в вверху справа, "текущий FPS" - опредаляяется по последним 10и рендерам, а "средний" по всем рендерам с самого начала работы скрипта, серез пару минут среднее значение перестает колебаться и показывает истинное значение скорости работы браузера. У меня расстановка сил следующая: Chrome 4: 25.2, Opera 10: 17.8, FF 3.6: 16.8, IE 8: 0.7, iPhone 0.7 (тестовая машина Core2Duo7300 4gb Win764), Очень интересно узнать ваши результаты
Какое будущие у этой технологии? Кто-то видит в этом основу для будущих онлайн игр, кто-то конкурента флешу, кто-то ненужный тег в html, а как вы считаете?
Кстати, небольшой оффтоп про выборки из таблиц и в частности про GetList: в Битриксе есть ряд замечательных методов, объединенных названием PrepareSQL (например CGroup::PrepareSQL). Любой из этих методов позволяет сделать полноценную функцию GetList (со всеми группировками, объединениями, сортировками и фильтрами) для своих таблиц за пять минут.
Создание GetList-а сводится лишь к заполнению специального массива заданной структуры. Причем такой подход оказывается удивительно гибким. В частности, удавалось создавать GetList-ы с возможностью генерации иерархических запросов, использования аналитических функций и т.д. И, опять же, все что для этого потребовалось, это правильно поиграться с тем самым массивом.
Плюс, в теории, написанные таким образом GetList-ы будут расширять свою функциональность вместе с соответствующими обновлениями Битрикса.
class CColumn//столбцы таблицы { function err_mess()
function Add( $table_name, $fields_new )//добавляет новое поля (можно передовать как массив так и одно значение)
function Update( $table_name, $fields_new )//обновляет $fields_new в таблице $table_name
function Delete( $table_name, $fields )//удаляет столбец $fields в таблице $table_name
function Check_Field( $key, $fields )//проверяет присутствует ли поле $key в полях $fields
function GetList( $table_name )//возвращает список полей таблицы $table_name }
class CRow//строки таблицы { function err_mess()
function Check_Value( $val )//проверяет значение на корректость
function Get_Field_Type_For_Bitrix_API( $type )
function GetList( $table_name, $order, $arFilter=Array(), &$is_filtered )//возвращает список (массив) всех строк отсортированных $arOrder и отфильтрованных $arFilter
function Add( $table_name, $arFields=Array() )//добавляет новую строку в таблицу $table_name с полями $arFields
function Delete( $table_name = false, $id = false )//удаляет строку в таблице $table_name с $id
function Update( $table_name = false, $id = false, $arFields = array() )//обновляет строку в таблице $table_name с полями $arFields }
class CTable//таблицы { function Table_exists( $table_name )//проверяет наличие таблицы $table_name
function Add( $table_name )//добавляет новую таблицу $table_name
function GetListArray( $arOrder )//возвращает список (массив) всех таблиц отсортированных $arOrder
function GetList( $arOrder )//возвращает список (CDBResult) всех таблиц отсортированных $arOrder
function Update( $old_table_name, $new_table_name )//переименовывает таблицу
CRow::Delete( $table_name = false, $arFilter=Array() )//удаляет строки в таблице $table_name в соответствии с фильтром $arFilter
- в состав модуля включать не хочу ибо в случае ошибки в $arFilter можно разом удалить много всего, а по $id медленнее - но места для ошибок меньше, к тому же метод CRow::GetList() имеет встроенное кэширование, которое позволит минимизировать потерю в производительности.
Ну немудрено в $arFilter в GetList допустить ошибку и так же удалить все записи.
Если в Deletе не будет возможности удалять по фильтру, то: Для удаления 1000 неактивных записей мы делаем один запрос, который вернет 1000 записей и + делаем 1000 запросов на удаление по одной записи ))) Аналогично с Update
В данной ситуации полностью согласен, но чаще всего количество запросов к базе в рамках одного компонента (например удаление комментария к блогу или удаление новости) лежит в пределах 10 штук, и разница между 0.001с и 0.01с не критична.
Признаю для нагруженных сайтов, это может стать узким горлышком, но и удалять записи могут не только в своих таблицах но и в битриксовых, так что лучше пусть удаляют по одной - на стадии отладки больше вероятность обнаружить свои баги, чем привести сайт в нерабочее состояние.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».