[html/js]Последовательное выполннение запросов
мб, прежде, чем отправлять куку юзеру, похранить её на сервере и читать/писать во временную переменную?
Для ясности - каждый запрос скорее всего обрабатывается другим инстансом сервера на другом боксе. Единственная возможность отослать куку - это в ответ на запрос. Но в связи с тем, что запрос несколько миллисекунд обрабатывается, сука-браузер успевает послать второй запрос.
Ну так делайте так, чтобы не более 1 запроса на страницу было.
Это мера, на которую пойти невозможно
а, мб, вместо куков сессию использовать?
если есть - правь их, что бы куки брались не в самом начале, а для каждого запроса отдельно...
Если нет доступа- то делай авторедирект после каждого запроса автоматом... типа что бы пользователь ниче не нажимал.... или один запрос на страницу...
А вообще - это надо же еще было додуматься до такой херни то....
Где это ? и что за запросы?
Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходит
1) Первый запрос читает cookie в состоянии Xну можно на чтоб сервер возвращая инфу по 2-му запросу добавлял туда и то, что надо от первого
2) Воторой запрос читает cookie в состоянии X
3) Первый запрос присылает ответ и обновляет cookie до состояния Y = updated X
4) Второй запрос присылает ответ и обновляет cookie до состояния Z = updated X(а должно быть updated Y)
На странице может быть несколько баннеров от одной и той же баннерной сети, информация о том, что клиен тпосмторел картинку необходима впоследствии, например, для того, чтобы посчитать, сколько продаж какой-нить хуйни принесла реклама.Хранить в куках только uid пользователя. Все остальное хранить на сервере. Все так делают, разве нет?

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

на каком из 300 серверов мне хранить все что нужно о пользователе по его uid?
Я могу поправить алгоритм если есть идеи КАК это сделать. В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другой
Сервера разные в общем случае. я же говрил уже раньше
В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другойНасколько я понимаю, ровно один - грамотным использованием JavaScript.
т.е. обработка событий onLoad...
Как вариант - если инклюдить банеры - то последней строкой слать код инклюда следующего банера с уже измененными куки в виде начального условия.
А на серваке сделать проверку, если в запросе явно прописаны переменные - работать с ними, а если нет - то из кукисов...
Хотя, конечно, идиот тот, кто придумал 300 серверов для сети использовать... надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...
надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...Централизация нехило бабла обычно требует
Чем ты собираешься обрабатывать миллиард заросов в день?
Вообще удивительно, конечно, как люди пытаются поднять систему такого масштаба, не имея ни малейшего представления о том, как это следует делать. Некомпетентность жжот.
Скажика мне хотя бы один адрес, по которому крутятся твои баннеры. Я чую запах легкой наживы! =)
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...Почитай, как примерно гугл (сам поисковик) сделан - может изменишь мнение насчёт централизации.
А уж бабок у Google хватает: больше, наверное, только у Microsoft и, может быть, у Oracle.
Всем спасибо, все охуенно помогли
пример www.myspace.com
мб тебе это поможет.
То что ты предложил нихуя не работает. Информация нужна сразу а не через несоклько часов. Так что не надо тут поднимать вопрос о моей компетентности.
Был задан конкретный ворос - как это сделать средствами js/html.
Пост FJ нихуя не подтвердил. Скажи мне, что все сервера гугла стоят в одном месте, давай
Еще ни один человек не предложил другого подходящего хранилища данных, кроме кук(и я не думаю, что такое существует).Причины изложены выше.
Скажи мне, что все сервера гугла стоят в одном месте"Централизация" это не значит что они стоят в одном месте... Если ты так этот термин понимаешь, то мне нечего добавить.

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

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

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

