Тут matem полез копать код гиперкеша (в связи с чем подозреваю, что в детстве он наверняка любил надувать лягушек через соломинку в ж), и в результате мы поменяли там функцию filectime на filemtime =) патамучта есть мнение, что в среде Windows Server filectime работает не так, как на unix.

Следите за рекламой, вобщем, пока главврач всё это не прикрыл

CPU стали жрать в 2–3 раза меньше, ну и плюс я традиционно с помощью левой пятки в отдельно взятый момент времени вдруг намерял, что на сервер влезет аж ~240 таких сайтов с такой посещаемостью. Т.е. недельку ещё полетаем, и если жалоб не будет, то можно считать, что экономика в этом всём какая-то вроде бы есть. Если MS починит cpulimit в седьмом IIS хотя бы до такого уровня, чтобы было хотя бы приблизительно понятно, что и как он там считает (т.е. до уровня IIS 6.0), то можно жостко выносить в бой, по-взрослому конкурировать с другими платформами, и т.д.

Ну и тут после всего этого ВНЕЗАПНО пришёл клиент с десятью сайтами на wordpress :-) На этом моменте я неиллюзорно завис

А пока я тут всё ещё развлекаюсь с WordPress, оставил для сайта в тесте только один instance php-cgi.exe (надо было сразу это сделать, не?), поскольку, например, один такой процесс больше 12.5% от двух QC CPU физически сожрать не может. Без кеша под ab.exe -n 1000 -c 10 сайт с WordPress и с одним процессом php-cgi обрабатывает аж, скажем, 10 запросов в секунду (если количество php-cgi увеличить до дефолтных четырёх, то иногда получается запросов эдак 25/сек., и, как я уже говорил, при этом довольно долго и успешно просирается процентов 50 от обоих CPU). Все возможные кеши я ещё не протестил, hyper cache всё ещё считаю лучшим, но постоянно вижу проблемы с тем, что протухший кеш не протухает вовремя. Можно его принудительно обновлять, даже раз в, эээ, три минуты, но с ним сайт может обслуживать и запросов 100-200 в сек., что для виртуального хостинга неплохо. А без кеширования сайт вполне можно использовать как “уютненький дневничок” начального уровня извините за шизофренический поток сознания но мне этот пых уже весь моск высосал рас рас адин адин

Для сравнения, скриншот работы tomillo.ru, сайт на ASP .NET под ab.exe -n 1000 -c 10

Прожевал 500 запросов в секунду “из коробки”, тупо на порядок-два быстрее вордпресса, .NET патамучта.

В пике до 80% CPU, ага, поэтому виртуальный хостинг тестить с помощью ab не надо, это никому не понравится :-)

И вот то же самое, ab.exe -n 1000 -c 10, только для test.tomillo.ru, wordpress без кешей, для полноты ощущений сайт обслуживают 8 инстансов php-cgi.exe:

Обратите внимание на длительность процесса, и обведённые циферки. Циферки – это CPU. Для одного сайта, их там суммировать надо, если вы не поняли :-). Причём в данном случае при снятии вот этого вот скриншота масштабирования производительности при увеличении количества процессов php-cgi.exe не произошло, вот они все обработали щаз 10 запросов в секунду, и всё, может мне не везёт с этим, не знаю :-)

Не, ab, повторяю, по большому счёту меряет сферических попугаев в вакууме, эмулирует работу сайта под DDoS, больше ничего. Сервис для массового пользователя на этом всём делать теоретически можно, и с юникс-хостингов причём народ с вордпрессом на windows-хостинг вполне себе побежит :-) Но практически глядя на всё это мне хочется для начала хорошенько убицца об стену. Два раза

Все четыре процесса видел запущенными только в будни, сейчас, в субботу, сайту хватает двух. Вот те маленькие всплески – это процентов по 10 от ресурсов сервера. Но, несмотря на это, жить вроде будет.

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

А то сейчас на ровном месте заклинило при ковырянии в профиле пользователя на Call to undefined function wp_enqueue_script() in bla-bla-bla user-edit.php on line 15, и оно потом же стало отдаваться другим юзверям при обращении к дефолтной странице, я аж с перепугу соответствующий пул в IIS перезапустил, думаю вот, шо это было.

