17 Гб ОЗУ на запрос? — Это перебор для меня, тем более, что я знаю о шарпе, ровно то, что есть такой язык программирование) Пытался ознакомиться с вашим ответом и комментариями по ссылке, но там что-то на марсианском) С деревьями таблиц познакомлюсь.
Вариант, несомненно, верный для уточнения при совершении запроса посетителем, но есть пара но. 1. Вопрос о частоте смены (может быть, есть опыт, знаете. 2. Запрашивать таким образом адрес при каждом посещении ресурса может быть накладно — цепочка запрос-ответ может занять значительное время, а для скорости открытия страниц — это не очень хорошо.
Как я понял, по сути, есть только эти две глобальные переменные, в которых содержатся доступные сведения о посетителе сайта. Других данных в PHP о посетителе просто нет. Верно?
А могли бы конкретный пример/код привести? Что-то не получается.
Только вот не понял связь между PHP-файлом и событиями Modx.
Поясню. Человек в браузере запрашивает адрес страницы сайта. В работу включается MODX — что то там делает (инициализирует, обрабатывает чанки, сниппеты, шаблоны, парсит и прочие штуковины делает. На все эти действия MODX тратит какое-то время, к примеру, на инициализацию чего-то там 50 мс, на парсинг шаблона 50 мс, на обработку чанков/сниппетов 100 мс и того набегает какое-то время.
У меня есть PHP скрипт (в файле file.php), который должен выполняться максимально быстро после запроса страницы человеком. Если я подключу как-то этот скрипт ДО всех работы MODX, тогда скрипт после запроса страницы будет выполнен сразу, а не ПОСЛЕ условных 200 мс (то время, которое необхомо MODX на обработку своей внутренней кухни).
Привет. Выше уже ответил, что не встречал такого калькулятора.
А про сопоставление — все просто. Есть два массива. Один содержит весьма конкретные адреса, второй вот эти подсети. Разворачиваю подсеть в конкретные адреса и что-либо делаю с этими двумя массивами: ищу одинаковые элементы, разницы, добавляю, вычитаю. В общем, для целей анализа адресов надо.
Я искал уже такие штуки, перепробовал вариантов 10–15 — все они показывают стартовую позицию адреса и конечную. Есть исключения и показывают больше адресов, но и в них есть какие-то пропуски.
Владислав Лысков, Интересное решение, такое простое, из него сразу стало все понятно, даже уточняющих вопросов не осталось.
Вопрос: как нагрузить? Ответ: нагрузи!
::два_больших_пальца_вверх::
Ankhena, в этом случае если второй и третий элементы помещаются на одну строку, то они будут на одной строке, т. е. большой первый элемент может занять всю строку, а второй и третий окажутся небольшими по ширине и займут вторую строку, но тут важна логика: каждый элемент должен занимать свою отдельную строку при нехватке ему места.
Нет, не то это. Поясню. Если сделать случайную ширину элементов, то при достижении определенного размера ширины окна браузера элементы в зависимости от их ширины и доступной ширины контейнера не будут идти именно в той очередности, в которой показал я на примере в вопросе. Вот вам наглядный пример из вашего примера:
А надо чтобы была универсальная логика при любых ширине элементов и ширине окна браузера, т. е. при любом раскладе: третий элемент уходит на второю строку первым, второй — на вторую вторым и никак иначе. Тут, наверное, все-таки, JS нужен.
