[html/js]Последовательное выполннение запросов

ark21

Ситуация - есть сервер, который обрабатывает n видов запросов(и при этом пишет что-то в cookie).
Все бы ничего, но если какой-нибудь сайт вставляет 2 или более запроса на страницу, то происходит следющее:
1) Первый запрос читает cookie в состоянии X
2) Воторой запрос читает cookie в состоянии X
3) Первый запрос присылает ответ и обновляет cookie до состояния Y = updated X
4) Второй запрос присылает ответ и обновляет cookie до состояния Z = updated X(а должно быть updated Y)
В итоге один из запросов не сохраняется в cookie - нежелательный эффект
Какие есть простые способы застваить браузер делать сначала 3) а потом 2)? Желательно не особо запарно для владельца сайта, вставлябщего эти запросы

klyv

мб, прежде, чем отправлять куку юзеру, похранить её на сервере и читать/писать во временную переменную?

ark21

Честно говоря не понял.
Для ясности - каждый запрос скорее всего обрабатывается другим инстансом сервера на другом боксе. Единственная возможность отослать куку - это в ответ на запрос. Но в связи с тем, что запрос несколько миллисекунд обрабатывается, сука-браузер успевает послать второй запрос.

ava3443

Ну так делайте так, чтобы не более 1 запроса на страницу было.

ark21

Это мера, на которую пойти невозможно

klyv

а, мб, вместо куков сессию использовать?

stm7884696

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

ark21

Запросы - это запрос баннера. На странице может быть несколько баннеров от одной и той же баннерной сети, информация о том, что клиен тпосмторел картинку необходима впоследствии, например, для того, чтобы посчитать, сколько продаж какой-нить хуйни принесла реклама.
Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходит

sergei1969

1) Первый запрос читает cookie в состоянии X
2) Воторой запрос читает cookie в состоянии X
3) Первый запрос присылает ответ и обновляет cookie до состояния Y = updated X
4) Второй запрос присылает ответ и обновляет cookie до состояния Z = updated X(а должно быть updated Y)
ну можно на чтоб сервер возвращая инфу по 2-му запросу добавлял туда и то, что надо от первого

rosali

На странице может быть несколько баннеров от одной и той же баннерной сети, информация о том, что клиен тпосмторел картинку необходима впоследствии, например, для того, чтобы посчитать, сколько продаж какой-нить хуйни принесла реклама.
Хранить в куках только uid пользователя. Все остальное хранить на сервере. Все так делают, разве нет?

stm7884696

Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходит
И правильно, что не подходит...
Кроме как править алгоритм банерообменной сетки ничего тебе посоветовать не могу....
Типа надо исправлять на серваке... или перестать пытаться наколоть банерообменную сетку, запихивая по 100 банеров на одну страницу, когда должон быть только один

ark21

на каком из 300 серверов мне хранить все что нужно о пользователе по его uid?

ark21

Почему много баннеров на одной странице это наебывание баннерной сети?
Я могу поправить алгоритм если есть идеи КАК это сделать. В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другой

ark21

Сервера разные в общем случае. я же говрил уже раньше

ava3443

В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другой
Насколько я понимаю, ровно один - грамотным использованием JavaScript.

stm7884696

ну в таком случае можно поставить на странице условие, что если подгрузился первый банер, то грузить следующий...
т.е. обработка событий onLoad...
Как вариант - если инклюдить банеры - то последней строкой слать код инклюда следующего банера с уже измененными куки в виде начального условия.
А на серваке сделать проверку, если в запросе явно прописаны переменные - работать с ними, а если нет - то из кукисов...
Хотя, конечно, идиот тот, кто придумал 300 серверов для сети использовать... надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...

ava3443

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

ark21

Ты зря так демаешь(насчет идиотима)
Чем ты собираешься обрабатывать миллиард заросов в день?

bleyman

А что тебе нужно хранить для пользователя? Количество показов? Храни на каждом сервере информацию по обращениям конкретно к этому серверу, а потом на отдельной машине собирай статистику со всех них.
Вообще удивительно, конечно, как люди пытаются поднять систему такого масштаба, не имея ни малейшего представления о том, как это следует делать. Некомпетентность жжот.
Скажика мне хотя бы один адрес, по которому крутятся твои баннеры. Я чую запах легкой наживы! =)

