Xpoint
   [напомнить пароль]

Алгоритмы формирования динамической страницы

Метки: [без меток]
2008-11-26 11:51:21 [обр] Антон[досье]

Доброго времени суток!

Для фомирования динмической страницы я использую наверное стандартный подход!
Например, авторизованному юзеру нужно выдать такую страничку (стартовую скажем):

Приветствуем, [Антон]
Для вас [1 новое сообщение]
Новых фото отзывов [3]
Для вас [3 новых уведомления]


Сейчас на сайте [26 человек]
Ваши контакты [3 онлайн/5 всего]


Топ анкета: [Юзерлогин]
...
ну и так далее. [в скобочках динамические данные - которые могут изменится при повторной перезагрузки этой же страницы]

Естественно начиная программировать - я делал так: скрипт на perl, коннект к БД mysql для получения каждого элемента (например, селект кол-ва новых сообщений). Все бы ничего, но проект стал расти! стали расти и проблемы

МОИ ПОИСКИ ОПТИМАЛЬНОГО РЕШЕНИЯ (в сети тоже много читал перед этим):

  1. Пересадил скрипты на fast::cgi
  2. оптимизировал БД, добавил индексы, по возможности изменил структуру

эти шаги дали мне весомый прирост в скорости выполнения скриптов, но.. все не стоит на месте и вот настал тот день, когда нужно увеличить скорость еще на порядок. ТО ЧТО Я СДЕЛАЛ ЕЩЕ:

  1. добавил хранимые процедуры (далее ХП)

это опять же дало результат, но вот так же дало еще больше пищи для раздумий

Итак, МОИ РАЗДУМИЯ:
А. ХЕШ ИНИЦИАЛИЗАЦИИ:

  1. создал ХП которая на запрос выдавала следующую текстовую строку: fio=>"Антон",new_mes=>1,new_photocomment=>3,...,online=>28
  2. в perl добавлял следующую конструкцию: eval("\%page_value=($str_from_db);");
  3. данный подход так же дает прирост, но думаю о многом я могу не подозревать.

Б. ПРОДОЛЖАЕМ ЭКСПЕРИМЕНТ:

  1. читая ту же самую строку, что и в А.1, но только из файла, а не из БД - получаем еще прирост! отсюда мысл, что возможно формировать строчку и записывать ее в файл каким то фоновым процессом (у каждого юзера свой файл).
  2. трудно представляю реализацию "относительно без задержек". то есть либо лопатить бд перезаписывая файлы каждые n-секунд, что помоему не оптимально, либо видоизменять файлы по событию, скажем отправили для юзера новое сообщение, тут же и перезаписать файл!
  3. тут больше вопросов чем ответов и поэтому:

В. КАЖДОМУ ОБЪЕКТУ СВОЯ ТАБЛИЦА:

  1. как я представляю себе, что будет несколько "таблиц-результатов", скажем чтоб не сканировать огромную таблицу на предмет, где USER_ID=мойID и READING=0, а в момент добавления нового сообщения для меня добавлять как в таблицу MESSAGE, так и в NEW_MESSAGE... при прочтении сообщения - удалять из NEW_MESSAGE
  2. Прирост/неприрост по тестить не смог...

...

И вообще, может я не туда двигаюсь?! какие оптимальные алгоритмы формирования динамических страниц с часто обновляемыми данными вы используете?! ПОМОГИТЕ, МЫСЛИ ПУТАЮЦО, НО ЗАДАЧУ РЕШИТЬ ОХОТО! МОЖЕТЕ ССЫЛОК НАДАВАТЬ, я впринципе сам суть уловлю, главное правильное направление принять!

ЗАРАНЕЕ СПАСИБО, РЕБЯТ!

спустя 2 часа 24 минуты [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] Хотите прирост? Пишите на C/C++. А то, что Вы делаете - вообще ерунда какая то.
спустя 1 час [обр] Thirteensmay(0/157)[досье]

