Постойте, постойте, какой же это компилятор.
То что вы описали это будет лишь кеширующий алгоритм (доп. пройслойка, которая тем эффективенее чем больше хитов на конкретные наборы данных).
Проблема данного изобретения в том, что eaccelerator уже изобретен, успешно внедрен во множество проектов, и работает эффективно.
при просмотре фильма и при клике в комментарии на рейтинг пользователя появляется слой с какой-то инфой (синий)… но он появляется под видеоплеером… было бы не плохо показывать его над плеером.
у мну FF 3.0.10 + flashBlock
я с вами не согласен! это универсальное решение. и оно очень сильно снимает «тупую» нагрузку на сервера. я это применяю повсеместно…
данные подтягиваются из хранилища только в том случае, если они реально понадобились…
все это в PHP реализуюется легко благодаря ООП.
если к объекту сессии пользователя небыло никакого обращения, то они останется неизменным и ни читать ни сохранять ничего не будет.
все это работает и в других местах… надо просто уметь применять.
назовите, на ваш взгляд, более серьезную оптимизацию.
интересно, не программисты ли писали модифицированный механизм работы с сессиями? ;)
молчу, что по-умолчанию, разработчики PHP его написали неоптимальным. :)
На самом деле все происходит так:
1. Если опыта нет — то это делают, как правило, когда упираются в сеть/диск/БД.
2. Если опыт есть — то сразу пишут объекты работы с сессиями (и прочие объекты), чтобы они срабатывали только по необходимости, потому что опытный программер задумывается над тем, что будет происходить с системой в каждой строчке его кода.
PS: возможно для кого-то будет тайной но в некоторых задачах оптимальным является даже кеширование объекта на уровне PHP на момент генерации объекта, в силу того, что он может быть задействован во многих блоках и/или вычислениях. Это и многое другое дает значительный выигрыш производительности системы в целом.
у меня два VPS в hc.ru
были пару раз проблемы с диском такие же. день продолжались… на второй день написал в саппорт с графиками мониторинга. на третий ответили, что проблема была — исправили.
я думаю, что важным является подход… нужно себя поставить на место хостера и подумать как надо написать сообщение.
были VPS в firstvds.ru:
там памяти и места мало дают. но та виртуализация статический код не плодит по всем VPS, а использует для него общее место в памяти… таким образом ваша память не занимается… Но тут есть проблема — стоит собрать свой апач или любое другое приложение и они будут жрать больше оперативки… ну и работает гораздо медленнее.
был VPS у Агавы:
тормозной.
дороже чем в hc.ru
на нем стоял мониторинг zabbix (мониторил VPS в hc.ru, и реальную машину дома на выделенке) — что интересно — постоянно давал ложные срабатывания на недоступность сервера…
сейчас фунции этого мониторящего сервера выполняет самый простой VPS от hc.ru — все гладко и еще половина ресурсов свободно. и никаких ложных срабатываний.
так что на данные момент из того что я уже щупал — VPS от hc.ru — лучший.
пользуюсь год.
на VPS2 от hc.ru крутиться несколько сайтов с общей статистикой:
уники: > 7 000
страниц: > 100 000
плюс Nginx отдает кучу графики тяжелой напрямую с диска.
в итоге LA редко поднимается выше 2.
у нас в стране тендеры выигрывают обычно приближенные к администрации люди.
остается надеяться, что эти приближенные будут профессионалами в том деле, которое они выиграли.
То что вы описали это будет лишь кеширующий алгоритм (доп. пройслойка, которая тем эффективенее чем больше хитов на конкретные наборы данных).
Проблема данного изобретения в том, что eaccelerator уже изобретен, успешно внедрен во множество проектов, и работает эффективно.
у мну FF 3.0.10 + flashBlock
данные подтягиваются из хранилища только в том случае, если они реально понадобились…
все это в PHP реализуюется легко благодаря ООП.
если к объекту сессии пользователя небыло никакого обращения, то они останется неизменным и ни читать ни сохранять ничего не будет.
все это работает и в других местах… надо просто уметь применять.
назовите, на ваш взгляд, более серьезную оптимизацию.
у нас nginx, за ним 5 php бэкендов, один мемкеш, 1 mysql + 1 slave
и все это вытягивает 10M страниц в день (примерно 1M посетителей)
и страница раз в 10 тяжелее по структуре чем в представленном сайте…
«на момент генерации объекта» нужно читать как «на момент генерации страницы»
молчу, что по-умолчанию, разработчики PHP его написали неоптимальным. :)
На самом деле все происходит так:
1. Если опыта нет — то это делают, как правило, когда упираются в сеть/диск/БД.
2. Если опыт есть — то сразу пишут объекты работы с сессиями (и прочие объекты), чтобы они срабатывали только по необходимости, потому что опытный программер задумывается над тем, что будет происходить с системой в каждой строчке его кода.
PS: возможно для кого-то будет тайной но в некоторых задачах оптимальным является даже кеширование объекта на уровне PHP на момент генерации объекта, в силу того, что он может быть задействован во многих блоках и/или вычислениях. Это и многое другое дает значительный выигрыш производительности системы в целом.
были пару раз проблемы с диском такие же. день продолжались… на второй день написал в саппорт с графиками мониторинга. на третий ответили, что проблема была — исправили.
я думаю, что важным является подход… нужно себя поставить на место хостера и подумать как надо написать сообщение.
были VPS в firstvds.ru:
там памяти и места мало дают. но та виртуализация статический код не плодит по всем VPS, а использует для него общее место в памяти… таким образом ваша память не занимается… Но тут есть проблема — стоит собрать свой апач или любое другое приложение и они будут жрать больше оперативки… ну и работает гораздо медленнее.
был VPS у Агавы:
тормозной.
дороже чем в hc.ru
на нем стоял мониторинг zabbix (мониторил VPS в hc.ru, и реальную машину дома на выделенке) — что интересно — постоянно давал ложные срабатывания на недоступность сервера…
сейчас фунции этого мониторящего сервера выполняет самый простой VPS от hc.ru — все гладко и еще половина ресурсов свободно. и никаких ложных срабатываний.
так что на данные момент из того что я уже щупал — VPS от hc.ru — лучший.
пользуюсь год.
на VPS2 от hc.ru крутиться несколько сайтов с общей статистикой:
уники: > 7 000
страниц: > 100 000
плюс Nginx отдает кучу графики тяжелой напрямую с диска.
в итоге LA редко поднимается выше 2.
остается надеяться, что эти приближенные будут профессионалами в том деле, которое они выиграли.
PS: этот пример показывает обратное :)