PHP программист в handmade-стартап Mash.ua — йиииха, растём!

lkt Виталик 16.07.2013 16:09

Хотел купить вязанного зайца, кнопка не нажимается... срочно нанимайте програмиста

Відповісти

Підтримати

Kate Burovova CEO в Mash 16.07.2013 18:53

we’re on it)

Відповісти

Підтримати

lkt Виталик

Станіслав Малкін DevOps в Flix 19.07.2013 12:02

вы на этом?

Відповісти

Підтримати

Kate Burovova

Eugene Koval developer в Yola 16.07.2013 07:45

«годный стартап» :-)

Відповісти

Підтримати

Нестор Иванович 15.07.2013 07:26

у меня впечатление что вы хотите кого то на dev ops позицию но почему то избегаете этого слова в описании вакансии :З

Відповісти

Підтримати

Kate Burovova CEO в Mash 15.07.2013 09:17

Хьюстон, нас раскрыли! ;)

Відповісти

Підтримати

Нестор Иванович

Max Ischenko Founder в DOU.ua 15.07.2013 21:39

Хех, есть парочка толковых DevOps по $7k:
djinni.co/q/28b91bd3 djinni.co/q/76a0ff99

Відповісти

Підтримати

Kate Burovova

Alexandr Yatsuk Працює в SHALB 15.07.2013 03:02

Пхп девелопер с опытом администрирования Linux? Если человек пхп девелопер, то весь его опыт в администрировании - убунта на локалхосте.... Если больше, то он и админ херовый и девелопер. Ибо хороший админ не будет на php программировать. Хотябы из принципа :)

Відповісти

Підтримати

reality_hacker 15.07.2013 03:42

А чем вообще админы занимаются в век облачных технологий?

Відповісти

Підтримати

Alexandr Yatsuk

anonymous 15.07.2013 09:23

-

Відповісти

Підтримати

reality_hacker

reality_hacker 15.07.2013 09:29

А программеры неосиливают?

Відповісти

Підтримати

anonymous

Pavel Kruchina CTO 15.07.2013 10:48

Ну — тяжело знать всё. Очень часто на рынке существует довольно большое кол-во однотипных продуктов (в том числе форки), и разобраться какой выбрать и как оптимально их настроить — лучше для этого иметь выделенного человека. Я уже молчу про обновления — должен же кто-то решать, сидим на старом, или обновляемся?

К тому же, если у вас приличная «ферма», то нужен человек просто для мониторинга и обработки результатов изменений в конфигурации.

А уж как вы называете «чувака, который следит за серверами» — не есть суть важно.

Відповісти

Підтримати

reality_hacker

Alexandr Yatsuk Працює в SHALB 15.07.2013 09:42

«облако» это та же виртуализация. Просто новое модное слово и дороже :). Эти «облачные сервера» всегда нужно настраивать. Дабы не попадать на бабло при повышенной СPU и IO активности, коих можно было избежать настройкой. Плюс не всегда «облако» есть выход. Для нагруженных проектов «облако» зачастую не подходит из-за показателя стоимости и качества

Відповісти

Підтримати

reality_hacker

reality_hacker 15.07.2013 09:48

Сколько пафоса, нагруженные проекты, что именно ты настраиваешь на твоих серваках что бы «не попадать на бабло при повышенной СPU и IO активности»?

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 12:05

где ты пафос увидел ? о_О. Относительно нагруженных проектов — так все к этому стремяться. Нагрузки, пользователи, клики. все же именно туда идут. Именно там веб-проект начинает приносить деньги. Так что о больших нагрузках нужно думать всем. Кроме тех, кто не хочет расти.
Раз мы так на ты, то Ты когда нибудь изучал дефолтовый конфиг mysql ?
Он создан, чтобы отчаянно крутить винтом .... А знаешь какие оптимальные настройки mysql? Нет таких. Онизависят от структуры, обьемов БД и типу запросов к ней.
Apache тоже тюнится и по скорости работы и по коричеству используемой памяти. И так кадый софт, ОС.
Админ должен быть. :)

Відповісти

Підтримати

reality_hacker

Pavel Kruchina CTO 15.07.2013 12:19

Админ должен быть.

... если «программист» уже не справляется. И да, я знаю многих ребят, весьма успешно работающих на стыке программирование/администрирование. Обычно это бывшие/действующие фрилансеры, которым то выпадет работка по программировнию, то по администрированию.

P.S. не забываем, что реально тонко тюнить нужно далеко не каждый сервак. В большинстве случаев «советов из гугла» и смекалки хватит с головой.

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 14:33

чтобы советы из гугла применять, нужны какието знания.
Мы сейчас админа ищем себе в команду. Скромные требования, хорошая ЗП. www.work.ua/jobs/736811. Но только 5% из приходящих могут дать точное определение что такое LA, в чем оно меряется и что будет, если на сервере закончилась память.
И это «админы» с несколькими годами стажа .. и кто то им платит уже сейчас ....
я это к чему, считаю, что Вы счастливый человек, если знаете ребят,

весьма успешно работающих на стыке программирование/администрирование

.

Відповісти

Підтримати

Pavel Kruchina

Ilya Trushchenko SRE в Carta 15.07.2013 15:04

Но только 5% из приходящих могут дать точное определение что такое LA

Может потому что LA на современных многопроцессорных многоядерных системах — это часто полная фигня? :)
кстати, зоопарк у вас странный — фря, гента... я таким страдал лет...мм.. 6 назад. Сколько десятых процента производительности выжали, собирая из портов? :) а сколько времени потратили в поисках человека, которому хочется с этим возиться?

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 15:10

С какой это радости ? Современные сервера работают по другому, нежели 10 лет назад? Или Вам непривычно осознавать что LA 25 — 64 абсолютно нормальный показатель?(в зависимости от количества ядер конечноже)

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 15:13

У вас в вакансии про воип тоже упомянуто — хорошо воипу живется при LA 64 (допустим, что включен транскодинг)?

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 15:47

Вы чисто технически интересуетесь? Тогда проведите тесты.
А если увидели знакомые слова в вакансии и в моих ответах, после чего решили их почемуто связать вместе и задать каверзный вопрос — не нужно.
Притом вы ставите задачу очень расплывчато.
«хорошо воипу» — это как?
Если на сервере 128 процессоров, то ему очень хорошо. Если 12 — то не очень.. :) Да и памяти должно быть, чтобы не свопило.

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 16:34

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

Максимально-допустимые значения LA могут в разы различаться в зависимости от задач, возложенных на сервер, поэтому отсеивать соискателей по знанию, в чем оно измеряется — это немного странно :)

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 17:27