А. Мысль верная, ХП возвращает готовый набор, нечего его части по кусочкам дергать. Реализации могут быть разными, можно возвращать из БД процедуры несколько отдельных параметров и получать их по отдельности через подстановку переменных, но это и БД и драйвер должен быть соответствующим.

create or replace procedure get_possible_link(iquery in number,
                                              iappend_source in number,
                                              oname out varchar,
                                              onumber out number, 
                                              linklist out cursor) is
...
q.sql.text = 'begin pk_rep.get_possible_link(12, 67, :oname, :onumber, :olinks); end;';
q.exec;
my name := q.getVariable('oname');
my number := q.getVariable('onumber');

Также в ХП можно поля складываю в одну строку результата так:

open mycursor for select $var1 as v1, $var2 as v2, $var3 as v3... (где var - переменные внутри ХП или подзапросы)
return mycursor;

тогда на клиенте результат можно обрабатывать как результат обычного запроса с одной строкой в которой несколько полей.

Можно предложить и др. варианты. Ваш, если проблем с нарушением синтаксиса из за значений внутренних полей не возникает, например если fio=>"Антон" в "Антон" попадется какой нить спецсимвол, ну теже кавычки например, так вот, если проблем нет, ну тоже как вариант, хотя и несколько ограниченный за счет отсутствия типизации.

Б. Забудьте о файлах. Они имеют смысл только в случаях элементарного хранения данных, как только задача хоть чуть усложняется, появляются условия, анализ, конкуренция, транзакции и т.п. файлы сразу же идут лесом, ибо на их поддержку начинает уходить неимоверно много времени, и производительность как правило сразу падает, не потому что в теории, в теории то все как раз хорошо, а на практике, потому что среднестатистический разработчик не бог. СУБД же как раз для таких случаев и разработаны. Вот и вы говорите типа файлы быстрее, да быстрее, в голом простом тесте, а на практике ? сами же говорите что "трудно представляю полную реализацию". Это все не означает что файлы совсем на помойку, в некоторых исключительных (простейших) случаях они могут быть полезны, это уж вам решать. Вы хотите на них сделать некое подобие кеша для каждого пользователя ? точно с тем же результатом вы можете это сделать с помощью отдельных таблиц, при этом гораздо удобнее.

Что касается остального и вообще производительности (в частности БД). Во-первых надо четко понимать что убийственным фактором производительности является множественный коннект-расконнект и запросы из одного скрипта, делайте все в одном коннекте, запросы упаковывайте в ХП. Во-вторых, раз пошла песня в сторону обработки внутри БД, то учтите что не все СУБД одинаково в этом плане хороши, я хочу сказать именно про производительность, а точнее масштабируемость, есть сведения от самих же хозяев например mysql, что она начинает резко проседать после увеличения одновременного количества сложных обрабатываемых процедур более 5, в то время как др. тянут на том же железе и 50 и 100 почти без видимого проседания (т.е. проседание линейно, а не вниз по экспоненте). В третьих, fastcgi, ХП и т.п. это конечно хорошо, но это всего лишь довесок, самый потрясный результат дает как правило оптимизация самих алгоритмов, переосмысление задачи и перекладывание части задач на административный уровень. Надо смотреть как можно оптимизировать запросы, циклы и пр., что можно упростить, от чего вообще отказаться и т.п.

По поводу C/C++, ну на ++ будут теже яйца что и Perl, сам тестил, знаю что говорю, по крайней мере что касается работы со строками, хотя конечно и здесь может быть выгода хотябы за счет отсутствия первоначального запуска интерпретатора, парсенья кода и т.п. А на чистом C, ну наверное да, есть смысл, вопрос только в том что чтобы его получить - писать на сях надо еще соответствующим образом уметь, да и вообще трахаться придется несколько больше.

спустя 3 минуты [обр] Антон[досье]

то есть вы хотите сказать, что все упирается только в скомпилированный с++? может где есть в сети методы формирования динамических хтмл-страниц!

