HTTP и Закон

Юристы разницы между POST и GET делать точно не будут. Да и не нужно это. Это не более, чем детали реализации коих в юридическом контексте знать не нужно. А вот брудфост значим, т.к. говорит о намеренной и целенаправленной попытке получить несанкционированный доступ.

HTTP и Закон

VolCh прав, в УК РФ в статья в духе 282-283 говориться о предоставлении секретных сведений к которым лицо имеет служебный доступ для третих лиц. Если чиновник забыл документы, их нашел посторонний человек и опубликовал, то ответственность несет чиновник. Если есть в законе статья регламентирующая механизм привлечения третьей стороны (нашедшего), то хотелось бы узнать какая из.

Разработка Web-приложения с использованием AJAX + REST

Хм, про range… Больше получится заметка, а не статья. Хотя почему бы и нет, по RESTful в рунете инфы не так много. Пожалуй зарелизю движок и займусь статьей.

Разработка Web-приложения с использованием AJAX + REST

Предлагаю зайти от getEvents и пейджинга. Что мешает на клиенте в файле конфигурации хранить page, per_page и делать вызов в духе: /getEvents?page=1&per_page=5? per_page хранить в настройках программы, page понятное дело считается в рантайме.

P.S. Хотя в контексте RESTful и пейджинга я все же ратую за использование более правильного, с точки зрения идеологии, подхода. Работа через *Range заголовки. Благо согласно RFC 2616 unit может быть и свой, а не только bytes.

Разработка Web-приложения с использованием AJAX + REST

Не очень понятно про «мало команд — больше настроек». И почему в клиенте нельзя менять настройки? Из-за хардокда в духе «количество элемента на странице»?

Linux: разрешение на удаление файлов, но запрет на создание

Там есть обратное — запрет удаления (флаг u). Не говоря уже о том, что реализация xattr на многих системах по прежнему не полная.

Aсинхронную очередь заданий для PHP?

Поддерживаю. 200 кхитов на высокую нагрузку как-то не тянут. На PHP вполне реально уложившись в 200МБ ОЗУ отрабатывать этак миллионов 20 хитов, т.е. в сотня раз больше.

Альтернатива EAV, структура базы?

>Действительно, получить карточку одного товара, используя данную струтуру не составляет проблемы.
Иерархия в отдельной таблице в виде AL или NS по ситуации. Связь с товар-лист_дерева через треть таблицу. Это покрывает текущие бизнес требования. В частности поиск по конкретным атрибутам не требуется, для интернет магазина одежды логика поиска «хочу красную рубашку ХХ размера» обычно приводит к быстрой выборке рубашек с использованием индекса и более медленной, но в рамках приложения быстрой, фильтрации по значениям атрибутов. Это с лихвой перекрывает текущие требования причем с большим запасом. Если бы это был каталог компьютерного оборудования с частым поиском по набору атрибутов, то конечно же такая структура бы не использовалась.

За наводку на UDA спасибо.

PHP класс роутера

rewrite в том или ином виде есть во многих веб серверах. К примеру, в nginx.

Альтернатива EAV, структура базы?

«Отрабатывает» значит выполняет sql запрос.

=> SELECT COUNT(*) FROM goods;
 count
--------
 250000
(1 row)
=> SELECT COUNT(*) FROM goods_option;
 count
-------
 10000
(1 row)
=> SELECT COUNT(*) FROM goods_option_link;
  count
---------
 2500000
(1 row)

EXPLAIN ANALYZE показывает. что запрос получения карточки конкретного товара (у которого 10 параметров) занимает ~0.15 мс. PHP часть думает больше, чем запрос отрабатывается в postgresql-е.

Я всяких умных курсов не слушал. Я инженер и решаю конкретные задачи в конкретных условиях. Бизнес мало интересуют эти технические заморочки. Но представителям бизнеса хочется любое количество типов товара с любым набором характеристик и так, что бы при появлении нового типа не приходилось привлекать разработчиков которые буду что-то там колдовать в структуру таблиц. И конечно же это должно быстро и безбагово работать при увеличении каталога до миллиона позиций.
Вот и я решаю эти задачи. Поэтому у меня простой PHP движок которые держит поток в 300 запросов/сек с времени генерации страницы ~0,015 сек долговременно (т.е. ~25 миллионов в сутки). На отрезке в 5 секунд он мог обработать кратковременный всплеск нагрузки до 1000 запросов/сек с генерацией
страниц ~0.070 сек. При этом PHP часть потребляет менее 200 МБ ОЗУ. В целом же вся связка nginx+php-fpm+postgresql+redis кушает ~1-1,5 Гб.