stm7884696

пост Fj доступно объяснил мое мнение по поводу идиотизма...
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...

ava3443

А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...
Почитай, как примерно гугл (сам поисковик) сделан - может изменишь мнение насчёт централизации.
А уж бабок у Google хватает: больше, наверное, только у Microsoft и, может быть, у Oracle.

ark21

Всем спасибо, все охуенно помогли

ark21

2FJ:
пример www.myspace.com
мб тебе это поможет.
То что ты предложил нихуя не работает. Информация нужна сразу а не через несоклько часов. Так что не надо тут поднимать вопрос о моей компетентности.
Был задан конкретный ворос - как это сделать средствами js/html.

ark21

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

ark21

И вообще, господа, хватит плз тупить. Из того, что я сказал ранее, по-моему любой ребенок может понять что вариант, предложенный неким FJ'ем не подходит ну никак.
Еще ни один человек не предложил другого подходящего хранилища данных, кроме кук(и я не думаю, что такое существует).Причины изложены выше.

rosali

Скажи мне, что все сервера гугла стоят в одном месте
"Централизация" это не значит что они стоят в одном месте... Если ты так этот термин понимаешь, то мне нечего добавить.

Dasar

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

rosali

миллиард заросов в день
Миллиард хитов в день не бывает, потому что это означает, что к вам зашел каждый человек имеющий интернет, и не раз. А вы не гугль все таки. Ну или кто-то типа fj вашу банерокрутилку на&*ывает
Нет я действительно не понимаю, в чем трудность поднять базу и хранить в ней сколько какому пользователю чего там показали, и обеспечить доступ к этой базе с каждой морды? Много данных не влезает в базу. Ну поднимите 10 баз. По uid-у база определяется каким-нибудь простеньким хешем. Короче проблема из пальца высосана, по-моему, ну правда это все уже и без меня поняли...

Dasar

централизованность - это палка о двух концах...
Лучше по максимуму стараться обойтись без жесткой централизации.

bleyman


Которая из них твоя?
Энивей, если в них всех хранится только юзерID, почему не запоминать его на сервере? И зачем он вообще нужен, если он изменяется после каждого захода?
ЗЫ: у меня была Мечта - чтобы ты хиты хранил в куках. Вот тогда бы я разгулялсо =)

ark21

Ты когда в инете серфишь только один баннер в день видишь?
Поясняю. Представь себе следующую ситуацию: приходит человек на сервер A и получает баннер. Он кликает на баннер и покупает то, что там предлагается купить(например). Сообщение о покупке приодит на сервер B. Как ты попытаешься обеспечить чтобы сервер B имел доступ к тому, что записал сервер A через минуту? При миллиарде хитов в день.
В данном случае централизованность никак помочь не может.
Разумеется другие данные статистики собираются в одном месте.

ark21

Считай что тебе не повезло. У myspace.com стоит тэг генератор(теги примерно из 10 сетей).

ark21

Что значит "меняй куки на стороне клиента а не сервера"? Не понял=(
Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.

ark21

Ниче, ты все еще можешь разгуляться.
Хинт: ходи по инету и ищи баннеры с yieldmanager.com
После этого в цикле: 1) трешь куки 2) f5 3) клик

rosali

Повторяю для высшего офицерского состава. Децентрализация (масштабируемость если угодно) достигается тем, что существует разделение юзеров по базам. Централизация состоит в том, что все веб-морды имеют доступ ко всем базам. Современные сетевые технологии вполне это позволяют даже при миллиарде хитов в день. Я не знаю, что ты называешь "сервером", для меня "сервер" это все что не клиент. Хранить данные на сервере = хранить их не на клиенте. Как можно хранить хиты в куках? А если я тебе пришлю куку, в которой будет сказано, что я видел [подставить нужное] банеров?

ark21