кстати, насчет ерунды! это ерунда работает почти на порядок быстрее, чем классический подход :/ скрипт выполняется за 0.0040-0.0050 секунд.. используя классический подход, путем поэтапного запроса данных и вывода их на динамически формируемую страницу 0.0100-0.0130.. я и сам понимаю, что ерунда! но почему она работает быстрее? суть "ерунды" - сбор всех небходимых для формирования страницы данных в одной хранимой процедуре, которая эти данные возвращает! а дальше - по шаблону только страницу собрать... (хотя я интуитивно понимаю, что "костыль" - но как-то с этим костылем ходить быстрее получается чем с "обычной ногой")

а какой вы подход используете для формирования динамической страницы, с часто обновляемыми данными??

спустя 1 минуту [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] Простите, а как Вы меряете скорость выполнения скрипта?
спустя 5 минут [обр] Антон[досье]
Thirteensmay[досье] Даже не ожидал такого развернутого коммента! Спасибо тебе огромное! мои бессоные ночи дают мне понимание того, что надо развиваться в сторону архитектуры проекта, чем я собственно не особо всегда занимался... опять же на классическом уровне! у вас нет материалов по этому поводу?
спустя 4 минуты [обр] Антон[досье]

Алексей Севрюков[досье]
опять же классика:

$t0 = new Benchmark;

# my code

$t1 = new Benchmark;
$td = timediff($t1, $t0);
print timestr($td), "\n";

либо еще вот так:

require 'sys/syscall.ph';
$TIMEVAL_T = "LL";
$done = $start = pack($TIMEVAL_T, ());
syscall(&SYS_gettimeofday, $start, 0) != -1 or die "gettimeofday: $!";

# my code

syscall( &SYS_gettimeofday, $done, 0) != -1 or die "gettimeofday: $!";
@start = unpack($TIMEVAL_T, $start);
@done = unpack($TIMEVAL_T, $done);
# fix microseconds
for ($done[1], $start[1]) { $_ /= 1_000_000 }
$delta_time = sprintf "%.4f", ($done[0] + $done[1] ) - ($start[0] + $start[1] );

print $delta_time, "\n";

примерно одинаковые результаты выдают

спустя 3 минуты [обр] Thirteensmay(0/157)[досье]

Алексей Севрюков[досье] Подход с ХП в 10 .. 15 раз быстрее позапросного дергания из внешнего скрипта, лично неоднократно проверенный факт. Другое дело что это максимум и больше из него не вытянуть, а если надо больше, то см. выше, вполне возможно переход на C ;) но есть ведь и др. моменты.

Антон[досье] Нет, в сети смотрите.

спустя 1 минуту [обр] Алексей Севрюков(0/1292)[досье]

Thirteensmay[досье] если уже и CPP не устраивает, тогда еще проще - пишем свой микро-вебсервер, без всяких апачей, компиляций и так далее. Который и будет все это делать. К базе коннект уже есть, скрипты все скомпилированы, останется только достать данные, обработать и отдать обратно клиенту )

Не думал что CPP будет по скорости идентичен Перлу. Зачем тогда народ пишет модули (особенно для обработки строк) на перловой версии С, а не на чистом Perl? И разве ручное управление памятью будет не быстрее автоматического?

спустя 1 минуту [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] ну-ну, я примерно так и думал. Вы действительно полагаете, что Ваш код даст Вам хотя бы примерную картинку производительности? Очень сильно заблуждаетесь.
спустя 8 минут [обр] Антон[досье]

Алексей Севрюков[досье]

я не претендую в профессионалы, я только учусь! иногда мы в чем то заблуждаемся, но попытки развеять недопонимания не должны обрубаться..

ps если не хотите помогать, лучше вообще ничего не писать... чем писать, что "вы заблуждаетесь, а я знаю всю истину!" (обидно)

спустя 1 минуту [обр] Антон[досье]

Алексей Севрюков[досье]

я не прошу меня научить, я только прошу помочь с направлением, ибо в сети говна хватает... и не охота читать то, что я и сам бы смог написать, думаю что так оно и есть...

