LINUX.ORG.RU

MySQL победил на Open Source Database the Benchmark


0

0

Издание "C'T magazine" провел соревнование среди наиболее популярных open source СУБД. В качестве теста было предложено обслуживание клиентов в интернет-магазине.

Результаты участников:
MySQL5/PHP: 3664 заказов в минуту
DB2/Java : 1537
Oracle/Java: 1412
PostgreSQL/PHP: 120

>>> Подробности



Проверено: Demetrio ()
Ответ на: комментарий от vtVitus

> никакого скрипта - это java. время выполнения запроса (отсылка запроса, обработка запроса, передача данных (по сети) 0.004) и 0.001 время на работу java. там времена написанны.

там не учтено время ПОДКЛЮЧЕНИЯ к БД, которое и составляет 90% времени выполнения. Для PostgreSQL это время заставляет скрипт работать в 10 раз медленнее, чем аналог под MySQL. Время выполнения самого селекта вообще не играет особой роли - да и оно практически одинаково для разных баз/ У MySQL кстати оно составляет около 2-3 миллисекунд (сложно замерить точно)

anonymous-III
()
Ответ на: комментарий от anonymous-III

>там не учтено время ПОДКЛЮЧЕНИЯ к БД

ещё раз повторяю - те кто меряет время подключения к бд, могут идти в сад и дальше. Нормальные люди держат пул коннектов и их подобные дурости не волнуют - время подключения к БД это хуже сферического коня.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

> ещё раз повторяю - те кто меряет время подключения к бд, могут идти в сад и дальше. Нормальные люди держат пул коннектов и их подобные дурости не волнуют - время подключения к БД это хуже сферического коня.

на 90% серверов, где крутится MySQL вам не дадут использовать пул коннектов, это раз. Второе - разница в ДВЕ миллисекунды при подключении через connect или pconnect не играет особой роли для MySQL.

anonymous-III
()
Ответ на: комментарий от anonymous-III

>на 90% серверов, где крутится MySQL.

??? кто мне что запретит ? какими это средствами ? (я честно говоря только с дедикейт серверами имею дело, поэтому не совсем шарю, что там на "дешёвом" хостинге)

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

> ??? кто мне что запретит ? какими это средствами ? (я честно говоря только с дедикейт серверами имею дело, поэтому не совсем шарю, что там на "дешёвом" хостинге)

Заметно что кроме dedicated вы ничего не пользовали или не пробовали раздавали свои ресурсы другим. А вы в курсе, что если не делать запрета на постоянные соединения с MySQL на shared хостинге, любой пользователь положит базу (общую) на колени просто передав пару сотен mysql_pconnect с разных хостов или даже с одного хоста?

anonymous-III
()
Ответ на: комментарий от anonymous-III

>А вы в курсе, что если не делать запрета на постоянные соединения с >MySQL на shared хостинге, любой пользователь положит базу (общую) на >колени просто передав пару сотен mysql_pconnect с разных хостов или >даже с одного хоста?

Ещё один довод в пользу постгри. У неё есть возможность задавать ограничения на каждого пользователя. И на базу тоже.

CREATE USER name CONNECTION LIMIT N;

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

vtVitus ★★★★★
()
Ответ на: комментарий от anonymous-III

> А вы в курсе, что если не делать запрета на постоянные соединения с MySQL на shared хостинге, любой пользователь положит базу (общую) на колени просто передав пару сотен mysql_pconnect с разных хостов или даже с одного хоста?

А вы в курсе, что можно сделать так:

jdbc:mysql://localhost/dbname?autoReconnect=true

anonymous
()
Ответ на: комментарий от Sorcerer

>Какой довод-то? В MySQL такое тоже есть, правда, возможность тоже новая

Это вы не мне это вы товарищу третему анонимусу говорите :).

vtVitus ★★★★★
()
Ответ на: комментарий от Sorcerer

> правда, возможность тоже новая:

Хотя не такая уж и новая, - даже в версиях < 4 есть глобальная переменная, ограничивающая максимальное число соединений.

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

>ограничивающая максимальное число соединений.

Максимальное кол-во это не очень интересно, интересно именно ограничение для каждого пользователя.

vtVitus ★★★★★
()
Ответ на: комментарий от anonymous

> А вы в курсе, что если не делать запрета на постоянные соединения с MySQL на shared хостинге, любой пользователь положит базу (общую) на колени просто передав пару сотен mysql_pconnect с разных хостов или даже с одного хоста?