та в любом случае нужно понимать что это количество процессов в очереди на исполнение и что показатель зависит не только от загрузки процессора. Без этого понимания просто невозможно определить допустимое это LA или нет. Грош цена тому админу, который рассматривая вывод команды top, не поинтересовался что значит каждая из цифр.

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 17:52

Без этого понимания просто невозможно определить допустимое это LA или нет.

Ну и как понимание, что это процессы в очереди на исполнение — поможет админу определить, допустимое сейчас значение LA или нет? :D Эти «попугаи» ничем не лучше попугаев в синтетических тестах. Вроде что-то конкретное значат, а на деле — зависит исключительно от конфигурации сервера и возлогаемых на него задач. И важнее понимание того, каким должен быть LA для конкретного сервера, а не в чем он измеряется. Вы все равно ему потом объясните, мол этот сервер занимается отложенной обработкой таких-то данных, тут LA в 64 — это норма. А эти сервера занимаются стримингом, тут LA должен быть не более 1.2 * CoresCount....

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 18:00

та так, что если он думает о LA как о попугаях — то как он что то вообще может по нему определить ? Что рассказать админу мы и так найдем. Но фундаментальные вещи, как устроена ОС, как она работает с памятью, чем тридинг от форкинга отличается — нужно понимать. Если у человека 3 года опыта, а он в этом не разобрался, то это ленивый, конченый человек. Который все что может — советы с хабры копипастить, с надеждой, а вдруг поможет.
Хабраспециалист блин а не админ.

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 18:29

благодаря AWS и подобным спрос на linux-админов упал, конечно. Наверное, теперь можно вот так «харчами» перебирать :) Те знакомые админы, кто хорошо срединг от форкинга отличает — работают за ЗП минимум в 2 раза больше вами озвученной.. может им повезло, конечно :)

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 18:31

Повезло тем, кто не знает и получает $1.5к — ото точно повезло :)

Відповісти

Підтримати

Ilya Trushchenko

reality_hacker 15.07.2013 20:05

Те знакомые админы, кто хорошо срединг от форкинга отличает — работают за ЗП минимум в 2 раза больше вами озвученной..

Охеренно сокровенное знание.

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 20:57

Не сокровенное, просто для многих админов не первой необходимости.

Відповісти

Підтримати

reality_hacker

reality_hacker 15.07.2013 20:58

Я тогда не понял зачем за это в два раза зп накидывают?

Відповісти

Підтримати

Ilya Trushchenko

Ilya Trushchenko SRE в Carta 15.07.2013 22:26

Накидывают за знания всеговсего, в тч и этого.

Відповісти

Підтримати

reality_hacker

Pavel Kruchina CTO 16.07.2013 12:15

Э, а разве деньги не за работу платят? Я так понимаю, что «лишние» знания, т.е. которые не влияют на качество исполнения текущей работы не дают прироста зп.

Відповісти

Підтримати

Ilya Trushchenko

Alexandr Yatsuk Працює в SHALB 16.07.2013 16:05

именно за лишние и не нужно доплачивать

Відповісти

Підтримати

Pavel Kruchina

Alexandr Yatsuk Працює в SHALB 16.07.2013 16:01

хм...а что по вашему первой необходимости ?
Это же из области базовых знаний о системе....
Вот ставит такой админ Apache. И как ему выбрать, prefork или worker ? Наугад ? :)
Наугад — это как-бы больше для рисования нежели администрирования :)

Відповісти

Підтримати

Ilya Trushchenko

Alex Batler заговорщик в Mutabor-science 16.07.2013 15:13

LA не очень хорошо отражает реальную ситуацию на системах, поддерживающих виртуализацию. Я просто приведу пример.
uptime
2:07pm up 115 day(s), 14:36, 4 users, load average: 19.91, 16.25, 12.97
psrinfo -vp
The physical processor has 64 virtual processors (0-63)
SPARC-T4 (chipid 0, clock 2848 MHz)
The physical processor has 64 virtual processors (64-127)
SPARC-T4 (chipid 1, clock 2848 MHz)
...........................................................
CPU states: 79.0% idle, 15.0% user, 6.0% kernel
--------------
Это на одной из зон, где все пока что тихо.
Как только где-то начинается шось нехорошее, загрузка ядра растет, LA растет везде.

З.Ы. Я не админ

Відповісти

Підтримати

Alexandr Yatsuk

Pavel Kruchina CTO 15.07.2013 15:13

Эти ребятки получают 20-24к гривен (т.е. вдвое больше того, что вы предлагаете). Вы всё ещё удивляетесь, почему такие как они вам не звонят?

P.S. 5% ? Чтобы сделать такой вывод, надо опросить хотябы человек 40. Это ж дофига работы. Не проще ли было уже отдать администрирование на аутсорс?

P.P.S Кстати, как мне подсказывают «досвидчени» товарищи, искать хорошего админа надо на 2к+ долларов

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 15.07.2013 15:41

там очень большие требования ? LАMP ! это вдруг стало так тяжело ? У нас работает админ и получает $2к. пришел на $1к полтора года назад. Знаний вразы больше было нежели у тех, кого мы видим сейчас. 300 резюме, что нам приходили и с кого мы собеседовали. Некоторых лично, некоторых по телефону. Может 40 человек и небыло. Но то что больше 20 то точно. Остальные не подходили на уровне резюме . Это кстати нифига не сложно. просто время надо.

P.S. Мы и есть аутсорс админов.

Відповісти

Підтримати

Pavel Kruchina

reality_hacker 15.07.2013 20:57

дефолтовый конфиг mysql ?
Он создан, чтобы отчаянно крутить винтом

А расскажи какие именно улучшения ты делаешь что бы не заставлять мскл крутить винтом?

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 16.07.2013 10:45

Если в двух словах, то основная тема — подтянуть данные в память. Запись всеравно на диск, а вот читать лучше с памяти.
Кеш ключей для myisam, буфер innodb, кеш запросов.
Также размеры временных таблиц, чтобы они в памяти создавались. Если все же программисты пишут запросы с сортировкой на диске — то RAM диск для временных таблиц.
Также следует обратить внимание на то, какие и куда бинлоги пишутся, если они вообще нужны.
В innodb есть много переменных, которые могут улучшить ситуацию.
Например метод сброса логов при коммите, при каждом или раз в секунду.
И тд.

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 11:55

Если в двух словах, то основная тема — подтянуть данные в память.

Данные и так подтягиваются в кеш ФС, и куча БД это использует, вроде монгодб(где вообще нету никаких кешей), кассандры(где рекомендуют отдавать под служебные нужды не больше 25% памяти), а то что ты делаешь приводит к обратному эффекту, потому что у тебя данные дублируются, в кеше ФС и кеше БД, и соответсвенно в память помещается меньше. Учил бы матчасть прежде чем пафосничать.

