Comments 24
> Возможно если бы мы использовали True FastCGI, то у нас бы не было это проблемы, но php стал готов к этому всего несколько месяцев назад, а проблема существует уже около 6 лет.
Да, хотя бы потому что в phpDaemon есть свой независимый драйвер постгреса, написанный прямыми руками :-) Никаких левых запросов там не делается.
Да, хотя бы потому что в phpDaemon есть свой независимый драйвер постгреса, написанный прямыми руками :-) Никаких левых запросов там не делается.
PostgreSQLClient в phpDaemon несколько урезанный, например там не поддерживается биндинг переменных. Меньше функционала — меньше глюков :)
Вы правы. Спасибо что обратили на это внимание. Спецификация протокола реализована полностью. Всё поддерживается, но не всё вынесено в отдельные методы. Если кому-нибудь понадобится биндинг, надеюсь напишут с чем его подают в PHP, я никогда не использовал.
Его подают с PDO, например.
Без биндинга сразу же возникает куча проблем c SQL injects, поэтому как можно жить без него — вообще не представляю. Workarounds типа mysql_real_escape_string на каждый чих иначе, как извращенством, не назовешь…
Да и вообще, это же так удобно — скормить переменную запросу, будучи точно уверенным в том, что она всегда останентся «просто данными» и никогда не будет перемешана с самим запросом!
Без биндинга сразу же возникает куча проблем c SQL injects, поэтому как можно жить без него — вообще не представляю. Workarounds типа mysql_real_escape_string на каждый чих иначе, как извращенством, не назовешь…
Да и вообще, это же так удобно — скормить переменную запросу, будучи точно уверенным в том, что она всегда останентся «просто данными» и никогда не будет перемешана с самим запросом!
Используйте джангу)
UFO just landed and posted this here
занятная багофича :)
насколько я помню, из пхп убрали отдельные библиотеки драйверов мускуля и постгри, заменили их пдошными, а пдо встроили в «ядро»
насколько я помню, из пхп убрали отдельные библиотеки драйверов мускуля и постгри, заменили их пдошными, а пдо встроили в «ядро»
А еще у кодеров принято делать запросы SELECT… LIKE '%something%'. Особенно замечательно это работает в MySQL при, скажем, 10 миллионах строк, когда вырастает база. Такие конструкции не задействуют индексы.
Даже если в WHERE стоит ограничение по ключевым полям?
Но в главном вы правы — неразумное увлечение разными вкусными фенечками в запросах может дать весьма неприятный побочный результат в виде приличных тормозов.
Но в главном вы правы — неразумное увлечение разными вкусными фенечками в запросах может дать весьма неприятный побочный результат в виде приличных тормозов.
Верно. А вот запрос вида SELECT… LIKE 'something%' уже будет работать с индексами.
Мне для одного из проприетарных продуктов пришлось использовать mysql-proxy и скрипт к нему на lua, чтобы реврайтить запросы, поскольку «чудо индийской школы программирования» умирало уже на 10.000 строках в базе, с прокси же удалось выжать все соки из БД, хотя и немного пожертвовав скоростью обработки.
Мне для одного из проприетарных продуктов пришлось использовать mysql-proxy и скрипт к нему на lua, чтобы реврайтить запросы, поскольку «чудо индийской школы программирования» умирало уже на 10.000 строках в базе, с прокси же удалось выжать все соки из БД, хотя и немного пожертвовав скоростью обработки.
Время начала всплеска аномально высокого трафика подозрительно точно совпадало с временем выкладывания одного крупного релиза, что и навело на мысль о том что мы DDOS`им себя сами.Вы себя DoS'или, а не DDoS'или.
Теперь знаю как тестировать PostgreSQL на нагрузку :)
Ух, и все-таки с утра немного тяжело воспринимать DOS как DoS… а то прочитав заголовок задумался о том, как можно из-под DOS-а атаковать сервер баз данных одной строчкой… сразу в голове мысль о
но это не одна строчка…
Но, возможно, это просто утреннее занудство от недосыпа :)
:while
echo "...some..sql" > mysql
goto while
но это не одна строчка…
Но, возможно, это просто утреннее занудство от недосыпа :)
Кстати говоря, с PDO есть такая проблема, что в нем пара prepare()+execute() вызывает 2 запроса к PostgreSQL-базе (первый — PREPARE, второй, соответственно, EXECUTE). Это означает и удвоение времени на мелких запросах (двойной пинг), и «подвисшие в воздухе» PREPARE в случае, если почему-либо до execute() дело не дошло, а соединение не успело открыться. Кроме того, опять же для PostgreSQL, PDO-шная пара prepare()+execute() убивает оптимизацию запроса на основе значений параметров (план запроса строится на этапе PREPARE, когда о реальных значениях параметров еще ничего не известно), так что ее еще и поэтому не стоит применять.
Так что для PostgreSQL единственный путь — это руками заменять placeholder-ы на заквоченные значения и посылать запрос в один прием. В этом отношении, получается, PDO теряет всю свою привлекательность по сравнению с pg_* функциями.
Так что для PostgreSQL единственный путь — это руками заменять placeholder-ы на заквоченные значения и посылать запрос в один прием. В этом отношении, получается, PDO теряет всю свою привлекательность по сравнению с pg_* функциями.
Sign up to leave a comment.
Как устроить DoS атаку на сервер баз данных одной строчкой