24 июля 2013 г., 8:20
Hamster-fox.ru Техническая оптимизация и обновление MODX Revolution.
Небольшое описание исходного положения.
Картина на самом деле очень печальная… Зайти в админку я просто не мог… Сервер просто рыдал. В htop нашел php-процесс, который висит уже 640+ часов… Рестарт fast-cgi никак не хотел выполняться. Пришлось вручную убивать все php-процессы. Наконец-то удалось рестартануть все службы, зайти в админку и перевести сайт в состояние «Отключен». Админка работает со скрипом (скорее всего из-за большого размера кеш-файла. Версия MODX-а 2.2.6, так что еще предстоит обновить движок, и не только по соображениям безопасности, но и для того, чтобы частично отключить кеширование карты ресурсов, что сократит кеш процентов на 50 (основная фишка версии 2.2.7)).
Сам сайт по сути вообще не рабочий. Главная страница не открывается вообще, а попытка открыть простую внутреннюю страницу Контакты показала вот такой результат (это при сброшенном кеше):
Memory: 26.25 Mb TotalTime: 29.6804 s
Ajax-овый запрос корзины 28 секунд (на скрине и еще один результат захода на внутреннюю)
?
В общем, под катом рассказ об оптимизации этого сайта (записки по ходу работы)
1. Обновим версию MODX-а.
Для начала конечно же обновим сам движок. Как я и говорил выше, главное, что у нас появится — это возможность сократить объем кеша.
Результат:
Memory: 27.75 Mb
TotalTime: 32.7369 s
К слову, кеш-провайдер на сайте используется memcache. Я пока переключился на стандартный файловый, чтобы посмотреть какой выигрыш мы получаем от новой фишки MODX-а с отключением карты алиасов. Получилось следующее:
С включенным полным кешированием:
— объем кеша: 445Kb.
— потребление памяти: Memory: 26.5 Mb
С отключенным кешированием:
— объем кеша: 109Kb.
— потребление памяти: Memory: 25.5 Mb
В общем, мегабайт оперативки уже отбили.
2. Оптимизируем шаблоны.
Как и говорилось уже неоднократно раньше, основной источник зла (тормозов MODX-сайтов) — это система шаблонизации MODX-а, включая ее теги и т.п. Вкупе с не очень прямыми руками это может дать вообще ооочень плохие результаты.
Я же сейчас попробую перевести это дело на phpTemplates+modxSmarty+shopModx, и сократить хотя бы тормоза на кешируемых элементах, и на тех элементах, которые можно заменить за счет использования MODX API.
Для начала сделаем замеры на голой странице, чтобы было от чего отталкиваться. То есть я удалил полностью контент главной страницы и убрал шаблон. Это чтобы увидеть минимальное время на выполнение пустой страницы (то есть чисто инициализация MODX-а, подгрузка кеша контекста и т.п.), чтобы потом посмотреть какие модули сайта какой прирост в нагрузке дают.
И вот на этом этапе я уже получил первый сюрприз… При сброшенном кеше на пустой странице при первом заходе имеем:
Memory: 9.5 Mb
TotalTime: 1.0075 s (разброс 0,9-1,35 сек)
Как-то это совсем много… Поигравшись с настройками и кеша, я пришел к выводу, что такой результат нам дает memcache… При переключении на файловый провайдер имеем:
Memory: 8.75 Mb
TotalTime: 0.2330 s (разброс 0,23-0,44 сек)
Разница весьма существенная и гораздо больше похоже на правду. Не знаю точно по какой причине memcache так тормозит (сервер не мой, и возможно что-то не так в настройках или типа того), но в любом случае, думаю, лучше вернуться на классический файловый кеш-провайдер. 6000 документов — не так много, чтобы переживать за кеширование на файлах. В любом случае, советую в таких случаях отключать кеширование Wayfinder-а, так как на один документ вы можете получить до нескольких кеш-файлов, что потом будет очень сильно тормозить процесс сброса кеша сайта. Но в любом случае, не забывайте про индивидуальный подход в таких вопросах.
Установил все свои пакеты, результаты такие:
Memory: 11.75 Mb
TotalTime: 0.3043 s
Увеличение потребления памяти объясняется автоматической инициализацией модулей-расширений shopModx, phpTemplates и modxSDK, а так же выполнением плагина modxSmarty (и инициализацией Smarty-шаблонизатора).
К слову сказать, здесь больше всех прибавил именно shopModx, так как он помимо дополнительной службы MODX-а еще и добавляет несколько CRC + процессоров для них. Но в оправдание могу сказать, что входящие в состав shopModx процессоры нам позволят в дальнейшем здорово отыграться на выборках из каталога, в разы сократив время и потребляемую память, и увеличив при этом гибкость в запросах.
Итак, отталкиваемся от последних показателей — 11,75 метров памяти и 0,3 сек. на голой странице. Повторный заход (из кеша):
Memory: 7.5 Mb
TotalTime: 0.1968 s
И сразу зафиксирую текущие показатели главной страницы без выполнения самого сложного — выборки товаров из каталога. То есть это все то, что по сути у нас кешируемое, и что мы должны получить на выходе в точно таком же виде, только на phpTemplates+Smarty.
Первый заход после сброса кеша:
Memory: 28.5 Mb TotalTime: 28.7388 s
Повторный заход:
Memory: 11.75 Mb TotalTime: 0.9649 s (разброс 0.9-2.8)
Кстати, сразу можно сказать, что здесь дает нагрузку — боковое меню. Так сразу не видно, но оно имеет несколько уровней вложенности, которые видно только при наведении мыши.
Для начала просто переработаем шаблон. То есть возьмем исходный MODX-шаблон и заменим в нем все кешируемые MODX-теги на Smarty-теги. Это позволит разгрузить MODX-парсер и на первом заходе (так как после первого же использования шаблона, Smarty скомпиллирует его в php, и в дальнейшем все будет работать на php-переменных и функциях, а не MODX-парсер будет перелопачивать весь код документа), так и при последующих заходах, так как в кеше документа уже будет полностью конечный HTML-код, а не MODX-теги, которые придется повторно выполнять MODX-парсеру.
Разница в выполнении при сброшенном кеше почти отсутствует (Смарти не отменяет нагрузку, создаваемую Wayfinder-ом при 4-ехуровневой выборке из каталога на 6000 документов):
Memory: 28.25 Mb TotalTime: 28.4921 s
Но зато повторный заход:
Memory: 11.75 Mb TotalTime: 0.2999 s
Сразу время в несколько раз (10 раз обновил, ни разу не превысил 0,35 сек.)
И вот это как раз благодаря тому, что в кеше почти что полностью только конечный HTML. Кеш документа: gist.github.com/Fi1osof/58ce08c0066de83d6a22
Оптимизируем элементы шаблона.
Далее нам предстоит оптимизировать те элементы, которые дают наибольшую нагрузку.
1. Бренды в подвале. Это удивительно, но выборка нескольких документов первого уровня из одного раздела с набивкой в простенький шаблон, отнимает 2 секунды времени…
Вот такой шаблончик:
<div class="brandRow"> <a href="[[~[[+id]]]]" title="[[+longtitle:default=`[[+pagetitle]]`]]"> [[+tv.preview:isnot=``:then=`<img class="brandLogo" src="/[[+tv.preview:phpthumbof=`h=100`]]" alt="[[+pagetitle]]" />`:else=`<b>[[+pagetitle]]</b>`]] </a> </div>
В общем, перепишем это на shopModx-овых list-процессорах.
Вот такой код у нас получился на замену:
{assign var=params value=[ "limit" => 0, "where" => [ "parent" => 3 ] ]} {processor action="web/getdata" ns=hamster params=$params assign=brands_result} {foreach $brands_result.object as $brand} <div class="brandRow"> <a href="{$brand.uri}" title="{if $brand.longtitle}{$brand.longtitle}{else}{$brand.pagetitle}{/if}"> {if $brand.tvs.preview.value} {snippet name=phpthumbof params="input=`{$brand.tvs.preview.value}`&options=`h=100`" assign=preview} <img class="brandLogo" src="{$preview}" alt="{$brand.pagetitle}" /> {else} <b>{$brand.pagetitle}</b> {/if} </a> </div> {/foreach}
Он конечно побольше будет, чем одна строчка вызова getResource-а, но зато его выполнение вообще не ощущается. 0.1-0.2 секунды — большая разница по сравнению с двумя. Ито здесь основную «нагрузку» дает phpthumbOf.
Итак, сейчас с отключенными менюшками и с галереей в подвале мы имеет такие показатели при первом заходе:
Memory: 20.5 Mb TotalTime: 1.0186 s
Верхние две менюшки на Wayfinder-е еще секунду отъедают (при первом заходе). Скрин: www.diigo.com/item/image/3q9lh/ht5v
Но их нет смысла оптимизировать. Во-первых, я еще планирую чуть-чуть по базе в заключение пройтись. А во-вторых, при повторном заходе это не имеет значения. Показатели:
Memory: 8.5 Mb TotalTime: 0.2525 s
Оптимизация бокового меню.
А вот с боковым меню все гораздо сложнее… Во-первых, оно отрабатывает 4 уровня каталога (а это не легкий Wayfinder со всеми примочками и шаблонизацией на чанках). Во-вторых, его нельзя закешировать для всего сайта сразу, так как меню меняется в зависимости от текущей страницы. И вот включив боковое меню (еще не включая каталог), мы уже имеем вот такие показатели:
Memory: 34.5 Mb TotalTime: 26.7212 s
К слову, вот такие показатели мы имеем сейчас на полной главной странице вместе с не оптимизированными еще боковым меню и выводом каталога без постраничности. Скрин: www.diigo.com/item/image/3q9lh/rtp9
Memory: 35 Mb TotalTime: 39.7604 s
И вот здесь я достал свою довольно старую наработку (писал процессор для формирования тоже тяжелой менюшки на одном не маленьком магазине) и доработав, прикрутил здесь на замену Wayfinder. Сам код выложу ниже, а пока просто результаты:
Первый заход после полного сброса кеша сайта (включая кеш дерева документов меню):
Memory: 23 Mb TotalTime: 5.3554 s
Первый заход на страницу, для которой кеша еще нет, но есть кеш карты меню:
Memory: 19.75 Mb TotalTime: 2.1977 s
При повторном заходе на уже закешированную страницу само собой проблем вообще нет:
Memory: 8.5 Mb TotalTime: 0.2646 s
И здесь стоит отметить самый главный момент этого процессора — он кеширует полную карту ресурсов, входящих в это меню, и в дальнейшем, когда вы заходите на другую страницу, для которой должно сформироваться новое меню со всеми этими active и т.п., данный скрипт не выполняет повторно все эти запросы к БД, а просто берет массив всех элементов из кеша, и пробегается по нему, устанавливая active, level и т.п. Нагрузка падает в разы.
Замена всех Wayfinder.
И вот тут я решил: а почему не заменить все менюшки на Wayfinder?.. В общем, хотя и пришлось еще чуть-чуть подшаманить процессор, но в целом он дал довольно неплохой результат. Что уже в нем есть:
- Поддержка стандартных:
- startId
- where
- level
- levelClass
- activeClass
- sortBy
- sortOrder
- ignoreHidden
- Дополнительно:
- showUnpublished
- cacheable — кеширование. Работает не так, как в Wayfinder. Там кеш создается для каждого документа в отдельности, а здесь кешируется все дерево, начиная со startId. Чтобы разделить кеш для разных кешируемых менюшек на одном уровне, просто укажите индивидуальные id для вызываемых процессоров
С шаблонами вот пока еще не игрался (просто нужды не возникло), но в дальнейшем буду этот скрипт развивать.
Кстати, так же необходимо иметь ввиду, что он пока не делает проверок на права доступа к документу.
В общем, заменил все менюшки на этот скрипт, и получил такие результаты:
Memory: 22.25 Mb TotalTime: 4.0456 s
Первый заход на страницу, для которой кеша еще нет, но есть кеш карты меню:
Memory: 19.25 Mb TotalTime: 1.3606 s
То есть первый заход на незакешированную страницу мы по времени сократили почти в два раза, выиграв секунду.
Последующие заходы на кешированные страницы само собой так же быстро отрабатываются (с той же скоростью), так как там уже не зависимо от используемой технологии конечный код отдается полностью из кеша.
Кешируемый глобальный сниппет.
Все-таки никак не давала мне покоя эта галерея брендов в подвале, с учетом того, что она на всех страницах абсолютно одинаковая. Закинул ее в отдельный Смарти-шаблончик, а в основном прописал вызов сниппета. Этот сниппет получает этот отработанный щаблончик, и пишет его в кеш. В дальнейшем на всех страницах он будет сразу брать код из кеша и отдавать в основной шаблон без всяких запросов к БД и т.п.
Оптимизация вывода каталога.
А вот теперь мы добрались до самого интересного — оптимизация каталога, организованного на minishop еще первой версии. Основные проблемные моменты, связанные с этим, я описывал еще в прошлом топике, но сейчас мы четко будет видеть разницу.
Сбрасываем полностью кеш и заходим в маленький раздел каталога с 10+ товарами: www.diigo.com/item/image/3q9lh/y5po
Memory: 25.75 Mb TotalTime: 13.9010 s
Заход в корень каталога:
Memory: 27 Mb TotalTime: 24.4069 s
В общем, картина ясная. Я уже не говорю, что разделы типа «Новинки» (то есть те, где есть хоть какие-то условия поиска) не открываются в принципе. Скрипт разваливается. И это при том, что таймлимиты подняты.
Я сейчас не буду писать детали того, как я каталог оптимизировал. Во-первых, потому что хочу спать (проработал вот почти 12 часов (все эти работы, включая написание этого топика)). Во-вторых, топик итак очень не маленький получился. Скажу только, что оптимизации почти и не было. Просто переписал на list-процессорах из shopModx-а. Конечный результат можете сами посмотреть: www.hamster-fox.ru/ (статистика памяти и времени внизу страницы).
Каталог на самом деле не так быстро работает, как мог бы, но это уже на совести сервера. На modxcloud.com все летает (это еще и старая версия, не так оптимизированная).
На том пока все.
UPD: Сделал копию сайта на modxcloud.com: hamster-2.fi1osof.modxcloud.com/
Вот там уже четко видно скорость работы сайта.
Кликнул но одному из товаров Memory:
22.25 Mb
TotalTime: 7.1164 s
Ну, слово летает тут неуместно…
еще кликнул www.hamster-fox.ru/catalog/zh-doroga-garazhi-treki/treki/stroyploshchadka-na-15-mest-v-garazhe-s-liftom-54*35*9-smc326-h06020.html
Memory: 22 Mb
TotalTime: 6.0864 s
Связался с хостером, изучают проблему. Просили выслать им спецификацию modxcloud для воспроизведения на своих VDS. Хостер fastvps, представители хецнера в России, тариф OVZ-6. Оч странные проблемы, которые наблюдаются именно на ноде с хамстер фоксом. На «соседних» проектах, которые тоже используют фаствпс, таких проблем не наблюдается, хотя и cms там другие.
Про «летает» я говорил про старую копию на modxcloud.com (если вы там ссылку не увидели). А здесь сервер слабоватый. Это-во-первых. Во-вторых, конечные страницы товара набиваются с помощь minishop-а, работу которого я гарантировать не могу. В-третьих, такие тормоза во многом создаются phpthumbOf-ом (если зашли на страницу первый раз, во-первых, в кеше вообще ничего нет, то есть страница отрабатывается с нуля, а во-вторых, кеша картинки нет, ее надо обрезать еще (на это время и тратится)). Когда сайт поработает некоторое время и для всех картинок будут кешы, тогда он работать будет гораздо быстрее.
Но вы еще можете показать свой какой-нибудь интернет-магазин на MODX Revo тысяч на 6 и более товаров. Я бы посмотрел.
Кстати, с учетом того, что сайт не работал в принципе (вот уже более недели), а когда «работал», то открывался как правило за 10-20 секунд (менее трех секунд вообще ни одна, даже самая простая страница, не открывалась) (личный замеченный рекорд 50+ секунд), то в сравнении можно сказать, что сайт летает.
Точной спецификации нет. Они ведь себя называют «облачным» хостингом, но на самом деле они не облачные, а по сути простой шаредхостинг. По разным причинам характеристики не публикуются, но пара параметров есть:
— php-memory — 128M
— 24-core Intel Xeon box
— APC
Я многократно читал ваши критические замечания о Минишоп1 и т.п. Но вот захожу по этой ссылке mamaboutique.ru/catalog/dlya-beremennyix/kupalniki-dlya-beremennyix/kupalniki-emma-jane/kupalnik-dlya-beremennyix-slitnyij.html и вижу сделанный руками магазин (да, это Мигишоп2, а не 1) Магазин который не вызывает ни одной отрицательной эмоции.
Так же есть возможность не генерировать превьюхи на лету, и знчит не говорить и не ссылаться га это как на проблему.
Вы так увлечены критикой разработок Василия Наумкина и иже с ним, что технические доводы меркнут в неприличных для человека со статусом «амбассадор» выпадах и постоянных грязных намеках о некачествености их разработок. Не интересно ни читать ни вникать в то что есть грязь. Не нравится Мигишоп, покажите свой продукт, не то что вы выдаете за него (нечно собранное на костылях), а продукт со всеми теми удобствами для конечного пользователя, какие явно есть у Минишопа. А все бла-бла-бла про миллионы товаров…
Перед тем как сотрете мой комментарий, или забаните меня, задайте себе вопрос, на кой черт вы тратите время и силы га удовлетворения своих комплексов, оставшихся вам от пубертатного периода. Да, Николай, я читал все что вы пишите, вы специалист, но как человек вы просто застрявший в пацанячем возрасте подросток. Очень позорное поведение для статуса «амбассадор».
Перед тем как сотрете мой комментарий, или забаните меня
Я не Василий, такие комментарии не затираю, и людей за критику без матов и явных оскорблений не блокирую.
Но ваш комментарий основан полностью на отсутствии собственного опыта. Вы смотрите на конечные сайты, сделанные безумкиным. А собственные сайты у вас есть. У вас есть готовый магазин на минишопе? Крупный и классный. Есть? На хамстере дизайн совершенно далек от того, чтобы им восхищаться, и это портит конечно картину. Но если вы именно по красоте морды определяете уровень разработки, то посмотрите хотя бы www.factum-doors.ru/
И да, это на моем shopModx-е сделано.
А теперь простое сравнение: в мамабутик вообще нет ничего такого, чего я не смог бы сделать на shopModx, при чем в считанные дни. Просто пока заказа на это не было. Но www.factum-doors.ru/ с тринадцатью тысячами товаров и на modxcloud.com за $10 легко крутится (во всяком случае пока не перекинули на сайт клиенту), а мамабутик с сотней товаров на VPS или типа того за $80 крутится.
Во-вторых, какой там говорили бюджет у мамабутик? примерно 300 000? (и потом за хостинг по 2500 в месяц платить). А factum-doors.ru + его зеркало для оптовиков (сайт выглядит по-другому и цены другие, но каталог единый) выполнен был за гораздо меньшие деньги. Может для вас и нет прямой разницы за какие деньги что сделано, но для клиента есть. И для разработчика тоже, так как чем меньше издержки, тем больше профит.
В общем, ваш коммент — это очередной коммент рядового фаната безумкина, коих тысячи (комментов). А рядовой фанат безумкина — это тот, кто не умеет программировать и не понимает разницу между хорошим продуктом и не хорошим. Те, кто умеет программировать, знает цену безумкинским «продуктам».
Но это так, к слову. Раз уж вы этот момент зацепили. А не к слову: в данном топике ваш любимый минижоп вообще с боку-препеку. Не он цель. Здесь разбирались тормоза самого MODX-а и т.п. Но вы этого явно не поняли. У вас мозги безумкиным заплыли. Так что если хотите хоть что-то понять, попробуйте еще раз внимательно перечитать.
P.S. Амбассадор я вообще не за умение корректно общаться или типа того. Амбассадор я за свои знания. Так что ваши выпады по поводу моего подросткового возраста или типа того меня вообще не трогают. Меня далеко не все уважают, но в своих кругах знают во всем Мире. А вы — просто еще одна недовольная тень, коих миллионы. Всего хорошего!
Морда: Memory: 9 Mb
TotalTime: 0.2817 s
здается мне, на сервере (если VDS) или хостинге — дикий оверселлинг (короче говоря в свопе сидит).
Ловика, братуха:
?
Еще бы я поставил настройки кеширования в modx так, чтобы кеш не сбрасывался вообще. если при повторном заходе спустя несколько часов опять будут тормоза, значит уперлись в дисковую систему носителя. что и есть, по сути своей, оверселлинг (ну и винты стоят там какие-нить типа IDE).
Что, вообщем-то, похоже на правду: Estonia Johvi Fastvps Network For Vps
Вот это ты в кассу кинул!!! :-)
Уже не мало из тех, с кем мы изначально были в конфронтации, сейчас в очень даже хороших отношениях. Но почти все они умеют программировать. То есть чтобы изменилось отношение, человек должен не на личность смотреть, а здраво на его разработки и знания. И когда понимание формируется, что знания есть, и они полезные, тогда человек прекращает зацикливаться на личности.
вероятно, там просто мозгов много, а еще вероятней, что memcached стоит на отдельном соседнем сервере, гигов на 20-60, и вуаля, весь хлам банально в мозгах, оттуда и скорость. 24 ядра способствуют в этом случае только математике и парралельным нагрузкам с разных пользовательских аккаунтов, но не являются, что любопытно, главным ускорителем.
Правильнее говоря, не обязательно только memcached на отдельном сервере. вот тебе, по сути, и личное облако. добавь хорошие винты — и всё, хостинг провайдер. гыгы
Я точно не скажу (не сисадмин), но swap там вообще не выделен. 0/0.
Но проблем здесь сразу несколько. Элементарно, там всего один процессор, и при заходе на страницу с каталогом (там же постраничность и результат не кешируется), процессор грузится на 100%. То есть если возникает параллельная задача, то на нее просто нет ресурсов, и она выполняется последовательно.
Плюс судя по всему медленные диски.
А скорость скачет. Вот сейчас зашел туда же (в машинки):
Memory: 19 Mb TotalTime: 3.2951 s
Но я сейчас сделаю копию сайта на modxcloud.com и сравним работу.
Если интересно скину свои наблюдения по настройке кеширований.
1. Если у нас железяка.
а) modx revo Ставим на файловый кешинг
б) ставим xcache или apc
в) забиваем на всё навсегда.
2. если у нас VDS с диким оверселом
а) увеличиваем тариф до 512 или до гига.
а) ставим memcached мегов на 128 и с бесконечным TTL.
б) добавим xcache или apc по вкусу мегов на 32-64.
в) modx revo ставим на кеширование в memcached или, после коротких экспериментов, в xcache/apc.
г) забиваем на это дело надолго и наблюдаем недели две.
3. если шаред
а) меняем на VDS и смотрим пункт №2, ибо настройки шареда могут быть совершенно дикими, да еще и сам шаред на VDS может находиться в диком оверселе.
swap на VDS выделяется с ноды, а сама нода (материнский сервер) сидит в такой глубокой попе в свопе, что на всех вас там гига 2 физической памяти, отсилы, но каждому из вас дано якобы «по гигу».
Конечно, этот гиг — это своп по сути и есть, и все клиенты теснятся в этих самых 2х гигах физической памяти (включая ноду).
А так как диск там, обычно, IDE какой-нибудь, от старого ноутбука, то всё упрётся в диск так, что ни один скрипт не отработает.
Так обычно выглядит дешевый VDS изнутри.
Кроме того, 100% нагрузка одного ядра еще не означает, что он и правда на 100% работает, так как его тоже порезали, скорее всего, раза в 4.
Оттуда мы получаем VDS 1 ядро с гигом памяти. На самом деле это «ноутбук» прошлого века и на нем таких клиентов штук 16. Вот и секрет.
ЗЫ. проверь cloud, судя по всему там мозгов много.
Да, вот такие моменты очень полезны. Спасибо!
Я в недалеком будущем планирую одну штуку замутить, обращусь за помощью к тебе. Надо будет очень хитрый сервер настроить. Кстати, на днях нас ждет очень интересные новости из MODX, и там будет кое-что, что нам очень даже туда пригодится.
Тебе замут понравится :-)
Вот сейчас разверну на modxcloud.com и все будет видно в сравнении.
скинь потом результаты сравнения, чтобы показательно было
Без проблем, пиши если что.
А его опубликую и посмотрите. Просто скрою от индексации.
А теперь смотрим на нормальном хостинге: hamster-2.fi1osof.modxcloud.com/
Покажите-ка там страницы тормознутые.
Писец… Зацени работу на modxcloud.com: hamster-2.fi1osof.modxcloud.com/
Внутренняя из кеша:
Memory: 8 Mb TotalTime: 0.0605 s
Не вопрос, тут быстрее. Об остальном: ни какой пристрастности, когда быстро- тогда быстро, когда текст написан без «грязи» и поливания говном, тогда есть уважение к автору и можно думать о сути сказанного, а когда автор забывает что ни какие знания не заменяют и не выше человеческих качеств — то налицо личностные комплексы и т.п.
Вы вот сами задали как будто мне вопросы сами на них ответили («высосав» что то обо мне из пальца), а все почему? Потому что есть некая болезненная для вас тема, где специалист в одной области борется со своим альтер-эго — человека страдающего нереализованными амбициями. Потому вы часто ссылаетесь на достижения, признание вас, ваши знания и т.п. Куда было бы ценнее когда бы эти ваши качества отмечали другие люди, как некий индекс цитирования, а вы бы скромно о них умалчивали. И еще, о статусе так называемого посла, за что бы вам его не дали, сам статус обязывает быть дипломатичнее, что бы как минимум не позорить то сообщество которое оценило вас и наделило соответствующим статусом, да, как специалиста, но, Амбассадор — само слово имеет только одно значение, и исключительно обязывает уметь общаться. Ваши рассуждения о человеческих качествах и суждения о людях очень портят общую картину ваших дел. Всего то, писать по сути, работать над своими проектами и избегать грязи в адрес иных своих «коллег по цеху», и будет вам уважение. А еще, поищите другие и цитаты Ганди )) Вот кто не одобрил бы ваш стиль общения, Николай. Успехов.
Всем не угодить. И я уж точно не буду никому пытаться угождать. У меня не комплексы, а завышенные эгоистичность и эксцентричность. Если вы типа рубите в психологии или типа того, то разницу должны уловить.
И скажу просто: здесь ресурс в первую очередь для специалистов. Есть что сказать обоснованное по технической части? — милости просим. Пришли обсуждать мою личность? — мне вообще пофиг. Заведите здесь же соседний топик и пытайтесь поливать меня грязью — мне все равно. Но технический топик флудить рассуждениями и высоком не надо. А то воды налили, но ни одного «коллегу по цеху» ничему не научили. А значит пользы с вас ноль.
совсем другое дело!
вот и показатель узких мест у русскоговорящих «хостингов».
Ага. Но на таймвебе сейчас тоже круто. Они итак-то хорошо работали, но сейчас VPS-ки и т.п. все перевели на твердотельные накопители, там сейчас вообще все летает.
За последние 7 лет я убедился насколько, что русскоговорящие хостинги не исправимы, что я еще ни разу не нашел столь же убедительного подтверждения обратного. Поэтому я больше не рискую как по этой причине, а также и по многим другим соображениям (включая похеривание бэкапов и блокировки без причин).
Кстати, давай-таки расковыряем параметры modxcloud? там же вроде есть доступ по ssh? очень интересно узнать как они достигли таких потрясающих результатов для столь, казалось бы, невыносимо медленного сайта. А?
Так поковыряй. Дев-аккаунт там бесплатный. ssh и в бесплатном аккаунте есть. Но там не полноценное облако, а урезка, и многих команд вообще нет. Так что не знаю нароешь ты там что или нет. Если нароешь, напиши топик здесь же, интересно будет почитать.
Попутно. Посмотрел таймвеб — можно взять VDS за 1130 руб. в месяц с гигом оперативы и 10 гигами SSD.
Маловато места. И нашел вот такое в другом месте:
2x HDD 1,5 TB SATA
1x SSD 240 GB SATA
6x RAM 2048 MB DDR3
за 75.00 €
устроим свой хостинг?
ну или вот:
1x SSD 120 GB SATA
6x RAM 4096 MB DDR3
78 евро
тут, я полагаю, не только магазинчик заработает быстро…
ЗЫ. А у меня сейчас железо тоже стоит, но с обычным винтом и именно в него упирается, кстати.
24 гига оперативы нифига не спасают отца нью-русской демократии если винт в мощном бекапировании например (при этом не помогает уже ничего, если там миллионов 12 файлов).
устроим свой хостинг?
Вот как раз это нам и предстоит с тобой сделать :-)
Но не хостинг в чистом виде (то есть я не планирую делать хостинг, на котором основной статьей дохода были бы услуги хостинга), а кое что другое. Когда я доберусь это делать, я тебе обязательно маякну. Буду надеяться, что получится заняться этим очень скоро.
На самом деле можно смотреть в сторону nginx+APC+MODX. Получится очень хорошо. Только все динамические части сайта надо на AJAX переносить, чтобы nginx мог отдавать полный кеш страницы без обращения к MODX-е в принципе.
Я думал о похожем решении, но именно Ajax и остановил меня, так как он не индексируется поиском вообще. Чтобы ни говорили, он НЕ индексируется или, по крайней мере, у меня неправильный ajax. Но как ajax может быть неправильным?
А хрень в стиле site.ru/page1# ради выдачи поиску не-Ajax версии меня не устраивает в корне.
Ajax хорош, если не рассчитывать на поисковые системы вообще и продвигаться другими путями. Например политическими.
А вообще в тему, то я так до конца и не понял как еще распараллелить создание выходящей html страницы используя например все ядра процессора, и не использовать при этом Ajax. Частично это таки решается, но не полностью.
Кроме того, у меня есть приятель-админ многопосещаемого ресурса, там применяется похожая идеология, но у него сайт не строится динамически под каждого юзера, поэтому скриптами он подгружает данные о логине и всё.
А если сайт строится под юзера или строится относительно страны посещения? И так далее, тут динамика и еще раз динамика.
Я решил это так: для анонимуса всё уже закешировано до мозга костей, причем всё лежит уже в HTML, подгружая например курсы валют и погоду отдельно. Но это наталкивается на такие вещи, как мультиязычность сайта, что тоже должно быть динамическим. И так далее.
Короче говоря, одно из решений — это распаралеливание работы php на все ядра, как я вижу. А не так, как обычно: пока страница грузится, одно ядро занято на 100%, а 7 ядер, к примеру, простаивают.
Куда-то сюда я думаю надо копать.
Давай, даже только для своих проектов это уже стоит того, чтобы оно было.
Нет, с индексацией проблем нет. Вот посмотри к примеру этот каталог: portfolio-home-ex-ru.fi1osof.modxcloud.com/catalog/
Он Ajax-овый, при это все ссылки — реальные. Просто на сервере логика хитрая. То есть любую ajax-ссылку можно открыть в соседней вкладке, и она будет вести на целевую страницу.
Но я имею ввиду именно те динамические элементы, которые не надо индексировать, то есть форму авторизации, личный кабинет и прочие плюшки, которые меняются для конкретного пользователя. Просто в классическом виде, когда пользователь заходит на страницу, для него могут выдаваться данные, которые актуальны конкретно для него. При этом сама страница может быть общая для всех. Так вот, все, что общее (саму страницу), после первого захода загонять в кеш и уже нгинксом отдавать при последующих заходах. А все индивидуальное — все через AJAX.
P.S. еще одно интересное AJAX-решение: omaxgames.fi1osof.modxcloud.com/ (попробуй скопировать адрес внутренней страницы и открыть в отдельной вкладке (вставив адрес, как будто первый заход)).
Описал свои взгляды на это в предыдущем комменте. А по поводу распараллеливания: так ведь nginx вроде как это и делает. Если в системе несколько ядер, то под отдельные запросы он использует разные ядра.
ssh у modxcloud, как я узрел, есть только на платных тарифах. По крайней мере меня не пустило, а может уже и забанило за 3-4 неудачные попытки войти. Наплевать.
Но то, что я уже успел понять используя доступные данные, вполне может повергнуть в шок: там нет апача!
Вот так, олдскул уже не рулит.
Короче,
0. Linux 64 бита (сборка достоверно не выяснена)
1. Mysql локальный, то есть всё просто и на одном месте и никаких облаков. и для целей такого хостинга вполне подходит.
2. Кешер APC, всего на 64 мега
3. nginx/1.2.4 и FPM / FastCGI
и нифига ничего больше нет, судя по всему.
придется пересмотреть свою любовь к апачу и к тяжелым увесистым решениям… ой, придется, я чую…
Если накопать бы полный доступ, было бы приятно узнать внутренности и склонировать их себе.
Вах вах, какое приятное и элегантное решение в твоем P.S. Вах вах (качаю головой и подбираю слюну)
Под отдельные запросы и апач может. я имел ввиду под один запрос. а то получается, как раньше — в компе 4 ядра, а компьютерная программа работает только на одном, совершенно не используя 3 ядра. Но если запустить еще 3 таких софтины — то все лягут все равно на одно ядро.
В нашем случае выглядит так: 1 запрос — одно ядро. Представим, что скрипт выполняется 60 секунд.
Запускаем 1 раз — одно ядро работает. Тут же запускаем еще раз — второе. Третий раз — третье начало работать.
Спустя 60 секунд первое ядро освободится. Но это не то, что нужно.
Должно быть так:
Запускаем скрипт и он резво цепляет все, например, 8 ядер сразу. Выполняется, стало быть, он почти в 6-8 раз быстрее. Именно об этом я говорил.
Сейчас же это решается путём того же ajax:
1. Запускам скрипт,
2. Тот вызывает 7 доп. запросов к другим скриптам.
результат: все 8 ядер учавствовали в работе.
Но это, мягко говоря, несколько криво. Почему PHP не юзает все 8 ядер сразу?
Так это, а никто и не говорил, что там суперхостинг. Для меня там главное — это снимки сайтов и т.п. То есть чисто плюхи для Ревы. А сам хостинг много вопросов вызывает, на которые я уже давно забил. Очень просто момент: там нет cron!!!
Но обо всем этом, как я и говорил, чуть попозже ;-)
По-моему, я чего-то не уловил. Можешь дать чуть более развернутый коммент?
Эээ, придержи коней :-) Зачем тогда мучать php? Пойдем уже сразу на nodx.js? ;-)
Да просто красиво замутил, я восторгнулся и выронил слюну.
Ну я думал об этом, но переучиваться сейчас полностью когда, можно сказать, все проекты на PHP, как-то мне не очень симпатизирует эта идея. Да и знакомый программер на js говорит, что не стоит этого делать (может, конечно, он так себе забил местечко под солнцем, кто знает).
Если ты уже умеешь программировать, то переучиваться на новый язык — это как-то слишком сильно сказано. Да, есть особенности, но это все равно не с нуля учить.
Да и знакомый программер на js говорит, что не стоит этого делать
Вот это ооочень спорный вопрос. php и js — принципиально разные языки, и подходы в разработке с ними тоже совершенно разные. php — последовательный язык, а JS — событийный. Не хочу сейчас вдаваться в тонкости и обсуждение этих языков, но я всерьез планирую добраться до node.js, как только появится немного времени.
Попробуй, затем поделись впечатлениями. Я пока по старому на php порисую, хотя, не спорю, чаще требуется новые и интерактивные решения.
Вот то, о чем я тебе говорил: modx.com/blog/2013/07/25/welcome-back-modx-cloud/
Будем свой облачный хостинг делать;-) Вливаешься?
В личку перехожу