Відповісти

Підтримати

Alexandr Yatsuk

Pavel Kruchina CTO 16.07.2013 12:14

Есть подозрение, что кеш СУБД несколько производительнее будет, чем кеш ФС, за счёт работы с родными типами данных, а не файлами (пусть и в оперативке). Так что я думаю, есть некое оптимальное соотношение.

Ну а вообще, круто было бы глянуть на прирост производительности после тонкого тюнинга (при условии что первоначально СУБД сконфигурированна по советам из гугла).

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 12:15

Есть подозрение

Есть такое подозрение, но оно совершенно не релевантно «подтягиванию данных в память».

Відповісти

Підтримати

Pavel Kruchina

Pavel Kruchina CTO 16.07.2013 12:33

Ну дык — админ :). Всё таки лучший результат, это если админ-программист обьеденяют усилия, и выдают на-гора совместный продукт оптимизации, а не «закидывают данные в память»

Відповісти

Підтримати

reality_hacker

Alexandr Yatsuk Працює в SHALB 16.07.2013 15:42

Это 100%, без налаженной комуникации и админы <=> программисты вообще никак.
Но данные в память всеравно прийдется закидывать, так дешевле :)

Відповісти

Підтримати

Pavel Kruchina

Pavel Kruchina CTO 16.07.2013 15:51

Но данные в память всеравно прийдется закидывать

Да это понятно, весь вопрос в том, какие данные и в какую память. Особенно, если мы говорим об облаке/ферме

Відповісти

Підтримати

Alexandr Yatsuk

Alex Batler заговорщик в Mutabor-science 16.07.2013 15:48

Кэш СУБД работает гораздо производительнее при условии отключении кэша ФС, т.е. монтировании файловой системы с опцией forcedirectio или что там разрешается на конкретной ФС.
Запись в файлы и журналирование работает намного быстрее в случае если асинхронный ввод-вывод возможен.
Но это уже очень специфично для ОС, ФС и СУБД.
Прирост производительности может варьироваться в широких пределах.

З.Ы. я не админ)

Відповісти

Підтримати

Pavel Kruchina

Alex Batler заговорщик в Mutabor-science 16.07.2013 16:41

Чего только в этих линуксах не встретишь...
«The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances.» © Linus T
Надо отметить, что большинство файловых утилит по умолчанию работают с очень небольшим размером блока ввода-вывода, что может замедлить работу стандартных файловых утилит в отсутствии файлового кэша.

Відповісти

Підтримати

Alex Batler

reality_hacker 16.07.2013 19:54

Кэш СУБД работает гораздо производительнее при условии отключении кэша ФС, т.е. монтировании файловой системы с опцией forcedirectio или что там разрешается на конкретной ФС.

Прям какой то топик вредных советов. Ты реально видел что бы кто-то так делал?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 20:00

Короткий ответ — да. Я сам так делаю
Нужен длинный ответ?

Відповісти

Підтримати

reality_hacker

Alex Batler заговорщик в Mutabor-science 16.07.2013 20:19

Дополню свой ответ. Подразумевается, что кэш СУБД разделяемый, т.е. данные, загружаемые туда, кэшируются для всех пользователей. Если в рамках каждого серверного процесса создается свой «собственный» кэш, то ~~никакого выигрыша не будет, конечно~~ выигрыш сомнителен.

Відповісти

Підтримати

Alex Batler

reality_hacker 16.07.2013 22:07

И у тебя есть бенчмарк который показывает что ты получил выигрыш в производительности?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 22:46

Я сейчас бенчмарк показывать не готов.
Самый лучший и убедительный бенчмарк может быть получен на сравнении и прогоне какого-нибудь эталонного теста на файлах данных, созданных на файловой системе и файлах данных, созданных на «сырых» устройствах (raw devices). В этом случае обходится наибольшая часть «лишнего» кода в ядре.
У меня на это нет времени. Могу только сказать, что в те далекие времена, когда прямой доступ не был доступен на файловых системах, простой перенос файлов данных на сырые устройства давал прирост в общей производительности ввода-вывода до 10%, а там где возникали проблемы и ожидания, до 30%.
Ссылки по теме.
www.solarisinternals.com/....php/Direct_I/O
www.ibm.com/...1204concurrent
www.toadworld.com/....direct-io.aspx
pic.dhe.ibm.com/..._admin_0569.htm
И... внимание! Firebird!
Правда, тут непонятно. Из форума не совсем ясно действительно ли правильным образом реализована поддержка прямого ввода-вывода в ядре СУБД и дает ли это выигрыш.
tech.groups.yahoo.com/.../message/113376
PostgreSQL не поддерживает ни сырые устройства, ни прямой ввод-вывод на файлах данных, только на журналах.
grokbase.com/...-device-support

Простые тесты с dd не дают оценить реальной выгоды для СУБД.
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc oflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 24.3632 s, 51.6 MB/s
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 30.9162 s, 40.7 MB/s
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc oflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 24.4824 s, 51.4 MB/s

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 22:54

Т.е. выставляя forcedirectio ты действуешь в слепую? Я правильно понимаю?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 23:06

Еще раз повторяю, монтирование forcedirectio на файловых системах с файлами данных дает выигрыш, измеряемый отчетами статспака, и другими объективными измерениями.
Плюс, это снижает загрузку сервера, таким образом позволяя либо нагрузить его еще, либо иметь запас прочности.
Ссылки читал?

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 23:28

Ссылки читал?

Все нечитал. Какую из нужно почитать?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 23:37

Ну как бы там, в основном, ссылки на документацию разных СУБД.
ОК, вот еще хорошая ссылка.
kevinclosson.wordpress.com/...ranged-monkeys

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 23:40

Ну все твои ссылки после беглого взгляда (уж извини, детально читать некогда, нужно Головача троллить), либо пространные вроде «но может дать прирост, а может и не дать», либо иррелевантны БД, как последняя например.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 00:03

Ну ок. Мое дело показать, твое дело — не согласиться.
Последняя ссылка намекает на ограничения функций стандартного буферизованного ввода-вывода и на то, как их можно обойти, используя прямой ввод-вывод.
kevinclosson.wordpress.com/...with-direct-io
Из этой ссылки цитата:
I encountered this with a customer complaining about the time it was taking them to do a backup and suspecting something was wrong with the tape subsystem. Of course, running a few very simple tests, like reading from /dev/zero and writing to tape (perfectly compressible) showed what the tape could do if supplied fast enough. Therein lay the problem, that the data wasn’t being sourced fast enough. Using large i/o buffers and a multithreaded utility like star made a huge difference.

