Pull to refresh

Comments 43

Тест очень хитрьій, GAE скейлится довольно медленно, но уверенно. Вот пример habrahabr.ru/blogs/webdev/70252/ первьіе результатьі теста, что сам наблюдал тогда бьіли в раз 7 меньше чем текущие.
Так что гордость за партию Microsoft топикстартер может закатить обратно.
Простите за нескромный вопрос, у вас проблема с 'ы'? Клавиша залипает? Или проблема глубже? Маппить не пробовали на другую физическую клавишу?
[кэп]
у него украинская раскладка
[/кэп]
Извините, не знал что в украинском алфавите нет буквы 'ы', теперь буду.
у него комп слабый — русскую раскладку не тянет :)

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

Успехов.
Извиняюсь, что режет глаза, но тут глюк в семерке образовался, русский в списке есть, но переключится на него не могу хоть тресни — проскакивает.
у меня 3 раскладки стоит. русская-анлийская по контролу правому переключается (punto switcher).
немецкая — не так часто надо — по стандартному виндовскому переключению.
«В общем, действительно, все работает как и обещает Гугл – скорость не зависит от масштаба, медленно в маленьком масштабе, медленно и в большом :-) Даже один запрос к чему-то, что требует работы с Datastore или несколько Memcached – занимает кучу времени. Ну а если вам нужно сделать несколько запросов на страницу – ваши шансы увидеть exception’ы по таймауту резко повышается. » — это по вашей ссылке.

Вы ничего толком не опровергли. GAE, да, „устойчиво медленно“ работает. А Azure — быстро. Мне кажется, стоит бороться с маниакальным желанием опустить MS невзирая на факты.
UFO landed and left these words here
Как всегда самое интересное в комментах к статье оригинала:

«SQL Azure provides two database sizes: 1 GB (Web Edition) or 10 GB (Business Edition). If the size of your database reaches its MAXSIZE, you will receive an error code 40544. When this happens, you cannot insert or update data, rebuild indexes, and create new objects, such as tables, stored procedures, views, and functions. However, you can still read and delete data, truncate tables, and drop tables and indexes. If you remove some data to free up your storage space, there can be as much as a fifteen-minute delay before you can insert new data.»


А с 9000 онлайн юзеров, которые совершают 1200 транзакций в секунду — 10 Гигабайт данных, это очень мало
При том, что Amazon гораздо старее сервис, Azure себя показывает очень достойно
Естественно что наибольшее масштабирование у сервисов хранения данных.
Google AppEngine не файлохранилище или БД.
Глупо его включать в это сравнение.
MS Azure — это тоже не БД. Это связка из СУБД SQL Azure и App-сервера на .Net. Картинка из оригинальной статьи:
очень хочется понять что такое этот «WIPS», поскольку странным является сравнение сервисов приложений таких как appengine, azure, баз данных — simpledb и rds и стораджа S3

ведь очевидно же, что, например 1000 запросов в секунду на статический файл в S3 и 1000 транзакций на RDS — совершенно разные вещи — это как сравнивать скорость самолета и автомобиля
«смотрите — скорость самолета в 5 раз быстрее» — абсолютно разные же задачи

а azure удивил, да, но к сожалению найти деталей пока не могу

