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

>Чушь какая то, вы читали посты выше? БЕЗ пула коннектов MySQL быстрее >PostgreSQL в десять раз если замерять время соединения.

Чушь - каждый раз коннектится к базе. Такую глупость мой мозг просто отказывает воспринимать.

> Не совсем так. Правильный ответ -- пока в mod_php не сделают по умолчанию пулл коннектов к PostgreSQL, большинство будет счиать что PostgreSQL не конкурирует по скорости обработки _простых_ запросов с MySQL.

пул коннектов не поможет или поможет не сильно: Как я уже говорил выше, использование постоянных соединений с БД в случае с MySQL лишь незначительно увеличивает производительность. Думаю в случаес PostgreSQL разница будет тоже не существенная.

> пул коннектов не поможет или поможет не сильно: Как я уже говорил выше, использование постоянных соединений с БД в случае с MySQL лишь незначительно увеличивает производительность. Думаю в случаес PostgreSQL разница будет тоже не существенная.

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

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

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

мне практика показала две миллисекунды прироста скорости при pconnect, а вам?

>И?

>Welcome to the MySQL monitor. Commands end with ; or \g.
>Your MySQL connection id is 354793 to server version: 5.0.15
>mysql> use test;
>Database changed
>mysql> CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = MYISAM ; >INSERT INTO `date` ( `date` ) VALUES ('0000-00-00');
>Query OK, 0 rows affected (0.27 sec)

>Query OK, 1 row affected (0.00 sec)

А вы вот так попробуйте:

mysql> SET sql_mode=TRADITIONAL;
Query OK, 0 rows affected (0.42 sec)

mysql> CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = MYISAM ;
Query OK, 0 rows affected (0.07 sec)

mysql> INSERT INTO `date` ( `date` ) VALUES ('0000-00-00');
ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'date' at row 1

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

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

CREATE USER name CONNECTION LIMIT N;

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

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

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

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

> Ещё один довод в пользу постгри.

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

http://dev.mysql.com/doc/refman/5.0/en/grant.html

см. MAX_USER_CONNECTIONS

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

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

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

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

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

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

> мне практика показала две миллисекунды прироста скорости при pconnect, а вам?

1000 Запросов SELECT NOW() с использованием пула и без: Direct: 5.463017 seconds Pooled: 0.296813 seconds

Исходник примера: http://www.pastebin.ru/4259

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

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

>Постгри наверно запустили ночью, когда пипл дрых, а не по магазинам лазил.
В онлайновых Интернет-магазинах нет понятия "ночь" :-)

>> if ($usePconnect == false) // Seems like PHP Does not closes it itself and returning cached version
>> pg_close($dbConnection);

Чё это вообще такое? Бенчмарк для функции pg_close?

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

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

Блин тут половине в школу по новой идти! Вопрос: насколько большой нужен пул коннектов, если время одного запроса составляет 0.1 сек, а скорость обработки запросов требуется 3000 в минуту? Ответ : 3000:60:10 = 5! Всего навсего! Тот же Оракл может с легкостью до 1000 коннектов держать, т.е мы можем спокойно достичь обработки в 600000 операций в минуту, допустив что скорость обработки не уменьшается с увеличением нагрузки на сервер, без открытия новых сессий!

Вот ваш коллега онанимус тоже утверждает, что 1000 операций за 0.3 секунды для постгреса - раз плюнуть.
http://www.linux.org.ru/jump-message.jsp?msgid=1555217#1556252
Так что победители обсуждаемого контеста с их жалкими 3000 операциями в минуту просто ничтожные ламеры по сравнению с вами. Только вот какое вообще отношение pg_pconnect (или mysql_pconnect) имеет к производительности _сервера_ баз данных?

>>1000 Запросов SELECT NOW() с использованием пула и без: Direct: 5.463017 seconds Pooled: 0.296813 seconds

Это прерасное подтверждение слов anonymous-III. Для постгрес разница между pconnect и connect - 5 мс минус неизвестное время на выполнение функции pg_close. Т.е. приемрно те же самые 2 мс, о которых говорил anonymous-III.

Ну, поскольку тестирование открытое, то где же исходные тексты реализованные киосков?

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

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

PS Мораль ;)
Когда видишь цифры типа "Direct: 5.463017 seconds Pooled: 0.296813 seconds" почему-то всегда хочется взять их отношение и сказать "Ого! Pooled в 15 раз быстрее Direct!" Однако это практически всегда неправильно. На самом деле нужно всегда смотреть не "во сколько...", а "на сколько...". В итоге получаем, что для 1000 запросов pconnect дает выигрыш всего в 5 секунд.

>Чё это вообще такое? Бенчмарк для функции pg_close?

>Это прерасное подтверждение слов anonymous-III. Для постгрес разница между pconnect и connect - 5 мс минус неизвестное время на выполнение функции pg_close. Т.е. приемрно те же самые 2 мс, о которых говорил anonymous-III.

Народ, неужели не ясно про pg_close? Когда мы не используем пул коннектов, то pg_close будет вызван автоматически для каждого соединения, как только отработает скрипт. Этот код учитывает это.

Здесь мы видим что на 1000 простых запросов к БД при неиспользовании пулов получается 5 секунд оверхеда. То есть если взять те 3000 opm MySQL-ля, то в этом случае из этой минуты 15 секунд уйдут только на создание новых соединений. И еще кстати не известно, находилась ли у них база на том же компе что application или нет (мой тест запускался на том же компе).

Далее. Как уже было сказано, PostgreSQL имеет по умолчанию очень либеральные настройки, и маленький объем буферов. Скорее всего данные запросов просто не влезали в них, и PostgreSQL начинала использовать временные файлы.

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

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

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

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

