меня вот всегда интересовал вопрос — почему так мало денег достаеться вебмастерам?
смотрю тарифы smscoin.com/info/pricing-ukraine/
от СМС за 80 коп сервису отойдет всего 8 коп!!!
как можно предложить какой-то дешевый сервис конечным потребителям, если тебе от него ничего не останется…
собственно ничего удивительного — люди зашли, посмотрели и вернулись к своим старым предпочтениям.
я, к примеру, ничего там сверхестественного не обнаружил для себя, а менять дефолтный поисковик во всех браузерах мне лень :)
сорри, отправилось рано, так вот:
$interval = '+1 month';
$shift = '+1 day';
$curDate = date('Y-m-d H:i:s');
$startDate = strtotime($curDate. ' '. $shift);
$endDate = strtotime($interval, $curDate);
ну а дальше как и в пред. примере.
высокосные нам не страшны ни в первом ни во втором случаях
у вас же в системе известно текущие дата и время? думаю что да :)
к пример у вас $curDate это оно и есть, $interval — это период а $shift — сдвиг от текущего времени в сек. тогда:
$curDate = date('Y-m-d H:i:s');
$startDate = strtotime($curDate) + $shift;
$endDate = $startDate + $interval;
прводим к читабельному формату:
$sStartDate = date('md', $startDate);
$sEndDate = date('md', $endDate);
ну а дальше в ваш первый запрос подставляете эти значения. только преобразовывать дату на лету не самый лучший вариант для мускула, лучше сделать отдельную колонку для даты в формате DATE_FORMAT(birthday,'%m%d') и при вставке вносить туда уже подготовленные данные. + сделать по ней индекс. будет летать. проверено на табл со 100 млн. записями, правда на постгре.
не хочу показаться занудой, но:
«В многокорной и многопроцессорной системах у каждой коры или процессора есть свой персональный кеш» — может всетаки так:
«В многоядерной и многопроцессорной системах у каждого ядра или процессора есть свой персональный кеш»? а то «кора» как-то режет «кору» мозга :)
Вы говорите очевидные вещи и ВЕБ 2.0 здесь ни причем. да, мусором торговать это не хорошо. и тут я с вами полностью согласен, но вас ведь никто не заставляет это покупать. есть выбор.
ну это уже давно известный факт.
я давно смирился с тем, что в подавляющем большинстве случаев хороший маркетинг с лихвой покрывает недостатки кривого продукта.
а так как эти сервисы используют далеко не ITшники и им глубоко фиолетово качество (в большинстве своем), то они и не обращают на это внимания, или принимают как должное.
более требовательные найдут качественный продукт.
вот никогда не понимал таких фраз:
«Что ж, радует, что тех людей, который готовы платить за «виртуальные удовольствия» «Одноклассников» становится меньше»?
вам то с этого что?
хм, 6G это круто.
я написал «кажись при 4G». вот что про перегрузки говорит wikipedia, и еще, перегрузки бывают разные. при катапультировании у человека кровь отливает от головы, и если нет специального костюма, который сдавливает все тело, а так же человек не тренирован, то потеря сознания, а возможно и повреждение мозга обеспеченно.
MVC это не совсем то. я имею ввиду разделение логики при работе с данными.
за примером пойдем к хабру — главная страница из статей с атрибутами. так вот, тут присутствует логика отображения и бизнес логика формирования исходных данных (т.е. текста и атрибутов).
для достижения наименьшего времени которое пройдет меджу тем как сервер получит запрос от пользователя и отдаст ему первый байт, я бы закешировал полностью главную страницу в виде объекта и никогда не парился о проверке/изменениях аттрибутов при формировании результата пользователю. никаких проверок вообще.
а вот во время изменения данных (кто-то плюсанул статью, к примеру) — формировал бы новый объект и помещал бы его в кеш. улавливаете мысль? не нужно кажды раз лезть в базу для того что бы получить данные. да, вы тоже не лезите если у вас закешированные данные, но вы проверяете их актуальность, а этого не должно быть в принципе при формировании контента пользователю. не нужно туда лезть вообще.
где об этом почитать? погуглите на предмет архитектурирования многопользовательских высоконагруженных систем. посмотрите как устроен фликер, скайп, фейсбук. последние в прошлом году открыли часть своих кодов, много чего интересного есть.
то что у вас сайт на одном, а база на другом сервере особой роли на коннекшенах не играет, если у вас там конечно не 10MBit. к мемкешу так же по TCP идут коннекты.
MySQL не тратит время на повторные одинаковые запросы если у него хватает памяти. а время для вычисление MD5 от запроса, который вы используете для формирования ключа вполне можно сравнить с сетевыми издержками к базе.
что такое очень быстро? это примерно как бжжж и все :)
если серьезно, то на 0,5% медленне, чем кешировать данные в мемкеше. думаю этим можно принебречь. проверенно на собственных тестах и на живом игровом проекте под нагрузкой.
во первых — при таком катапультировании как оно сейчас есть в военной авиации могут выжить только подготовленные люди в специальных перегрузочных костюмах. катапультирование — это выстреливание человеком с кратковременными перегрузками до 16G. нетренированный человек теряет сознание кажись при 4G. да и на всех костбмы не наденешь.
во вторых — очень дорого под каждое кресло поставить катапульту и корпус самолета не выдержит того, что бы над каждым креслом был люк.
в третих — при массовом катапультировании будет такая плотность народу в воздухе над самолетом, что парашюты могут банально запутаться.
я не имею ввиду где физически располагать сервер кеширования. это вопрос отдельной статьи.
фронтенд это то, что работает с готовыми данными, бэкенд — это то, что эти данные готовит для фронтенда.
должно быть строгое разделение бизнес логики от отображения. у вас этого нет.
«обновление данных происходит по мере выполнения запросов» — вот это и есть зло — скрипт, который пришел за данными должен их только получить и все. он не должен их обновлять. они должны быть уже готовые и актуальные на столько, сколько того требует логика системы.
на счет MySQL — таблица memory полностью располагаеться в памяти так же как и данные мемкеша. а если грамотно оттюнить MySQL то он может работать ооочень быстро и кешировать все запросы таким же методом как и у вас только вы избавитесь от еще одного велосипеда.
так и сейчас летают с гидравликой. но суть в том, что на большие поверхности самолета действуют очень большие силы в создухе и даже малейшие изменения, скажем, плотности воздуха могут сказаться на положении самолета. вот это и исправляет система управления в реальном времени вместо пилота. пилот такое не сможет сделать физически. и это не автопилот. это система, которая помагает пилоту в управлении. что-то типа трекшен контроль в машинах.
по поводу военной авиации — так в истребителях нет никакого прямого управления — это в принципе не возможно. от него отказались еще 2 поколения назад.
правильно, при должной гидравлике, но ей-то нужно передать комманду. или вы думаете что там все просто как в автомобиле с гидроусилителем руля? :)
З.ы. закрылками двигает не шутрвал а переключатель на панели приборов ;) и без них самолет удержать в горизонтальном положении на малых скоростях при посадке практически невозможно.
вы полагаете что там идет прямая тяга через вес корпус от штурвала к закрылкам или хвостовому рулю? :)
в современной авиации летательными аппаратами таких масштабов пилот управлять не может в принципе, если бы он это делал — он бы после взлета сразу же упал бы. пилот только отдает команды бортовым системам, что нужно делать — повернуть налево, направо, вверх, вниз, накрениться и т.д. а система сама принимает решение как это более эффективно сделать — то ли рулем высоты, то ли закрылками, то ли хвостовым рулем.
это не то, что управлять маленьким легким самолетом. уж очень много факторов влияет на поддержание самолета в заданом напрвлении. я уж не говорю о военной авиации. где ситуация меняеться много раз за секунду.
смотрю тарифы smscoin.com/info/pricing-ukraine/
от СМС за 80 коп сервису отойдет всего 8 коп!!!
как можно предложить какой-то дешевый сервис конечным потребителям, если тебе от него ничего не останется…
я, к примеру, ничего там сверхестественного не обнаружил для себя, а менять дефолтный поисковик во всех браузерах мне лень :)
вот тут на больше хватает :)
www.wherethehellismatt.com/
$interval = '+1 month';
$shift = '+1 day';
$curDate = date('Y-m-d H:i:s');
$startDate = strtotime($curDate. ' '. $shift);
$endDate = strtotime($interval, $curDate);
ну а дальше как и в пред. примере.
высокосные нам не страшны ни в первом ни во втором случаях
$interval = '+1 month';
к пример у вас $curDate это оно и есть, $interval — это период а $shift — сдвиг от текущего времени в сек. тогда:
$curDate = date('Y-m-d H:i:s');
$startDate = strtotime($curDate) + $shift;
$endDate = $startDate + $interval;
прводим к читабельному формату:
$sStartDate = date('md', $startDate);
$sEndDate = date('md', $endDate);
ну а дальше в ваш первый запрос подставляете эти значения. только преобразовывать дату на лету не самый лучший вариант для мускула, лучше сделать отдельную колонку для даты в формате DATE_FORMAT(birthday,'%m%d') и при вставке вносить туда уже подготовленные данные. + сделать по ней индекс. будет летать. проверено на табл со 100 млн. записями, правда на постгре.
а strtotime вам чем не угодил???
«В многокорной и многопроцессорной системах у каждой коры или процессора есть свой персональный кеш» — может всетаки так:
«В многоядерной и многопроцессорной системах у каждого ядра или процессора есть свой персональный кеш»? а то «кора» как-то режет «кору» мозга :)
я давно смирился с тем, что в подавляющем большинстве случаев хороший маркетинг с лихвой покрывает недостатки кривого продукта.
а так как эти сервисы используют далеко не ITшники и им глубоко фиолетово качество (в большинстве своем), то они и не обращают на это внимания, или принимают как должное.
более требовательные найдут качественный продукт.
«Что ж, радует, что тех людей, который готовы платить за «виртуальные удовольствия» «Одноклассников» становится меньше»?
вам то с этого что?
я написал «кажись при 4G». вот что про перегрузки говорит wikipedia, и еще, перегрузки бывают разные. при катапультировании у человека кровь отливает от головы, и если нет специального костюма, который сдавливает все тело, а так же человек не тренирован, то потеря сознания, а возможно и повреждение мозга обеспеченно.
за примером пойдем к хабру — главная страница из статей с атрибутами. так вот, тут присутствует логика отображения и бизнес логика формирования исходных данных (т.е. текста и атрибутов).
для достижения наименьшего времени которое пройдет меджу тем как сервер получит запрос от пользователя и отдаст ему первый байт, я бы закешировал полностью главную страницу в виде объекта и никогда не парился о проверке/изменениях аттрибутов при формировании результата пользователю. никаких проверок вообще.
а вот во время изменения данных (кто-то плюсанул статью, к примеру) — формировал бы новый объект и помещал бы его в кеш. улавливаете мысль? не нужно кажды раз лезть в базу для того что бы получить данные. да, вы тоже не лезите если у вас закешированные данные, но вы проверяете их актуальность, а этого не должно быть в принципе при формировании контента пользователю. не нужно туда лезть вообще.
где об этом почитать? погуглите на предмет архитектурирования многопользовательских высоконагруженных систем. посмотрите как устроен фликер, скайп, фейсбук. последние в прошлом году открыли часть своих кодов, много чего интересного есть.
то что у вас сайт на одном, а база на другом сервере особой роли на коннекшенах не играет, если у вас там конечно не 10MBit. к мемкешу так же по TCP идут коннекты.
MySQL не тратит время на повторные одинаковые запросы если у него хватает памяти. а время для вычисление MD5 от запроса, который вы используете для формирования ключа вполне можно сравнить с сетевыми издержками к базе.
что такое очень быстро? это примерно как бжжж и все :)
если серьезно, то на 0,5% медленне, чем кешировать данные в мемкеше. думаю этим можно принебречь. проверенно на собственных тестах и на живом игровом проекте под нагрузкой.
во вторых — очень дорого под каждое кресло поставить катапульту и корпус самолета не выдержит того, что бы над каждым креслом был люк.
в третих — при массовом катапультировании будет такая плотность народу в воздухе над самолетом, что парашюты могут банально запутаться.
ну и т.д.
НЕГРАМОТНЫЙ сброс — да, снижает.
фронтенд это то, что работает с готовыми данными, бэкенд — это то, что эти данные готовит для фронтенда.
должно быть строгое разделение бизнес логики от отображения. у вас этого нет.
«обновление данных происходит по мере выполнения запросов» — вот это и есть зло — скрипт, который пришел за данными должен их только получить и все. он не должен их обновлять. они должны быть уже готовые и актуальные на столько, сколько того требует логика системы.
на счет MySQL — таблица memory полностью располагаеться в памяти так же как и данные мемкеша. а если грамотно оттюнить MySQL то он может работать ооочень быстро и кешировать все запросы таким же методом как и у вас только вы избавитесь от еще одного велосипеда.
по поводу военной авиации — так в истребителях нет никакого прямого управления — это в принципе не возможно. от него отказались еще 2 поколения назад.
З.ы. закрылками двигает не шутрвал а переключатель на панели приборов ;) и без них самолет удержать в горизонтальном положении на малых скоростях при посадке практически невозможно.
в современной авиации летательными аппаратами таких масштабов пилот управлять не может в принципе, если бы он это делал — он бы после взлета сразу же упал бы. пилот только отдает команды бортовым системам, что нужно делать — повернуть налево, направо, вверх, вниз, накрениться и т.д. а система сама принимает решение как это более эффективно сделать — то ли рулем высоты, то ли закрылками, то ли хвостовым рулем.
это не то, что управлять маленьким легким самолетом. уж очень много факторов влияет на поддержание самолета в заданом напрвлении. я уж не говорю о военной авиации. где ситуация меняеться много раз за секунду.