Около пяти месяцев назад я завязал с zend framework и пересел на рельсы. Тогда же начал переписывать свой проект www.okinfo.ru. Сейчас он уже закончен и sloccount показал что количество строк в проекте уменьшилось с 15000 до 4000. Мои знакомые php разработчики попросили success story и в итоге родилась эта статья. В ней я опишу как оно было, а так же немного расскажу о своем переходе на ruby.

В то время, как я закладываю основу новой клиентской библиотеки для работы с Datastore с поддержкой асинхронных запросов, я добавил кое-какой низкоуровневый функционал, который Вы можете использовать уже сегодня. Единственный API с документированной поддержкой асинхронных запросов – это urlfetch. И этот функционал может оказаться довольно полезным.

Прекрасная тридцатиминутная история (на английском) от Джеймса Голика — CTO американской бдсм-соцсети выдерживающей 180 000 000 реквестов в месяц, при среднем времени отдачи ~200 мс, имея шесть серверов. В двух словах — смотрите тэги.

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

Как вы уже знаете из предыдущей статьи, в App Engine есть множество способов хранения информации. Но многие из них весьма специфичны, и для повсеместного пользования подходят всего три: память инстанса, memcache и datastore.

Под катом вас ждёт изложение в цифрах и картинках, краткие рекомендации по кэшированию и исходные коды простого cacher'a и приложения для тестов.

Всем доброго времени суток! Новогодние праздники позади, все хорошо отдохнули. Тем не мнеее, даже в праздники иногда появляется работа. Мне, к примеру, довелось покопаться в чужом коде на Python. Код хороший, замечательно документирован, но во время чтения не покидало ощущение, что автор читал доки по Python и портировал код с Си-подобного языка. Это меня вдохновило на написание статьи с указанием ошибок, которые неизбежно возникают при переходе на Python с Си-подобных языков.

Статья пригодится тем, кто недавно пишет на этом языке, а также для тех, кто пишет на нем маленькие скрипты, не заморачиваясь на деталях.

Одной из проблем, с которой сталкиваются GAE-разработчики, привыкшие работать с реляционными СУБД и ORM, являются ссылки и отношения в App Engine. В данном руководстве рассматриваются два вопроса: во-первых, что вообще представляют из себя отношения в СУБД?; во-вторых, как ими пользоватья в GAE?

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

При этом многие представители обоих лагерей придерживаются мнения, что Node.js — это эзотерическая игрушка, веселая задумка для переноса языка браузерных сценариев на «новые колеса». Дабы быть до конца честным, признаюсь, что я так же придерживался подобной точки зрения. В один прекрасный момент, я набрался духу и решил «копнуть поглубже». Выяснилось, что создатель Node.js Райан Дал далеко не фанатик, а человек, пытающийся решить реальную проблему. А его творение — не игрушка, а применимое на практике решение.

Если вы хотите научиться писать многопоточные приложения на PHP или здорово упростить себе жизнь — статья для вас.

Раньше для этих целей я пользовался либо запуском несколько копий скрипта, либо же использовал pcntl на более низком уровне, чем хотелось бы. Это, а от части и Java-идеология работы с потоками, побудили меня к написанию пакета phpThread.

Есть вроде бы обычные задачи, которые можно решить сразу и не задумываясь, но при интенсивном использовании таких решений возникают проблемы, причем не маленькие. Об одной из таких задач я и хочу рассказать.

Последнее время оживилась публика с вопросом случайной выборки из таблицы. Решений по оптимизации полно, и нового сейчас я вам наверное ничего не покажу, просто напомню про основные методы оптимизации — упрощение запроса и индексацию. Без предисловий про фриленсеров, сразу к делу ;)

Что такое PHP Speedy? Это набор php-скриптов, которые позволяют объединять и сжимать CSS- и JS-файлы для веб-сайта, написанного на PHP. Изначально разрабатывался как приложение к Wordpress, но сейчас получил более широкое распространение.

PHP Speedy был выбран в качестве основы для начала разработки Web Optimizer — веб-приложения, автоматизирующего клиентскую оптимизацию. Предполагается, что такое приложение можно будет максимально быстро и максимально легко развернуть на любой платформе, а оно уже само позаботится о всех действиях, связанных со скоростью загрузки страницы.

