Gevent ready memcache client? - memcached

I see that there's a port of memcache client for gevent (https://github.com/hjlarsson/gevent-memcache), but it has not been updated since August 2010. Do you guys have any recommendation on a memcache client for using in gevent?

Found one, released and maintained by the guys at www.esn.me
https://github.com/esnme/ultramemcache
They also have a faster JSON decoder as well, coded in C with python binding.

There is the python-ultramemcache that give the same interface as python-memcache, but use ultramemcache. So you only need to change your import if you already use python-memcache:
http://pypi.python.org/pypi/python-ultramemcached/0.0.2
To install:
pip install python-ultramemcache
Then in your code:
import ultramemcache as memcache

Related

Vertx 4.2.1 Redis ConfigReader issue

Running into some strange issues while using redis 6.2.6 as the config server. The config is stored using the HSET commands
HSET appt-src-svc-local vertx '{"listen.port": 8080}'
HSET appt-src-svc-local mongo '{"host":"127.0.0.1", "port":27017}'
...
When using Redis 4, the config can be retrieved correctly. If we switch to V 6.2.6, the RedisConfigStore is unable to parse the Response correctly.
Any help will be much appreciated.
TIA
I believe the vertx-config hasn't been verified to work correctly with the new protocol negotiation feature to support both old and new servers. For now, you could try to force the protocol to fall back to RESP2 (old one) and open an issue on GitHub to test and support any protocol.
To disable the protocol negotiation, you need to configure redis client with:
protocolNegotiation: false

Headless browser and locust.io