Еще добавлю, что хостеру наоборот выгоднее, если у пользователя есть аккуратный пул, а не создается огромное число подключений. Чтобы не быть голословным сходите на http://eatj.com , там они в факе пишут, что создавайте пул и даже пример дают.

anonymous
()
Ответ на: комментарий от vtVitus

> Максимальное кол-во это не очень интересно, интересно именно ограничение для каждого пользователя.

для кажого пользователя тоже есть ограничение. как в общем на кол-во открытых соединений для отдельного пользователя, так и на кол-во подключений в течении часа.

anonymous
()
Ответ на: комментарий от anonymous-III

>там не учтено время ПОДКЛЮЧЕНИЯ к БД, которое и составляет 90% времени выполнения.

Оказывается идиоты не только пишут егаис, но и попадаются на ЛОРе. А потом удивляемся, почему индусы пишут больше программ, чем русские. А потому что они пишут проги ГРАМОТНО

anonymous
()
Ответ на: комментарий от anonymous

> А вы в курсе, что можно сделать так: jdbc:mysql://localhost/dbname?autoReconnect=true

на 90% серверов в сети крутится LAMP и ВСЕ. Какой jdbc еше и на shared хостингах (коих намного больше в процентном соотношении)?

anonymous-III
()
Ответ на: комментарий от anonymous-III

> Какой jdbc еше и на shared хостингах (коих намного больше в процентном соотношении)?

jdbc -- это драйвера для работой с базами данных из ява программ, почему его не должно быть на shared хостингах не могу понять. Как же тогда к базе коннектится?

anonymous
()
Ответ на: комментарий от anonymous

> jdbc -- это драйвера для работой с базами данных из ява программ, почему его не должно быть на shared хостингах не могу понять. Как же тогда к базе коннектится?

на шаред хостингах java - это редкость. Лично мне не попадалась. Везде LAMP, питон и все.

anonymous-III
()
Ответ на: комментарий от anonymous-III

> на шаред хостингах java - это редкость. Лично мне не попадалась.

В принципе не такая уж и редкость. На один я уже давал ссылку ( http://eatj.com -- 6,85$/месяц 500 Мб, приватная JVM), правда тарифные планы, как правило, начинаются с 7$/месяц, но это не так уж и много, тем более, что как правило это VIP планы, где много места и широкий канал.

anonymous
()
Ответ на: комментарий от anonymous

> Оказывается идиоты не только пишут егаис, но и попадаются на ЛОРе. А потом удивляемся, почему индусы пишут больше программ, чем русские. А потому что они пишут проги ГРАМОТНО

LOL. Сразу видно человека не видевший код, который генерят индусы. Не доводилось после индусов код апгрейдить? Обычно проще переписать с нуля.

anonymous-III
()
Ответ на: комментарий от anonymous

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

anonymous-III
()
Ответ на: комментарий от anonymous-III

> а вот скажите, я не в курсе как на джава, но интересно - если написать простейшую прогу , которая будет открывать соединения с базой (не закрывая их), что скажет ваша база через примерно 300 соединений? можете проверить эксериментально?

1) Зачем такое делать?

2) Причем тут ява :)

3) Как правило, на хостингах ограничивают время жизни соединения, да и число соединений, поэтому, чтобы и твое приложение шустрее работало и им проще было советуют делать пул

4) По идее их должна прибить виртуальная машина

Попробовал ради интереса, все живо :)

anonymous
()
Ответ на: комментарий от anonymous

Чуть не забыл. Использовал MySQL, другого не держу :)

anonymous
()
Ответ на: комментарий от anonymous-III

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

anonymous
()
Ответ на: комментарий от anonymous

> в десятый раз для анонимуса 3 повторяют что пул коннектов приводит к тому что вместо 300 соедиений с базой будет 10. но думаю что он этого опять не поймет. почитай где нибудь за пределами лора про пул, перед тем как писать чушь дальше

LOL. Это в случае если будет только 10 хостов пользовать базу. А если 300? А 1000? Так вот 1000 в течении трех часов и положат базу в случае pconnect

anonymous-III
()
Ответ на: комментарий от anonymous