У сайта тыща уникальных посетителей в день примерно, btw. Если сравнивать со средневзятой заточенной под столько посетителей интернет-лавкой на asp или asp .net, то впадаю в ужас сразу. Там визуально ну скачет потребление CPU от нуля, до 0.3, до 1%, ну может до 2%, если выше, то уже значит что у кодера руки этосамое. А тут “из коробки” каждый процесс php-cgi.exe норовит откусить 12.5% (это ядро одно, если б пых умел бы больше жрать, то сожрал бы больше). Поскольку закешировали всё что можно, это не при каждом запросе к прекрасному вордпрессу происходит, но всё-таки. По умолчанию вобще же АдЪ. Только-только начало доходить, что это ж красноглазики вот с этим вот пыхапе обречены навечно жить, весь этот их скрежет зубовный оказалось что неспроста :-) И деваться-то им некуда, дотнета нет, классического асп нет, а в существование Mono на юнихах в производственных масштабах я не верю :-) Так что жалеть их надо, понимаем, тяжело вам, ребята, жить в мире с бесплатным ПО. Так что крепитесь, вы не одни, мы вам сочувствуем и жалеем всей душой :-)

Ну ладно, пойду от вас попробую английский позубрить, иначе зачем в этот прекрасный вечер я лишил себя трёх заслуженных литров пива (страдает)

Боимсо

До:

После:

При этом сам вордпресс (см. код и /site/wp-admin) никуда не девался.

Сервер переехал на новый адрес и теперь успешно прикидывается IIS-ом :-)

REQUEST: **************\n
HEAD / HTTP/1.1\r\n
Host: borntolearn.mslearn.net\r\n
Accept: */*\r\n
\r\n
H
HTTP/1.1 200 OK\r\n
Content-Length: 0\r\n
Content-Type: text/html; charset=UTF-8\r\n
Server: Microsoft-IIS/7.0\r\n
X-Powered-By: PHP/5.2.11\r\n
X-Pingback: http://borntolearn.mslearn.net/site/xmlrpc.php\r\n
X-Powered-By: ASP.NET\r\n
Date: Fri, 06 Nov 2009 18:19:50 GMT\r\n
\r\n
finished.

httprint верит ему на 71.69%

“Что я наделал, что я наделал!”

И это всё на фоне того, что Microsoft опять потратил $100000 на развитие Apache. Безумный мир, не?

===

Я: Должны ли корректно обрабатываться url-и c кириллическим %postname%? В данный момент получаю 404 ошибку.

В качестве workaround можно использовать плагин к вордпрессу Cyr2Lat Slugs, например, заодно url-ы становятся читабельными. Но хочется, чтобы wordpress работал “из коробки” хоть сколько-нибудь корректно (без 404-ой ошибки), это возможно?

Р.Я.: Вы не знаете работает ли это на Unix системах? У меня есть подозрение что это может быть вызвано тем что IIS раскодирует УРЛ перед тем как сохранить его в серверной переменной REQUEST_URI, которая используется WordPress. Из за этого WordPress пытается раскодировать раскодированный УРЛ еще раз.

Эта теория подтверждается следующим workaround. Добавьте в начале wp-config.php вот эту строку с кодом:

if ( isset($_SERVER['UNENCODED_URL']) ) {
$_SERVER['REQUEST_URI'] = $_SERVER['UNENCODED_URL'];
}

После этого должно заработать. Но url-ы в адресной строке все равно не читабельные в IE8, хотя вполне читабельные во всех остальных браузерах (Firefox, Chrome, Opera, Safari).

Я: Я проверил кириллические пермалинки в вордпрессе на нашем стандартном unix-хостинге, с FreeBSD/Apache – там они сразу работают нормально, ну разве что URL-ы в IE8 тоже нечитабельного вида.

Р.Я.: Действительно проблема в том как иис обрабатывает закодированные урлы. В иис всегда было так что урл раскодирутся в самом начале обработки запроса и все модули уже работают с раскодированным урл. Похоже что на апаче это не так.

Я не думаю что в обозримом будушем в иис будет внесено изменение по этому поводу, но можно попробовать открыть тикет в вордпресс, чтобы они использовали UNENCODED_URL на иис. Должно быть тривиальное изменение.

===

Workaround этот работает, проверено. Кто хочет завести баг разработчикам вордпресса? :-)