mod_perl и oracle против производительности php и oracle

У меня есть большое приложение Perl, которое мне нужно ускорить; исходя из того, что он тратит большую часть своего времени на общение с БД, я хотел знать, сколько хорошо написанных операторов SQL я могу выполнить и достичь целевых показателей производительности. Для этого я написал очень простой обработчик, который выполняет SELECT и INSERT, когда я протестировал его на 300 одновременных запросах (всего 10 000), результаты были довольно плохими (в среднем 1900 мс).

Цель производительности, которую нам дал клиент, основана на другом приложении, которое они используют, написанном на PHP, поэтому я написал быстрый PHP-скрипт, который функционально делает то же самое, что и мой простой тестовый обработчик mod_perl, и он дал среднее значение 400 мс!

PHP-код:

$cs = "//oracle.ourdomain.com:1521/XE";
$oc = oci_pconnect("hr","password",$cs);
if(!$oc) { print oci_error(); }
$stid = oci_parse($oc, 'SELECT id FROM zz_system_options WHERE id = 1');
oci_execute($stid);
$stmt = oci_parse($oc, "INSERT INTO zz_system_options (id,option_name) VALUES (zz_system_optionsids.nextval,'load testing')");
oci_execute($stmt);
echo "hello world";

Код Perl:

use strict;
use Apache2::RequestRec ();
use Apache2::RequestIO  ();
use Apache2::Const -compile => qw(:common);
use DBI;
our $dbh;
sub handler
{
    my $r = shift;

    # Connect to DB
    $dbh = DBI->connect( "DBI:Oracle:host=oracle.ourdoamin.com;port=1521;sid=XE", "hr", "password" ) unless $dbh;  
    my $dbi_query_object = $dbh->prepare("SELECT id FROM zz_system_options");
    $dbi_query_object->execute();
    $dbi_query_object =
      $dbh->prepare("INSERT INTO zz_system_options (id,option_name) VALUES (zz_system_optionsids.nextval,?)");
    $dbi_query_object->execute("load testing");
    # Print out some info about this...
    $r->content_type('text/plain');
    $r->print("Errors: $err\n");
    return Apache2::Const::OK;
}

В mod_perl есть скрипт startup.pl, вызываемый с помощью PerlRequire в конфигурации apache, который загружает все используемые модули. Если все работает правильно, а у меня нет причин думать, что это не так, то каждый запрос должен запускать только строки в «подобработчике» — это означает, что Perl и PHP должны делать почти одно и то же.

Сведения о сервере: Аппаратный узел представляет собой четырехъядерный процессор Xeon L5630 @ 2,13 ГГц с 24 ГБ ОЗУ, ОС для виртуальной машины Apache — Gentoo, ОС для Oracle — Centos 5.

Версии: обе ОС обновлены в течение последних 2 недель, Apache версии 2.2.22, mod_perl версии 2.0.4, DBI версии 1.622, DBD::Oracle версии 1.50, Oracle Instant Client версии 10.2.0.3, Oracle Database 10g Express Edition Release 10.2.0.1 .0, PHP версии 5.3

Конфигурация Apache MPM: ServerLimit 2000, MaxClients 2000 и MaxRequestsPerChild 300.

Что я проверил: во время тестирования единственная нагрузка была от тестового приложения/оракула, ни одна виртуальная машина не превышала ни одного из своих ограничений счетчика bean-компонентов, например, памяти, Oracle всегда показывал 1 сеанс на дочерний элемент Apache, вставки выполнялись после каждого бегать.

Итак, мой вопрос; Могу ли я сделать версию mod_perl быстрее, и если да, то как?