Если каждый сервер в твоем случае должен узнавать о каждом запросе в течении минуты, то все сервера(расположенные географически в разных частях света) должны только и делать, что обмениваться этой информацией(это равносильно тому, что каждый из серверов обслуживает 1 миллирад запросов в день, бредовая затея).
Я НЕ храню статистику в куках - я там храню информацию о том была ли показана кокретная картинка кокретному человеку. Смирись с тем, что больше эту информацию хранить негде.
Тут все прямо такие компетентные, я фигею дорогая редакция

ark21

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

ark21

+yorick

ark21

Предположим мы храним эту инфу в 10 разных базах.
Это значит, что количество запросов увеличится примерно в 1.5-2 раза(+редирект на нужный сервер). Кроме того это значит, что на каждую базу приходится 100 миллионов селектов и инсертов в день. Или 1157 в секунду(90% из них по сети). Смешно, да? Ежедневный прирост базы в этом случае составит 100 миллионов * 30 байт(uid, creative_id, date). 3 гига.
Если хранить свою базу на кадом отдельном сервере, то это будет значить: 1) увеличение времени отклика(причем нефиговое, если так случится что сразу много человек с одного сервера увидят баннер) 2) 100 метров - ежедневный прирост базы. 3) серверу пизда - баннеров нет 4) 40 инсертов и селектов ежесекундно.
Кто-нибудь все еще думает что это будет нормально работать? Куки и были сделаны для того, чтобы хранить такого рода информацию.
Никто не собирается хранить количество показов(и остальные подобные вещи, связанные с деньгами) в куках. Всем понятно что это бред. Но в данном случае, нам достаточно собирать статистику в RAM и раз в час скажем переносить ее в базу. А в базе аггрегировать. И никаких проблем с этим нет.

rosali

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

ark21

Почему с потолка? Это реальное число. Отступление по всем флангам нах?

Dasar

> Что значит "меняй куки на стороне клиента а не сервера"? Не понял=(
Куки можно читать и ставить, как на сервере, так и на клиенте через JS.
Если ты их меняешь на сервере - то у тебя появляется довольно большая задержка между чтением и записью куки, что и приводит к высокой вероятности того, что в эту задержку успеет вклиниться другой запрос, меняющий эту же куку.
Если же ты будешь менять куку через JS, то время между чтением и изменением - будет небольшим, что позволит резко уменьшить конфликты.
> Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Это только страшно звучит, на самом деле все просто.
Нам нужно при записи убедиться, что мы ничего лишнего не затерли, для этого можно, например, использовать подход ethernet.
для этого заводим две куки - одна будет блокировкой, другая - данные.
блокировка: 0 - не заблокирована, != 0 заблокирована.
если блокировка - незаблокирована, генерим случайное число, и пишем в блокировку.
выжидаем некоторое время, например, 100 мс, читаем блокировку - если там наше число, значит это мы заблокировали куку, если число другое - значит заблокировал кто-то другой (в этом случае - ждем когда данные разблокируются).
далее меняем данные, снимаем блокировку(пишем 0).
Дальше надо предусмотреть таймауты, после которых считать, что, например, процесс который установил блокировку - накрылся, и значит надо такую блокировку убирать.
Используя вот такой алгоритм - мы построили надежную, в условиях совместной записи, "файловую" систему поверх куков.
ps
правильнее, конечно, было написать: надежную систему хранения данных, а не "файловую" систему.

ark21

Первый вариант не подходит, так как кука зависит от выбранного баннера(процесс выбора нетривиален, происходит на сервере).
А за второй - спасибо.

rosali

Это реальное число
Реальное, значит замени число 10 на такое, которое подходит.

ark21

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

rosali

Ладно наконец то я понял что в куках хранится информация о том какой банер лучше показать а не о том сколько чего показано. Можно в куках.

stm7884696

Имхо единственный адекватный человек, отписавший в эту тему - .
У остальных только самомнение, какие-то знания и нелепые попытки применить эти знания там, где всего-то нужно посчитать и подумать
Ты бы на себя посмотрел.... первые постов 20 из тебя вытягивали инфу, что это для банеров надо...
Ты когда научишься правильно задачу ставить - тогда и приходи...
А то как же, взялся за проект, в котором сам не рубишь и еще и людей, которые тебе пытаются помочь основываясь на той скудной инфе, что ты предоставил обсираешь...
Если хочешь по нормальному - пиши кодом, что есть, что делаешь, какая ошибка возникает, и какие есть ограничения на исправления этой ошибки...
Умник нах..... руки бы поотрывал...

ark21

Ты заголовок читал? Там написано: html/js. Единственные 2 человека которые стали писать по теме - yorick и . А остальные стали учить меня писать сервер(который и так работает, да еще что-то там про некомпетентность и тд и тп).
Так что иди себе руки оторви

stm7884696

ну тут ты вообще неправ...
если внимательно почитаешь мой второй пост в твоей теме, то там как раз вариант на жабаскрипте описан... А то, что ты его не понял, или не принял - это все из-за того, что ты изначально неправильно задачу описал.
Как правильно - тебе уже сказали. Давай код, мы его отдебажим и перепишем, что бы все было ОК...
А так в теме можно что угодно писать, а потом говорить , что все дураки...
Тебе люди помочь хотят, и пишут ответы в меру того, как понимают вопрос.
А раз никто тебе нормально не ответил - значит проблема в постановке вопроса...

ark21

onload рассматривается как вариант
но его я знал до того как запостил вопрос сюда. он даже подходит более-менее
Мне ответили - darkGray

stm7884696

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

ark21

проблем никаких. тред можно закрывать

dedwowan

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

kruzer25

Не легче ли тогда использовать сессии?
Непонятно, почему они не подходят автору...

kruzer25

Чем плохи сорок инсертов/селектов в секунду?
Кстати, даже под винду хр есть такая замечательная вещь, которая из части оперативки делает раздел... и можно запланировать, как часто делать бэкап этого раздела на винчестер... вот тебе такая идея, раз сам не можешь придумать, что с базой делать

ark21

1) в варианте когда у каждого сервера своя база и свой набор клиентов и так дохуя недостатков. Они описаны на предыдущей странице. Приростбазы в этом варианте 100 метров в день - итого 3 гига за месяц, нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базе(а если рассматривать long-term, то еще больше)? инесрты хуй с ними, ты прав, можно раз в час скажем.