Которая из них твоя?
Энивей, если в них всех хранится только юзерID, почему не запоминать его на сервере? И зачем он вообще нужен, если он изменяется после каждого захода?
ЗЫ: у меня была Мечта - чтобы ты хиты хранил в куках. Вот тогда бы я разгулялсо =)
Поясняю. Представь себе следующую ситуацию: приходит человек на сервер A и получает баннер. Он кликает на баннер и покупает то, что там предлагается купить(например). Сообщение о покупке приодит на сервер B. Как ты попытаешься обеспечить чтобы сервер B имел доступ к тому, что записал сервер A через минуту? При миллиарде хитов в день.
В данном случае централизованность никак помочь не может.
Разумеется другие данные статистики собираются в одном месте.
Считай что тебе не повезло. У myspace.com стоит тэг генератор(теги примерно из 10 сетей).
Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Хинт: ходи по инету и ищи баннеры с yieldmanager.com
После этого в цикле: 1) трешь куки 2) f5 3) клик
Повторяю для высшего офицерского состава. Децентрализация (масштабируемость если угодно) достигается тем, что существует разделение юзеров по базам. Централизация состоит в том, что все веб-морды имеют доступ ко всем базам. Современные сетевые технологии вполне это позволяют даже при миллиарде хитов в день. Я не знаю, что ты называешь "сервером", для меня "сервер" это все что не клиент. Хранить данные на сервере = хранить их не на клиенте. Как можно хранить хиты в куках? А если я тебе пришлю куку, в которой будет сказано, что я видел [подставить нужное] банеров?
Я НЕ храню статистику в куках - я там храню информацию о том была ли показана кокретная картинка кокретному человеку. Смирись с тем, что больше эту информацию хранить негде.
Тут все прямо такие компетентные, я фигею дорогая редакция
У остальных только самомнение, какие-то знания и нелепые попытки применить эти знания там, где всего-то нужно посчитать и подумать
+yorick
Это значит, что количество запросов увеличится примерно в 1.5-2 раза(+редирект на нужный сервер). Кроме того это значит, что на каждую базу приходится 100 миллионов селектов и инсертов в день. Или 1157 в секунду(90% из них по сети). Смешно, да? Ежедневный прирост базы в этом случае составит 100 миллионов * 30 байт(uid, creative_id, date). 3 гига.
Если хранить свою базу на кадом отдельном сервере, то это будет значить: 1) увеличение времени отклика(причем нефиговое, если так случится что сразу много человек с одного сервера увидят баннер) 2) 100 метров - ежедневный прирост базы. 3) серверу пизда - баннеров нет 4) 40 инсертов и селектов ежесекундно.
Кто-нибудь все еще думает что это будет нормально работать? Куки и были сделаны для того, чтобы хранить такого рода информацию.
Никто не собирается хранить количество показов(и остальные подобные вещи, связанные с деньгами) в куках. Всем понятно что это бред. Но в данном случае, нам достаточно собирать статистику в RAM и раз в час скажем переносить ее в базу. А в базе аггрегировать. И никаких проблем с этим нет.

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


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

1) в варианте когда у каждого сервера своя база и свой набор клиентов и так дохуя недостатков. Они описаны на предыдущей странице. Приростбазы в этом варианте 100 метров в день - итого 3 гига за месяц, нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базе(а если рассматривать long-term, то еще больше)? инесрты хуй с ними, ты прав, можно раз в час скажем.
это средняя нагрузка.
Пиковая нагрузка - точно может в 10-100-1000 раз быть больше.
Реляционные базы - очень не любят (тормозят на этом) всякие изменения данных.
инесрты хуй с нимиУ тебя нет уникальных полей?
нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базеЕсли я не ошибаюсь - во всех современных БД можно индексировать поля... и тогда 40 селектов в 3гиговой базе займут не сильно больше времени, чем в 3метровой...
Хотя, инсерт тогда будет занимать порядка столько же времени, сколько и селект - но навряд ли при не совсем уж гигантском их количестве это действительно окажет какое-то сильное влияние...
Сессии не подходят, так как они перерастут на самом деле в uid(так как сессии длятся бесконечное время а это уже много обсуждалось
в этом варианте есть уникальное поле - uid. машина не справится с такой нагрузкой - dark gray прав. Помимо селектов надо и другие вещи тоже делать, алгоритм выбора там, все такое. Это же пиздец что будет. 25 мс на запрос в среднем(а распараллеливать селекты и обработку это лишниий гемор и усложнение логики ненужное). Где хранить базу в long term? что делать если на какой-нибудь машине слетел винт - все машины бекапить раз в час?
в этом варианте есть уникальное поле - uidТо есть, количество инсертов всё-таки важно...
Если ты селекты тоже по уид делаешь - чем плоха индексация? Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)... а тогда - уже не очень заметно, 3 гига там или гораздо меньше...
> Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)
для изменения данных - есть обратная зависимость - чем больше индексов, тем намного тормознее работают insert-ы.
Чем больше индексируемых полей, или чем больше строк?
чем больше индексируемых полей - тем выше тормоза при вставке.
Поле вроде планируется только одно - уид?
зачем все это нужно если есть куки? + в промышленном масштабе это не может работать стабильно
В любом случае, когда у клиента плохой коннект: у него может сразу грузится две твоих страницы, и обоим придут одни и те же куки... и сохранится в его куки - только одно из этих двух посещений...
Оставить комментарий
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)? Желательно не особо запарно для владельца сайта, вставлябщего эти запросы