CC BY
26УМЕНЬШЕНИЕ НАГРУЗКИ НА СЕРВЕР СРЕДСТВАМИ CMS DRUPAL
Сацык В.О.
кандидат сельскохозяйственных наук факультет компьютерных наук и информационных технологий Луцкий национальный технический университет, г. Луцк, Украина
Смолянкин О.А. ассистент
факультет компьютерных наук и информационных технологий Луцкий национальный технический университет, г. Луцк, Украина
Грудецький Р.Я. старший преподаватель факультет компьютерных наук и информационных технологий Луцкий национальный технический университет, г. Луцк, Украина
DECREASE OF LOAD ON SERVER BY MEANS OF CMS DRUPAL
Satsyk V.O.
Candidate of Agricultural Sciences Faculty of Computer Science and Information Technology Lutsk National Technical University, Lutsk, Ukraine
Smolyankin O.A.
assistant
Faculty of Computer Science and Information Technology Lutsk National Technical University, Lutsk, Ukraine
Grudetsky R. Y. Senior Lecturer
Faculty of Computer Science and Information Technology Lutsk National Technical University, Lutsk, Ukraine
АННОТАЦИЯ
В этой статье проведено описание и анализ: простых методов уменьшение (нейтрализации) серверной нагрузки, методов оптимизации Drupal на основе встроенных и дополнительно установленных модулей, оптимизации конфигурации и обслуживания Drupal, а также оптимизации работы сервера. Проведено тестирование прямых SQL запросов и запросов при помощи Drupal Database API на реально разработанном сайте с использованием взаимодействия XML и PHP. Отображения результатов исследования было реализовано на страницах разработанного сайта с использованием графического и статистического представления.
ABSTRACT
This article contain description and analyze of simple methods for reducing (neutralizing) server load, optimization of Drupal CMS based on embedded and additionally installed modules, optimizing Drupal CMS configuration and maintenance, and optimizing server performance. We tested direct SQL queries and queries with the Drupal Database API on a really developed site using the interaction of XML and PHP. Research results was implemented on the developed site pages with using a graphical and statistical presentation.
Ключевые слова: методы уменьшения серверного нагрузки: оптимизация Drupal, прямые SQL запросы, запросы Drupal Database API.
Keywords: server load reduction methods: Drupal optimization, direct SQL queries, Drupal Database API queries.
Постановка проблемы. Как известно, скорость работы веб-сайтов является лимитирующим фактором, влияющим как на ранжирование ресурсов в поисковой выдаче, так и на поведение пользователей. Наблюдается довольно высокая конкуренция среди множества сайтов одинаковых тематик. Период социальной консолидации интеллектуальных ресурсов остается пока, не проявленным. Остается единственное направление - совершенствование технических возможностей используемых инструментов работы. В нашем случае инструментария уменьшения нагрузки на сервер.
Как сообщает источник [1], время загруженности страниц сайта отражается на финансовых показателях. Так для ресурса amazon.com, задержка всего в 100 мс. привела к уменьшению доходов на 1%. Тогда как, сокращение времени загрузки страницы Google Maps и уменьшении ее объема данных с 100Кб до 70-80Кб, привело к росту трафика на 10% в первую неделю, и еще на 25% - в течение следующих трех недель.
Вместе с тем, по информации того же ресурса, 47% пользователей надеются на то, что время загрузки страницы не превышает 2-х секунд. Всего лишь одна дополнительная секунда при загрузке
страницы приводит к снижению количества их просмотра на 11% и уменьшение комфортности работы посетителей на 16%.
То есть, приведенные выше, короткие сообщения свидетельствуют о архиважность и актуальность тематики инструментария уменьшения нагрузки на сервер.
В частности наша публикация акцентирует внимание направлении минимизации серверного нагрузки средствами CMS Drupal
Анализ последних исследований и публика-ций.Как показывает экспресс анализ последних исследований и публикаций по данной тематике, литературные источники представляют разные пути решения поставленной проблемы.
Так по сообщению Коцюбы А.Ю., Цяпича Я.П., Лавренчук С.В. [2], решение в данной ситуации - это использование асинхронной обработки запросов на сервере. Базируется реализация такого подхода на использовании неблокирующий архитектуры, построенной на событийно-ориентированной парадигме «evented I / O», применяя платформу «Node.js».
На сайте http://www.drupal.ru/node/125608 [3] сообщается о важности скорости сайтов разработанных на базе CMS Drupal и предлагаются соответствующие шаги по ее увеличение за счет включения встроенного кэширования и агрегации, включения кэширования содержания представлений, включения функции Boost, выключение модулей РНР Filtr и Update Manager, или уменьшение вообще количества модулей.
О надежности, безопасность, универсальность, гибкость, быстродействие, простоту поддержки и легкость изменения дизайна сайтов созданных на базе CMS Drupal, можно ознакомиться по ссылке http://www.addinfo.com.ua/stat/2160 stat.html [4].
О возможностях которые предлагает CMS Drupal и ее поддержку, достаточно подробно описано на сайте: http://webstudio2u.net/ua/site-develop/185-drupal.html [5].
Уже ранее, мы в своих работах [6] также обсуждали данную тему. В последней публикации в частности речь шла об эффективности простых методов нейтрализации уменьшения серверного нагрузки и использования различных режимов кэширования на основе встроенных модулей Drupal. В данной публикации приведены рекомендации по результативности дополнительно устанавливаемых модулей: Authcache и Cache Router; настройки конфигурации и обслуживания Drupal и собственно функции настройки сервера.
Постановка задачи. Проведенный анализ публикаций по данной проблематике показывает, что CMS Drupal достаточно популярной системой управления контентом. Попытки веб-разработчиков обеспечить своей системе универсальность, пластичность и повышенную функциональность по сравнению с конкурентами, приводит к увеличению нагрузки на сервер и уменьшения его быстродействия. В большинстве случаев, данная проблема
решается выбором специализированных дорогостоящих хостингов путем выделения серверов или нескольких серверов.
Наша работа - представление научной общественности и практическим разработчикам результативно-действенных, относительно простых и бесплатных путей уменьшения нагрузки на сервер для уже существующих сайтов и сайтов, находящихся в стадии разработки на базе CMS Drupal.
Для логически-системного раскрытия данного вопроса необходимо решить ряд пошаговых задач, а именно:
• разработать веб сайт средствами CMS Drupal о взаимодействии XML и PHP;
• провести анализ, тестирование созданного сайта, по объемам, скорости обработанной информации разнообразным набором инструментария: простыми методами (нейтрализации) различными путями модификации собственно Drupal (на основе встроенных и устанавливаемых модулей, конфигурации и обслуживания Drupal) и прямых SQL запросов.
• сформировать практически применяемые выводы и предложения по минимизации серверной нагрузки.
Объект исследования: процесс изменения серверного нагрузки в зависимости от используемых средств запроса к базе данных.
Предмет исследования: практически-действующие средства уменьшения серверного нагрузки на основе простых методов (нейтрализации), методов оптимизации Drupal, прямых SQL запросов и Drupal Database API.
Основная часть (решение задачи). Простые методы (нейтрализации) снижение нагрузки на сервер
Под серверной нагрузкой в данной работе мы подразумеваем: уровень использования оперативной памяти сервером; нагрузки на процессор (процессорное время, или время обработки информации процессором), а также нагрузки на Интернет канал. Исходя из этого наша задача сводится к минимизации трех составляющих параметра нагрузки.
Для обеспечения рельефности показателей исследуемых параметров будем проводить расчет входной нагрузки в 100 условных пунктах.
Как показывает практика, на среднестатистическом сайте посетители создают нагрузку в размере около 10% от общего, другие ресурсы съедают боты (поисковые и другие). По отношению к ботам следует проводить соответствующие процедуры по их нейтрализации. И в первую очередь, необходимо исключить попадание на сайт «плохих», бесполезных и вредных ботов.
Определение главного зеркала.
Основная масса сайтов доступна по двум адресам - с «www» и без. Большинство ботов, за редким исключением, считают, что это два разных сайты и загружают сайт по два раза. Наша задача - решить который URL сайта оставлять, а с какой сделать 301 редирект на главное зеркало.
Например перейдем по ссылке типа: http ://webmaster.yandex. ru/check. xml?hostname=ww
w.test.com и если видим, что: сайт является зеркалом test.com, значит главным зеркалом будем делать домен test.com, а www.test.com с помощью .htaccess сделаем 301 редирект. Если вы хотите, чтобы главным доменом был сайт без WWW, то в .htaccess который лежит у вас в корне (если он там не лежит, то создайте) вводим следующее:
RewriteEngine on RewriteCond %{HTTP_HOST} Awww. test. com$ [NC] RewriteRule %*)$ http://test.com/$ 1 [R=301,L].
Вследствие данного шага, адрес с WWW и все SEO показатели достаточно быстро «перекле-ються» на вид без WWW.
В том случае, если главным доменом будет домен с WWW - то в .htaccess необходимо писать:
RewriteEngine on RewriteCond %{HTTP_HOST} Atest.com$ [NC] RewriteRule %*)$ http://www. test.com/$ 1 [R=301,L].
Такая принудительная «склейка» зеркал ощутимо понижает посещаемость сайта ботами, в среднем это снимает 20 пунктов нагрузки с сайта.
Файл robots.txt
В файл Robots.txt следует обязательно прописать главный домен. Для всех без исключения ботов, закрыть от индексации все бесполезные страницы (часто это страницы списка пользователей, внутренние дубликаты страниц, поиск по сайту, страницы тегов, pda и print версии сайта и т.п.). Если таких "мусорных" страниц на сайте много - то и нагрузка снизится также до 10 пунктов.
1менний бан
Достаточно действенный способ, с помощью .htaccess блокировать полностью доступ к сайту ботам по их имени, который используется на предупреждение посещение ботами. Для этого в .htaccess прописывается:
## Блокировка по USER AGENT: RewriteCond %{HTTP_USER_AGENT} MJ12bot [OR]
RewriteCond %{HTTP_ USER_A GENT} Java [OR]
RewriteCond %{HTTP_ USER_A GENT} Njuice-Bot [OR].....
......RewriteCond %{HTTP_ USER_A GENT}
Zeus
RewriteRule % *)$ - [F,L].
Также в этот список можно добавить боты: bingbot, msnbot, Slurp, для русскоязычных сайтов, трафика почти нет, а Yahoo (Slurp) создает огромною нагрузку, так как очень активный и агрессивный. Даже без блокировки Yahoo и Bing - этот способ уменьшает посещаемость ботами примерно на 4Q условных пунктов.
Блокировка по IP
Здесь необходимо ввести логи активности IP адресов или анализировать серверные логи, и банить IP-адреса безымянные активные боты, в основном это парсеры (автоматические воры контента и т.п.) и в большинстве случаев их IP принадлежат хостингу провайдера. В случае выявления активного IP, смотрим whois ip адрес, например http://whois.domaintools.com/83.222.14.3 и если там явно указан хостинг - смело баним всю подсеть через .htaccess (каждую IP досрочно в виде: deny from
83.222. 14.). Очень много таких неизвестных ботов - парсеров, а также спам-ботов уходит из русскоязычных хостингов, также Китая, Турции и т.п., в странах третьего мира, можно банить сразу всю подсеть. После таких периодических банов удается снизить ботову активность и обеспечить более 10 пунктов снижения серверного нагрузки.
Бан примитивных самопишущих ботов Такие боты имеют знаковое отличие - у них ничего не написано в HTTP_USER_AGENT и HTTP_REFERER. В том случае, если оба условия верны - блокируем.
Прописать условие необходимо в любой части кода до вызова любых других процессов (подключение к БД, вызов конфигурации и т.д.). Средствами языка программирования PHP, это выглядит следующим образом:
if ($_SERVER["HTTP_REFERER"] == " AND $_SERVER["HTTP_USER_AGENT"] == '') {die('Bad bot');}
Блокировка примитивных самопишущих ботов обеспечивает до 10 пунктов снижения серверной нагрузки.
Оптимизация DRUPAL (модификация системы для улучшения ее эффективности и уменьшения нагрузки на сервер как такового)
Drupal - довольно распространенная CMS и это отложило на ней свой отпечаток - базовой пакет Drupal не является готовым решением для определения типа вида сайта, а служит фундаментом для его создания. В связи с этим при создании того или иного сайта на основе стандартного пакета Drupal используют большое количество готовых дополнительных модулей и тем оформления для Drupal, или разрабатываются новые модули и темы специально для создаваемого сайта. «Завершающим аккордом» по созданию сайта является его оптимизация, которую можно разбить на основных 4 шага: •встроенная оптимизация Drupal; •оптимизация Drupal дополнительно установленными модулями;
•оптимизация конфигурации и обслуживания Drupal;
•оптимизация работы сервера. Рассмотрим более подробно каждый из этих шагов.
Встроенная оптимизация Drupal.
С целью уменьшения серверной нагрузки, в первую очередь стоит отключить все неиспользуемые модули. Это сделает невозможным выполнение кодирования этих модулей при генерации страницы перед отправкой ее браузеру пользователя. Примером такого модуля является Statistics. Вместо статистики выдаваемой данным модулем, рекомендуется использовать статистику Google Analytics.
Использование встроенного кэширования Drupal.
Использование встроенного кэширования Drupal позволяет кэшировать информацию, изъятую из базы данных, а также информацию, которая получена при обработке удаленной информации с PHP.
Кэширования системы меню фильтров форматов ввода, переменных администрирования (например название сайта) и настроек модуля - выполняется автоматически. Все остальные параметры кэширования можно настроить на странице: Управление -> Производительность. На данной странице можно настроить: компрессию страниц, кэширование блоков, оптимизацию CSS и JavaScript файлов.
Кэширование страниц в режиме - нормальный. В данном режиме кэширования страниц, в случае просмотра впервые (анонимным, незарегистрированным в системе пользователем) проводится сохранение сгенерированной страницы в кэш. В дальнейшем при просмотре данной страницы (анонимным пользователем) она подтягивается с кэша уже сгенерированной, что значительно ускоряет работу Drupal.
При включении кэширования страницы в режиме - агрессивный, в случае генерации страницы пропускается загрузки и выгрузки включенных модулей, поэтому часть модулей могут работать некорректно либо не работать вовсе.
Настройка минимального времени жизни кэша страницы для анонимных пользователей.
Данный параметр определяет, через какое время после кэширования страницы, проводится проверка на обновление содержания данной страницы. В случае обновления, кэш данной страницы очищается. То есть, если администратор сайта изменил содержание страницы, он его видит сразу, в то время как анонимные пользователи, только через минимальный промежуток времени существования кэша.
Включение компрессии страницы, для сохранения сжатого кэша страниц и для передачи страницы браузера пользователя в сжатом виде, если он поддерживает компрессию gzip. Компрессия производится с помощью библиотеки zlib установленной как расширение в PHP.
Включение кэширования блоков. Принцип работы кэширования блоков аналогичный принципу работы кэширования страниц. Для супер - пользователя (первого зарегистрированного пользователя при установке Drupal, его id равен 1) блоки никогда не кэшируются.
Включение оптимизации CSS и JavaScript файлов. Это уменьшит их размер и количество обращений к серверу при загрузке страницы в браузер. Все CSS и JavaScript файлы собираются в один файл (свой файл для CSS и свой - для Java Script). Что уменьшает количество обращений к серверу при загрузке страницы.
Оптимизация Drupal дополнительно установленными модулями
Установка модуля Authenticated User Page Caching (Authcache).
Данный модуль позволяет управлять страницы, как для анонимных пользователей, так и для аутентифицированых («залогинованых») пользователей более качественно по сравнению со встроенным кэшированием Drupal. Установка данного мо-
дуля, предусматривает перенастройки динамического контента на страницах (например вывод имени аутентифицированого пользователя).
Authcache сохраняет каждый кэш страницы отдельно для каждого пользователя или роли. Кэш хранится в базе данных, или в вмонтированной среде кэширования (memcahed, APC, и т.д.). Кэширование версии страницы для аутентифицированых пользователей (кроме супер - пользователя) передаются с помощью AJAX, за счет чего достигается достаточно быстрое отображение страницы в браузере. В случае браузерного отключения JavaScript в аутентифицированого пользователя страница формируется с самого начала (сервер БД) что занимает большое количество времени, и при перезагрузке страницы скорость ее загрузки останется постоянной. В то время как при использовании Authcache на некоторых серверах скорость загрузки страницы уменьшается до 1 миллисекунды.
Если необходимо управлять страницами исключительно для анонимных пользователей (без аутентифицирования), рекомендуется установить модуль Cache Router. Данный модуль находится в основе модуля Authcache и управляет страницами лучше встроенного кэширования Drupal.
После проведения действий приведенных выше, страницы создаваемого сайта будут передаваться серверу браузеру пользователя в сжатом виде, а вот CSS и JavaScript нет. Исправить это можно установив модули CSS Gzip и JavaScript Aggregator.
Оптимизация конфигурации и обслуживания Drupal
Уменьшение времени хранения пользовательских сеансов.
Так как Drupal сохраняет пользовательские сеансы в своей базе данных, то сокращение времени их хранения разгрузит базу данных, особенно, если на сайт заходит тысячи пользователей в день. По умолчанию сеансы хранятся 55 часов, лучше всего уменьшить время их хранения до 24 часов. Для этого на сервере в папке / sites / default в файле settings.php изменим строку
ini_set('session.gc_maxlifetime', 200000); на: ini_set('session.gc_maxlifetime', 86400); //24 часа.
Также на этом файле можно сократить время жизни кэшированных страниц сеансов до 24 часов, изменяя строку: ini_set('session.cache_expire', 200000); на ini_set('session.cache_expire', 1440); // 24 часа (в минутах)
На последок в этом файле можно изменить время хранения cookie в браузере пользователя, сократив его до 24 часов: ini_set('session.cookie_lifetime', 86400); // 24 години (в секундах)
Если установить время хранения cookie в браузере пользователя равным 0 - то cookie будет удаляться сразу же после закрытия Интернет браузера пользователем.
Сокращение количества сообщений протоколирования работы сайта, которые хранятся в базе данных. На странице «Управление -> Отчеты и со-
общения -> Отчеты в базе данных», нужно выставить необходимый максимум отчетов которые хранятся в базе данных. Так как эти отчеты полезны для просмотра попыток взлома сайта, поэтому минимум, который можно выбрать, это 100 записей. Посмотреть эти отчеты можно перейдя на страницу «Управление -> Последние записи, в системном журнале».
Настройка выполнения регулярных процедур (задачи cron), так как при их выполнении очищаются журналы записей сообщений протоколирования работы сайта, устаревшие записи кэша и другие статистические данные. Самым простым способом настройки автоматического запуска регулярных процедур является установка модуля -Poormanscron, в котором необходимо установить интервал запусков Cron.
В составе Drupal есть модуль Throttle, который выполняет оценку количества посетителей сайта и отключает некоторые функциональные возможности, если достигнуто порог установлен администратором. На странице настройки данного модуля проводится указание минимального количества анонимных посетителей и минимальное количество зарегистрированных пользователей для включения ограничения функционала сайта для них.
Оптимизация работы сервера
Сервер сайта может работать под управлением различных операционных систем: Windows, Linux, FreeBSD. Настройка работы сервера будет проводиться в соответствии с каждой операционной системой индивидуально, так как установление eAccelerator в Windows и Linux существенно отличаются.
Рассмотрим только основные, наиболее значимые рекомендации по оптимизации работы сервера.
eAccelerator является PHP-акселератором, основное назначение которого является кэширование бинарного представителя кода.
Рекомендуется установить Web-сервер nginx и настроить его работу с Web-сервером Apache так, чтобы информацию о странице (url, alias, мета данные и т.д.) отдавал браузеру Apache, а статический контент (CSS, JavaScript, фото и т.д.) nginx. Или полностью заменить Web-сервер Apache, Web-сер-вером nginx.
Осуществить перемещение содержимого файлов .htaccess в главный файл конфигурации Apache - httpd.conf (в зависимости от используемой операционной системы), обеспечивает ускорение их обработки web-сервером. После чего, необходимо запретить поиск файлов .htaccess в пределах корневого каталога web-сервера, установив
AllowOverride в None. Несмотря на то, что некоторые модули внутри своих каталогов содержат .htaccess файлы, следует осторожно работать с данным видом оптимизации, особенно при переносе содержания всех .htaccess файлов в httpd.conf, не пропуская ни один .htaccess файл.
Установить на сервере три типа систем:
• анализа лог файлов (например AWstats);
• мониторинга производительности сервера (например Munin);
• учета сетевого трафика (например Vnstat)
Включить кэш MySQL и установить его размер равным 64 мегабайт. Слишком малый размер кэша - малоэффективен, особенно большой размер кэша приводит к тому, что поиск нужной информации в кэше занимает большой промежуток времени. Поэтому рекомендуется поэкспериментировать с размером кэша, на каждом конкретном сервере и подобрать его оптимальный размер.
Результаты сравнительного тестирования прямых SQL запросов и Drupal Database API
В работе XML и PHP можно выделить два основных направления по уменьшению нагрузки на сервер: во время парсинга данных (обработка данных с файла XML с помощью PHP скрипта) и при записи обработанных данных в БД. Для работы с БД в системе Drupal разработана Drupal Database API, определенный стандарт в зависимости от поставщика, уровень абстракции для доступа к серверам баз данных.
Уровень абстракции БД позволяет выполнить один программный код на различных СУБД. Гибкий уровень абстракции позволяет легко работать с различными типами баз данных, например MySQL или PGSQL. Он максимально сохраняет синтаксис и мощность SQL, меняя отдельные параметры запросов для разных типов баз сохраняя основные элементы безопасности неизменными.
Таким образом, при взаимодействии XML и PHP, по минимизации серверного нагрузки, мы детализируем второй метод: «во время записи обработанных данных в БД», так как метод уменьшения нагрузки «во время парсинга данных» (обработка данных с файла XML с помощью PHP скрипта ) есть достаточно трудоемким, время- ресурсо- и финансово затратным.
Для занесения информации в БД в Drupal принято использовать Drupal Database API, стандартный подход которым пользуются на практике.
Результаты проведенного сравнительного тестирования прямых SQL запросов и Drupal Database API показано в таблице 1.
Таблица 1
Результаты сравнительного тестирования прямых SQL запросов та Drupal Database API_
№ Название функции Результаты запросов
/п //прямой SQL //Drupal
11 Простой запрос выборки NID I TITLE С таблицы NODE, де NID >= 5 Select n.nid, n.title from node n where n.nid >= 5 $query = db_select('node', 'n'); $query->fields('n', array('nid', 'title')); $query->condition('n.nid', 5, '>='); $result = $query->execute();
22 Получение количества записей в таблице NODE, где NID > 10 Select count (*)from node n where n.nid >10 $query = db_select('node', 'n'); $query->fields('n'); $query->condition('n.nid', 10, '>'); $result = $query->execute ()->rowCount();
33 Запрос с одним логическим оператором AND и оператором LIKE Select n.nid, n.title from node n where n.nid >= 5 AND n.tile LIKE 'Chapter % $query = db_select('node', 'n'); $query->fields('n', array('nid', 'title')); $query->condition('n.nid', 5, '>='); $query->condition('n.title', 'Chapter0/«', 'LIKE'); $result = $query->execute();
44 Запрос с использованием логического оператора OR Select n.nid, n.title from node n where n.nid = 5 OR n.nid =20 $query = db_select('node', 'n'); $query->fields('n', array('nid', 'title')); $or = db_or(); $or->condition('n.nid', 10); $or->condition('n.nid', 20); $query->condition($or); $result = $query->execute();
55 Использование DB_Insert () для добавления записей Insert Into node (title, uid, type) Values ('New node', 1, 'article') db_insert('node') ->fields(array( 'title' => 'New node', 'uid' => 1, 'type' => 'article',)) ->execute();
66 Использование DB_Update () для обновления записей Updatet node Set title = 'Updated', changed = 1363104629 where nid = 1 $query = db_update('node'); $query->fields(array( 'title' => 'Updated', 'changed' => REQUEST_TIME,)); $query->condition('nid', 1); $num updated =$query->execute();
77 Использование DB_Delete () для удаления записей Delete From node where nid > 10 $query = db_delete('node'); $query->condition('nid', 10, '>'); $num_deleted = $query->execute();
Как видно из результатов проведенного тестирования прямые SQL запросы во всех семи случаях в объемном отношении значительно меньше по сравнению с Drupal Database API.
С целью обеспечения проведения экспериментальной части нами был разработан сайт (http://dp.rocksolid.com.ua/).
Блок поиска осуществляется по коду аэропорта (3-х значного кода).
Основной информационный блок составляет 3592 аэропорты, который выгружается из XML файла.
Загрузка XML файлов в БД и их обработку осуществлялось на основе системы данных поиска аэропорта (рис. 1). Данная закладка также отображает информацию последней загрузки:
•количество элементов приложенных к БД; •объем элементов приложенных к БД; •время обработки прямым SQL запросом; •время обработки через стандартную функцию которую использует Drupal «db_insert».
В данном случае было загружено различными методами всего 3592 элементы. Размер файла составляет 447,9 Кб; время обработки прямым SQL запросом составляет 1,88 секунды, тогда как по запросу Drupal db_insert 3,32 секунды.
Если представить данные результаты в процентном отношении, то, время обработки прямым SQL запросом уменьшено на 55% по сравнению с Drupal db_insert запросом.
Рисунок 1.
Информационное сообщение об объемах и ходе проведенных загрузок в закладке «Отгрузка XML»
Это достаточно наглядно продемонстрировано в графическом отображении, рисунок 2, (в закладке «Отгрузка XML»).
Такая результативность объясняется прохождением процедуры верификации до момента прямого SQL запроса, тогда как Drupal Database API в обязательном порядке будет проводить необходимые шаги по обработке данных, а именно:
•скрытие в интерфейсе информации о прямых запросах в БД;
•проведение предварительной работы по обработке данных (сериализация, приведения типов и т.д.);
•проведение работы по защите от возможных ошибок в запросе.
Сериализация, которую выполняет Drupal Database API - процесс перевода любой структуры данных в соответствующую последовательность битов. Обратной операцией к сериализации является операция десериализации (структурирование) - восстановление первоначального состояния структуры данных с битовой последовательности.
Стоит заметить, что для проведения прямых SQL запросов нужно обладать дополнительными навыками и умениями в программирование на языке SQL, тогда как для проведения записи в БД
обработанных данных через Drupal Database API достаточно знаний языка программирования РНР.
Предполагается, что процедура верификации проводится в ручном режиме и является обязательным для всех иностранных сайтов, в то время как на территории бывшего СНГ она (верификация) отсутствует.
Верификация - это проверка, способ подтверждения с помощью доказательства каких ни будь теоретических положений, алгоритмов, программ и процедур путем их сопоставления с опытными (эталонными или эмпирическими) данными, алгоритмами и программами.
Другими словами можно сделать вывод, что преимущество Drupal Database API в данном случае (при наличии процедуры верификации) становится его недостатком. Так как этот набор функций при его использовании тратит время на сериализацию данных для обеспечения безопасности и предотвращения посторонних SQL инъекций. В нашем случае мы имеем верифицированы данные, не требующие сериализации, поэтому использование прямых SQL запросов бесспорно уменьшают нагрузку на сервер, так как время обработки полученных данных меньше, что и подтверждается графиками запечатленными на рисунке 2.
Рисунок 2. Графическое отображение информационного сообщения об объемах и ходе проведенных
загрузок в закладке «ОтгрузкаXML».
Цифровые показатели становятся более рельефными в том случае, когда мы проведем увеличение входных данных в 10, 100 и 1000 раз.
Если провести простое математическое моделирование, результаты которого отражаются в той же закладке, при увеличении входных данных в 10 раз, благодаря прямому SQL запросу, сервер находится под нагрузкой на 14,4 секунды (в 100 раз в 144 секунд) - меньше по сравнению с Drupal db_insert запросу, рисунок 3.
При увеличении входных данных в 1000 раз размер файла будет составлять 437,4 Мб, время обработки по прямому SQL запросу - 31,3 минуты, тогда как время обработки Drupal db_insert соответствии 55,3хвилины.
И в этом случае, благодаря прямому SQL запросу, сервер находится под нагрузкой меньше на 24 мин по сравнению с Drupal db_insert:, что является весьма существенным в современных информационных системах.
Рисунок 3 Математическое моделирование увеличение входных данных в 10, 100 и 1000 раз.
Основные результаты и выводы. Как видим применение простых методов снижения серверного нагрузки: определение главного зеркала; файл robots.txt; именной бан; блокировка по IP; бан примитивных самопишущих ботов есть достаточно эффективными, так как в общей сумме уменьшают серверные нагрузки до 90 пунктов. В то же время стоит отметить, что результативность применения вышеприведенной процедур повышается с увеличением страниц на сайте, срока существования и большей его «раскрутки».
Подробно описано четыре шага оптимизации работы Drupal: встроенная оптимизация Drupal; оптимизация Drupal дополнительно установленными модулями; оптимизация конфигурации и обслуживания Drupal; оптимизация работы сервера.
Как видно из результатов проведенного тестирования прямые SQL запросы во всех семи случаях в объемном отношении значительно меньше по сравнению со стандартной функцией, которую использует Drupal «db_insert».
Для занесения информации в базу данных, было загружено различными способами 3592 элементы, размер файла составил 437,4 Мб. Время обработки по прямому SQL запросу на 55% меньше по сравнению с Drupal db_insert, так как прямой SQL запрос осуществляется - 31,3 минуты, тогда как время обработки Drupal db_insert соответствии 55,3 минуты.
Литература
1. https://promodo.ua/ua/blog/keshuvannya-storinok-optimizatsiva-zavantazhennva.html.
2. Коцюба А.Ю., Цяпыч Я.П., Лавренчук С.В. О методике оптимизации отказоустойчивости веб-серверов на одновременное количество запросов. Научный журнал «компьютерно-интегрированные: образование, наука, производство» Луцк, 2016. Выпуск № 24-25. С. 37-41.
3. http://www.drupal.ru/node/125608
4. http://www.addinfo.com.ua/stat/2160 stat.h
tml
5. http://webstudio2u.net/ua/site-develop/185-drupal.html
6. Сацык В.А., Гарлинський А.И. Практические методы уменьшения нагрузки на сервер функционирующих и новосозданных сайтов на базе CMS Drupal. // Международная научно-практическая конференция «Актуальные проблемы автоматизации и управления». 2016. Выпуск №4. С. 53-59.
7. Основы анализа спектра [Электронный ресурс] // Юнитест. Измерительное оборудование. 2001. URL: http: www.unitest.com/theory/spectrum-1.html. (дата обращения 12.11.16)
8. Python 3.6.0 documentation [Электронный ресурс] // Python Software Foundation. 2017. URL: https: docs.python.org/3 (дата обращения 04.01.17).
