WapGraf, мы нигде не говорили о том что SATA это 15000, и не сравнивали исключительно с десктопными дисками.
... перечитайте внимательно наш отзыв :)
WapGraf, попробуем сказать по другому:
Обычные лучшие компьютерные 3.5 HDD (именно их мы называем десктопными) вряд ли смогут значительно преодолеть 100 IOPS.
Серверные SAS, в самом лучшем исполнении, вряд ли смогут взять значительно больше 200 IOPS.
Какое количество из предложенных на рынке самых лучших серверных SAS 15000 RPM перейдет 200 IOPS - не знаем, у нас нет серверного парка HDD.
Наш посыл был в том, что в самом-самом лучшем случае, мы не можем расчитывать на скорость больше 200 IOPS даже для лучших SAS HDD.
Если вы говорите, что на вашей практике самый лучший выдал 192 IOPS - так тому и быть, пусть вместо 200 будет 192, сути это не меняет.
Среднюю цифру хостеров, а у каждого могут быть свои серии дисков, мы не знаем (у вас свои цифры, вы поделились, у кого-то другие - возможно, тоже напишут).
В любом случае, она вряд ли будет больше 200 IOPS, а скорее всего меньше.
Т.е. речь шла о том, что даже получив отличное решение в виде SAS HDD, мы бы значительно не вышли за 200 IOPS в случае одного диска
(а в реальности эта цифра в силу разных причин была бы меньше).
А нам уже нужно было больше, т.е. без SSD никак.
Приведенные цифры не мифические, а предельно допустимые.
Если нужны ссылки подтверждения , то вот сходу находятся несколько ссылок:
https://answers.splunk.com/answers/84340/how-many-iops-can-i-expect-from-a-disk.html
Device Type IOPS Interface
=========== ===== ================ ===========
7,200 rpm SATA ~75-100 IOPS[2] SATA 3 Gb/s
10,000 rpm SATA ~125-150 IOPS[2] SATA 3 Gb/s
10,000 rpm SAS ~140 IOPS[2] SAS
15,000 rpm SAS ~175-210 IOPS[2] SAS
http://community.netapp.com/t5/FAS-and-V-Series-Storage-Systems-Discussions/IOPS-for-SATA-SAS-FC-disks/td-p/51494
sata 70-80 iops
scsi
10k FC/sas 110-120 iops
15k FC/sas 150-160 iops
http://serverfault.com/questions/512386/hdd-performance-differences-between-7-2k-sata-and-15k-sas
For a 7.2K RPM drive, a seek-time of 8.5ms and latency of 4.16 gives an IOPS number of 78.
For a 15K RPM drive, a seek-time of 2.6ms and latency of 2.0ms gives an IOPS number of 217.
For a 15K RPM drive, a seek-time of 3.4ms and latency of 2.0ms gives an IOPS number of 185.
Добрый вечер!
Пришла и наша очередь написать отзыв (наш проект, для которого, собственно, и брался хостинг, уже работает ~2 недели, так что уже можно рассказать, что и как).
Дальше много букв, поэтому сразу наш вывод, кто испугался и решил не читать до конца: Услугой полностью довольны, все быстро и стабильно.
Кратко о нас - разработчики десктопного софта базы ключевых слов.
Хостинг от ua-hosting.company нам нужен прежде всего для практической (в боевых условиях) проверки некоторых технических моментов (основной проект ещё не готов, но наработки для проверки уже есть).
Поэтому было решено попутно решить 2 задачи:
1. Проверить эти самые технические моменты в боевых условиях.
2. Выпустить что-то полезное, которые было бы нужно и привлекло аудиторию.
Чтобы заинтересовать как можно большо людей, а заодно проверить некоторые идеи по поводу нагрузки, было решено:
1. Сервис предоставить бесплатно.
2. Не требовать регистрации для доступа к сервису (т.е. просто заходи и пользуйся).
Сам сервис - это подбор ключевых слов по домену конкурента.
Ну а теперь возвращаемся к хостингу.
В начале был один нюанс, из-за которого чуть было не передумали воспользоваться предложением hosting_manager - это скан паспорта для использования услуги.
Ты вроде как и не скрываешься, и не собираешься делать что-то плохое на сервере, но делать сканы своих документов вот так сходу желания нет никакого.
Но после общения с поддержкой выяснилось, что скан нужен для тестирования (т.е. когда полностью бесплатно).
В нашем же случае оплата была (февраль куплен, январь по условиям акции - бесплатно).
Поэтому решение было принято простое - при регистрации указать полностью правильные данные (т.е. никаких фейков).
Ну а если в процессе выяснится, что нужен скан - то принять решение по факту - если ситуация такая, что действительно нужен, то предоставить, если надуманная - то отказаться от услуги.
В первую очередь нас заинтересовал выделенный SSD накопитель (поэтому собственно и обратили внимание на этот топик), поэтому конфигурация была куплена следущая:
VPS 12 Cores E5-2650v4, 20GB DDR4, 480GB SSD
Сейчас уже сложно вспомнить, сколько времени активировался сервер, но что-то типа часа или близко к этому (+/-).
Т.е. с нашей точки зрения это быстро, тем более если учесть, что это было 31 декабря :)
SSD
Прежде всего решили протестировать SSD с помощью CrystalDiskMark:
Sequential Read (Q= 32,T= 1) : 2987.601 MB/s
Sequential Write (Q= 32,T= 1) : 2035.610 MB/s
Random Read 4KiB (Q= 32,T= 1) : 148.416 MB/s [ 36234.4 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 128.225 MB/s [ 31304.9 IOPS]
Sequential Read (T= 1) : 3775.585 MB/s
Sequential Write (T= 1) : 1596.060 MB/s
Random Read 4KiB (Q= 1,T= 1) : 55.548 MB/s [ 13561.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 48.368 MB/s [ 11808.6 IOPS]
Test : 1024 MiB [C: 3.1% (13.3/431.9 GiB)] (x5) [Interval=5 sec]
Нас прежде всего интересовали случайные чтения, результаты нас полностью устроили.
Sequential Read и Sequential Write показались нам слишком высокими, было такое ощущение, что где-то что-то кешируется.
У CrystalDiskMark есть возможность увеличить область тестирования (по умолчанию она 1 Гб), чтобы не попадать в кеш.
Увеличили, провели повторный тест:
Sequential Read (Q= 32,T= 1) : 2921.873 MB/s
Sequential Write (Q= 32,T= 1) : 2022.334 MB/s
Random Read 4KiB (Q= 32,T= 1) : 137.367 MB/s [ 33536.9 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 129.519 MB/s [ 31620.8 IOPS]
Sequential Read (T= 1) : 3893.853 MB/s
Sequential Write (T= 1) : 1640.742 MB/s
Random Read 4KiB (Q= 1,T= 1) : 52.716 MB/s [ 12870.1 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 49.217 MB/s [ 12015.9 IOPS]
Test : 32768 MiB [C: 44.7% (193.1/431.9 GiB)] (x5) [Interval=5 sec]
Это практически не изменило цифры.
В итоге просто скопировали большой файл в nul и посмотрели сколько времени это займет.
Скорость вышла ~420 Mb/sec для последовательного чтения, на чем мы и успокоились (на выяснение, где все-таки и что кешируется, просто решили не тратить время).
CPU и память
После этого решили потестировать CPU и память.
С нашей точки зрения для этого идеально подходит архиватор 7-zip (у него есть встроенный benchmark, и его результаты хорошо ложатся на нашу задачу).
Тестирование проводилось со словарем 2 MB и 32 Mb.
Тест с словарем 2 MB:
1 - 3009
6 - 14798
12 - 22852
Тест с словарем 32 MB:
1 - 2708
6 - 16395
12 - 26233
Первая цифра - это количество потоков, вторая - MIPS, общий рейтинг.
Из этих цифр можно сделать простой вывод - чем интенсивнее используется память (словарь 32 MB - более интенсивно, чем словарь 2 Mb), тем лучше масштабирование по ядрам.
Для варианта со словарем 32 Mb оно почти линейное, что очень хорошо.
Поскольку VPS - это не ты один, а всегда с "соседями по коммуналке", то было интересно проверить, насколько цифры могут меняться со временем.
Запускали тест повторно в разное время суток, цифры были такими же, на чем опять же и успокоились :)
Сеть
Загрузку канала по полной не проверяли, поскольку у сервера, судя по всему, должен быть гигабит, а такого канала у себя просто нет.
Но проверили по другому - с трех разных обычных ПК у разных провайдеров начали загружать данные по полной (100 мбит).
В итоге ~300 мбит было стабильно загружены, т.е. на практике 300 Mbit (то, что было в силах проверить) отдаются отлично.
Дальше пришло время разработки самого проекта - разработка, баги, фиксы.
В итоге хоть сервер мы и взяли 31 декабря, выпустили сервис только 17 января вечером.
18 января был первый пик посещений - был анонс на разных форумах.
25 января был второй пик посещений - этот пик связан с тем, что 24 вечером мы были упомянуты в новостной ленте серча - /ru/news/40230 - соответственно, были как новые заходы с самого серча, так и с других ресурсов, которые новость растиражировали.
В пиках у нас было 80-90 одновременных поисков в секунду (для нас это самая тяжелая операция, просто запрос страничек с точки зрения нагрузки можно игнорировать).
Технически для нас один поиск - это 2-4 случайных операции чтения с диска, каждая объемом вплоть до 20 МБ (но обычно меньше 1 МБ).
Т.е. в итоге в моменты пика нагрузки это было от 160 ("легкий" вариант) до 360 ("тяжелый" вариант) IOPS.
Просто для сравнения: обычные десктопные HDD, грубо говоря, неплохо себя чувствуют приблизительно до 100 IOPS, все что свыше - уже проблема (медленно).
Серверные - приблизительно 150-200 IOPS - нормально, выше - тоже медленно.
Т.е. на HDD (даже на серверных) наш проект стал бы в пиках немного тормозить, и это никак бы не решилось (закешировать нельзя, чтения ведь случайные).
Но благодаря SSD это даже не нагрузки (см. цифры выше: 33-36 тыс. IOPS для SSD), т.е. запас огромный, и мы уже знаем как его использовать :)
В итоге, как видно, выбор хостинга с выделенным SSD от ua-hosting.company себя полностью оправдал.
По CPU/памяти хотелось добавить следующее - изначально ни CPU, ни память не планировалось особо использовать.
Схема работы планировалась "у себя локально подготовить всего данные, залить на сервер, а с сервера раздавать уже все готовое".
Т.е. исходили из того, что нужен только быстрый SSD, а остальное - как получится.
Но в реальности получилось, что CPU было столько и памяти столько, что данные уже формировались на самом сервере, и не было необходимости формировать их локально.
Более того, по результатам боевого теста (первый пик) - стало видно, что CPU более, чем достаточно, схема работы ещё немного поменялась, и часть данных мы стали считать "на лету", не формируя заранее.
Ну и поскольку ресурсов сервера хватает с избытком, то решили добавить (пока в разработке) ещё один модуль, который изначально не планировали.
По поводу hosting_manager (Sergii Sikorskyi)
Ещё до запуска (когда был уже куплен хостинг, но проект ещё не был готов), были прикидки, что нужно для основной части проекта (там нужен именно выделенный сервер).
Поэтому было решено поспрашивать в чате у поддержки, что и сколько стоит, в итоге в чате попали именно на Sergii Sikorskyi (он же здесь hosting_manager).
Ответив на несколько технических вопросов, Сергей задал пару вопросов-уточнений для чего нужно, предложил ещё пару возможностей.
Потом снова ответил на вновь возникшие вопросы...
Изначально по плану было задать пару вопросов за 5 минут и выйти из чата, но общение затянулось намного дольше, наверное, на час или около того.
Все это время Сергей отвечал на все вопросы, которые возникли, и которые уже, наверное, достигли стадии "непонятно будут ли клиентами, но голову поморочат" :)
Где-то уже во второй половине чата, узнав, что я уже клиент компании (изначально общение было анонимно), спросил о текущей конфигурации, подсказал, как по необходимости ускорить виртуалку для специфичного софта путем включения дополнительных инструкций CPU, ответил ещё на пару вопросов по новым конфигурациям виртуальных серверов.
Впечатление об общения исключительно положительное - все по делу.
Итого:
1. Техническая часть (железо) - отлично. 2. Консультация hosting_manager - отлично. 3. Тех. поддержка - "общие" вопросы - отлично, решение проблем - неизвестно (не пришлось воспользоваться).
Надеемся, наш отзыв, пусть и отчасти субъективный, был интересен и полезен.
Спасибо hosting_manager за отличную услугу.
Марина и Сергей,
Команда Букварикс
Обновлена база рекламных объявлений Яндекс.Директ, которая собиралась с октября прошлого года по январь текущего года.
В базе 52 528 849 уникальных рекламных объявлений, 494 021 уникальных доменов рекламодателей, 6 090 071 уникальных заголовков и 17 023 738 уникальных текстов рекламных объявлений по регионам Россия, Украина, Беларусь, Казахстан и крупным городам этих стран.
Как и прежде, базу можно скачать в виде дампа CSV (473 МБ в архиве, 9,09 ГБ в развернутом виде) и в виде файла базы данных SQLite DB для работы в оболочке (1,35 ГБ в архиве и 14,2 ГБ в развернутом виде).
Подробнее, скачать:
http://www.bukvarix.com/ad-bases.html
Мы только что перекачали и проверили первую часть с облаков, ошибки в ней нет. Возможно, другие части скачались с ошибками, а архиватор указывает только на первую часть, проверьте, пожалуйста, md5. Вот список правильных:
97973375d6b52a79b8cd1d22acdfd8d7 *bukvarix2.6.part001.rar
66397a201d5a563ab1b1b4b81f5c62d3 *bukvarix2.6.part002.rar
e7695bbbedde774f384bba70137c4a68 *bukvarix2.6.part003.rar
bf78d88f6b9750928b9cb1552c3315d3 *bukvarix2.6.part004.rar
2870d476b2e32ace2147ba531c13630c *bukvarix2.6.part005.rar
b131cd73f45707c1db47adfb28e392e8 *bukvarix2.6.part006.rar
86cb66b3ef3ee57ce7386f67bda4e0c9 *bukvarix2.6.part007.rar
d31adf3c8a8616bb1756f8d344ea6526 *bukvarix2.6.part008.rar
de9fb808affcae2cf639bbceb68f90ba *bukvarix2.6.part009.rar
80cb95099726c2e34412cd7a7e0bb883 *bukvarix2.6.part010.rar
af640337ae21b52545ad41730d930155 *bukvarix2.6.part011.rar
06ed2d6e970657f2fa41aadac72d3382 *bukvarix2.6.part012.rar
28bf3c1ce05666416c7ddfb0b8bfc414 *bukvarix2.6.part013.rar
2bb29fbd7211b05128d8691bd2466fd8 *bukvarix2.6.part014.rar
fdf0d3fdb1f0d9a9337de4228fdc9438 *bukvarix2.6.part015.rar
d820bc203fed7845792dad2a0f906195 *bukvarix2.6.part016.rar
f7ed66ca383420afe4d02e173c8003d1 *bukvarix2.6.part017.rar
1fb54b1dcbb260210a2cf9e4e96a7789 *bukvarix2.6.part018.rar
dc8ed8bdd40fe5113ad86006f915eb72 *bukvarix2.6.part019.rar
bc8c9c1724b7fa12d3c072f471819755 *bukvarix2.6.part020.rar
41704cc9c9bad595a53f13abd1ccaab1 *bukvarix2.6.part021.rar
Здравствуйте,
Сегодня у нас несколько новостей.
1) Релиз Букварикса 2.6 - новой версии программы с обновленной базой ключевых слов и частотностей. Обновление проводилось в декабре 2016 г. - первой половине января 2017 г.
К спискам слов Комбинатора добавлены названия гостиниц и метро Москвы и Санкт-Петербурга (с благодарностью к пользователю по имени Антон, который прислал нам эти списки).
В этом релизе мы перешагнули за 2 млрд. ключевых слов.
Архив Букварикса 2.6 занимает 37,5 ГБ, после распаковки - 168 ГБ.
Скачать Букварикс 2.6:
http://www.bukvarix.com/download.html
2) 57 готовых выборок обновлены по базе Букварикс 2.6 (для тех, кто не может скачать Букварикс из-за размеров).
Скачать выборки:
http://www.bukvarix.com/keyword-selections.html
Добавлен предпросмотр списков ключевых слов в веб-сервисе для подбора слов по домену (добавит удобства пользователям, которые заходят на сайт с мобильных устройств):
http://beta.bukvarix.com/
Спасибо за отзыв!
Все файлы в кодировке UTF-8 + BOM.
Если речь идет о неправильном отображении в Excel, то тогда можно попробовать сделать следующее:
1. Для того, чтобы открыть список ключевых слов, нужно выбрать файл со списком через меню Excel Open/Открыть файл.
2. В меню выбора формата файлов нужно выбрать "Text Files (* .prn,* .txt, *.csv)"/"Текстовые файлы (*.prn, *.txt, *.csv)", затем выбрать файл со списком ключевых слов.
3. Откроется окно, в котором можно выбрать кодировку и знак разделителя для правильного отображения в колонках.
4. Выберите кодировку UTF-8, а разделитель - точка с запятой (semicolon).
Отличие этого способа открытия файла от стандартного по клику на файле в том, что здесь можно явно выбрать кодировку.
Сегодня мы обновили наш онлайн мини-сервис подбора слов по домену:
http://beta.bukvarix.com
Добавлена следующая информация:
1. Появился выбор региона Яндекса, т.е. в дополнение к региону "Москва" добавлены "Санкт-Петербург" и "Россия".
2. CSV файлы с данными в zip-архивах теперь называются не "keywords.csv", а по имени домена с упоминанем региона, например "msk_website.com.csv". Это позволит удобнее работать в Excel'е, который не позволяет открывать файлы с одинаковым названием. Да и нагляднее видно, к какому домену относится файл.
Хотелось бы уточнить, что данные можно получать не только по домену, но и по субдомену, например, при запросах "wikipedia.org" и "ru.wikipedia.org" получаются разные списки слов, но слова для "wikipedia.org" включают слова для "ru.wikipedia.org". Т.е. если вам нужны слова по конкретному субдомену, вводите субдомен, получите более точный список. Это имеет смысл, например, для авторских сайтов на livejournal.com, blogspot.com и т.п.
Предварительный просмотр добавим на следующей неделе.
Мы несколько раз обдумывали переход на платную версию в прошлом, но приняли решение перейти к ней, когда в наличии будут все главные функции, которых ожидают от такого продукта.
Это не альтруизм и не подвох, это неготовность продукта к коммерческой стадии. А природа продукта такова, что данные устаревают быстро и теряют ценность, поэтому нам не жалко для пользы дела (поддержания интереса к своему проекту в принципе) раздавать эти данные бесплатно, пока мы не сможем предложить достойную платную версию.
Как всегда возникает вопрос, а останется ли бесплатная версия? Мы планируем оставить бесплатную версию, но сколько и какого функционала в нее войдет, мы сможем определить по результатам тестирования нагрузки на сервер. Хотим, чтобы бесплатная версия была достаточно функциональной.
Что касается текущего сервиса, то слова и частотности взяты из Букварикса 2.5 (обновлялся в конце октября-ноябре 2016 года), это топ 103 млн. ключевых фраз. Выдача Яндекса по Москве собиралась с середины декабря до почти середины января.
Через несколько дней мы добавим данные из выдачи Яндекса по Санкт-Петербургу и по России. Эти данные запрошены в первой половине января по топ 30 млн. ключевых слов.
В перспективе мы хотим выйти на срок обновлений этого сервиса примерно 1 - 1,5 месяца. В ближайшем будущем сервис останется бесплатным, а вообще платная версия появится с появлением онлайн сервиса для подбора ключевых слов (по поиску слов). Бесплатную версию в каком-то достаточно функциональном виде мы также планируем оставить, а что сможем потянуть по нагрузке, посмотрим по результатам тестирования. Но опять же - это будет позже, а в ближайшее время все останется бесплатным.
Спасибо, что отметили полноту базы. Пока мы не можем похвастаться более функциональным решением, чем известные платные сервисы, но со временем подтянемся :)---------- Добавлено 18.01.2017 в 20:32 ----------
Мы видим, что адреса страниц востребованы, поэтому в будущем добавим (не в ближайшем). А сейчас хотели прежде всего оттестировать некоторые технические моменты для будущего сервиса Букварикса, но и попутно быстро выпустить решение, которое было бы бесплатным и полезным всем.