спустя 3 минуты [обр] Thirteensmay(0/157)[досье]
Алексей Севрюков[досье] Заметьте, народ пишет модули (особенно для обработки строк) на перловой версии С, чистый С, а не ++, т.е. STL. С тем что чистый C будет быстрее я соглашусь, но как сразу сказал этож как трахаться надо, вы давно чтоли приведением типа указателей не занимались ;) ? Это я все к тому что С смысл конечно имеет, и даже С++, но не легче ли будет сначала в строну оптимизации структуры посмотреть, пусть пока на Perl, оно же просто невпример легче.
спустя 3 минуты [обр] Thirteensmay(0/157)[досье]
Антон[досье] Алексей вам нормальную идейку подсказывает. Будет время попробуйте чистый C, мне самому интересно что там вытянуть можно, но времени потестить нет.
спустя 5 минут [обр] Антон[досье]

Thirteensmay[досье]
чот я правда погорячился с Алексеем...

Алексей Севрюков[досье]
мой тон был неуместен, спасибо за идею с С/С++

спустя 2 минуты [обр] Алексей Севрюков(0/1292)[досье]
Thirteensmay[досье] конечно давно ) Лет эдак 10 назад. Да я и не спорю что Perl на порядок проще. Но я все равно за простой и понятный код, а не за непонятные конструкции типа eval("\%page_value=($str_from_db);");, прирост производительности от которых в рамках полного цикла вызова скрипта клиентом AFAIK получится либо весьма сомнительным, либо совершенно незначительным и не стоящим ухудшения логики и читаемости скрипта. ИМХО.
спустя 7 минут [обр] Thirteensmay(0/157)[досье]
Алексей Севрюков[досье] Ну конструкция конечно сомнительная, см. мой первый пост. Но дело то вобщем не в ней, это насколько я понимаю просто следствие того что Антон[досье] не знал как вернуть структуру из ХП. Если этого не делать, то придется пилить несколькими запросами, а вот тут уже производительность и спухнеть ;)
спустя 44 секунды [обр] Алексей Севрюков(0/1292)[досье]

Антон[досье] Тестирование следует проводить:

  1. Вызывая этот код многократно, минимум несколько десятков тысяч раз
  2. Машина, на которой проводится тестирования - должна быть чистой, без "всплесков" загруженности, которые могут негативно сказаться на точности полученных результатов.
  3. Вы меряете только скорость куска уже скомпилированного кода и совершенно теряете из виду время старта скрипта, время его интерпретации, время коннекта к БД и так далее. Т.е. реальные накладные расходы, которые неминуемо возникают при каждом обращении к скрипту. Т.е. как минимум правильно было бы мерять хотя бы программкой ab, входящей в поставку Apache.

В итоге получается что все относительно. Например, время инициализации скрипта займет одну секунду (просто предположим), Ваш код выполняется 0.01-0.03 секунды, а оптимизированный — 0.0005-0.0008. Далее все просто, что быстрее: 1.03 (инициализация + выполнение) либо 1.0005? Конечно, второй вариант быстрее. Но велика ли разница? ) Стоит ли она того, чтобы заморачиваться, усложнять структуру и логику скрипта и ухудшать его читабельность в разы?

спустя 20 минут [обр] Антон[досье]

Thirteensmay[досье]

да ты прав, с ХП я иду на ощуп... в рунете не очень много написано про ХП..(прокачиваю свой ингишь :) ) да и пока готового для себя решения я не нашел! поэтому сюда и написал, чтоб вы мой вектор в нужное русло помогли направить!

ps теперь я знаю как вернуть структуру из ХП, спасибо ;)

спустя 9 минут [обр] Антон[досье]

Алексей Севрюков[досье]
а разве технология fast_cgi тратит время на запуск???

use CGI::Fast;

   require 'sys/syscall.ph';