With respect to cpu time, I don’t think the cost is associated with moving the bytes into or out of a buffer per se, but rather the entire code path or set of instructions that have to be executed. In some of the cases I’ve investigated, the cpu time cost was sufficient to represent a significant component of the elapsed time. As always though, its a good idea to measure it, so that its contribution is known. I suggest 100MB/s as a reasonable number where you might want to pay some attention to it.

То есть, с повышением требований к пропускной способности на уровне ввода-вывода и конкурентного использования издержки файлового кэша становятся заметнее. Использование прямого ввода-вывода и правильной буферизации программ/команд/функций, читающих или передающих данные, позволяет масштабировать систему.
Если речь идет о СУБД, то преимущества становятся заметны на больших объемах или под нагрузкой.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 00:24

Ну ты же думаю понимаешь что перемещение больших файлов на пленку это далеко не то же самое что иголочные бд чтения записи с/на ссд к примеру, т.е. этот эксперимент абсолютно нерелевантен БД. То что кеш ФС неэфективен для длинных непрерывных записай общеизвестная тема.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 00:33

Не знаю что тебя еще может убедить.
Я могу, конечно, на домашней виртуалке провести эксперимент, но с другой стороны, зачем?
Эксперимент с dd, который ясно показывает за счет чего появляется выигрыш по используемым ресурсам хотя бы, плюс мои выкладки, тебя не убеждают, мои примеры тоже. Следовательно, эксперимент тебя тоже не убедит.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 00:36

Ну я же написал, dd это совсем другой шаблон использования диска, эксперимент с стандартным mysql-евским бенчмарк тулом показал бы намного больше.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 01:02

У нас нигде mysql не используется. Ставить его себе только ради экспериментов я тоже не хочу.
Последняя ссылка на сегодня. Кто-то протестировал, по крайней мере. Не совсем сравнение с ФС, а скорее сравнение прямого ввода-вывода на разных файловых системах под линуксом.
dimitrik.free.fr/...e-linux-io.html

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 01:17

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

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 21:12

Рассказываю что там. Во-первых, тестовая конфигурация состоит из 1 (адын) файла данных.
Сначала сравниваются разные «планировщики ввода-вывода в линуксе», не знаю как правильно перевести I/O scheduler.
Дальше, точнее, до этого рассказывается о реализации «сырых» устройств на линуксе.
Дальше идет оценка производительности когда файл данных на raw device, и эти измерения и полученная пропускная способность берется за эталонную.
После чего последовательно тестируются EXT3, EXT4, XFS с разными опциями монтирования, включаяю опцию прямого доступа.
Оказывается, что в EXT3,4 прямой доступ реализован херово, так что даже с включением прямого доступа буферирование все равно имеет место быть.
XFS по производительности на графиках даже выглядит лучше (или сравнимо, во всяком случае) с прямым доступом чем с буферированным.
Теперь если посмотреть эту ссылку:
dimitrik.free.fr/...d-fusionio.html
Здесь тестируется производительность raw, EXT4, XFS на 1 файле, 2, 4, 8. Производительность буферизованного ввода-вывода выше только в одном случае: EXT4, 1 файл данных.
Во всех остальных случаях производительность прямого доступа выше, хотя и ясно что далека от производительности размещения файлов данных на «сырых» устройствах.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 21:25

Рассказываю что там. Во-первых, тестовая конфигурация состоит из 1 (адын) файла данных.

Это где ты такое вычитал? Он там использует тулы, mysqlbench и iobanch про то сколько файлов они рожают ничего не известно.

XFS по производительности на графиках даже выглядит лучше (или сравнимо, во всяком случае) с прямым доступом чем с буферированным.

А где ты такое увидел? Помоему одинаково!

Теперь если посмотреть эту ссылку:
dimitrik.free.fr/...d-fusionio.html
Здесь тестируется производительность raw, EXT4, XFS на 1 файле, 2, 4, 8. Производительность буферизованного ввода-вывода выше только в одном случае

А где ты в этой статье увидел производительность буферизированного ИО? Там сравнивается только raw & direct.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 21:36

Это где ты такое вычитал? Он там использует тулы, mysqlbench и iobanch про то сколько файлов они рожают ничего не известно.

Ты прикалываешься что ли?
Из первой ссылки:
“Workloads: Random Reads, Random Writes on a single 128GB file — it’s the most critical file access for any database (having a hot table, or a hot tablespace)”
1 файл данных, причем эти тулы вообще?

А где ты в этой статье увидел производительность буферизированного ИО? Там сравнивается только raw & direct.

Опять прикалываешься?
“While for Random-Read access it doesn’t make sense to test ‘fsync() case’ (the data will be fully or partially cached by the filesystem), but for Random-Write and Random-RW it’ll be pretty important. So, that’s why there are 4 cases represented on each graph containing Write test:
O_DIRECT with 4K block size
fsync() with 4K block size
O_DIRECT with 16K block size
fsync() with 16K block size”

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 21:45

1 файл данных, причем эти тулы вообще?

При том что он делал эту нагрузку тулами.

While for Random-Read access it doesn’t make sense to test ‘fsync() case’ (the data will be fully or partially cached by the filesystem)

Т.е. он решил не тестировать типичную БД нагрузку в котором буфер 100% выиграет?

o, that’s why there are 4 cases represented on each graph containing Write test:
O_DIRECT with 4K block size
fsync() with 4K block size
O_DIRECT with 16K block size
fsync() with 16K block size"

И как эти 4-е кейса представлены на графиках, не обьяснишь?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 21:54

Первый, второй, третий, четвертый.
Красненькой пунктирной линией показано разграничение.
«the load is growing with 1, 4, 16, 64, 128, 256 concurrent IObench processes»
Это тот самый единственный тест где «write()+fsync() performs better than O_DIRECT»

Т.е. он решил не тестировать типичную БД нагрузку в котором буфер 100% выиграет?

Что это значит?
Там ясно написано «and of course all the I/O requests are completely random.. — yes, the worse scenario ;-)»

З.Ы. про 1 файл данных больше объяснять не надо, или ты и дальше будешь включать дурачка?

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 22:14

Это тот самый единственный тест где «write()+fsync() performs better than O_DIRECT»

Там все го два теста по сути, на ext4 всегда рулит буферизация, на xfs рулит directio.

Что это значит?
Там ясно написано «and of course all the I/O requests are completely random.. — yes, the worse scenario ;-)»

А это что значит? Я привел цитату, где он сказал что не будет тестировать nodirectio fs, потому что все равно ясно что она зарулит директ ио, потому что будет кешировать данные в памяти. Ну и вообще понятно что полностью рандомные риды — это уже не типичная бд нагрузка.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 22:30