Как показала практика, клиентская оптимизация интересует большой круг людей. Но очень многих останавливает то, что нужны специальные знания для освоения этой области. Web Optimizer создается как раз, чтобы убрать этот барьер (и как наш ответ Чемберлену www.getrpo.com :).

Порой мы отображаем на сайтах контент с других ресурсов: картинки или фавиконы. Некоторе браузеры просто оставят пустое место (Firefox), другие же отобразят уродский прямоугольник, явно указывая, что чего-то не хватает (IE). Как же можно средствами PHP проверить существование файла.

Есть функция file_exists(), но она хороша только для файлов в пределах нашей файловой системы, а с удаленным сервером не пройдет.

Есть вариант открывать файл на чтение и в случие ошибки констатировать факт, что файла не существует:
<?
// файл, который мы проверяем
$url = "http://url.to/favicon.ico";

// пробуем открыть файл для чтения
if (@fopen($url, "r")) {
echo "Файл существует";
} else {
echo "Файл не найден";
}
?>


Однако такой прием занимает достаточно много времени.

Есть вариант еще лучше — использовать функцию get_headers():
она делает запрос к файлу и получает все заголовки с ответом примерно в таком массиве
Array
(
[0] => HTTP/1.1 200 OK
[1] => Date: Sat, 29 May 2004 12:28:13 GMT
[2] => Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
[3] => Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
[4] => ETag: "3f80f-1b6-3e1cb03b"
[5] => Accept-Ranges: bytes
[6] => Content-Length: 438
[7] => Connection: close
[8] => Content-Type: text/html
)


Как мы видим, в нулевом элементе есть код ответа, 200 значит, что файл существует, и мы спокойно можем получить к нему доступ.
Вот код, который проверит существование файла.

<?
// файл, который мы проверяем
$url = "http://url.to/favicon.ico";
$Headers = @get_headers($url);
// проверяем ли ответ от сервера с кодом 200 - ОК
//if(preg_match("|200|", $Headers[0])) { // - немного дольше :)
if(strpos('200', $Headers[0])) {
echo "Файл существует";
} else {
echo "Файл не найден";
}
?>


Теперь сравним по времени два метода с существующей favicon и с несуществующей:
при несуществующем файле второй метод (get_headers) выигрывает на две сотые секунды.
при существующем файле оба метода показали примерно одинаковое время.

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

REST (Representational state transfer) — это архитектурный стиль или свод соглашений для web-приложений и сервисов, основанный на манипулировании ресурсами и спецификацией HTTP. Впервые об этом заговорил Рой Филдинг (Roy Fielding) — один из отцов основателей HTTP (Hypertext Transfer Protocol).

Web-приложения зачастую игнорируют спецификацию HTTP и двигаются вперёд используя полюбившиеся возможности: GET и POST, 200 OK и 404 NOT FOUND. Так как используются программируемые web-приложения, со своими собственными API, то решение игнорировать спецификацию HTTP, может создать проблемы в дальнейшем. Как следствие — имеем множество приложений с интерфейсами GET и POST. Например интерфейс удаления пользователя: GET /user/1/delete против POST /user/delete {id=1}; в случае REST можно указать /user/1 это ресурс, а удаление HTTP метод DELETE.

Так исторически сложилось, что домены сайтов называют с префиксом www или без.

Есть несколько взглядов как истинно должен называться домен, прогрессивное человечество считает, что без www — nowww.ru, многие западные эксперты считают обратное.

Однако речь не об этом, а о том, как в наших любимых web серверах организовать постоянный редирект туда-обратно.

Примечание: ниже перевод статьи «Non-blocking JavaScript Downloads», в которой автор рассказывает о проблемах, связанных с подключением JavaScript-файлов, и возможной параллелизации их загрузок. Мои комментарии далее курсивом.

Об авторе: Stoyan Stefanov является веб-разработчиком Yahoo! в группе Exceptional Performance и курирует разработку YSlow — инструмента по измерению производительности. Он также внес значительный вклад в разработку продуктов с открытым кодом, выступал на конференциях и автор технических текстов. Его последняя книга Object-Oriented JavaScript.

Внешние JavaScript-файлы блокируют загрузку страницы и сильно влияют на ее производительность, но существует достаточно простой выход из этой ситуации: использовать динамические теги script и загружать скрипты параллельно, увеличивая тем самым скорость загрузки страницы и улучшая пользовательское восприятие.

читать дальше на webo.in →