my $q;
while ( $q = new CGI::Fast ) {
   $TIMEVAL_T = "LL";
   $done = $start = pack($TIMEVAL_T, ());
   syscall(&SYS_gettimeofday, $start, 0) != -1 or die "gettimeofday: $!";

# ничего не делаем

   syscall( &SYS_gettimeofday, $done, 0) != -1 or die "gettimeofday: $!";
   @start = unpack($TIMEVAL_T, $start);
   @done  = unpack($TIMEVAL_T, $done);
   # fix microseconds
   for ($done[1], $start[1]) { $_ /= 1_000_000 }
   $delta_time = sprintf "%.4f", ($done[0]  + $done[1] ) - ($start[0] + $start[1] );

print $delta_time, " sec\n";
}

как вы думаете что в $delta_time??? при первом запуске какое-то число, а при последующих - 0.0000 (порядки ниже я рассматривать не стал)

я понимаю, что это все равно, что ловить 25 кадр своими глазами и что будет там 0.03 или 0.003 - какая хрен разница! но если в соотношении рассмотреть? в 10 раз быстрее??? это много? это "на порядок".

я конечно не знаю, но полагаю, что есть такие архитектурные решения, которые позволяют шагнуть еще на порядок выше!

или не стоит стремится к цифрам? что вообще является показателями производительности??? какие цифры?

спустя 2 минуты [обр] Антон[досье]
к посту выше и коннекты к БД происходят до while - приконектились и висим.. так что я полагал, что мои цифры близки к истине, или я не прав опять? :/
спустя 4 минуты [обр] Thirteensmay(0/157)[досье]

Алексей Севрюков[досье] Совершенно очевидно что использование ХП не дает результата само по себе, также как и C. Все должно применяться к месту. Рассмотрим следующий случай: Допустим полный цикл вызова скрипта (с 3 внутренними запросами) = 1.03 сек без ХП, и 1.01 сек если запросы вынесены в ХП. Это конечно мелочь. Теперь допустим в скрипте нам надо вычислить всех потомков некоторого узла, дерево имеет классическую структуру (id, value, parent_id), и достаточно велико, допустим 10К нод. Классический в общем то случай. В среднем надо выполнить порядка 5К запросов, при казалось бы мизерной экономии на одном запросе (порядка 0.01) в результате получим 1.01 + расходы выполнения внутри СУБД прибл. 2 сек (запросы то там всетаки всеравно выполняются, только гораздо быстрее) = 3 сек против 50. Полное время выполнения.

Антон[досье] "в рунете не очень много написано про ХП" - почитайте книжку (в сети есть скан) "Oracle PL/SQL для профессионалов" авторы помню Прибыл (это фамилия такая) и еще ктото там. Даже если Oracle не собираетесь, весьма рекомендую, очень хорошо написано, с толкованием, русский, основы ХП и не только основы, примеры, и т.п. По крайней мере будете в курсе что и как.

спустя 3 минуты [обр] Антон[досье]
Thirteensmay[досье] мне нравится ваш подход, еще раз спасибо за помощь, и что не пугаетесь много писать и разъяснять!
спустя 2 минуты [обр] Thirteensmay(0/157)[досье]
Хм. уточнение: ;) запросы то там всетаки всеравно выполняются, только гораздо быстрее, следует понимать так: Скорость выполнения непосредственно самих запросов таже, но за счет того что трафик постоянно туда-сюда не гоняется, каждый очередной запрос не парсится, нет межпроцессного взаимодействия, и т.п. накладных расходов, скорость выполнения ХП гораздо выше.
спустя 7 минут [обр] Антон[досье]
+ ХП ведь вкомпилированы в сервер мускульный? насколько я понял!
спустя 2 минуты [обр] Thirteensmay(0/157)[досье]
Антон[досье] А вот здесь поподробней пожалуйста ;) Вы это про что ?
спустя 5 минут [обр] Антон[досье]
Храни́мая процеду́ра — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере.

википедия, http://ru.wikipedia.org/wiki/Хранимые_процедуры