person Alex M    schedule 27.08.2012    source источник
comment
Сначала вы должны сравнить одни и те же вещи, поскольку ваши запросы SELECT и INSERT не совпадают между вашим PHP и вашими сценариями Perl: WHERE id =1 в PHP SELECT и вы используете заполнители в Perl INSERT ( Известно, что заполнители влияют на производительность — лучше или хуже).   -  person Ouki    schedule 27.08.2012
comment
Тест повторен без заполнителя (отсутствующее слово WHERE было вырезано и вставлено из другой версии). Новый результат составляет 1810 мс в среднем для Perl - PHP такой же, как и без редактирования.   -  person Alex M    schedule 27.08.2012
comment
Решение найдено. В моем тестировании PHP я использовал http вместо https. Переключение на https дало очень похожие результаты на Perl. Дох!   -  person Alex M    schedule 27.08.2012
comment
@Ouki прав, зачем выбирать только WHERE id = 1 для PHP и выбирать все для Perl?   -  person tbone    schedule 27.08.2012


Ответы (1)


Если вы изменили код PHP, а время не изменилось, то, очевидно, вы не измеряете время кода, не так ли?

Важный вопрос: почему вы постоянно подключаетесь в Perl-скрипте, а не в PHP-скрипте?

Наконец, этот тест, вероятно, не даст вам ничего полезного, если только все ваши запросы не будут простыми выборками и вставками одной строки в одной таблице.

person Richard Huxton    schedule 27.08.2012
comment
Извините, я не уверен, где я сказал, что изменил код PHP - код PHP везде был одинаковым (и, кроме исправления различий в SQL, то же самое и с Perl). Кроме того, не «если» после подключения в perl — $dbh объявлен как «наш», поэтому он будет использоваться между запросами к одному и тому же дочернему элементу apache. - person Alex M; 27.08.2012
comment
Что касается того, говорит ли он мне что-нибудь полезное, он говорит мне, что либо mod_perl намного медленнее, чем php, либо моя настройка неверна. Я очень надеюсь, что это последнее. И под «намного медленнее» я подразумеваю настройку и ответ на запрос, у нашего приложения есть много других дел, и они могут быть или не быть быстрее в perl/php, но 1700 с лишним миллисекунд, чтобы сделать очень мало довольно много, чтобы затем «сохранить» остальную часть кода. - person Alex M; 27.08.2012
comment
1. Тест повторяется с..., 2. он говорит мне либо... Я надеюсь - вы догадываетесь, а это значит, что он не говорит вам ничего полезного, не так ли? Даже если вы реструктурировали свой тест, это вряд ли скажет вам что-то полезное о вашем приложении. - person Richard Huxton; 27.08.2012
comment
Это было изменение кода Perl, а не PHP, но я думаю, что вы правы; если изменение кода не меняет тайминги, то это не код. Кроме того, я абсолютно согласен с тем, что это не говорит мне ничего полезного о моем приложении, однако это говорит мне о том, что в настройке моего сервера/стека есть что-то, из-за чего mod_perl работает намного медленнее, чем эквивалент. PHP-скрипт. Я действительно хотел бы понять или устранить эту разницу, прежде чем я буду слишком долго работать над приложением - на случай, если есть хорошее изменение настройки, которое мы можем внести, чтобы наше приложение работало быстрее без изменения кода! - person Alex M; 27.08.2012
comment
Только что вернулся и проверил. Я предположил, что вы добавили заполнитель в PHP. Проведите тестирование с заполнителями - это будет важной частью времени разбора/настройки/отправки запроса. Вы пропустили часть моего ответа о количестве соединений в php и perl? - person Richard Huxton; 27.08.2012
comment
Нет, ответ на проблему с подключением заключается в том, что после подключения есть «если» и $dbh является глобальным; ручной способ выполнения PHP oci_pconnect. - person Alex M; 27.08.2012
comment
Однако, в конце концов, я заметил кое-что в таймингах, а именно то, что большая часть времени была в «подключении», то есть вне кода - оказывается, я удалил https из URL-адреса PHP... Спасибо за ваш ответы, однако, только когда вы начнете критически относиться к своим предположениям, вы замечаете вещи - как будто это может быть только настройка ... - person Alex M; 27.08.2012
comment
Я хотел сказать, где? повторно подключиться - потом заметил, что мне нужно прокрутить панель кода. Не уверен, что SO мог сделать, чтобы сделать это лучше, но это поймало меня раньше. Рад, что вы нашли свое несоответствие. - person Richard Huxton; 27.08.2012