Если завтра изменятся условия которые покажут, что EAV мне не подходит, я без проблем применю более оптимальную структуру. И уж точно я ни когда не буду религиозным фанатиком кричащим: %username%, твой %lang% гавно и %struct% монструозный монстр потому как я инженер и практик. И критерий адекватности для меня — эффективное выполнение поставлено задачи, а не абстрактные рассуждения теоретиков.

Какую структуру БД выбрать

В чем заключается задница в случае EAV?

Как создать структуру таблицы?

>скажем миллион записей будет
Миллион это совсем не много. Делайте как Melkij советует, это правильное решение. Касательно подхода не так принципиально, адейтить поле или удалять запись. Это спички.

Dedicated vs Cloud. Что выбрать?

Угу… и нахлынувшая армия ботов сожрет весь бюджет?

По мне все это облака это как платить помегабайтно за инет. Из тех, кто помнит модемные времена, типа меня, и кто сидит в наше время на анлимах, врятли горят желанием вернуться к помегабайтке.

PHP-FPM на рабочем сервере под Debian 6?

По мне, нет такого понятия как высокие нагрузки. Соответственно и книги такой нет. Просто нужно понимать механизм работы системы с целом и исходя из этого искать узкие места.

К прочтению могу рекомендовать:
«UNIX. Разработка сетевых приложений.» У. Р. Стивенс, Б. Феннер, Э.М. Рудофф
«UNIX. Профессиональное программирование» Стивенс У. Р., Раго С. А. (2-ое издание, посмертное)
«UNIX. Взаимодействие процессов» Стивенс У. Р.
«Ядро Linux» Д. Бовет, М. Чезати

Вообще Стивенс крайне крут, имхо, к прочтению обязательно любому сетевому программисту. Так же могу рекомендовать «выжимку» в том числе и из этих книг от наших авторов: «Операционная система UNIX»
Андрей Робачевский, Сергей Немнюгин, Ольга Стесик.

PHP-FPM на рабочем сервере под Debian 6?

В первом приближении он дает плюсы всегда. Но это не сказывается на скорости генерации ответа бэкэндом. Как оно генерилось, условно 2мс, так и будет генериться. Выгода от keep-alive получается если с бэкэндом связаны какие-то другие данные (картинки там) или идет поток запросов на коротком промежутке времени (в течении полуминуты). Смысл в следующем. Вот берем данную страницу. С ней связанно 19 ресурсов вещих на сервер хабра (1 запрос — сама страница, 18 — разная JS/CSS статика). Если keep-alive отлючен, то браузер открывает 19 разных TCP коннектов. Сама операция открытия пары сокетов достаточно «долгий» процесс, т.к. TCP гарантирует доставку и много времени тратится на согласование данных. Причем на сервере с каждым TCP конектом связаны разные данные, которые под себя так же требуют ресурсы. А это ведь только от одного клиента. Когда клиентов тысячи, то потребление ресурсов это уже не копеечный процесс, опять же повторюсь, установление соединения это очень долгий процесс. Но он открывается на каждый связанный ресурс. Поэтому и появился keep-alive при котором создается одно (возможно и больше, но всегда сильно меньше количества связанных ресурсов) TCP соединение и уже по нему передаются все ресурсы. Т.е. к примеру открытие страницы порождает TCP коннект, по нему сервер отдает страницу и по этому же коннекту передается JS и CSS и картинки. И для них не нужно тратить время на установление связи в виде трехэтапного рукопожатия. Данные можно передавать с ходу ведь надежный канал передачи данных уже установлен.

Поэтому по умолчанию можно и нужно использовать keep-alive. В тех случаях, когда он не нужен об этом обычно знают. Если нет точной причины почему keep-alive не нужен, то значит его нужно использовать без сомнений.

PHP-FPM на рабочем сервере под Debian 6?

>«max children reached» в моем случае нет
У меня есть. Но у меня 5.3.8 самосборный через checkinstall.

>Есть ли в nginx'е параметры, которыми можно регулировать эти вещи?
Нет, такого нет. И это правильно. Кроме того даже если и был, то бэкэнд все равно отвечал бы «свободных рабочих процессов нет», что автоматически означает разрыв коннекта. У самого nginx так же есть backlog, но он действует для него и внешних клиентов.

Кстати, если ресурсов не жалко, то можно поставить static режим. ОЗУ будет отжираться стабильно под завязку, но не будет оверхеда на запуск воркеров. Это сэкономит ЦП и время, но заберет ОЗУ. Ибо по мне dynamic механизм по сравнению с apache топорный.

PHP-FPM на рабочем сервере под Debian 6?

>700 конкурентных запросов, у меня на сервере тоже происходил затык.
Не удивительно ) для php который по дефолту пишет сесии на диск.