спустя 14 минут [обр] Thirteensmay(0/157)[досье]
Это очень упрощено, ХП бывают разные, кроме набора SQL инструкций они содержат полный набор процедурных расширений (циклы, ветвления, записи и т.п.) Компилироваться полностью они могут если в них нет eval подобных инструкций, кроме того, сами ХП могут быть написаны на внутреннем процедурном языке СУБД, или на чистом C с интерфейсом прямого доступа к методам и структурам самой СУБД. Оба варианта компилируются, но второй теоретически быстрее, не знаю не проверял, ибо в общем случае он более гемороен.
спустя 1 час 24 минуты [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] Снова не правильно тестируете. Используйте Apache Banchmark, тогда Вы увидите картину целиком.
спустя 15 минут [обр] Антон[досье]
Алексей Севрюков[досье]
хорошо! пошел читать мануалы
спустя 26 минут [обр] Thirteensmay(0/157)[досье]
Будете тестить незабудьте про "многопользовательность", ибо теже ХП дают ощутимый прирост не только в скриптах выполняющих большое кол-во запросов, но и в скриптах с небольшим их количеством расположенных на серверах с достаточным количеством одновременных пользователей (принцип тотже что я описал выше, только большое кол-во запросов получается из-за нескольких одновременно работающих пользователей), на время выполнения скрипта это влияет опосредовано за счет снижения нагрузки на СУБД в общем.
спустя 8 минут [обр] Антон[досье]
ребят, а вас тут двое??? просто я совсем недавно тут, мне помоему никто больше и не отвечал!
спустя 10 минут [обр] Антон[досье]

ab -c 10 -n 1000 http://mydomen/fcgi-bin/__test.fpl

Document Path:          /fcgi-bin/__test.fpl
Document Length:        11 bytes

Concurrency Level:      10
Time taken for tests:   0.948895 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      222000 bytes
HTML transferred:       11000 bytes
Requests per second:    1053.86 [#/sec] (mean)
Time per request:       9.489 [ms] (mean)
Time per request:       0.949 [ms] (mean, across all concurrent requests)
Transfer rate:          227.63 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       6
Processing:     3    8   4.9      7      53
Waiting:        3    8   4.8      7      53
Total:          3    8   4.9      7      53

Percentage of the requests served within a certain time (ms)
  50%      7
  66%      9
  75%     10
  80%     11
  90%     12
  95%     14
  98%     16
  99%     47
 100%     53 (longest request)

опытным взглядом вообще можно диагноз ставить? как по кардиограмме (сам смотришь - ломаная линия, а для врача - работа сердца (системы считай))??

http://httpd.apache.org/docs/2.0/programs/ab.html - тут не нашел расшифровок результата, а интуитивно могу наверное не правильно понять :/ (опять в дебри понесет еще :))

спустя 9 минут [обр] Антон[досье]
Percentage of the requests served within a certain time (ms)
  50%      7
  66%      9
  75%     10
  80%     11
  90%     12
  95%     14
  98%     16
  99%     47
 100%     53 (longest request)
особенно суть вот этого для меня непонятна пока (вернее интуитивное понятие сложилось, а вот точного)...
спустя 37 минут [обр] Антон[досье]
кстати, а как вы относитесь к fork() процесса? скажем если делать копию процесса и в родительском скрипте генерировать сообщение для юзера, скажем "Ваше сообщение отправлено", а в чайлде - делать "тяжелые операции инсертов апдейтов" и тем самым не заставлять юзера ждать, пока там это все выполницо! я конечно понимаю, что костыль, но что скажите - господа?
спустя 4 часа 54 минуты [обр] Давид Мзареулян(14/1003)[досье]

Антон[досье] Блин, до чего же трудно Вас читать! Неужели сложно писать по-русски?

По делу: сколько у Вашего сайта сейчас показов в сутки?

спустя 3 часа 26 минут [обр] Роман Чемисов(0/350)[досье]
Алексей Севрюков[досье]
Я не понял при чём тут C++? Конечно, я согласен, что первый вызов будет медленнее, но в дальнейшем никакого принципиального выигрыша в скорости мы не получим. Подробности здесь.
спустя 2 часа 24 минуты [обр] Антон[досье]

Thirteensmay[досье]

Также в ХП можно поля складываю в одну строку результата так:

open mycursor for select $var1 as v1, $var2 as v2, $var3 as v3... (где var - переменные внутри ХП или подзапросы)
return mycursor;

чтото я не пойму как объявлять такой курсор :/

я с курсорами обычно так:
declare mycursor corsor for
   select ...

попробывал просто declare mycursor corsor; - не вкатило ;)