Is it possible to integrate a headless browser with locust? I need my load tests to process client side script that triggers additional requests on each page load.
That's an old question, but I came across it now, and found a solution in "realbrowserlocusts" (https://github.com/nickboucart/realbrowserlocusts) - it adds "Real Browser support for Locust.io load testing" using selenium.
If you use one of its classes (FirefoxLocust, ChromeLocust, PhantomJSLocust) instead of HttpLocust for your locust user class
class WebsiteUser(HeadlessChromeLocust):
then in your TaskSet self.client becomes an instance of selenium WebDriver.
One drawback for me was that webdriver (unlike built-in client in HttpLocust) doesn't know about "host", which forces to use absolute URLs in TaskSet instead of relative ones, and it's really convenient to use relative URLs when working with different environments (local, dev, staging, prod, etc.).
But there is an easy fix for this: to inherit from one of realbrowserlocusts' locusts and pass "host" to WebDriver instance:
from locust import TaskSet, task, between
from realbrowserlocusts import HeadlessChromeLocust
class UserBehaviour(TaskSet):
#task(1)
def some_action(self):
# self.client is selenium WebDriver instance
self.client.get(self.client.base_host + "/relative/url")
# and then for inst. using selenium methods:
self.client.find_element_by_name("form-name").send_keys("your text")
# etc.
class ChromeLocustWithHost(HeadlessChromeLocust):
def __init__(self):
super(ChromeLocustWithHost, self).__init__()
self.client.base_host = self.host
class WebsiteUser(ChromeLocustWithHost):
screen_width = 1200
screen_height = 1200
task_set = UserBehaviour
wait_time = between(5, 9)
============
UPDATE from September 5, 2020:
I posted this solution in March 2020, when locust was on major version 0. Since then, in May 2020, they released version 1.0.0 in which some backward incompatible changes were made (one of which - renaming StopLocust to StopUser). realbrowserlocusts was not updated for a while, and is not updated yet to work with locust >=1.
There is a workaround though. When locust v1.0.0 was release, previous versions were released under a new name - locustio with the last version 0.14.6, so if you install "locustio==0.14.6" (or "locustio<1"), then a solution with realbrowserlocusts still works (I checked just now). (see https://github.com/nickboucart/realbrowserlocusts/issues/13).
You have to limit a version of locustio, as it refuses to install without it:
pip install locustio
...
ERROR: Command errored out with exit status 1:
...
**** Locust package has moved from 'locustio' to 'locust'.
Please update your reference
(or pin your version to 0.14.6 if you dont want to update to 1.0)
In theory you could make a headless browser a Locust slave/worker. But the problem is that the browser is much more expensive in terms of CPU and memory which would make it difficult to scale.
That is why Locust uses small greenlets to simulate users since they much cheaper to construct and run.
I would recommend you to break down your page's requests and encode them as requests inside of Locust. The Network tab in Chrome's Dev Tools is probably a good start. I've also heard of people capturing these by going through a proxy that logs all requests for you.
You could use something like browserless to take care of the hosting of Chrome (https://browserless.io). Depending on how you brutal your load tests are there’s varying degrees of concurrency. Full disclaimer: I’m the maker of the browserless service
I think locust is not desinged for that purposes, it is for creating concurrent user to make http requests so I didnt see any integration with locust and browser. However you can simulate browser by sending extra information in the header with that way client side scripts will also work.
r = self.client.get("/orders", headers = {"Cookie": self.get_user_cookie(user[0]), 'User-Agent': self.user_agent})
The locust way of solving this is to add more requests to your test that mimic the requests that the javascript code will make.
I structure my locust tests to parse the JSON response from an early request in the app's workflow. I then randomly pick some interesting piece of data from that JSON, and then issue more requests that mimic what would happen in the browser if the user had clicked on that piece of data.

Installing openTSDB on Ubuntu15.04

I have installed openTSDB(.deb package) on ubuntu 15.04 by following the guidelines stated in documentation. when I give this command "service opentsdb start" it is not starting and it is mentioned in documentation that we have to change some configuration files.can anyone please tell me what are the changes that we have to do and in which file the changes have to be done?
Thanks in advance
Regards
VHC
Check your logs in /var/log/opentsdb/opentsdb.log. You should have HBase up&running correctly (means i.e. you are able to create table and store some values)
Remember you have to create tables in HBase running
env COMPRESSION=NONE HBASE_HOME=path/to/hbase-X.XX.X /usr/share/opentsdb/tools/create_table.sh
http://opentsdb.net/docs/build/html/installation.html#create-tables

Zend_Cache with Memcachier

Can I use memcachier with ZendFramework 1.12 ?
The provider that I am useing(AppFog) only offers Memcachier (Memcached is comming soon from 10 Months) And My app will need a lot of caching when it starts. I don't want to stick with APC so I have no other good alternative.
So this is just a half answer right now, I'll try to figure out the rest. I work for MemCachier by the way, so please shoot us an email on support#memcachier.com if you have more questions.
PHP includes two memcache bindings by default: memcache and memcached. The first one (memcache) is its own implementation of the memcache procotol, while the second one (memcached) is a php binding to the libmemcached C++ library.
The memcached binding for php does support SASL these days (since version 2.0.0). Sadly it isn't documented. It also is an optional part of the memcached module, so you'll need to make sure it is compiled on your machine (or AppFog) with the SASL support enabled. The steps to do that roughly are:
Install libmemcached. I used version 1.0.14.
Install php-memcached. Make sure to pass the "--enable-memcached-sasl" option to it when running ./configure.
When building both of these you can sanity check the output of "./configure" to make sure that SASL support is indeed enabled, sadly right now it can be tricky.
Edit you php.ini file. Put the following line into it:
[memcached]
memcached.use_sasl = 1
I did all of this on OSX 10.8 using homebrew. If that is the case for you the following should work:
$ brew install libmemcached
$ brew edit php54-memcached
// you'll need to add the line:
args << "--enable-memcached-sasl"
// to the brew file.
$ brew install php54-memcached
Now to actually use SASL support, here is a test file that demonstrates it and is a good sanity check.
<?php
/**
* Test of the PHP Memcached extension.
*/
error_reporting(E_ALL & ~E_NOTICE);
$use = ini_get("memcached.use_sasl");
$have = Memcached::HAVE_SASL;
echo "Have SASL? $have\n";
echo "Using SASL? $use\n\n";
$mc = new Memcached();
$mc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mc->setSaslAuthData("user-1", "pass");
$mc->addServer("localhost", 11211);
$mc->set("foo", "Hello!");
$mc->set("bar", "Memcached...");
$arr = array(
$mc->get("foo"),
$mc->get("bar")
);
var_dump($arr);
?>
Adapting this to work in the Zend Framework is unknown to me right now. I'm not familiar with it so may take me some time to install and figure out. It seems very doable though given one of the backends works with SASL auth.

issues running jiraSOAP from ruby

I am trying my hands on accessing jira from ruby using the jiraSOAP gem.
I'm running ruby 1.9.2
But the moment I pass in my login credentials, I get the following error:
RuntimeError: The response is not a valid SOAP envelope
from /Users/rahulbaxi/.rvm/gems/ruby1.9.2p180/gems/handsoap1.1.8/lib/handsoap-/service.rb:388:in on_missing_document'
from /Users/rahulbaxi/.rvm/gems/ruby-1.9.2-p180/gems/handsoap-1.1.8/lib/handsoap/service.rb:442:in `parse_http_response'`
from /Users/rahulbaxi/.rvm/gems/ruby-1.9.2-p180/gems/handsoap-1.1.8/lib/handsoap/service.rb:250:in `invoke'
from /Users/rahulbaxi/.rvm/gems/ruby-1.9.2-p180/gems/jiraSOAP-0.10.3/lib/jiraSOAP/api.rb:55:in `build'
from /Users/rahulbaxi/.rvm/gems/ruby-1.9.2-p180/gems/jiraSOAP-0.10.3/lib/jiraSOAP/api.rb:69:in `soap_call'
from /Users/rahulbaxi/.rvm/gems/ruby-1.9.2-p180/gems/jiraSOAP-0.10.3/lib/jiraSOAP/api.rb:18:in `login'
from (irb):3
from /Users/rahulbaxi/.rvm/rubies/ruby-1.9.2-p180/bin/irb:16:in `<main>'`
Please help me out fix this!
Perhaps one of these samples will help.
http://jira4r.rubyhaus.org/2+minute+walkthrough
http://blogs.reucon.com/srt/2007/11/05/accessing_jira_from_ruby.html
#!/usr/bin/env ruby
require 'jira4r/jira4r'
jira = Jira::JiraTool.new(2, "http://jira.atlassian.com")
jira.login("soaptester", "soaptester")
puts jira.getProject("DEMO").inspect
Did you ensure that the JIRA instance has the RPC feature turned on?
It would be really helpful to see the HTTP response that is coming from the JIRA server and to know what version of JIRA it is
ended up using jira4r-jh which works just fine with ruby 1.9