Но ведь то, что не удалялись ссылки — это как раз и есть причина утечек памяти. А если в сокете ничего нет — то и память не течёт. Значит, мы выбираем память условно-пропорционально числу запросов (с поправкой как раз на «не всегда одинакового размера»).
Память по идее должна убегать условно-линейно с ростом счётчика. Иначе по закону сохранения получается, что она убегает даже в том случае, если в сокете ничего нет и никогда не будет. Так написать — надо очень постараться.
writing из nginx_stub_status? в том смысле, что за мгновения до «горбиков» все лочили друг друга, а потом разом отдали? имхо с натяжкой, writing может скакать по куче других причин, а вот если бы вы привели одновременно latency и cpu usage — можно было бы смотреть предметнее.
а можно подробнее, почему приведенный первый график описывает именно ту самую проблему одновременного доступа к кешу? казалось бы, трафик вырос — и число соединений тоже.
7 человек ничего не слышали про хантера томпсона, но картинка а) автора оригинала, поэтому вопрос надо задавать ему и б) действительно непонятно к чему.
>>SaaS (оно же облако)
В житейском смысле вы правы. Но формально saas != облако (saas — часть концепции облачных вычислений, но не единственная). Среди технарей «облака» — это в первую очередь резиновые ресурсы: инфраструктура и мощности как сервис, то есть под этим делом подразумевается в первую очередь облачный хостинг.
Мне, конечно, совершенно непонятно, причем тут «облака». Рекрутеру, конечно, важно знать buzzwords, но сыпать ими без надобности — вредно для кармы :)
Но по существу Вы правы, инструментов мало. Прежде чем расскажу, чем сам пользуюсь — оговорюсь, что я в-общем технарь, который совмещает разные роли, в том числе и «рекрутер по неволе» (ищем HR). Так что я банально могу что-то не знать. Всю информацию касательно поиска и статуса я решил пока хранить в вики. Я смотрел несколько разных сервисов — мне тупо удобнее вики. Постоянно порываюсь сделать что-то более удобное, но вовремя себя отговариваю. Для «понтового» хранения документов есть хороший сервис — box.net/. Предварительный отбор для меня неактуален: мой входящий поток — это несколько десятков резюме в месяц, причем я почти для каждого резюме делаю скрининг-интервью, т.к. для меня резюме не главное. Календарь в организации нужен много для чего другого, так что здесь нужна интеграция с теми же iCal и прочими — сервисов, которые такое умеют, я вообще не видел. Для тестирования мы сделали свои тесты — php.feedme.ru, т.к. прочие аналоги очень слабые, и проверяют только какие-то узкие компетенции. Но наш тест получился слишком уж забойным — впрочем мы и нанимаем людей сильно выше среднего уровня ;)
ты в шаблоне можешь cказать {{ escape($var) }} вместо {{ $var }} и всё. либо передавать экранированные значения. отсутствие автоэкранирования не ведет к xss само по себе ;)
про дублирование — я не понимаю о чем вообще спор. может быть ты приведешь какой-то свой пример, чтобы мне стало понятно, что именно ты считаешь ценностью и чего я не могу сделать при помощи blitz?
разве это имеет какое-то принципиальное значение? всегда для отображения дерева его либо надо разворачивать через стек либо писать рекурсию. всё остальное — как там будут отличаться ссылки и так далее — это всё мелочи, ну дополнительное условие.
так нечестно — попробуйте взять список списков и ввести логику специального отображения для первого элемента в каждом списке. в пхп будет всё отлично — но ничерта непонятно, потому что вам придется начать писать код мешая его с HTML. когда появятся ещё условия — смесь станет ещё запутанней. «разделить» и «властвовать» можно только вынося код в отдельные файлы либо пиша где-то функцию-хелпер. в-общем, на простых примерах понять зачем не получится. но если умеете всё сделать на голом пхп и вам это удобно — оставайтесь на пхп, это всегда будет самый быстрый вариант по производительности.
по куче шаблонов как раз не надо раскидывать — делаете вложенные блоки или fetch.
про XSLT. мне кажется, что blitz во многом наследует «концепцию» XSLT, только всё очень сильно упрощает. назовите мне прелести XSLT — и я попробую привести аналогии.
В житейском смысле вы правы. Но формально saas != облако (saas — часть концепции облачных вычислений, но не единственная). Среди технарей «облака» — это в первую очередь резиновые ресурсы: инфраструктура и мощности как сервис, то есть под этим делом подразумевается в первую очередь облачный хостинг.
Но по существу Вы правы, инструментов мало. Прежде чем расскажу, чем сам пользуюсь — оговорюсь, что я в-общем технарь, который совмещает разные роли, в том числе и «рекрутер по неволе» (ищем HR). Так что я банально могу что-то не знать. Всю информацию касательно поиска и статуса я решил пока хранить в вики. Я смотрел несколько разных сервисов — мне тупо удобнее вики. Постоянно порываюсь сделать что-то более удобное, но вовремя себя отговариваю. Для «понтового» хранения документов есть хороший сервис — box.net/. Предварительный отбор для меня неактуален: мой входящий поток — это несколько десятков резюме в месяц, причем я почти для каждого резюме делаю скрининг-интервью, т.к. для меня резюме не главное. Календарь в организации нужен много для чего другого, так что здесь нужна интеграция с теми же iCal и прочими — сервисов, которые такое умеют, я вообще не видел. Для тестирования мы сделали свои тесты — php.feedme.ru, т.к. прочие аналоги очень слабые, и проверяют только какие-то узкие компетенции. Но наш тест получился слишком уж забойным — впрочем мы и нанимаем людей сильно выше среднего уровня ;)
про дублирование — я не понимаю о чем вообще спор. может быть ты приведешь какой-то свой пример, чтобы мне стало понятно, что именно ты считаешь ценностью и чего я не могу сделать при помощи blitz?
phpclub.ru/talk/showthread.php?s=&threadid=94234&perpage=40&pagenumber=2
мой предпоследний комментарий — он не 100% верный, но думаю суть будет ясна.
про XSLT. мне кажется, что blitz во многом наследует «концепцию» XSLT, только всё очень сильно упрощает. назовите мне прелести XSLT — и я попробую привести аналогии.