Dasar

> Чем плохи сорок инсертов/селектов в секунду?
это средняя нагрузка.
Пиковая нагрузка - точно может в 10-100-1000 раз быть больше.
Реляционные базы - очень не любят (тормозят на этом) всякие изменения данных.

kruzer25

инесрты хуй с ними
У тебя нет уникальных полей?
нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базе
Если я не ошибаюсь - во всех современных БД можно индексировать поля... и тогда 40 селектов в 3гиговой базе займут не сильно больше времени, чем в 3метровой...
Хотя, инсерт тогда будет занимать порядка столько же времени, сколько и селект - но навряд ли при не совсем уж гигантском их количестве это действительно окажет какое-то сильное влияние...

ark21

Сессии не подходят, так как они перерастут на самом деле в uid(так как сессии длятся бесконечное время а это уже много обсуждалось

ark21

в этом варианте есть уникальное поле - uid. машина не справится с такой нагрузкой - dark gray прав. Помимо селектов надо и другие вещи тоже делать, алгоритм выбора там, все такое. Это же пиздец что будет. 25 мс на запрос в среднем(а распараллеливать селекты и обработку это лишниий гемор и усложнение логики ненужное). Где хранить базу в long term? что делать если на какой-нибудь машине слетел винт - все машины бекапить раз в час?

kruzer25

в этом варианте есть уникальное поле - uid
То есть, количество инсертов всё-таки важно...
Если ты селекты тоже по уид делаешь - чем плоха индексация? Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)... а тогда - уже не очень заметно, 3 гига там или гораздо меньше...

Dasar

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

kruzer25

Чем больше индексируемых полей, или чем больше строк?

Dasar

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

kruzer25

Поле вроде планируется только одно - уид?

ark21

по-моему разговор ни о чем
зачем все это нужно если есть куки? + в промышленном масштабе это не может работать стабильно

kruzer25

В любом случае, когда у клиента плохой коннект: у него может сразу грузится две твоих страницы, и обоим придут одни и те же куки... и сохранится в его куки - только одно из этих двух посещений...
Оставить комментарий
Имя или ник:
Комментарий: