Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokНакладные расходы на connection не велики, про крайне мере для Oracle и MsSQL.Вы ошибаетесь. Можете сказать лишь следующее: "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL". Наш сервер работал на оракле и постгресе. Для обоих субд использовали persistent connections (через mod_perl), так как это давало большое увеличение производительности. Недавно я писал об этом . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 10:00 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Господа программисты, я не в коем случае не хочу утверждать что долговисящщие транзакции - это хорошо. Долго висящая транзакция у вас ассоциируется с долго висящей блокировкой (блокировка - это действительно ресурс). Но, однако, заметьте, точто я здесь предлагал - все совсем наоборот. Не ставте все с ног на голову. Несмотря на то, что, транзакция довольно продолжительная, блокировка - быстрая и безболезненная т.к. осуществляется лишь на очень короткий промежуток времени. И, честно говоря то, реализовать такое только средствами СУБД практически невозможно. Есть такая штука как SEQUENCE, или IDENTITY. Все знают что для ускорения выдачи этих значений они как-бы генерятся предварительно. Поэтому при сбое возникает identity gap, или разрыв в sequence. А ведь можно реализовать собственную версию sequence, которая этим не страдает. Опять же, без низкоуровнего программирования тут не обойтись. А скажите мне разве невозможно в случае зависания сессии, сначала считать ее незакомиченные данные, а затем сбросить зависшую сессию и продолжить ее работу? Возможно многое. И, как правило, такие прямолинейные действия на самом деле более работоспособны. Часто бывает так, что программист находит какой-то инструмент, изучает его и старается приспособить ко всему. Типа - мартышка и очки. Нельзя зацикливаться. Бог любит разнообразие. Короче - смотрите чуть шире. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:08 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
3 раза прочитал но чесно говоря совсем не вьехал, как транзакция в блокировочнике (db2 как я понимаю) длинная а блокировки быстрые, какие-то зависания у сессий - это сессия веб приложения имеется ввиду или сессия субд и что такое "зависание" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:33 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Я тоже первый раз прочитал - ничего не понял. Хотел второй было читать - но увидел, что Yo! и с 3-го не понял, то и я не стал читать больше. С ходу - каша какая-то, смешались в кучу люди, кони.... По коннектам: к MS SQL из asp.net можно через пул коннектов ходить, удобно однако. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 14:41 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Леха Налоговый Я не ошибаюсь (я так думаю, вообще-то), однако, они _дейсвительно_ не велики. Хотя и зависят от многих факторов, в частности оракл и cgi на одном сервере или нет. Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл. Хотя, полностью согласен, что использовнание долгоиграющей connection может увеличить производительность. Это с одной стороны, с другой увеличивается вероятность блокировки. Представте себе ситуацию, когда куча пользователей одновременно что-то делают - а результаты их работы постоянно суммируются и отображаются в одном месте (строчке в таблице). Тоесть каждый пытается менять эту строчку. Все процессы выстраиваются в очередь. Минимизация времени connection в этом случае спасает - отработал, отвались. 2 Садовник Таки тоже не понятно. Кады transaction началася, она по ходу дела выставляет блокировки. И блокировки будут сняты только в момент окончания транзакции. Сделать блокировку маленькой (по времени) - значит сделать маленькой саму transaction. Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 00:38 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторПредставте себе ситуацию, когда куча пользователей одновременно что-то делают - а результаты их работы постоянно суммируются и отображаются в одном месте (строчке в таблице). Тоесть каждый пытается менять эту строчку. Все процессы выстраиваются в очередь. Минимизация времени connection в этом случае спасает - отработал, отвались зачем "отработал, отвались" ? отработал - закоммить транзакцию и дыши спокойно. Какие в ж..у блокировки после завершения транзакции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 01:17 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Отвались, потому что connection другим понадобиться может. Ресурс, таки. У а commit али rollback само собой разумеется, кудыж без него... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 05:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2andrushok почитайте все таки про connection pooling, отваливается веб клиент конекция остается просто отдается следующему веб клиенту. прерывая конекцию вы ничего не выйграете, только проиграете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 10:03 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushok2 Садовник Таки тоже не понятно. Кады transaction началася, она по ходу дела выставляет блокировки. И блокировки будут сняты только в момент окончания транзакции. Сделать блокировку маленькой (по времени) - значит сделать маленькой саму transaction. Или я не прав? Абсолютно правы. А теперь с другой стороны - блокировка ставится для того, чтобы всех клиентов построить в очередь к ресурсу. Я в своем варианте слегка "расширил" возможности этого подхода позволив клиенту считывать незакомиченные, но согласованные данные построив их в очередь перед семафором. Поэтому "лишний" билетик продать невозможно. А сам ресурс (запись с количеством доступных билетов) блокируется и освобождается стандартным способом. Т.е. каждый сеанс видит количество проданных и количество "заблокированных" билетов в реальном времени. 2 Alexey Sh andrushok - прав. запуск процесса - дорогое удовольствие. Поэтому в системах и используют сервера приложений, которые держат очередь запросов на транзакции от клиентов и пропускают эту очередь через пул соединений. Выигрыш может составить 200-300%. А может и больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 10:20 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
авторАбсолютно правы. А теперь с другой стороны - блокировка ставится для того, чтобы всех клиентов построить в очередь к ресурсу . Я в своем варианте слегка "расширил" возможности этого подхода позволив клиенту считывать незакомиченные , но согласованные данные построив их в очередь перед семафором. Поэтому "лишний" билетик продать невозможно. А сам ресурс (запись с количеством доступных билетов) блокируется и освобождается стандартным способом. Т.е. каждый сеанс видит количество проданных и количество "заблокированных" билетов в реальном времени. Я так и не понял, зачем вы транзакцией блокируете данные и потом из-за этого используете грязное чтение? Этого я не пойму!!! У вас есть таблица с билетами, на которые идет оформление (если я правильно понял), зачем вам ее блокировать а потом грязно читать? Не пойму я - зачем тут блокировки на уровне транзакций? Вы что, в эту таблицу и так не можете посмотреть, чего там у вас? И кстати, зачем выстраивать в очередь клиентов? Они сами выстроятся - когда количество менять будете в проданных и заблокированных. Мдааааа. Вы все-же словами - не надо скриптов - еще раз пояснили бы алгоритм. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:27 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
типа... последний раз попытаюсь объяснить что я имею в виду. Оракл: Запись с количеством билетов обновлена, но коммит еще не сделан. Никто не видит реального количества билетов. Всем доступно только предыдущее значение. Поэтому сказать точно сколько билетов еще можно продать - никто не может. (грязное чтение отсутствует как класс) Т.е. можно так выразиться (перефразировать) невозможно работать в реальном времени. Все клиенты вынуждены вставать в очередь и ждать когда можно будет заблокировать запись и получить актуальное количество доступных билетов. DB2: (режим - грязное чтение) видно - что запись обновлена, видно сколько в билетов на данный момент другие намериваются продать (типа зарезирвировано). Но, однако чтобы получить эти данные, и быть уверенным что пока я их читаю и резервирую некоторое количество билетов, никто их не поменял, перед считываением выставляется семафор, резервируется некоторое количество билетов (добавляется запись в таблицу Locks), затем семафор освобождается. Я начал транзакцию, но горячий ресурс с количеством свободных билетов - не заблокировал. Теперь я могу в любой момент закончить транзакцию, гарантируя что зарезервированные мной билеты имеются, и транзакция завершится удачно. (т.е. очередь к горячему ресурсу отсутствует) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:52 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
т.е. я хочу сказать что при таком подходе ситуация в которую попал многоуважаемый hell (пока оформляли билет - оказалось что билетов нет(стихами заговорил))- невозможна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:56 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanтипа... последний раз попытаюсь объяснить что я имею в виду. Оракл: Запись с количеством билетов обновлена, но коммит еще не сделан. Никто не видит реального количества билетов. Всем доступно только предыдущее значение. Поэтому сказать точно сколько билетов еще можно продать - никто не может. (грязное чтение отсутствует как класс) Т.е. можно так выразиться (перефразировать) невозможно работать в реальном времени. Все клиенты вынуждены вставать в очередь и ждать когда можно будет заблокировать запись и получить актуальное количество доступных билетов. DB2: (режим - грязное чтение) видно - что запись обновлена, видно сколько в билетов на данный момент другие намериваются продать (типа зарезирвировано). Но, однако чтобы получить эти данные, и быть уверенным что пока я их читаю и резервирую некоторое количество билетов, никто их не поменял, перед считываением выставляется семафор, резервируется некоторое количество билетов (добавляется запись в таблицу Locks), затем семафор освобождается. Я начал транзакцию, но горячий ресурс с количеством свободных билетов - не заблокировал. Теперь я могу в любой момент закончить транзакцию, гарантируя что зарезервированные мной билеты имеются, и транзакция завершится удачно. (т.е. очередь к горячему ресурсу отсутствует) Если Вы намереваетесь использовать понятие резервирования, то отразите его в структуре данных. Вы пытаетесь внушить нам, что механизм транзакций сервера надо использовать для моделирования понятий предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:58 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Dogen Если вы подразумеваете, что резервирование - это синоним бронирования, или эээ. предварительной продажи, то - ОК! Назовем это не резервированием, а назовем это - блокированием на время проведения транзакции. Впрочем термин можете подобрать сами. Это не изменит сути процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2gardenman опять читал 3 раза :) вы предлагаете при бронировании запускать на пару недель транзакцию с блокировкой ? я правильно понял ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:27 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Yo!2gardenman опять читал 3 раза :) вы предлагаете при бронировании запускать на пару недель транзакцию с блокировкой ? я правильно понял ? Я больше объяснять не буду. Я лучше жестами покажу @#$!@#$ ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:32 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman2 Dogen Если вы подразумеваете, что резервирование - это синоним бронирования, или эээ. предварительной продажи, то - ОК! Назовем это не резервированием, а назовем это - блокированием на время проведения транзакции. Впрочем термин можете подобрать сами. Это не изменит сути процесса. нет-нет я имею в виду отметку о том что место занято - в момент начала оформления билета это укладывается в бизнес-процесс выписки - застолбил место и давай вводить паспортные данные бронирование - это отметка о том что на это место имеется бронь бронь снимают за сутки и за 4 часа до поезда (может и за час, не знаю). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 12:34 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну наконец-то я получил тот ответ, который ожидал. Присоединяюсь к остальным: вы пытаетесь методами сервера БД решить задачу, которая должна решаться методами архитектуры системы, причем решаете извращенно как оееееей. По-русски вам объясняю решение: Пишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. Если вы это до сих пор понять не можете, то вашему работодателю нужно вас гнать в шею - извините уж, но это так и есть. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 13:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
tygraНу наконец-то я получил тот ответ, который ожидал. Присоединяюсь к остальным: вы пытаетесь методами сервера БД решить задачу, которая должна решаться методами архитектуры системы, причем решаете извращенно как оееееей. По-русски вам объясняю решение: Пишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного. Если вы это до сих пор понять не можете, то вашему работодателю нужно вас гнать в шею - извините уж, но это так и есть. -- Tygra's -- И это еще что. Как только появится касса, общающаяся с головной БД методами оффлайновой репликации (ну раз в полчаса, например), начнется кино - транзакции не помогают, ой-ой-ой. В МПС это, как я догадываюсь, решали путем раздачи квот на места в конкретном поезде. Но мы же про крутую современную систему говарим :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 13:14 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 andrushok andrushok LeXa NalBat andrushokНакладные расходы на connection не велики, про крайне мере для Oracle и MsSQL.Вы ошибаетесь. Можете сказать лишь следующее: "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL".Я не ошибаюсь (я так думаю, вообще-то), однако, они _дейсвительно_ не велики. Хотя и зависят от многих факторов, в частности оракл и cgi на одном сервере или нет. Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл. Хотя, полностью согласен, что использовнание долгоиграющей connection может увеличить производительность."Они _дейсвительно_ не велики." Я привел вам ссылку на результат моего теста: время коннекта в 0.019 сек не велико по сравнению со временем выборки в 0.0035 сек? "Я таки про cgi толкую, на не про весь спектр задач, включаюших оракл." Из вашего категоричного утверждения "накладные расходы на connection не велики, про крайне мере для Oracle и MsSQL" непонятно, что вы толкуете исключительно про cgi. :) Даже если это так, то все равно вы не правы, потому что на все задачи веб-программирования ваше утверждение распространить нельзя. Сейчас наш веб-сервер отдает страницу объемом 20-60 Кб, содержащую 5-20 строк из БД, за 0.1-0.3 сек. Если бы мы не использовали persistent connectios, то на показ каждой страницы тратилось бы еще время для подключения к БД, равное 0.02 сек. То есть благодаря постоянным подключениям мы имеем выигрыш в производительности в 7-20%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 19:46 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Уважаемый Леха Налоговый, Мы с Вами об одном и том же толкуем. Вот тольки по разному. 0.019 сек - это много? Помойму нет. То, что мой cgi за время своей жисти переконектится 2-3 раза - проблем не вижу никаких. Пусть даже 10 раз, фигня это все - 0.2 сек. Зато даст возможность другим cgiям жить спокойно. А то, что всяки там выборки идут за 0.0 ... 001 сек, мне как-то фиолетово, все равно потеря впемени на траффике все съедает. Cgi, если их конечно правильно писать, долго жить не должны. Хотя, бывают, конечно исключения. Всяки там отложенные запросы. Такой cgi может и час пахать (на самом деле не cgi а кака-нить апликуха, а другие cgiи тольки ее статус проверяють, пашат она еще, или закончилась уже). Ну дык, это совсем другой случай. По сему этому, Ваши попытки, доказать, что я не прав, странны однако. Опять таки я про _cgi_ говорю, а не про все веб-приложения. На виндах cgi то не очень хорошо чуйствует. Там надоть какий-то DLL (точнее их расширения, не помню). Вот они и живут в памяти, и с IIS общаются как-то. Вот там подход может быть совсем другой. А к словам цепляться, нехорошо. Негигиенично... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 22:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushok0.019 сек - это много? Помойму нет.Так ставить вопрос нельзя. Много по сравнению с чем? Много в какой ситуации, для какой задачи? Два кило яблок - это много? Сожрать в одно рыло - да, закрыть на зиму компотов - нет. И отвечать надо не так, а как я вас уже учил :) "Помойму для задач, с которыми я сталкивался, нет." andrushokТо, что мой cgi за время своей жисти переконектится 2-3 раза - проблем не вижу никаких. Пусть даже 10 раз, фигня это все - 0.2 сек.Если мой скрипт переконнекчивался бы 10 раз за время своего выполнения, то количество серверов нам пришлось бы удваивать. :) Для моего начальства - это бабки, а не фигня. :) andrushokпотеря впемени на траффике все съедает.Съедает что? Память, процессорное время? Если клиент (веб-броузер) задерживает апачевского ребенка, медленно читая данные, то при этом апачевский ребенок будет спать, то есть занимать память, но не процессорное время. andrushokПо сему этому, Ваши попытки, доказать, что я не прав, странны однако.Я сказал, что вместо неверного утверждения "накладные расходы на connection не велики, про крайне мере для Oracle и MsSQL", вы можете сказать лишь "накладные расходы на connection не велики, про крайне мере для задач, с которыми я сталкивался на Oracle и MsSQL". Я не нахожу такое уточнение странным хотя бы потому, что лично у меня есть подтверждающий его пример. andrushokОпять таки я про _cgi_ говорю, а не про все веб-приложения.Я полагал, что "cgi-программирование" и "веб-пограммирование" - одно и то же. Объясните пожалуйста разницу. andrushokА к словам цепляться, нехорошо. Негигиенично...О цеплянии к словам vs точности формулировок я как-то рассказал анекдот. :) P.S.: К налоговому ведомству отношения не имею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 19:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 Леха Ватный (если Налоговый не нравится - извините) Я так думаю, разговор заходит в тупик - для Вас 0.019 сек много, для меня нет. Спорить тут уже бессмысленно. Вы можете дать пример Вашего web, где сие критично? Я могу - сюды пожалста . Кстати - для ликбеза - сие произведение программиского искуйства (я не скромен, а?) в основном наваено на ColdFusion - что к CGI технологии не имеет никакого отношения. Хотя cgiи там все-же есть, их время от времени и жаба дергает, и на прямую из HTML и JavaScript для некоторых целей вызывают. Но их там мало, да и чужеродны они там. Я думаю - это web приложение. И _почти_ без CGI. Если постораться, можно найти и _совсем_ без CGI. Ну если Вам так угодно, я могу согласиться, что только, с теми, к какими я сталкивался. Мир велик, и я за все программы не в ответе. Ну шо, мир, или бум дальше пиписками мериться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 20:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
andrushokВы можете дать пример Вашего web, где сие критично?price.ru andrushokНу если Вам так угодно, я могу согласиться, что только, с теми, к какими я сталкивался.Иейс! (Как сказал бы мальчик, который "один дома".) Теперь с этим вашим утверждением смог бы поспорить только программист, столкнувшийся с тем же проектом что и вы, и обнарувший, что в этом проекте "расходы на connection не малы по сравнению с другими расходами". :) andrushokНу шо, мир, или бум дальше пиписками мериться?Не будем уподобляться Беклемишеву. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 20:54 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну шо, посмотрел я Вашу price. Так, шустро работает. Правда, HTML простой, как сибирский валенок. Ни те фреймов, ни DHTML, ни JavaScript, ни какой жабы конечно (может иде есть, везде не лазил). Конечно, еще с Macа интерестно залесть, как оно там под Camino например пашет, или (упоси Господь) под маковский IE. Вот тольки вопросик, а чой то за скриты таки хитрые либо без расширения, либо с html (?) расширением Код: plaintext 1. 2. Интерестна, а? Кстати, а Вы согластны, что есть некоторые приложения, иде время connection особой роли не играет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 22:51 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32886651&tid=1546074]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 404ms |
| 0 / 0 |
