поддерживаю! тоже хотелось бы посмотреть, т.к. на некоторые доклады не успел и на некоторые тупо не попал в силу того что в другом зале было тоже интересно :(
что самое интересное! создание и поддержка этих игр не так дорога, как мощных видеосервисов, работных сервисов, поисковых сервисов и прочего.
односложные операции.
Достаточно написать один раз масштабируемую горизонтально систему и затем заниматься только строганием игр на уже готовой платформе. Вообщем затрат-то достаточно не много!
Радует тот факт, что у них есть SLA (ну для большинства крупных компаний это нормально).
Но вот, что за нарушение SLA они готовы отдать месяц услуги в дар — это ооочень позитивно. (т.к. это уже не просто гарантии, а гарантии подкрепленные финансовой ответственностью)
Я смотрю здесь есть представители этой компании.
Ответьте пожалуйста на эти вопросы:
1. как происходит перезагрузка зависшей намертво виртуалки? по звонку или через веб-интерфейс?
2. KVM и Xen — это все же очень разные подходы, насколько я знаю. Как происходит выбор между ними?
3. Изменение ядра на Xen виртуалках разве возможно на уровне доступа к виртуалке?
4. почему вы не занимаетесь оверселлингом? ну хоть немного? :)
вполне нормальная практика.
могли бы просто снести :)
на нас иногда наваливаются некоторые имбицилы, с целью тырить контент…
стукнишь хостеру или noc`у в саппорт на эту тему — прекращают.
а в последнее время просто сами стали отдавать всякие приколюхи вместо контента для таких сборщиков :)
аа… ну дак именно по этой причине за __call вынесенны ТОЛЬКО состояния и обработчики, которые занимают основную часть сложного модуля. (я об этом писал)
А часто используемые методы написаны прям в классе.
Тут я с вами полностью согласен.
мы немного о разном…
мы код прячем за _call метод и вызываем — один раз.
а вы кучу данных и обращения к ним за методы __get __set и вызывает много раз.
этот код писала команда программистов в течение 4-5 лет.
Что тут удивительного?
Некоторые алгоритмы повторяются из библиотеки в библиотеку, из модуля в модуль, но только с целью ускорения кода… Система постоянно развивается. Ее не возможно было спланировать всю целиком. Не исключаю, что 10-20% этого кода уже отмер (тоесть не используется по факту, но он рабочий).
Кстати мы когда то тоже задались этой проблемой, что для отображения списка скажем вот такой же странички как эта от модуля необходимо лишь получить статью, и комментарии.
Но кроме этого в модуле были еще и другие состояния и блоки… и они постоянно грузились…
Было предпринято наипростейшее решение — сделать все состояния, обработчики и просто методы в модуле через magiс метод __call(). Размер загружаемого кода резко сократился…
про гугл и lisp утверждать не могу, т.к. не знаю и лениво тратить на это время…
а вот про смарти могу сказать:
Smarty code -> PHP code
или вы будете утверждать, что шаблоны смарти пишутся на PHP?
Вы же предлагаете PHP преобразовывать в PHP, просто вместо 12345 в одном файле будет написано 5! (пять факториал) файлов с разными комбинациями внутренностей.
Вот собственно этим и будет заниматься ваш компилятор? я вас правильно понял или мы о разном?
Ой какой полиглот нашелся :)
Вы еще поди и по английски то читать умеете? Не поленитесь тогда воспользоваться ссылкой.
en.wikipedia.org/wiki/Compiler
«A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code). The most common reason for wanting to transform source code is to create an executable program.»
Вы же предложили написать компилятор, который сделает преобразование PHP в PHP. и после этого вы его называете компилятор…
Более правильного название, нежели EXPLODER, это не подходит ;)
> Чем из наиболее мелких и простых частей состоит конструктор, тем…
чем проще кусок кода — тем более понятен он программисту. Это не значит, что он должен быть маленьким… он может быть и большим, но должен быть логичен.
ААА… и еще забыл.
нужен же еще и какой-то маленький файл starter.php, который будет исходя из REQUEST_URI, POST, GET и прочего составлять ключ для кеша и в случае отсутсвия кеша — бежать генерить… и это должен быть какой-то отдельный скрипт от движка.
Но есть ряд минусов, которые опущены в статье:
1. огрмный размер кеша (если конечно это не домашная страничка какого-нить мальчика из неизвестной деревни.)
2. как уникально генерить ключ для кеша? хорошо если проект маленьки, а если большой и активноразвивающийся.
3. вообще если из вашей идеи убрать БД — уже будет лучше.
4. дебаг усложняется при использовании __call, а при использовании еще и БД, вообще бэктрейсы будут веселые.
вот пример одного крупного проекта:
Кол-во файлов движка — ~4089
Кол-во строк в этих файлах — 652091
В среднем по 160 строк на файл.
Вес: 43 метра
Нагрузка — так, небольшой highload. (~150qps)
Я даже не представляю себе как оценить размер необходиомого диска для этого проекта, чтоб на нем мог храниться кеш всех страниц.
Заигрались с идеями, ИМХО…
А за нестандартное мышление только респект! Направление верное, но надо шкурить…
Постойте, постойте, какой же это компилятор.
То что вы описали это будет лишь кеширующий алгоритм (доп. пройслойка, которая тем эффективенее чем больше хитов на конкретные наборы данных).
Проблема данного изобретения в том, что eaccelerator уже изобретен, успешно внедрен во множество проектов, и работает эффективно.
при просмотре фильма и при клике в комментарии на рейтинг пользователя появляется слой с какой-то инфой (синий)… но он появляется под видеоплеером… было бы не плохо показывать его над плеером.
у мну FF 3.0.10 + flashBlock
я с вами не согласен! это универсальное решение. и оно очень сильно снимает «тупую» нагрузку на сервера. я это применяю повсеместно…
данные подтягиваются из хранилища только в том случае, если они реально понадобились…
все это в PHP реализуюется легко благодаря ООП.
если к объекту сессии пользователя небыло никакого обращения, то они останется неизменным и ни читать ни сохранять ничего не будет.
все это работает и в других местах… надо просто уметь применять.
назовите, на ваш взгляд, более серьезную оптимизацию.
односложные операции.
Достаточно написать один раз масштабируемую горизонтально систему и затем заниматься только строганием игр на уже готовой платформе. Вообщем затрат-то достаточно не много!
Это уже частность… А они охватили только основные шаблоны…
Но вот, что за нарушение SLA они готовы отдать месяц услуги в дар — это ооочень позитивно. (т.к. это уже не просто гарантии, а гарантии подкрепленные финансовой ответственностью)
Я смотрю здесь есть представители этой компании.
Ответьте пожалуйста на эти вопросы:
1. как происходит перезагрузка зависшей намертво виртуалки? по звонку или через веб-интерфейс?
2. KVM и Xen — это все же очень разные подходы, насколько я знаю. Как происходит выбор между ними?
3. Изменение ядра на Xen виртуалках разве возможно на уровне доступа к виртуалке?
4. почему вы не занимаетесь оверселлингом? ну хоть немного? :)
могли бы просто снести :)
на нас иногда наваливаются некоторые имбицилы, с целью тырить контент…
стукнишь хостеру или noc`у в саппорт на эту тему — прекращают.
а в последнее время просто сами стали отдавать всякие приколюхи вместо контента для таких сборщиков :)
А часто используемые методы написаны прям в классе.
Тут я с вами полностью согласен.
мы код прячем за _call метод и вызываем — один раз.
а вы кучу данных и обращения к ним за методы __get __set и вызывает много раз.
какая разница в нагрузке на CPU при интерпретации файла 150-200Кб и двух-трех файлов размером ~5Кб? Замеряли?
Что тут удивительного?
Некоторые алгоритмы повторяются из библиотеки в библиотеку, из модуля в модуль, но только с целью ускорения кода… Система постоянно развивается. Ее не возможно было спланировать всю целиком. Не исключаю, что 10-20% этого кода уже отмер (тоесть не используется по факту, но он рабочий).
Кстати мы когда то тоже задались этой проблемой, что для отображения списка скажем вот такой же странички как эта от модуля необходимо лишь получить статью, и комментарии.
Но кроме этого в модуле были еще и другие состояния и блоки… и они постоянно грузились…
Было предпринято наипростейшее решение — сделать все состояния, обработчики и просто методы в модуле через magiс метод __call(). Размер загружаемого кода резко сократился…
а вот про смарти могу сказать:
Smarty code -> PHP code
или вы будете утверждать, что шаблоны смарти пишутся на PHP?
Вы же предлагаете PHP преобразовывать в PHP, просто вместо 12345 в одном файле будет написано 5! (пять факториал) файлов с разными комбинациями внутренностей.
Вот собственно этим и будет заниматься ваш компилятор? я вас правильно понял или мы о разном?
Вы еще поди и по английски то читать умеете? Не поленитесь тогда воспользоваться ссылкой.
en.wikipedia.org/wiki/Compiler
«A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code). The most common reason for wanting to transform source code is to create an executable program.»
Вы же предложили написать компилятор, который сделает преобразование PHP в PHP. и после этого вы его называете компилятор…
Более правильного название, нежели EXPLODER, это не подходит ;)
например, хотя бы, в зависимости от REQUEST_URI
> Чем из наиболее мелких и простых частей состоит конструктор, тем…
чем проще кусок кода — тем более понятен он программисту. Это не значит, что он должен быть маленьким… он может быть и большим, но должен быть логичен.
RTFM
нужен же еще и какой-то маленький файл starter.php, который будет исходя из REQUEST_URI, POST, GET и прочего составлять ключ для кеша и в случае отсутсвия кеша — бежать генерить… и это должен быть какой-то отдельный скрипт от движка.
Но есть ряд минусов, которые опущены в статье:
1. огрмный размер кеша (если конечно это не домашная страничка какого-нить мальчика из неизвестной деревни.)
2. как уникально генерить ключ для кеша? хорошо если проект маленьки, а если большой и активноразвивающийся.
3. вообще если из вашей идеи убрать БД — уже будет лучше.
4. дебаг усложняется при использовании __call, а при использовании еще и БД, вообще бэктрейсы будут веселые.
вот пример одного крупного проекта:
Кол-во файлов движка — ~4089
Кол-во строк в этих файлах — 652091
В среднем по 160 строк на файл.
Вес: 43 метра
Нагрузка — так, небольшой highload. (~150qps)
Я даже не представляю себе как оценить размер необходиомого диска для этого проекта, чтоб на нем мог храниться кеш всех страниц.
Заигрались с идеями, ИМХО…
А за нестандартное мышление только респект! Направление верное, но надо шкурить…
То что вы описали это будет лишь кеширующий алгоритм (доп. пройслойка, которая тем эффективенее чем больше хитов на конкретные наборы данных).
Проблема данного изобретения в том, что eaccelerator уже изобретен, успешно внедрен во множество проектов, и работает эффективно.
у мну FF 3.0.10 + flashBlock
данные подтягиваются из хранилища только в том случае, если они реально понадобились…
все это в PHP реализуюется легко благодаря ООП.
если к объекту сессии пользователя небыло никакого обращения, то они останется неизменным и ни читать ни сохранять ничего не будет.
все это работает и в других местах… надо просто уметь применять.
назовите, на ваш взгляд, более серьезную оптимизацию.
у нас nginx, за ним 5 php бэкендов, один мемкеш, 1 mysql + 1 slave
и все это вытягивает 10M страниц в день (примерно 1M посетителей)
и страница раз в 10 тяжелее по структуре чем в представленном сайте…