> 1) Зачем такое делать? для того, чтобы проверить ваш код и сервер на более менее приличных нагрузках. Вам это незнакомо? siege или подобный софт никогда не использовали? Ваши действия когда вам дают ТЗ - сайт должен гарантированно отрабатывать 10 запросов в сек от разных пользователей или 10000 в течении часа?

> 2) Причем тут ява :) она может вести себя по другому, нежели ПХП

> 3) Как правило, на хостингах ограничивают время жизни соединения, да и число соединений, поэтому, чтобы и твое приложение шустрее работало и им проще было советуют делать пул

не стоит теоретизировать. Практика доказывает обратное. Посмотрите значение wait_timeout на вашем MySQL.

4) По идее их должна прибить виртуальная машина Попробовал ради интереса, все живо :)

рад, что это так. А теперь повторите то же самое с одним простым селектом

anonymous-III
()
Ответ на: комментарий от anonymous-III

> LOL. Это в случае если будет только 10 хостов пользовать базу. А если 300? А 1000? Так вот 1000 в течении трех часов и положат базу в случае pconnect

Причем тут 3 часа? Пул из 300 соединений под быстрые задачи web-сервера довольно тяжело забить, - должна быть такая высокая нагрузка, что простой shared хостинг лучше в таком случае заменить на выделенный сервер.

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

> Причем тут 3 часа? Пул из 300 соединений под быстрые задачи web-сервера довольно тяжело забить, - должна быть такая высокая нагрузка, что простой shared хостинг лучше в таком случае заменить на выделенный сервер.

рекомендую посмотреть значение wait_timeout на дефолтово установленном MySQL (какой на всех хостингах и стоит за очень редким исключением). Вопросов откуда 3 часа больше не возникнет. Впрочем бывает и 8 часов.

anonymous-III
()
Ответ на: комментарий от Sorcerer

вообще для тех кто в танке и прочих теоретиков, до которых туго доходит, рекомендую прочитать комменты к функции mysql_pconnect: http://www.php.net/function.mysql-pconnect

я работаю с MySQL довольно плотно с 1999 года, так что опыт кой какой имеется в тюнинге этой БД и использования ее возможностей на разных задачах и с разными нагрузками...

anonymous-III
()
Ответ на: комментарий от anonymous-III

Ты тупой или прикидываешься ? Сколько из тех 300 хостов сделают ОДНОВРЕМЕННЫЙ запрос в базу ? По статистике не больше 2%-5% для средненавороченного приложения. Значит нужно будет всего лишь 6-15 ПОСТОЯННЫХ коннектов к базе, которые после запроса ТУТ ЖЕ ВОЗВРАЩАЮТСЯ В ПУЛ!

anonymous
()
Ответ на: комментарий от anonymous-III

> рекомендую посмотреть значение wait_timeout на дефолтово установленном MySQL (какой на всех хостингах и стоит за очень редким исключением). Вопросов откуда 3 часа больше не возникнет. Впрочем бывает и 8 часов.

Я же в свою очередь рекомендую ознакомиться с тем, что же такое пул, как Вам уже здесь неоднократно советовали. Соединения _переиспользуются_.

Sorcerer ★★★★★
()
Ответ на: комментарий от anonymous

> Ты тупой или прикидываешься ? Сколько из тех 300 хостов сделают ОДНОВРЕМЕННЫЙ запрос в базу ? По статистике не больше 2%-5% для средненавороченного приложения. Значит нужно будет всего лишь 6-15 ПОСТОЯННЫХ коннектов к базе, которые после запроса ТУТ ЖЕ ВОЗВРАЩАЮТСЯ В ПУЛ!

Это смешно. Ознакомтесь сначала с работой пула в MySQL. До истечении времени wait_timeout соединение с клиентом не будет закрыто (если коиент его сам не закрыл). Это время измеряется часами, т.е достаточно эти 300 запросов сделать в течении нескольких часов (пока у первых соединений не истекло wait_timeout), чтобы положить базу в случае pconnect. В случае connect только одновременные 300 запросов положат базу. Теперь надеюсь понятно?

anonymous-III
()
Ответ на: комментарий от Sorcerer

> Я же в свою очередь рекомендую ознакомиться с тем, что же такое пул, как Вам уже здесь неоднократно советовали. Соединения _переиспользуются_.

Вообще то мы говорили о запросах с уникальных хостов при pconnect. Такой кстати баг имеется (имелся) в MySQL, когда переиспользовалось одно и тоже соединение для разных клиентов, вы это имеете в виду?

