В mysqlnd появилась возможность выполнять запросы к MySQL асинхронно, то есть продолжить работу скрипта не дожидаясь выполнения запроса и формирования результата. Преимущество такого подхода очевидно, ведь можно выполнить массу полезной работы во время ожидания запроса, но для начала я приведу немного другой пример:

Допустим у Вас есть 3 запроса (q1, q2, q3), каждый запрос выполняется за определенное время (t1, t2, t3), например так:

SELECT 1 AS val, SLEEP(1) AS sleep
SELECT 2 AS val, SLEEP(2) AS sleep
SELECT 3 AS val, SLEEP(3) AS sleep

В случае синхронного выполнения запросов, Вы сможете получить результаты их выполнения через t1 + t2 + t3 (ex: 6 секунд), а в случае асинхронного выполнения запросов уже за max(t1, t2, t3) (ex: 3 секунды)

Примеры работы с асинхронными запросами, а также другие примеры работы с mysqlnd можно найти на github

Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

Samy Mamkar разработал систему, которая позволяет хранить куки в 8 местах, автоматически восстанавливая друг друга, и даже добиться того, чтобы куки, поставленное в одном браузере, действовало и в другом.

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

Внутри у среднего банкомата лежит от 1 до 3 миллионов рублей. Они разложены по 4 кассетам, в каждой из которых – купюры своего номинала. Замена кассет похожа на замену картриджей в принтере: модуль вынимается (и неважно, сколько там осталось денег — инкассаторы этого даже не знают по правилам безопасности), а на его место вставляется другой модуль точно по стрелке, указывающей, какой стороной и как это делать.

Инкассация — дорогая и достаточно рискованная с точки зрения безопасности процедура, поэтому любое обслуживание банкомата обходится довольно дорого. Естественное желание банка – уменьшить количество инкассаций. Получается классическая задача распределения ресурсов: с одной стороны, в банкомате всегда должны быть деньги для клиентов, с другой — в идеале банк хочет, чтобы ровно перед инкассацией из ящика уходила последняя купюра.

В последнее время термин “NoSQL” стал очень модным и популярным, активно развиваются и продвигаются всевозможные программные решения под этой вывеской. Синонимом NoSQL стали огромные объемы данных, линейная масштабируемость, кластеры, отказоустойчивость, нереляционность. Однако, мало у кого есть четкое понимание, что же такое NoSQL хранилища, как появился этот термин и какими общими характеристиками они обладают. Попробуем устранить этот пробел.

С недавних пор, заходя в Google Webmaster Tools, начал замечать у себя на сайте рост количества ошибок типа «Переход не выполнен», которые в моём случае возникали из-за так называемой циклической переадресации. Таковы уж особенности используемого «движка» сайта. Но ни в одном из браузеров данная ошибка не повторялась, при запросе «руками», то есть посредством telnet — тоже никаких аномалий замечено не было. Тем не менее, ошибки в GWT продолжали появляться вновь и вновь, указывая на те же самые URL'ы моего сайта и раздражая одним лишь своим существованием. Пришлось здорово поломать голову, но докопаться до сути проблемы всё же удалось.