> Блин тут половине в школу по новой идти! Вопрос: насколько большой нужен пул коннектов, если время одного запроса составляет 0.1 сек, а скорость обработки запросов требуется 3000 в минуту? Ответ : 3000:60:10 = 5! Всего навсего! Тот же Оракл может с легкостью до 1000 коннектов держать, т.е мы можем спокойно достичь обработки в 600000 операций в минуту, допустив что скорость обработки не уменьшается с увеличением нагрузки на сервер, без открытия новых сессий!

в реальности все сложнее, увы. Вы учитываете ВРЕМЯ таймаута открытых соединений? При доступных 1000 одновременно открытых соединениях, каждое с таймаутом в неск часов (а у MySQL по дефолту wait_timeout именно такой и я нигде не встечал, чтобы кто-нибудь на западных хостигах менял это), этот лимит в 1000 соединений будет выбран в течении скольких минут при нагрузке хотя бы 1 новое соединение в секунду? Мало того, по дефолту у MySQL значение max_connections гораздо меньше 1000, так что пара сотен pconnect ложит сервер вполне надежно, это проверено. Мы не говорим о последних версиях MySQL, хостингов с которыми можно перечесть по пальцам одной руки. Почти везде еще MySQL 4.x а кое где и 3.23 вполне делает свою работу. У меня из 24 серверов, где я более менее часто появляюсь, только два под MySQL 5, все остальное в основном 4.0/4.1 и пару на 3.23.

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

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

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

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

> PS Мораль ;) Когда видишь цифры типа "Direct: 5.463017 seconds Pooled: 0.296813 seconds" почему-то всегда хочется взять их отношение и сказать "Ого! Pooled в 15 раз быстрее Direct!" Однако это практически всегда неправильно. На самом деле нужно всегда смотреть не "во сколько...", а "на сколько...". В итоге получаем, что для 1000 запросов pconnect дает выигрыш всего в 5 секунд.

да и причем получаем геморрой при переполнении пула этих соединений (в случае MySQL). Овчинка не стоит выделки, я отказался от использования pconnect на серверах (где нету возможности оттюнить параметры базы) еще года три назад. Кстати года три назад я еще использовал PostreSQL для некоторых проектов. Теперь - не вижу смысла. везде только MySQL а разных инкарнациях

>>Когда мы не используем пул коннектов, то pg_close будет вызван автоматически для каждого соединения, как только отработает скрипт. Этот код учитывает это.

Ты на код хотя бы смотрел? Там отсчет времени делается в скрипте, те до того как "pg_close будет вызван автоматически". Пока же я вижу только неумелые попытки автора скрипта подогнать действительное под желаемое (комментарий в тексте скрипта говорит о многом) с помощью дополнительного вызова pg_close.

>>Здесь мы видим что на 1000 простых запросов к БД при неиспользовании пулов получается 5 секунд оверхеда.

Еще никто не доказал что секунд оверхеда будет именно 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> Я изучаю EJB3 с JBoss4 и Postgres 8 под Fedora Core 5 kernel >> 2.6.17 Сделал простой тест на вставку записей в одну тавлицу >> одновременно с трех клиентов, каждый вызывает одноименный EJB3 >> Bean где и запускается цикл на вставку 100000 записей. Я получил >> результат 26 сек.

И учтите, что это с оверхедом в виде JNDI-lookup, сериализации/десериализации и т.п. накладных расходов.

Кстати, у меня на дефолтовой установке PG под винду, на 512 мб оперативы, и JBoss, запущенном под JBuilder, в секунду в БД ложились где-то 2000 записей.

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

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

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

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

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

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

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

Ну так и не кто не сомневался, что для подобной говно-задачи - интернет-магазин, где 90% транзакций - insert MySQL впереди планеты всей. Скока там? 3664 заказов в минуту ? А если б использовали dbf да еще и без индексов результат был раза в 2 больше.

>Ну так и не кто не сомневался, что для подобной говно-задачи - интернет-магазин, где 90% транзакций - insert MySQL

Так я писал об этом:

А тестировать СУБД на восьми (!!!) таблицах, с тринадцатью (!!!) связями между ними..... кхм..... .... простите, это серьезный проект или детская игрушка со свободного хостинга с поддержкой PHP?

http://firebird.sourceforge.net/connect/images/dvdshop2.gif

2stellar Ну, не заметил твоего поста.

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

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

>А если б использовали dbf да еще и без индексов результат был раза в 2 больше.

Твоя правда, брат.

> В мускул скажем впихиваешь не валидную дату в колонку с Date типом и получаешь 0000-00-00 - просто песня.

> не бубни урод.

> CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = MYISAM ; INSERT > INTO `date` ( `date` ) VALUES ('2006-13-38');

Комплекс неполноценности мучает ;-) За 500 буказоидов на сайты с использованием мускуля ваяешь ppy. Я просто на 100% уверен, что ты не пробовал импортировать данные в мускуль например из текстовых файлов, иначе сия фича тебя бы быстро вернула с небес на землю и ты бы не стал приводить в каКчестве сампла свой smart ;-) insert.

А если тебе совсем интересно, попробуй создать индекс на таблицу с более чем 16 колонками в нем и удивись ;-)

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

Я сделал еще один тест, те же 3 клиента, каждый вызывает EJB3 Bean 10000 раз в цикле, где и происходит вставка 10 записей. Время не засекал, но пошел покурить (3-5 мин), вернулся, тест закончился, 300000 записей в таблице