anonymous-III
()
Ответ на: комментарий от anonymous-III

> Вообще то мы говорили о запросах с уникальных хостов при pconnect.

Не знаю, о чем Вы говорили, а в данной теме говорится об использовании связки web-сервер со скриптовым языком + сервер БД. Сколько уникальных хостов в такой связке? Столько же, сколько web-серверов, то есть, обычно ровно 1. Если Вы в своих проектах даете пользователям php-скрипт и удаленный доступ к базе, то это уже другой разговор, к данной теме отношения не имеющий.

Sorcerer ★★★★★
()
Ответ на: комментарий от anonymous-III

>В случае connect только одновременные 300 запросов положат базу. Теперь надеюсь понятно?

Нет, это Вы чего-то не понимаете.

Еще раз и медленно: у меня есть виртуальный хост, на котором крутится тот же вебмагазин.

Я создаю 10 (20, 30, 50) одновременных подключений к базе (пусть это будет простой массив из пар значений {MYSQL * conn, bool busy_flag } ). http://dev.mysql.com/doc/refman/5.1/en/mysql-connect.html

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

Как только я обрабатываю запрос пользователя (показываю ему хтмл-страницу, например) я помечаю это соединение как свободное.

Вот и весь алгоритм.

О каких wait_timeout ВООБЩЕ ИДЕТ РЕЧЬ?

Все тоже самое я могу сделать и с Постгресом, ДБ2, Ораклом и т.д.

stellar
()
Ответ на: комментарий от Sorcerer

> Не знаю, о чем Вы говорили, а в данной теме говорится об использовании связки web-сервер со скриптовым языком + сервер БД. Сколько уникальных хостов в такой связке? Столько же, сколько web-серверов, то есть, обычно ровно 1. Если Вы в своих проектах даете пользователям php-скрипт и удаленный доступ к базе, то это уже другой разговор, к данной теме отношения не имеющий.

Суть дела станет более ясна для вас, если задумаетесь о максимальном времени жизни apache/php процессов. Также посмотрите типичное значение KeepAlive. Рекомендую также подумать почему запросы HTTP 1.0 к php/apache положат базу быстрее чем HTTP 1.1.

anonymous-III
()
Ответ на: комментарий от stellar

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

кто в вашем случае помечает соединение как свободное?

anonymous-III
()
Ответ на: комментарий от anonymous-III

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

>кто в вашем случае помечает соединение как свободное?

Я сам, после того, как закончу работу с базой для данного запроса пользователя.

stellar
()
Ответ на: комментарий от stellar

Представьте, что очередной запрос к базе отрабатывает другой процесс apache/php (после окончания KeepAlive например или при HTTP 1.0 запросе). Каким образом они могут использовать общий пул? С точки зрения базы - запрос с другого процесса php это запрос с другого клиента/хоста. База не может повторно использовать соединение, если не истекло время wait_timeout, и нету возможности определить, используется еще соединение или уже нет

anonymous-III
()
Ответ на: комментарий от anonymous-III

>нету в PHP такой возможности. только mysql_close который вызывает соответствующую MySQL C API функцию.

Причем тут PHP?!

Где, НУ ГДЕ сказано, что PHP - единственно возможный ЯП для веба? Вы, простите, читать не умеете, или специально игнорируете тот факт, что в тестах в том числе использовалась и Java?

stellar
()
Ответ на: комментарий от stellar

> Причем тут PHP?! Где, НУ ГДЕ сказано, что PHP - единственно возможный ЯП для веба? Вы, простите, читать не умеете, или специально игнорируете тот факт, что в тестах в том числе использовалась и Java?

мы вообще-то обсуждали разницу в быстродействии MySQL/PHP и PostgreSQL/PHP решений в данном тестировании (см. посты выше). Я написал, что время соединения postgreSQL и MySQL отличается на порядок. И это разница может довольно сильно влиять на конечную производительность скриптов интернет магазина.

anonymous-III
()
Ответ на: комментарий от anonymous-III

>Представьте, что очередной запрос к базе отрабатывает другой процесс apache/php (после окончания KeepAlive например или при HTTP 1.0 запросе). Каким образом они могут использовать общий пул? С точки зрения базы - запрос с другого процесса php это запрос с другого клиента/хоста. База не может повторно использовать соединение, если не истекло время wait_timeout, и нету возможности определить, используется еще соединение или уже нет

Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