Ты путаешься в показаниях.
Сначала

Ну ты же думаю понимаешь что перемещение больших файлов на пленку это далеко не то же самое что иголочные бд чтения записи с/на ссд к примеру, т.е. этот эксперимент абсолютно нерелевантен БД. То что кеш ФС неэфективен для длинных непрерывных записай общеизвестная тема.

Теперь

Ну и вообще понятно что полностью рандомные риды — это уже не типичная бд нагрузка.

Ты уж определись, пожалуйста. Заодно может поделишься, что такое типичная бд нагрузка?

Там все го два теста по сути, на ext4 всегда рулит буферизация, на xfs рулит directio.

Там их не два.
Буферизация на EXT4 рулит в случае если есть 1(один) файл данных.
Дочитай хотя бы до середины что ли.
Начиная со слов «TEST with 8 data files».
Там сразу же идет тест EXT4, чтобы не распылять твое внимание.
Там даже для невнимательных в самом начале «summary»:
«You’ll see that:
* having 8 files brings FS performance very close the the RAW device level
* XFS is still performing better than EXT4
* having O_DIRECT gives a better results than write()+fsync()»

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 22:40

Ты путаешься в показаниях.

А в чем путаница? Ясен пень что база данных в которой все операции распределены абсолютно равномерно это сферический конь в вакууме. Обычно есть какие то горячие участки, и здесь всякие LRU кеши очень помогают, т.е. как раз то что делает буфер ФС.

Буферизация на EXT4 рулит в случае если есть 1(один) файл данных.

Ок, теперь какие твои выводы в контексте баз данных а не рандомных записей чтений в файл даже если их 8-емь?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 23:00

Я свои выводы уже говорил.
Ты просил

эксперимент с стандартным mysql-евским бенчмарк тулом показал бы намного больше.

Я тебе показал ссылки с такими экспериментами.
Там выводы тоже написаны.
«you’re using O_DIRECT within your InnoDB config (don’t know yet if using 4K page size will really bring some improvement over 16K as there will be x4 times more pages to manage within the same memory space, which may require x4 times more lock events and other overheads.. — while in term of Writes/sec potential performance the difference is not so big! — from the presented test results in most cases it’s only 80K vs 60K writes/sec — but of course a real result from a real database workload will be better ;-))»

Еще раз говорю, что самый большой выигрыш получается от использования сырых разделов либо проприетарных файловых систем на неразмеченных разделах, обходя весь ненужный код таким образом и настраивая буфера обмена на уровне кода СУБД или промежуточного кода для работы с такими системами.
Но даже просто отключение буферизации (без асинхронного ввода-вывода) дает иногда заметный выигрыш, но самое главное, что это позволяет экономить ресурсы, так как память не засирается и процессор меньше используется.
Я говорю — иногда заметный. В моей практике это давало выигрыш всегда, просто не всегда его можно ощутить, если особых проблем не ощущается.
На этом я эту тему заканчиваю «засирать» тоже.
Если ты считаешь иначе, считай на здоровье.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 23:19

Я тебе показал ссылки с такими экспериментами.

Я если честно не понял из твоих ссылок какие именно результаты получены с помощью бенчмаркинга MySql.
Не подскажешь?

Еще раз говорю, что самый большой выигрыш получается от использования сырых разделов либо проприетарных файловых систем на неразмеченных разделах, обходя весь ненужный код таким образом и настраивая буфера обмена на уровне кода СУБД или промежуточного кода для работы с такими системами.

Ну ведь нету end to end теста который подтверждает эту теорию? Или я что-то пропустил?

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

А что значит «не засирается память»? И с чего ты взял что процессор меньше используется?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 23:02

Теперь делаем то же самое, только с прямым доступом и на чтение, и на запись.
alexb@XXX:~$ dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc oflag=direct iflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 58.6896 s, 21.4 MB/s
alexb@XXX:~$ rm test_cp.tmp
alexb@XXX:~$ dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 58.9389 s, 21.3 MB/s

В данном случае выигрыша практически никакого.
О чем это говорит? О том что prefetch в ядре работает почти так же эффективно как и прямой доступ на таких операциях, но если мы имеем дело с СУБД, то это не только лишнее звено в цепи, но и отбор процессорных ресурсов.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 23:29

