у вас случаем не стоить eAccelerator или другой прекомпилятор? Попробуйте его отключить и посмотреть что будет.
24.11.2012 07:21:45
Возникла задача в интернет-магазине - необходимо фильтровать товары по размеру скидки. Например, выбрать все товары со скидкой 3% (до 3% или от 3% и более, не суть важно). Обычный API не позволяет фильтровать товары по размеру скидки, поэтому пришлось костыли воротить. В качестве первой версии решил использовать сохранение размера скидки для товара в свойстве товара. Завел 2 свойства: размер скидки в процентах для гостя и для авторизованного пользователя. Очевидно, что для каждого товара эти поля должны считаться в момент сохранения товара и сохранения скидки. И вот тут начались проблемы. Скидки в базе есть, товары есть. Просто на странице если сделать вывод скидки для товара - всё ок, получаем скидку, а если запихнуть в /bitrix/php_interface/init.php по событию OnAfterIBlockElementUpdate, то уже не работает. Пробовал все возможные варианты получения скидок для товара, результат один и тот же. Вот пример просто для страницы:
Может быть я что-то перестал понимать и так и должно работать? Может быть есть другие варианты фильтрации товара по размеру скидки? |
|||
|
22.11.2012 04:50:53
Такие каракули похожи на бинарный код. Скорее всего у вас проблемы со сжатием. Возможно страницы сжимаются дважды: первый раз модулем компрессии в битриксе, второй раз средствами PHP. Либо сжатия нет, но отправляются заголовки о нем. Но если были бы такие проблемы со сжатием, то сайт всегда бы показывался криво, а не при повторных запросах к серверу.
|
|
|
20.11.2012 23:09:01
|
|
|
20.11.2012 23:05:10
Такие службы доставки уже есть, работают через постоматы, например. Сейчас в маркетплейсе есть подобные решения:
Несколько ценовых вариантов может быть и это как раз основная функция автоматизированных доставок, называется профили. Также можете посмотреть доставку СПСР и ЕМС, в них как раз есть разные профили доставки для разных городов, на выбор там предлагает быструю и дорогую. долгую и дешевую. |
|
|
20.11.2012 17:53:50
Нет ли возможности разнести компоненты, чтобы не был один в другом? Вообще, это не очень корректно делать вызов одного компонента в шаблоне другого, для этого обычно используется комплексный компонент, где в шаблонах комплексного компонента вызываются обычные компоненты. Как вариант решения может быть использование AJAX для подгрузки некешируемых данных в закешированном компоненте. Если данные во вложенном компоненте обновляются не постоянно, а по событиям, например, по событию изменения информации в инфоблоках, то можно использовать управляемый кеш для сброса кеша родительского компонента. В общем, чтобы более корректно ответить на ваш вопрос, вам лучше описать конкретную задачу и указать используемые модули.
|
|
|
15.11.2012 16:06:15
Я пообщался с топикстартером по поводу его сайта более детально, спасибо ему за предоставленную возможность изучить проблему, надеюсь, он не против, если я тут распишу найденные проблемы. Хостинг на мастерхосте, медленные дисковые операции (1000 операций/сек.), это видно даже на приложенном скрине из админки, но это не главная проблема, с этим еще можно жить.
Половину времени генерации страниц "жрет" компонент altasib:callback. Какие-то проблемы в таблице b_user_access с дублированием записей. Например, запрос "sel ect * fr om b_user_access where user_id=1" возвращает 210 тысяч одинаковых строк. А всего в этой таблице 367 тысяч строк. Явно они не сами появились, какой-то модуль или сторонний компонент их генерирует. Первый раз в жизни такое видел, но на сайте установлено 136 сторонних модулей и почти все они включены. Тут явно надо разбираться, что действительно необходимо, а что лишь занимает ресурсы. И скорее всего где-то среди этих сторонних решений есть проблемы в плане оптимизации, которые и создают нереальное количество записей в БД. Есть ошибки разработки, так для каждого товара в списках подключается компонент bitrix:iblock.vote, который создает по 3 запроса. В итоге страница из 20 товаров - это 60 запросов к БД только из этого компонента. В меню выбираются разделы инфоблока и не кешируются, в итоге при каждом запросе любой страницы создается 18 запросов к БД, хотя контент в меню может не меняться месяцами. Все эти проблемы определены только на основе анализа первой страницы, если полезть глубже, наверняка еще что-то всплывет. Есть еще несколько мелких проблем, но на фоне описанных выше они просто несущественны. В итоге страницы сайта открываются по 2-4 секунды, а под админом 5-8 секунд. Тут проблемы решаются только оптимизацией кода, поиском "виновника" неверного заполнения таблиц БД дублями. |
|
|
12.11.2012 19:08:20
Лучше всего искать хостинги, специализированные на битрикс. У многих хостеров есть такие тарифные планы, у того же таймвеба, мастерхоста, еще у крупных каких-то есть. VPS тоже бы не советовал - требуется квалифицированный админ, а преимущества в производительности зачастую незаметны или вообще отсутствуют при цене в 5 раз выше. Имел опыт переноса сайта на FastVPS, при цене в 100 евро/мес. сервер ну никак не оправдал надежд на быструю и стабильную работу, пришлось отказаться и взять премиум на таймвебе по той же цене.
|
|
|
09.11.2012 17:02:39
Посмотрите в оценке производительности, какие элементы у вас медленные. Например, может быть быстрая база данных (больше 10К запросов на чтение в секунду), но может быть медленный процессор (меньше 7М операций в секунду). Система должна быть сбалансирована, а иначе получается эффект бутылочного горлышка.
Если у вас медленная база данных, то обычно хватает подкрутить настройки MySQL для кеширования и она начинает работать быстрее. Полный перечень параметров для оптимизации есть даже в битриксе, некоторые рекомендации по параметрам есть в последних версиях phpMyAdmin, ну и по разным форумам есть много инфы. По работе PHP можно ускорить прекомпилятором. Обычно ставят eAccelerator, XCache, APC. С eAccelerator у меня часто встречались проблемы, он нестабилен, так что предпочитаю ставить XCache. По сути между ними разницы мало. Но также требует настройки под конкретный проект. PHP быстрее работает как модуль Apache, но не всегда есть возможность его так поставить. Для кеширования лучше использовать memcached. В общем, это вот самый базис, но если это всё делать, то памяти 2 Гб вам маловато будет, надо как минимум 4-6 Гб. А вообще, рассуждать без конкретной постановки задачи (целевая нагрузка) и без конкретных результатов тестирования достаточно сложно. |
|
|
09.11.2012 01:24:04
|
|||||
|
09.11.2012 01:23:12
|
|||||
|
07.11.2012 22:49:18
Лучше всё-таки увеличить ресурсы. Гиг памяти сегодня в холодильниках стоит. Для сайта с такой посещаемостью у вас всё либо в притык, либо не хватает, наверняка сервер часто начинает своп использовать. Тем более VPS сейчас недорогой, наверняка можете позволить себе расходы на 300-500 рублей дополнительно.
|
|
|