Мы о чем ведем речь? О вебмагазине Васи Пупкина на шаред хостинге или о магазине, который должен обрабатывать *несколько*тысяч* клиентских заказов в секунду?

stellar
()
Ответ на: комментарий от stellar

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

anonymous-III
()
Ответ на: комментарий от stellar

> Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

а это потому что 90% процентов интернет магазинов сделаны на LAMP.

anonymous-III
()
Ответ на: комментарий от anonymous-III

>> Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

>а это потому что 90% процентов интернет магазинов сделаны на LAMP.

Вы жестоко ошибаетесь. Вебмагазины с 1000+ заказов в секунду никто на LAMP не пишет. Мы же рассматриваем именно высокопоизводительные решения.

stellar
()
Ответ на: комментарий от stellar

а кто говорит о магазинах с 1000+ заказов в секунду? Вы сами это придумали.

Я не в курсе как в СНГ/Европе, но среднестатистическому заказчику-американцу для своего личного интернет магазинчика хватает за глаза потолка в 5-10 запросов в секунду. Для них PHP/MySQL - самое то. Подавляющее большинство заказов - именно на такие проекты. Таких магазинов на несколько порядков больше чем тех, которые обрабатывают 1000+ в секунду.

anonymous-III
()
Ответ на: комментарий от anonymous-III

>а кто говорит о магазинах с 1000+ заказов в секунду? Вы сами это придумали. >Я не в курсе как в СНГ/Европе, но среднестатистическому заказчику-американцу для своего личного интернет магазинчика хватает за глаза потолка в 5-10 запросов в секунду. Для них PHP/MySQL - самое то. Подавляющее большинство заказов - именно на такие проекты. Таких магазинов на несколько порядков больше чем тех, которые обрабатывают 1000+ в секунду.

Какой же Вы сложный....

Я НИЧЕГО НЕ ПРИДУМАЛ

Прочтите, о чем предмет дискуссии. http://www.heise.de/ct/05/20/156/ http://firebird.sourceforge.net/connect/ct-dbContest.html

Если же мы обсуждаем вебмагазины, для которых не столь важно быстродействие, то причем тут вообще измерение скорости работы компонент? Если быстродействие неважно, значит, надо тестировать по другим факторам: надежности, функциональности, юзабилити...

Короче, определитесь для начала с предметом. Чесслово, достали подобные вихляния по теме.

stellar
()
Ответ на: комментарий от stellar

о чем предмет дискусии - потрудитесь прочитать еще раз мой пост выше:

> мы вообще-то обсуждали разницу в быстродействии MySQL/PHP и PostgreSQL/PHP решений в данном тестировании (см. посты выше). Я написал, что время соединения postgreSQL и MySQL отличается на порядок. И это разница может довольно сильно влиять на конечную производительность скриптов интернет магазина.

anonymous-III
()
Ответ на: комментарий от anonymous-III

> Суть дела станет более ясна для вас, если задумаетесь о максимальном времени жизни apache/php процессов.

Ну ладно. Значит, дело в реализации web-сервера? Дескрипторы соединений в общем случае никто не запрещает передавать между процессами. Как насчет Apache2?

Sorcerer ★★★★★
()
Ответ на: комментарий от anonymous-III

>MySQL/PHP и PostgreSQL/PHP

Просто хреново написаны интерфейсы к базам и все. Что тут еще обсуждать? СУБД не виновата в том, что у разработчиков PHP-extensions криво настроены руки....

stellar
()
Ответ на: комментарий от stellar

тут дело скорее не в интерфейсах. Дело в разной архитектуре баз. Я сомневаюсь, что PostgreSQL когда либо обгонит MySQL на этапе установки соединения. Пул соединений для PostgreSQL не сильно поможет, как ни помогает он в MySQL, а проблем добавляет изрядно. Достаточно вспомнить время, когда pconnect вообще нельзя было использовать нормально - он просто не отдавал соединения. У же не помню, при каких версиях PHP/MySQL был этот баг.

anonymous-III
()
Ответ на: комментарий от Sorcerer

> Ну ладно. Значит, дело в реализации web-сервера? Дескрипторы соединений в общем случае никто не запрещает передавать между процессами. Как насчет Apache2?

буду рад услышать от вас что изменилось в Apache 2.

anonymous-III
()
Ответ на: комментарий от ed