alexb@XXX:~$ sudo time dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc 
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 61.4573 s, 20.5 MB/s
0.00user 6.38system 1:01.47elapsed 10%CPU (0avgtext+0avgdata 19840maxresident)k
2457624inputs+2457600outputs (1major+1293minor)pagefaults 0swaps
alexb@XXX:~$ rm test_cp.tmp 
rm: remove write-protected regular file `test_cp.tmp’? y
alexb@XXX:~$ sudo time dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc oflag=direct iflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 60.2474 s, 20.9 MB/s
0.00user 0.82system 1:00.27elapsed 1%CPU (0avgtext+0avgdata 19856maxresident)k
2457632inputs+2457600outputs (1major+1294minor)pagefaults 0swaps

--------------------------------------------------------
10%CPU против 1%CPU с включением прямого доступа. Теперь представим что буферный кэш, к примеру, 512G, совершенно средний по сегодняшним меркам. Предположим, 100-200 серверных процессов грузят данные в буферный кэш. Каждый из них «серит» понемногу (или помногу, в зависимости от настроек на уровне ФС и ОС) в файловый кэш и грузит на 10-15% доступный процессор/ядро/поток. То, что один процесс «серит» в файловый кэш, никак недоступно другим процессам, то есть, это абсолютный waste. В то же время, данные в буферном кэше немедленно разделяются всеми процессами.
Если теперь представить, что это таки большая база данных, и буферного кэша не хватает, т.е. активно используются прямые чтения, т.е. чтения в адресное пространство серверного процесса, а не в буферный кэш, чтобы не «засирать» уже его, то здесь файловый кэш — это просто катастрофа.

Відповісти

Підтримати

Alex Batler

reality_hacker 16.07.2013 23:30

О том что prefetch в ядре работает почти так же эффективно как и прямой доступ на таких операциях, но если мы имеем дело с СУБД, то это не только лишнее звено в цепи, но и отбор процессорных ресурсов.

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

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 16.07.2013 23:50

Монгодб в моем представлении не РСУБД. Вот когда они начнут удовлетворять требованиям dirability, ну в общем.. даже тогда в моем представлении это не будет РСУБД.
Если работает успешно с файловым кэшем — это прекрасно, что еще можно сказать.

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 23:51

Монгодб не РСУБД by design вообщето, какой именно dirability тебя не устраивает в монге?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 00:08

Durability. Опечатка вышла.
blog.mongodb.org/...bout-durability
Мне лично все равно, я монгу не использую и не собираюсь.
На эту тему дискуссию продолжать не вижу смысла, так как зачем читать что-то про то, что не используешь, не знаешь и не собираешься использовать.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 00:25

Ок, т.е. ты написал про проблемы с Durability в монго не изучив вопрос. Бывает.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 00:42

Т.е. ты утверждаешь, что в монго невозможны ситуации, когда с частью данных придется расстаться? Или иными словами, что монго полностью реализует принцип долговечности транзакций?

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 00:44

Транзакции иррелевантны этой теме, в монго их нету, но по твоей же ссылке написано что у монго есть write ahead log, в который синхронно логируются все операции, и при падении сервака эти данные потом оттуда востанавливаются. Т.е. нет, данные не теряются, если нету никаких багов и проблем в других местах.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 01:08

Из документации:
With journaling enabled, if mongod stops unexpectedly, the program can recover everything written to the journal, and the data remains in a consistent state. By default, the greatest extent of lost writes, i.e., those not made to the journal, are those made in the last 100 milliseconds. See journalCommitInterval for more information on the default.
Из другого места:
the write-ahead-log is fsync’ed every 100ms.
Вот и весь “дурабилити” — 100мс.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 01:25

Просто дефолтная конфигурация настроена на производительность а не надежность, это настраивается, при этом с самого начала они хотели обеспечить надежность с помощью репликации на другую ноду а не синка на диск.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 20:50

То есть, ты согласен что по умолчанию никакого «дурабилити» нет?
Теперь не очень понятно, можно ли (в отсутствие транзакций) получать подтверждение после каждой операции изменения, я в документации такого не нашел нигде. По поводу параметра journalCommitInterval.
Они сами путаются в показаниях. В одном месте
Specify an integer between 1 and 500 signifying the number of milliseconds (ms) between journal commits.
В другом
This option accepts values between 2 and 300 milliseconds.
В любом случае это не обеспечение долговечности, так как предполагается что «допустимые» потери ограничены этим параметром.
Ну и если ты объяснишь, каким образом синхронная репликация гарантирует «дурабилити», или при каких условиях, тогда конечно станет ясно вот это твое утверждение

Т.е. нет, данные не теряются, если нету никаких багов и проблем в других местах.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 21:01

То есть, ты согласен что по умолчанию никакого «дурабилити» нет?

А я где то утверждал что она есть по умолчанию? Хотя она конечно есть на уровне репликации ))

Теперь не очень понятно, можно ли (в отсутствие транзакций) получать подтверждение после каждой операции изменения, я в документации такого не нашел нигде.

docs.mongodb.org/...d/getLastError

В любом случае это не обеспечение долговечности, так как предполагается что «допустимые» потери ограничены этим параметром.

Не понял почему.

Ну и если ты объяснишь, каким образом синхронная репликация гарантирует «дурабилити», или при каких условиях, тогда конечно станет ясно вот это твое утверждение

А что непонятно? Шанс вылета винта намного выше чем одновременного вылета 3-ех-4-ех машин в реплика сете, т.е. при репликации надежность выше.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 21:22

Ок, т.е. ты написал про проблемы с Durability в монго не изучив вопрос. Бывает.

Не понял почему.

А что тут непонятного?
«In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. » © любимая всеми википедия.
Если нет транзакций, предполагается, что любое изменение данных, затрагивающее состояние этих самых данных, является транзакцией.
Восстановиться могут только транзакции, попавшие в долговременное хранилище. Даже если выставить

journalCommitInterval

в 1, в зависимости от количества транзакций (операций) в секунду всегда есть шанс что какая-то часть попадет в этот промежуток. Им гарантированный кердык.
Теперь таки вопрос. Как репликация защищает от этого?

Да, забыл написать.
getLastError — это на уровне приложения. Как это гарантируется на уровне СУБД, если монго — это таки СУБД, как ты декларируешь?

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 21:30

А что тут непонятного?
«In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. » © любимая всеми википедия.

Это очевидно кривое определение, durability очевидно может быть и без транзакций.

Восстановиться могут только транзакции, попавшие в долговременное хранилище. Даже если выставить
journalCommitInterval
в 1, в зависимости от количества транзакций (операций) в секунду всегда есть шанс что какая-то часть попадет в этот промежуток.

Ну вот getLastError и блокирует вызов пока не убедится что данные закомитились в лог и на заданное количество реплик.

Да, забыл написать.
getLastError — это на уровне приложения. Как это гарантируется на уровне СУБД, если монго — это таки СУБД, как ты декларируешь?

А так во всех БД сделано, если ты не напишешь специального кода на клиенте который проверяет что транзакция закомитилась, ты никогда не узнаешь закомитилась она или нет.

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 21:58

Понятно.

А так во всех БД сделано, если ты не напишешь специального кода на клиенте который проверяет что транзакция закомитилась, ты никогда не узнаешь закомитилась она или нет.

Никогда не работал с СУБД? Коммит означает что транзакция попала в долговременное хранилище. Никакого специального кода не нужно.
Это ты так троллишь?

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 22:00

Коммит означает что транзакция попала в долговременное хранилище. Никакого специального кода не нужно.
Это ты так троллишь?

НУ вот в jdbc ты вызываешь commit() в mongodb вызываешь getLastError, в обоих случаях удачное выполнение вызова означает что запись попала в долговременное хранилище. Что не так?

Відповісти

Підтримати

Alex Batler

Alex Batler заговорщик в Mutabor-science 17.07.2013 22:41

Разница в производительности. Но в общем, твоя мысль что getLastError и есть тем самым волшебным камнем, который обеспечивает durability.
Ну пусть будет так.

Відповісти

Підтримати

reality_hacker

reality_hacker 17.07.2013 22:42

И какая же разница в производительности?

Відповісти

Підтримати

Alex Batler

Alexandr Yatsuk Працює в SHALB 16.07.2013 15:40

Pavel Kruchina тебе ответил, он прав. Спасибо Павел. query_cache, например, вообще лишний, если апдейты частые. А если редкие, то здорово помагает. Ты еще расскажи, что не нужен на рейд котроллерах кеш свой, если есть кеш файловой системы ...

ПС. опять пафос гдето ты увидел? о_О

Відповісти

Підтримати

reality_hacker

reality_hacker 16.07.2013 19:53

Pavel Kruchina тебе ответил, он прав. Спасибо Павел. query_cache, например, вообще лишний, если апдейты частые. А если редкие, то здорово помагает.

А что именно он ответил касательно вопроса и в чем именно он прав?

ПС. опять пафос гдето ты увидел? о_О

Ну как же, преподавательский тон в том в чем дуба не рубишь.

Відповісти

Підтримати

Alexandr Yatsuk

Alexandr Yatsuk Працює в SHALB 16.07.2013 22:15

это ты так воспринимаешь

Відповісти

Підтримати

reality_hacker

anonymous 12.07.2013 11:15

-

Відповісти

Підтримати

Andrii Mishkovskyi Software Engineer в FreshBooks 12.07.2013 12:20

Ebay не конкурент, а вот Etsy делает то же самое, но кто про него слышал в Украине-то?

Відповісти

Підтримати

anonymous

Sandro Zakusilov 18.07.2013 09:30

но кто про него слышал в Украине-то?

Те кто смотрят и читают www.tested.com :P

Відповісти

Підтримати

Andrii Mishkovskyi

anonymous 12.07.2013 12:42

-

Відповісти

Підтримати

anonymous

Kate Burovova CEO в Mash 12.07.2013 14:31

Очень верно подмечено, Елена, а главное — такая логика доказана практически тем же etsy, которого присутствие e-bay ничуть не стесняет.

Відповісти

Підтримати

anonymous

Pavel Kruchina CTO 12.07.2013 12:49

Потому что пользователи будут хотеть покупать через тематические сайты. Грубо говоря, когда я хочу ширпотреб — я пойду в Ашан. Но если я хочу аутентичную резьбу по дереву, то скорее всего я куплю её в спец. мастерской. Даже если точно такая же продаётся в Ашане.

Таже фигня и с сайтами.

Відповісти

Підтримати

anonymous

anonymous 12.07.2013 10:12

-

Відповісти

Підтримати

Pavel Kruchina CTO 12.07.2013 10:25

Кстати, да. Это было бы во-первых интереснее, во-вторых больше по теме для форума, в третьих — гораздо больше привлекает потенциального соискателя, в отличии от стереотипного «нам в команду нужен прогер»

Відповісти

Підтримати

anonymous

Kate Burovova CEO в Mash 12.07.2013 14:39

Конечно! У нас очень скоро выходит релиз корпоративного блога, сама success story для него уже написана и трепетно хранится в док-те с названием «Битва против посредственности: 1:0 в нашу пользу»

Відповісти

Підтримати

anonymous

anonymous 12.07.2013 06:20

Congratulations !!

Відповісти

Підтримати

Олексій Пєніє 12.07.2013 06:15

Не завидую инвесторам...

Відповісти

Підтримати

anonymous 12.07.2013 10:57

Отчего такое трепетное отношение к чужим деньгам?

Відповісти

Підтримати

Олексій Пєніє

Kate Burovova CEO в Mash 12.07.2013 14:28

правильно, зависть — неконструктивное чувство, лучше порадуйтесь за них:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 12.07.2013 17:21

Могу пояснить — сайт пошёл в количественную раскрутку прототипом, до качественного становления. Это означает утрату ключевой выгоды, и первый же нормальный конкурент отберёт на себя всю аудиторию.

Достаточно небольшого допила того же aukro — и целевая аудитория будет туда слита без копейки затрат. В отличие от ebay, он «мягче»: ориентирован на удовольствие выбора, а не на моментальную покупку.

В отличие от prom.ua, mash.ua не имеет множества посадочных площадок, то есть не является аэродромом. Возможно развитие в эту сторону, но пока его нет. К тому же, для хэндмэйда подход сомнителен.

Лично я увидел до боли знакомую модель «купи слона». Не купил.

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 12.07.2013 17:57

Спасибо, что потратили время на такое развернутое пояснение, но:

1. Мы НЕ пошли в количественную раскрутку прототипом. Если под термином «количественная раскрутка» Вы имеете в виду слив денег на маркетинг, то нет, текущих показателей мы достигли без них:)
Мы придерживаемся принципа итерационного развития, в чем мы ошибаемся?)

2.

Достаточно небольшого допила того же aukro

- этот аргумент очень удачно опровергли выше, обратите внимание.

3. Специфика ниши заключается в том, что продажа — это акт коммуникации, а не просто транзакция. Хендмейд продавали и будут продавать и на aukro, и на e-bay, и на форумах, и в соц сетях. Другое дело, что для сервисов вроде etsy это не имеет значения, и именно такая специфика будет диктовать наш подход.

Алексей, на Mash есть много экзотических предложений, но вот слонов нет, увы:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 12.07.2013 18:28

Странно, я увидел обратное. Тогда позвольте спросить, сколько лет ресурсу?
// если не жалко — покажите нам на доу презентацию, которую давали инвесторам.

Специфика ниши заявлена верно. Но вот реализация... скажем так, скромнее чем у esty, и скромнее чем у allegro. Возможно я что-то пропустил, и подводная часть айсберга находится вне сайта? Например социальные группы, живые клубы и так далее.

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 12.07.2013 18:45

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

Не лет — Mash полноценно работает около 10 месяцев, из которых 2 — период закрытой регистрации.

Я уверена, Вы не станете серьёзно утверждать, что перед релизом на рынке нам стоило «докрутить» Mash до уровня etsy:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 13.07.2013 00:17

Я пока не вижу соотвествия между

30.000 уникальных товаров, 3.500 студий и мастеров

точечные активности в соц сетях

денег на маркетинг, нет, текущих показателей мы достигли без них

10 месяцев, из которых 2 — период закрытой регистрации.

Для меня это выглядит анекдотом про яблочный бизнес и наследство три миллиона. Однажды, когда взошла Луна, 3 500 студий и мастеров принесли 30 000 уникальных товаров к Лысой горе.

Я не стану ничего утверждать, кроме того что не понимаю соответствия. Прежде я подобной бизнес-модели не видел (а видел я предостаточно). Не верю.

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 13.07.2013 09:28

Алексей, наши показатели — факт. Наши методы — факт. Думаю, после «не верю» мы завершим нашу беседу и будем дальше делать вещи, в которые Вам сложно или даже невозможно поверить:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 13.07.2013 19:52

Попробую сказать по-другому: сайт не имеет механизмов не только чтобы собрать воедино, но даже чтобы поддерживать жизнеспособной желаемую часть рынка. Эти показатели достигнуты другими методами (которые Вы не озвучиваете), другими информационными системами (о которых предпочитаете умалчивать), и конечно же — усилиями людей, о которых Вы говорите «немного».

Вы очень сильно рискуете утратить данное преимущество, поскольку оно не найдёт отражения на сайте. Скажу больше — я знаю 0 случаев, чтобы в подобной ситуации преимущество сохранилось.

Я как раз умею «делать вещи», почему и спрашиваю: Как это сделано? Я могу поверить, что не хотите говорить. Но поверить, что всё случилось само собой — не могу :)

Я рассчитывал увидеть это преимущество прямо на сайте. Захожу в роли мастера, или в роли клиента — и вот оно, на блюдечке. Но нет же. Я поглубже копнул — ноль. Почему и считаю сайт лишь прототипом: это движок и ничего кроме. Мне же хотелось увидеть ту изюминку, которой в нём нет. И если есть такое количество вовлечённых — значит изюминка есть. По-любому есть. Но в другом месте. Вот только где? Откуда произошёл этот сайт?

Відповісти

Підтримати

Kate Burovova

Ivan Chuba CTO 13.07.2013 20:57

Алексей, вы думаете, вам кто-то все выложит на блюдечке, к тому же на форуме..... Я пока что никого не встречал, кто б все выкладывал, при личной встрече и вовлеченности, вам конечно раскроют карты....

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 14.07.2013 08:26

Я спрашиваю не о секретной информации. А как раз о самой публичной, которой не хватает. Вот она была — и её нет, и весь проект готов утянуть на дно своей рутиной.

В математики есть такой метод — комбинаторика. И для анализа проектов он годится лучше любого другого. Вместо копаться в деталях надежд и страхов основателей, просто предполагаю что проект работает, проблем нет. И смотрю, как он будет работать для +1 в каждой роли.

Если «+1» не работает, как в данном случае — есть 2 варианта:
1) Функция «+1» находится в другом проекте. Но этот как минимум странно, что зайдя на сайт я не могу к нему добраться.
2) Раньше работало, а теперь что-то поменяли и проект умирает.

// В случае вовлечённости проблема была бы поводом для серьёзного конфликта. Не дал бы загубить проект, и никаких отговорок.

Відповісти

Підтримати

Ivan Chuba

Kate Burovova CEO в Mash 15.07.2013 09:34

Все, что я могу ответить — ну, ок:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 15.07.2013 10:40

Собственно, проблема решается в 2 клика: сделай большие сслыки с mash.ua на группу ВКонтакте. Чтобы она была видна ещё до регистрации. Пересеки целевые аудитории, пусть клиенты mash подписываются на группу. Подписка — гарантия что придут снова.

Отдельное слово о презентации. Добавь раздел «кто мы», и пусть там будут ссылки на самое интересное. Блог, презентация, группа. В самой презентации следует добавить текстовое описание, до 200 символов (его же разместить в разделе). То есть рекламный вброс, заставляющий посмотреть презентацию.

Также рекомендую заказать себе рисованую аваторку. Сделанную лично для тебя, и чтобы ни у кого такой не было. Желательно в минимальном [не детализированном] стиле, рисунок который легко запоминается — из строгих линий или анимешный стиль. Возможно какой-то жест или присутствие предмета [можно то и другое]. Поищи подобные картинки, убедись насколько они приятны для глаза и делают любой ресурс персонализированным [в отличие от фотографий].

В дополнение нужно заиметь ники, желательно всей команде если они будут выходить в общение.

И моя личная просьба — найди для Mash нормальный шрифт, не такой вырвиглазный.

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 15.07.2013 11:44

Советы ценю, спасибо)

Відповісти

Підтримати

Олексій Пєніє

Kate Burovova CEO в Mash 15.07.2013 09:31

И если есть такое количество вовлечённых — значит изюминка есть. По-любому есть.

Знаете, мне эта дискуссия напоминает немного банальную шутку про «доказать, что ты не верблюд», в нашем случае «доказать, что ты несешь ценность».
Если Вам действительно интересно разобраться пошагово с нашими импульсными активностями, проектами «Строим Mash» и «Лаборатория» — пожалуйста, поделимся опытом в личном порядке, раз Вы уже уделили нам столько времени:)

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 15.07.2013 10:15

Ну наконец-то ключевые слова. Спасибо, уже разобрался.
Жаль, конечно, что php не мой язык.
Проект интересный, кто хочет войти — рекомендую. Посмотреть кто есть кто можно здесь, здесь и вот здесь в первую очередь

// Неужели так сложно было в топике указать, всё выпытывать надо?

Ещё момент: проект работает на женской логике. Идеальный кандидат на работу — студентка 5 курса, желательно общительная. Обязательное хобби — хэндмэйд, общий интерес поможет делу. Желательно не мастер, а просто любитель, покупатель. Хобби можно преобрести по ходу дела, вместе с товаром.
Отдельный акцент: доходом является процент. То есть личное участие, общение в группе, и вообще желание использовать данный проект для себя — будут ключевыми мотивами.
Положительный фактор — если есть какие-то недостатки внешности (или просто неуверенность в ней). Именно товар ручной работы создаёт максимальную выгоду для таких людей, а также заставляет быть максимально требовательными клиентами. В частности, это может быть возраст «за 29». Отдельно добавлю, что именно это целевая клиентская аудитория, самые монетезируемые клиенты. Которым товар не просто побрякушки, а помогает улучшить качество жизни, дать доступ в желаемые социальные круги.
Вторая целевая аудитория — мамочки с дочками. Детям более чем кому либо необходимо быть уникальными, и разбираться в товаре. Однако, этот вариант подразумевает удалённую работу.

Как видишь, знание PHP вторично. Лучшим вариантом будет html/css, с желанием применять php не вдаваясь в глубокие дебри. Большинство работы будет связано с дизайном и человеческим фактором. SEO знать необязательно, в проекте уже есть специалист.

// Скажи ещё что ошибся :)

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 12.07.2013 18:13

Простите, ещё пропустила аргумент:

В отличие от prom.ua, mash.ua не имеет множества посадочных площадок, то есть не является аэродромом. Возможно развитие в эту сторону, но пока его нет. К тому же, для хэндмэйда подход сомнителен.

Верно ли я поняла: у нас нет чего-то, что для нас сомнительно в качестве подхода?

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 12.07.2013 18:23

Сомнительно в качестве главного (или единственного) подхода. Множество посадочных зон — хорошо [хоть и затратно, но решаемо]. Для для Вашего ресурса невыгодно быть множеством, выгоднее единство. Технически — это переходы с конкретных страниц на несколько целевых — каталоги, форумы, распродажи.

Відповісти

Підтримати

Kate Burovova

Kate Burovova CEO в Mash 12.07.2013 18:46

Простите, не увидела объяснения позиции, увидела повторение аргумента другими словами:)

Відповісти

Підтримати

Олексій Пєніє

Kate Burovova CEO в Mash 12.07.2013 18:48

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

И отдельно — спасибо за внимание к дискуссии, прочла у Вас «Никогда не общаюсь „от делать нечего“. Если я с Вами общаюсь — значит Вы мне чем-то полезны», восприняла буквально:)

Відповісти

Підтримати

Олексій Пєніє