Похоже проблема со сжатием маленьких ответов от Битрикса.
Отключил модуль "Компрессия" и проблема ушла. Проблема возможно или в модуле Компрессия, или то, что он по-умолчанию работает и конфликтует со связкой nginx-apache
Создал 2 демо сайта, на одном провёл обновление, на другом - нет.
На обновлённом проблема появилась, на необновлённом - нет.
Технически проявляется в том, что после нажатия кнопки авторизации должен приходить ответ сервера в виде кода JScript. Когда проблема есть - он приходит пустым. Когда нет проблемы - есть JScript
Проблема проявилась на Win10 Pro 64, браузеры Chrome, Firefox, Edge, Opera, Internet Explorer В Яндекс.Браузере - проблемы нет.На Win10 (не Pro) 64 - работает.
На обоих Windows при этом - Касперский. У клиентов тоже проблемы с доступом (другие антивирусы). С Андроид+Chrome - всё нормально.
Отправлен тикет в поддержку, тикет принят в работу.
Oleg_, сейчас закажу у REG.ru хостинг и посмотрю что с показателями и конфигом.
Цитата
Алексей Власов пишет: Настроил nginx по примеру как это сделано в виртуальной машине битрикса - на результате теста никак не отразилось.
nginx, грубо скажем, экономит память для использования в различных кешах и буферах, что хорошо для нагруженных серверов
Итак: Reg.Ru. Тариф Host-1 с http://www.reg.ru/hosting/bitrix Сервер: Intel® Xeon® CPU E5606 @ 2.13GHz 24GB памяти RAID контроллер Adaptec с 4-мя HDD - режим RAID и размер памяти не смог узнать.
12GB - доступно для shared memory и tmpfs. tmp папка mysql смотрит в tmpfs
Согласно "top" сервер не нагружен, load average: 1.31, 1.56, 1.49 iowait - очень низкий, т.е. "прямо сейчас" свободны ресурсы и CPU и диска.
PHP работает в режиме FastCGI. Битрикс при установке красным отметил, что .htaccess файлы "не обрабатываются". Почему так и плохо ли это - не разбирался (с FastCGI не разбирался, думаю с ним связано).
Установил редакцию "Старт" - "ДемоСайт" - WEB 2.0. Кодировка cp1251, так как для UTF-8 нужны были бы настройки htaccess. (Кстати, влияет ли кодировка на скорость работы?) Получено 54.88 "попугая". Никак не 120
Oleg_, про отключение антивируса и проактивного фильтра, повторил тесты, действительно их влияние не особо велико. На "голом" эксперте (в Веб-аналитике выключено-отключено всё что можно), на пустой тестовой машине, у меня получилось 12.74 с включенными и 15.66 с выключенными. так что влияние действительно небольшое.
Кстати, на этой же самой машине "голый" "старт" показал 23.30 вот как влияет расширение списка модулей
Алексей Власов, пожалуйста, только не переусердствуйте с "объемами", у вас вроде 4GB ОЗУ было, и tmpfs в 2 + innodb_buffer_pool_size в 3 - это очень плохо при 4GB памяти....
Алексей Власов, неприятно, что pool не дал прироста. Тогда видимо можно спокойно уменьшить память для пула вдвое и для tmp_table до "разумных" цифр.
А вариант с tmpfs пробовали? Он как раз может обойти ограничение
Цитата
Алексей Власов пишет: Some conditions prevent the use of an in-memory temporary table, in which case the server uses an on-disk table instead: * Presence of a BLOB or TEXT column in the table
так что таблицы на диске будут создаваться в любом случае
Вообщем попробовать чтобы и память свободная (Innodb_buffer_pool_pages_free ) была, и чтобы tmp от MySQL смотрел на "диск" в памяти.
Ну и запросик (вместе с cre ate table всех используемых страниц если они нестандартные + примерное число записей в них) глянуть можно?
Алексей Власов, - теперь надо смотреть сам запрос, какие части таблицы с псевдонимом BE участвуют в "where" и дальше. У вас проблема в том, что а) Mysql затрачивает кучу дисковых операций на выборку 261006 строк данных б) эти данные скорее всего настолько велики по объему, что при выборке создается временная таблица на диске. Т.е. сначала mysql читает с диска данные, потом туда опять их пишет, потом только отдаёт вам.
Варианты дальнейших действий: 1. возможно переписать запрос, чтобы подвести как можно ближе под индексы, или индексы подвести под запрос - это может уменьшить цифру 261006 (самый "продвинутый" метод, если только возможен)
2. переписать запрос так, чтобы выбирались только нужные поля - тогда размер 1строки результата будет * 261006 - будет меньше, и может получиться обойтись без временных таблиц на диске.
3. примерно посчитать длину строки результата, умножить на 261006 - получиться примерно размер временной таблицы - разрешить создавать такие таблицы в памяти MySQL это параметры tmp_table_size = xxxM max_heap_table_size = xxxM НО возможно высчитанный xxxM будет неприлично велик для системы, всё зависит от размера памяти сервера update Судя по всему BE - это b_iblock_element. У меня длина строки таблицы - 3523 байта, при перемножении получается около 900МБ - примерно такой объем данных проворачивает ваш сервер при запросе. Потому вариант с tmp_table_size и max_heap_table_size получается неудачным. Если у вас на сервере оч.много памяти и таблица b_iblock_element в innodb, можно еще выставить большой innodb_buffer_pool_size может быть 2GB, может бльше, более точно подобрать можно по анализу отношения Innodb_buffer_pool_pages_free к Innodb_buffer_pool_pages_total - чем оно больше, тем дольше в кеше будет висеть b_iblock_element
4. использовать цифру из п.п.3, умножить в несколько раз и сделать такого размера диск в памяти, через tmpfs и указать её как папку для временных файлов MySQL
5. самый простой метод, если актуальность данных выборки не критично - делать выборку раз в XXX секунд по крону, сохранять её результат и показывать "из кеша", или же настроить кеш надолгое хранение выборки
Oleg_, у меня отключение проактивного фильтра и * улучшило результат в 2 раза, с 14 до 28, APC и eAccelerator вместе - не дружат, а влияние memcached у меня на показатель оказалось невелико. Но вероятнее всего в реальном приложении memcached поможет больше.
Алексей Власов, 92 - вполне нормальные показатели. Так как у вас на странице бОльшее время занимают запросы то надо определить, по какой причине, и тогда станет ясно, возможно ли оптимизировать работу настройкой сервера или же надо что то делать в коде сайта.
UP. Найдите самые тяжелые запросы, вносящие максимальный вклад в "Время исполнения запросов", посмотрите их EXPLAIN. В EXPLAIN внимание обратите на запросы, где много ROWS, и где используется сортировка с использованием временных файлов.
Oleg_, у вас пожалуй стоит определить, где узкое место - файловая система или сам диск. В linux есть команда hdparm -tT /dev/sdX думаю, во FreeBSD есть аналог. При этом в тесте "Timing buffered disk reads" не вмешивается кэш ОС, в отличии от dd. Современные сервера пустыми, на недорогих дисках, дают от 100 MB/sec "чтения с диска". Если же сервер покажет хорошую скорость диска, то видимо дело в настройке файл-системы. Из простого - проверить установленный noatime (Битрикс его любит).
RAID-0 - на сервере это жестко, не стоит ) А то что у виртуалки "быстрый" диск - это скорее всего хороший кеш-сервера.
Что касается "результата" теста производительности - то можно пожертвовать "Веб-Антивирус", "Проактивный фильтр" - это улучшит конечный показатель.
Также надо перепроверить все "прицепленные" акселераторы. Поддержка например правду говорит, что APC лучше чем eAccelerator.