ходил. Полезное решение для некоторых ситуаций. Однако как видно на графике, при нагрузке до 60 параллельных соединений оно проигрывает обычному методу доступа к базе, а после этого - лишь незначительно опережает. Неясно кстати, будет ли вообще преимущество на реальных преложениях - т.е куча процессов php/apache работающих с разными хостами, каждый имеет свой connection к базе и т.д... Это проверяется только экспериментально.

anonymous-III
()
Ответ на: комментарий от anonymous-III

> буду рад услышать от вас что изменилось в Apache 2.

В 2.0 реализована работа с потоками, в 2.2 помимо этого появился DBD Framework (SQL Database API).

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

> В 2.0 реализована работа с потоками, в 2.2 помимо этого появился DBD Framework (SQL Database API).

Я не виже принципиальной разницы при работе с MySQL через PHP. Все равно будет создаваться одно соединение для каждой php/apache instance. Вот скажите, после исчерпания ожидания KeepAlive, Apache2/mod_php закроет соединение с базой сам или база так и будет ждать пока wait_timeout не истечет? Я не держу Apache 2 на серверах за ненадобностью, поэтому провериь самому затруднительно.

anonymous-III
()
Ответ на: комментарий от anonymous-III

Еще раз. Пойнт в том, что работая из под Java Server и используя модель обращений PHP/MySQL (Чистый JSP/Oracle)(т.е. новый коннект на каждый запрос, единственно нормально работающую по вашим же словам) мы естественно будем терять на подключениях к базе через JDBC. Поэтому такое сравнение не имеет смысла, так как ЛЮБОЕ приложение сложнее HelloWorld в J2EE использует connection pool.

anonymous
()
Ответ на: комментарий от anonymous

Можно долго спорить, что лучше - pg или mysql, но пока мне кто нибуде не объяснит откуда взялось вот это - я обратно на мускуль не перелезу.

select distinct stamp_inserted from iptraffic_2006_06 order by stamp_inserted;


+---------------------+
| 2006-06-22 00:00:00 |
| 2006-06-23 00:00:00 |
| 2006-06-24 00:00:00 |
| 2006-06-25 00:00:00 |
| 2006-06-26 00:00:00 |
| 2006-06-27 00:00:00 |
| 2006-06-28 00:00:00 |
| 2006-06-29 00:00:00 |
| 2006-06-30 00:00:00 |
| 5510-70-02 70:74:16 |
| 5667-69-43 03:93:60 |
| |442-99-81 00:43:52 |
| ┌*.+-0'-*' 39:01:55 |
| .(+-,(-,( 53:95:52 |
| L)-+-.+-(- 30:36:16 |
| └927-92-13 44:16:00 |
| g.//-/)-+( 96:30:08 |
+---------------------+

Да и к триггерам я привык...

anonymous
()
Ответ на: комментарий от anonymous-III

> Однако как видно на графике, при нагрузке до 60 параллельных соединений оно проигрывает обычному методу доступа к базе, а после этого - лишь незначительно опережает.

вы не поняли и сравнили не те графики: To simulate web applications I also ran another benchmark by just adding -C option to pgbench. This makes pgbench connect to pgpool or PostgreSQL everytime each transaction starts("without pgpool(no persistent connection)" and "with pgpool(no persistent connection)" in the above graph shows the result. The ability to cache the connection makes pgpool faster than ordinary PostgreSQL despite the replication overhead of pgpool.

Даже с учетом оверхеда от репликации выйгращ в 3 раза на одной транзакции с пятью запросами. На нашем магазинчике выйграш будет раз в десять.

> Неясно кстати, будет ли вообще преимущество на реальных преложениях - т.е куча процессов php/apache работающих с разными хостами, каждый имеет свой connection к базе и т.д...

вы еще раз не поняли php/apache работает только с одним хостом на котором стоит pgpool, никаких "долго живущих" соединенией на этом участке нет

ed ★★
()
Ответ на: комментарий от anonymous

> |442-99-81 00:43:52 | > | ┌*.+-0'-*' 39:01:55 | > | .(+-,(-,( 53:95:52 | > | L)-+-.+-(- 30:36:16 | > | └927-92-13 44:16:00 | > | g.//-/)-+( 96:30:08 |

дико смешно :) Раскажите как вы это сделали. У меня есть много друзей программистов, а к первому апрелю еще не придумал не одной шутки.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.