ping highscalability.com
PING highscalability.com (65.39.205.54): 56 data bytes
^C
— highscalability.com ping statistics — 4 packets transmitted, 0 packets received, 100% packet loss
У меня все прекрасно работает, вот небольшая выдержка из оригинальной статьи:
The focus of the work is on transaction processing (i.e., read and update work-loads), rather than analytics workloads. We used the TPC-W, a standardized benchmark simulating a Web-shop, as the baseline for our comparison. The TPC-W defines that users are simulated through emulated browsers (EB) and issue page requests, called web-interactions (WI), against the system. As a major modification to the benchmark, we constantly increase the load from 1 to 9000 simultaneous users to measure the scalability and cost variance of the system. Figure 1 shows an overview of the different combinations of services we tested in the benchmark.
The main results are shown in Figure 2 and Table 1 — 2 and are surprising in several ways. Most importantly, it seems that all major vendors have adopted a different architecture for their cloud services (e.g., master-slave replication, partitioning, distributed control and various combinations of it). As a result, the cost and performance of the services vary significantly depending on the workload. A detailed description of the architectures is provided in the paper. Furthermore, only two architectures, the one implemented on top of Amazon S3 and MS Azure using SQL Azure as the database, were able to scale and sustain our maximum workload of 9000 EBs, resulting in over 1200 Web-interactions per second (WIPS). MySQL installed on EC2 and Amazon RDS are able to sustain a maximum load of approximate 3500 EBs. MySQL Replication performed similar to MySQL standalone with EBS, so we left it off the picture. Figure 1 shows that the WIPS of Amazon’s SimpleDB grow up to about 3000 EBs and more than 200 WIPS. In fact, SimpleDB was already overloaded at about 1000 EBs and 128 WIPS in our experiments. At this point, all write requests to hot spots failed. Google AppEngine already dropped out at 500 emulated browsers with 49 WIPS. This is mainly due to Google’s transaction model not being built for such high write workloads. When implementing the benchmark, our policy was to always use the highest offered consistency guarantees, which come closest to the TPC-W requirements. Thus, in the case of AppEngine, we used the offered transaction model inside an entity group. However, it turned out, that this is a big slow-down for the whole performance. We are now in the process of re-running the experiment without transaction guarantees and curios about the new performance results.
Не глупо, Google предоставляет «Platform as a Service (PaaS)» в виде Google Apps, а это соответственно полный стек услуг из коробки, включая Big Table, т.к. ничего другого кроме Big Table + Memcached в Google Apps использовать нельзя.
Тем не менее ничего новее не выпущено, и пользуются для тестирования именно им.
Много что obsolete в мире :)
Теперь буду спать спокойно т.к. пользуюсь Амазоном.
UFO landed and left these words here
первый же комментарий в блоге на highscalability говорит, что правильное тестирование по методике TPC-W подразумевает, что «For each of the emulated browsers, the database must maintain 2880 customer records and associated order information»
иначе говоря, для теста с 9000 одновременных клиентов база данных должна весить примерно 90Гб, тогда как для тестирования на любом количестве клиентов использовалась одна и та же база с 2880x100 записей (то есть та, которую нужно использовать только для сотни одновременных клиентов).
что сильно снижает ценность этого теста, поскольку результаты получаются не «TPC-W transactions per seconds», а сферические лошади в часах.
кроме того, вероятно, графики для mysql, s3 и azure распрямились бы гораздо раньше.
очередной заказной тетраэдрный тест от замполита эвангелиста
Вполне возможно, что неправильные сервисы были просто криво сконфигурированны. Наприме, у google app engine, есть такое понятие entity group, набор объектов, который условно говоря хранится очень рядом. Если вся большая база будет в одной entity group, естественно, все будет тормозить.
When implementing the benchmark, our policy was to always use the highest offered consistency guarantees, which come closest to the TPC-W requirements. Thus, in the case of AppEngine, we used the offered transaction model inside an entity group.
Ну да, я был прав.
Похоже, ещё на определённом этапе сработала защита от DDoS (падение производительности после 500 пользователей), без которой всё упёрлось бы в планку базы без дальнейшего падения до нуля.

Ну и, немного отходя от техники: грядущее появление SQL в GAE сделает платформу совместимой с современными корпоративными стандартами, что сильно изменит рынок облачных решений для бизнеса. Так что подобные подготовки со стороны конкурентов вполне закономерны. Интересно, чем ответит гугл…
Ддос тут не причем. Они просто тупо истратили поминутные квоты на бесплатном приложении (на платном фиксированные квоты сильно возрастают). И получали overquota, уверен на 99.99%

На счет SQL далеко не все ясно. Чудес гугль не сделает. Как сказал ikai@google — «Distributed datastores wouldn't exist if we had figured out a way to do scalable, cheap and fast horizontally scalable SQL that could preserve ACID transactions, foreign key constraints and table scans.»

Появится лишь еще одно хранилище, абсолютно надежнее конечно, чем на собственном сервере (т.к таблицы будут в облаке на GFS храниться, имхо), но и дороже это будет полюбому.
Такое вряд ли прокатило бы — в тесте делается упор на выгоду использования Azure и приводятся цифры резко возрастающей при нагрузке стоимости GAE. Кроме того, поминутные квоты больше не действуют.

С другой стороны, досталось и амазону — «для чистоты эксперимента» был отключен auto-scaling, очевидно поэтому его график тоже далёк от идеала. MS выделили C# (ибо их чудо-база с другими языками не умеет взаимодействовать), остальным — яву (я даже и не подозревал, что S3 поддерживает её).

В общем, рекламный проспектик платинового спонсора (тут полная версия) вышел так себе. Однако, почти наверняка многие воспримут как положено — будут восхвалять Azure и бояться неведомой облачной гугни.
Да, бичую себя. У меня все приложения на биллинг сразу вешаются, посему совсем вылетело из головы про отмену, спасибо что напомнили.
Но это и не защита от ддоса, поразбираюсь завтра, что у них могло случиться, или быть можент они вообще «подстроили» синтетический тест на хранении всех данных (!) в одной группе, благодаря чему получали отказ хранилища на большой нагрузке.
Почти наверняка кривой код на GAE был написан ради этой замечательной фразы:
This is mainly due to Google’s transaction model not being built for such high write workloads.