спустя 1 минуту [обр] Антон[досье]

Давид Мзареулян[досье]

давно не излагал мысли на бумаге ;)
в процессе думаю стиль изложения устаканицо!

а вас какие цифры интересуют? количество хитов?

спустя 49 минут [обр] Антон[досье]

Thirteensmay[досье]

кстати, немного почесав голову, все же соорудил рабочий вариант:

BEGIN
DECLARE var1,var2 INT DEFAULT 0;

set var1=1;
set var2=100;

set @xquery = concat('select ',var1,' as v1, ',var2,' as v2');

PREPARE stmt FROM @xquery;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

END

немного неудобный, если данных для формирования динамической страницы много, но зато сам и работает!

но все равно жду ваших дополнений к вашему примеру, он мне кажется лаконичнее и удобнее в эксплуатации!

спустя 1 минуту [обр] Антон[досье]
кстати, а тут редактировать свое написанное сообщение уже нельзя?!??
спустя 1 час 24 минуты [обр] Thirteensmay(0/157)[досье]
Антон[досье] По поводу курсоров это я вам принцип показал, не знаю я как оно точно будет в mysql, там вроде было так что из функции возвращается последний селект (ну типа неявный курсор такой получается), а вот в оракле например у процедуры можно обьявить несколько выходных параметров - явных курсоров типа refcursor, открыть их в одной процедуре, а потом передать в другую и т.д., так вот синтаксис что я показал это ближе к тому был.
спустя 4 часа 35 минут [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье], смотреть фактически надо отказы и строчку Requests per second:    1053.86 [#/sec] (mean). Ессно проверять надо на нормальном полноценном скрипте. Потом вносите правки - запускаете бенч снова, смотрите результат.
Роман Чемисов[досье] я же и не спорю - занимался С++ лет 10 назад, тогда он точно был быстрее -) Сейчас может Вы и правы. Но C в любом случае будет быстрее.
спустя 32 минуты [обр] Давид Мзареулян(14/1003)[досье]
Антон[досье] Я написал, что меня интересует. Да, количество хитов.
спустя 17 часов [обр] Антон[досье]
Давид Мзареулян[досье]
за вчера 80463 хита
спустя 4 минуты [обр] Антон[досье]

кстати, я нашел для себя идеальное решение, спасибо Thirteensmay[досье] и еще одному человеку не с этого форума!
суть в том, что на каждый динамический объект своя таблица:

скажем есть на странице запись: ONLINE 28 - так вот, при обычном методе цифру 28 я получал путем запроса с вычислениями! Сейчас же я создал табличку "онлайн" всего с одним полем! куда собственно и делаю +1 при входе пользователя на сайт и -1 при выходе (с помощью триггеров)!

спустя 4 часа 57 минут [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] В сутках 86400 секунд, у Вас за сутки 80463 запроса. Делайте выводы )))
спустя 16 часов [обр] Антон[досье]

Алексей Севрюков[досье]
это среднее вы получаете.. учитывая, что сайт больше регионального значения, то нагрузка распределяется неравномерно... обычно пик приходится с 9-23 по местному.. с 3-6 запросов же почти нет... так что выводы делаю исходя из этого..

могу дать если интересно точные данные по распределению по времени хитов!
стоит awastat по серверным логам, счетчики недолюбливаю

спустя 4 часа 52 минуты [обр] Алексей Севрюков(0/1292)[досье]
Антон[досье] Ну это Вы и сами посчитаете. А есть ли разница среднее или нет, при том что сервер обрабатывает в любом случае больше 50 коннектов в секунду?
Powered by POEM™ Engine Copyright © 2002-2005