>Можно узнать про редис?
А не важно, memcached это или redis, оба in memory хранилища со стремлением к О(1) сложно на выборке. Просто пишем свой обработчик сессий который сериализует данные и закидывает их в это хранилище. Для сериализации рекомендую использовать igbinary.

Хотя при в «Registered save handlers»=memcache или redis, свой обработчик не нужен, extension сам знает куда данные закидывать. redis кстати сериализует в igbinary автоматом, если этот extension подключен. В общем крайне рекомендую к использованию: "Сериализация данных в PHP".

Профит redis перед memcached — условная персистентность. После рестарта он запихает данные в кэш с диска. Теоретически там может не быть заданных на время Х. Время Х регулируется через конфиг. На практике нормальный сервер просто так не грохнется на пустом месте, а на случай штатного ребута redis данные на диск скинет.

PHP-FPM на рабочем сервере под Debian 6?

Если лимиты на уровне ОС подняты, то их так же стоит подкручивать в nginx и php-fpm. Как я уже писал выше в php-fpm при дефелтном значении в -1 работает не так ожидается. Так что нужно явно задавать настройки.

Еще раз повторю, если если есть свободная ОЗУ, то увеличивайте количество рабочих процессов. Хотя для начала стоило бы убедиться, что дело действительно в этом. Включайте в php-fpm статистику на странице /status и смотрите что происходит. Самые любопытные поля: active processes — количество текущих работающих воркеров, max children reached — сколько раз мастер процесс пытался запустить дочерние процессы, но не смог из-за pm.max_children (если больше 0, то проблема имеет место быть).

Кстати, лучше изменить дефолтный pm.status_path=/status на что-то в духе pm.status_path=/status-phpfpm, т.к. лично у меня не удалось заставить связку nginx+php-fpm показывать статистику. Как я понимаю из-за того, что у nginx есть точно такая же страница со статистикой. У меня он передавал запрос на php (видно по заголовку power-by), но страницы была пустая.

Из любопытства на одном проекте запустил нагрузку с 2 машин. Конфиг сервера:

pm                      = dynamic
pm.min_spare_servers    = 2
pm.max_spare_servers    = 4
pm.start_servers        = 4
pm.max_children         = 10

Опции запуска нагрузки на каждом из клиентов:

httperf --hog --server ... --uri="..." --num-conns=1000 --num-calls=1 --rate 500

т.е. генерировать поток запросов в количестве 1000 со скоростью 2 мс (500 запросов в секунду), все запрос не в keep-alive режиме. Соответственно нагрузка на сервер 1000 запросов/сек. Ни одной 5хх ошибки. На клиентах:
одновременых коннектов: 1 — 280; 2 — 774
медиана времени ответа: 1 — 0,28 сек (ибо этот клиент в той же стране, что и сервер) 2 — 2,9 сек.
Нагрузка на проц и ОЗУ ничтожна, ЦП активен только в момент старта дополнительных воркеров. Так что крутите конфиги, делайте нагрузочные тесты.

PHP-FPM на рабочем сервере под Debian 6?

>Можно ли поподробнее про backlog?
В первом приближении это очень, в которую php-fpm должен ставить запрос полученный от nginx в случае, если у него нет свободных рабочих процессов. Как только появится свободный воркер он тут же получит запрос с ходу из этой очереди. Клиент в этом случае получать 502 не будет (по крайне мере до наступления таймаутов).

Увеличивая backlog нужно понимать, что 1) очередь требует ресурсов, копеечных, но ресурсов, поэтому на нагруженных серверах она обычно небольшая, проще 502 отдать; 2) клиент по полминуты ждать не будет (я думаю и самому приходилось закрывать вкладки на которых ни чего не происходило, ни контента нет, ни 502, но браузер показывает, что грузит данные) поэтому делать очень большой нет смысла, но части клиентов при пиках она может помочь (ну подождут загрузки страницы не 1 сек, а 5, тоже не очень хорошо, но все лучше 502-ой).

Если ОЗУ есть, то в php-fpm можно поиграться настройками количества рабочих процессов. В наше время это динамическая величина (в бытность fpm патча был только статический режим). Сильно увлекаться тоже не стоит, на линух сервере обязательно должна быть «свободная» ОЗУ ибо линух всю свободную память использует под дисковый кеш. При малом объеме такой памяти можно быстро просесть по диску.

PHP-FPM на рабочем сервере под Debian 6?

Это означает «по дефолту как в ОС». На сколько я помню в линухе это 128. Но тут есть даже не фишка, а хм… я думаю бага. Это задуманно было, что -1 это по дефолту, реально же оно 0. По крайне мере когда я по быстрому проверял, оказалось, что 0. Возможно, стоило бы еще с таймаутами поиграться. Но это уже детали, по умолчанию backlog для php-fpm работает совсем не так, как от него ожидается.