Цифры, приведённые в сравнительной стоимости также не вызывают доверия. Если посчитать дневную стоимость на основании средней стоимости запроса из первой таблицы (1EB = 500 запросов в час), то получится следующее:
1EB: 0,02$/d (1 запрос: 2с)
10EB: 3,36$/d (1 запрос: 1с)
100EB: 39,6$/d (1 запрос: 1,12с)
500EB: 252$/d (1 запрос: 1,51с)
1000EB: 2112$/d (1 запрос: 6.34с)
При таких параметрах скрипта на обработку 1000EB требуется мощность, равная 880 ядрам x86 1200Мгц. Неудивительно, что далее гугл отказал в обслуживании.

А за сравнением плохого кода на AE и хорошего на Azure кроются такие цены:
WinAzure:
  • Compute = $0.12 / hour
  • Storage = $0.15 / GB stored / month
  • Storage transactions = $0.01 / 10K
  • Data transfers = $0.10 in / $0.15 out / GB — ($0.30 in / $0.45 out / GB in Asia)

SQL Azure:
  • Web Edition: Up to 1 GB relational database = $9.99 / month
  • Business Edition: Up to 10 GB relational database = $99.99 / month
  • Data transfers = $0.10 in / $0.15 out / GB — ($0.30 in / $0.45 out / GB in Asia)
>> ибо их чудо-база с другими языками не умеет взаимодействовать

это ложь, Azure доступна для Java и PHP разработчиков
SQL Azure вообще не зависит от языка, вот например JDBC-коннектор для нее
habrahabr.ru/blogs/Azure/81965/
Кстати, интересно почему не проводилось тестирование Blob Service Storage от Azure
Которое является неким аналогом Amazon S3

В нем как раз нет ограничений на объем хранимых данных habrahabr.ru/blogs/hi/94964/#comment_2895982

msdn.microsoft.com/en-us/library/ee691964.aspx
Притом тут есть, фактически, транзакционная модель.

Исследователи считают иначе, цитата из полной версии отчёта:
Microsoft has recently launched Azure, a set of cloud services
based on Windows, SQL Server, and .Net. To experiment with
Azure, we implemented the TPC-Wbenchmark in C# with embed-
ded SQL. In theory, other technology such as Java can also be de-
ployed on the Azure cloud, but then the libraries for accessing the
Azure database service and other Azure services are not available.
Как может дотнет-приложение «не мочь» взаимодействовать с другими языками? вы вообще хорошо знакомы с .net? любые .net-языки прозрачно взаимозаменяемы, а их море. в том числе и IronPython, и IronRuby.
С дотнетом я совершенно не знаком, как и с платформой Azure, поэтому в этом вопросе доверился авторам. Скажите, пожалуйста, приведённая выше цитата имеет техническое обоснование, или это чистый маркетинг для привлечение корпоративных пользователей на дотнет?
Конечно легко может НЕ взаимодействовать с другими языками, гуглите по CLS compliant code
Ограничение на 500 одновременных запросов, кстати, задокументировано
code.google.com/appengine/docs/quotas.html#Requests

The per-minute quotas for application with billing enabled allow for up to 500 requests per second--more than one billion requests per month. If your application requires even higher quotas than the «billing-enabled» values listed below, you can request an increase in these limits here.


code.google.com/appengine/docs/quotas.html#Per-minute_Quotas

In addition to the daily quotas described above, App Engine moderates how quickly an app can consume a resource, using per-minute quotas. This protects the app from consuming all of its quota in very short periods of time, and keeps other apps from affecting your app by monopolizing a given resource.
Это устаревшая информация. К сожалению, поддерживать документацию в актуальном состоянии они уже не успевают.
в общем, интересное тестирование какое-то,

кстати, я так понял объем данных для тестов был не больше гигабайта, т.е. все данные были в кеше, что тоже как бы не самый лучший тест для БД
тогда бы уже рядом и мемкеш потестировали бы
Кстати по поводу производительности Azure, по началу сложилось мнение, что она крайне низкая, но после переписки с суппортом разобрались в чем проблема была, если кому интересно magora-systems.ru/articles/83-azure-storage-slow (там про использование Entity Group Transactions)
Only those users with full accounts are able to leave comments. Log in, please.