memcached

Speeding up jQuery AutoComplete (Unavoidably long lists)

别说谁变了你拦得住时间么 提交于 2019-12-04 06:58:54
I began my journey to speed up jQuery's autocomplete earlier this afternoon, and decided it was probably a good idea to begin memcaching everything. As suggested in this article: Speeding up autocomplete . However, I am still dealing with slow response time even after installing and using Memcached. The problem in my case is that I am dealing with extraordinarily long lists, in my case, over 6700 individual members. (All genera or genuses of all plants) The bottleneck seems to be constructing the table and populating the client-side list, and it is not caused by retrieving the information from

微服务化的十个设计要点

喜欢而已 提交于 2019-12-04 06:43:38
原文: https://juejin.im/entry/5b35a770e51d4558cc35d95c 微服务有哪些要点呢?先看下图是 SpringCloud 的整个生态。 设计要点一:API 网关 在实施微服务的过程中,不免要面临服务的聚合与拆分,当后端服务的拆分相对比较频繁的时候,作为手机 App 来讲,往往需要一个统一的入口,将不同的请求路由到不同的服务,无论后面如何拆分与聚合,对于手机端来讲都是透明的。 有了 API 网关以后,简单的数据聚合可以在网关层完成,这样就不用在手机 App 端完成,从而手机 App 耗电量较小,用户体验较好。 有了统一的 API 网关,还可以进行统一的认证和鉴权,尽管服务之间的相互调用比较复杂,接口也会比较多,API 网关往往只暴露必须的对外接口,并且对接口进行统一的认证和鉴权,使得内部的服务相互访问的时候,不用再进行认证和鉴权,效率会比较高。 有了统一的 API 网关,可以在这一层设定一定的策略,进行 A/B 测试,蓝绿发布,预发环境导流等等。API 网关往往是无状态的,可以横向扩展,从而不会成为性能瓶颈。 设计要点二:无状态化,区分有状态的和无状态的应用 影响应用迁移和横向扩展的重要因素就是应用的状态,无状态服务,是要把这个状态往外移,将 Session 数据,文件数据,结构化数据保存在后端统一的存储中,从而应用仅仅包含商务逻辑。

Persistent multiprocess shared cache in Python with stdlib or minimal dependencies

我的未来我决定 提交于 2019-12-04 06:29:20
I just tried a Python shelve module as the persistent cache for data fetched from the external service. The complete example is here . I was wondering what would the best approach if I want to make this multiprocess safe? I am aware of redis, memcached and such "real solutions", but I'd like to use only the parts of Python standard library or very minimal dependencies to keep my code compact and not introduce unnecessary complexity when running the code in single process - single thread model. It's easy to come up with a single-process solution, but this does not work well current Python web

Failed to write session data (memcache)

我是研究僧i 提交于 2019-12-04 06:28:01
I'm noticing an intermittent issue with our Memcached session handler. The error that occurs is: Unknown: Failed to write session data (memcache). Please verify that the current setting of session.save_path is correct. Notes: It seems to be an intermittent issue that occurs 5 or 6 times a day to various users. Memcached is not localhost. i.e. It's on a different server than the web server. I'm using the Memcache extension (as opposed to the MemcacheD extension). I'm using the tcp prefix. If you look at this question , you'll see that the "fix" was to put tcp:// a prefix if you're using the

Using memcache inside Google Compute Engine with PHP

故事扮演 提交于 2019-12-04 05:20:44
I am trying to test using App Engine's Memcache with our servers running under Compute Engine. Currently we just have a couple VM instances which run Memcache where we call: $memcache->addServer('memcache', 11211); to reference each server. Looking at Google's sample code, it doesn't mention anything about what server we should call. I tried to test the below code from their document but it errors on creating the object. I understand that I might have to include a class, but it didn't mention anything in the document or what server to call. Can anyone help? <?php header('Content-Type: text

PHP中的Memcache详解

a 夏天 提交于 2019-12-04 05:02:47
一、Memcache简介 Memcache是danga.com的一个项目,最早是为 LiveJournal 服务的,目前全世界不少人使用这个缓存项目来构建自己大负载的网站,来分担数据库的压力。它可以应对任意多个连接,使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间,然后建立一个HashTable,Memcached管理这些HashTable,所以速度非常快。 二、Memcache和memcached的区别 为什么会有Memcache和memcached两种名称?其实Memcache是这个项目的名称,而memcached是它服务器端的主程序文件名,知道我的意思了把~~~~。一个是项目名称,一个是主程序文件名,在网上看到了很多人不明白,于是混用了。 三、Memcache的服务器端和客户端安装 分为两个过程:memcache服务器端的安装和memcached客户端的安装。 所谓服务器端的安装就是在服务器(一般都是linux系统)上安装Memcache实现数据的存储。 所谓客户端的安装就是指php(或者其他程序,Memcache还有其他不错的api接口提供)去使用服务器端的Memcache提供的函数,需要php添加扩展。 四、PHP的Memcache客户端所有方法总结 memcache函数所有的方法列表如下: Memcache::add – 添加一个值,如果已经存在

What is the best way to store an ActiveRecord object in memcached?

℡╲_俬逩灬. 提交于 2019-12-04 04:07:21
There are currently two problems with storing ActiveRecord objects in memcached. The Undefined Class/Module problem ( Google search ). From what I've read up, this is still a bug that nobody has a real good solution for. The cache_fu plugin has probably the best solution for this, wrapping its retrieve call in a block that tries to catch this error, parses the message and tries to load the undefined class/module. The infamous LH ticket #1339 ( LH Ticket ). This bug will only happen when you have cache_classes set to FALSE (development, test). After googling for weeks, I still haven't found a

memcached全面剖析–3.memcached的删除机制和发展方向

拥有回忆 提交于 2019-12-04 03:44:36
版权声明 :可以任意转载,但转载时必须标明原作者charlee、原始链接 http://tech.idv2.com/2008/07/16/memcached-003/ 以及本声明。 下面是《memcached全面剖析》的第三部分。 memcached是缓存,所以数据不会永久保存在服务器上,这是向系统中引入memcached的前提。 本次介绍memcached的数据删除机制,以及memcached的最新发展方向——二进制协议(Binary Protocol) 和外部引擎支持。 memcached在数据删除方面有效利用资源 数据不会真正从memcached中消失 上次 介绍过, memcached不会释放已分配的内存。记录超时后,客户端就无法再看见该记录(invisible,透明), 其存储空间即可重复使用。 Lazy Expiration memcached内部不会监视记录是否过期,而是在get时查看记录的时间戳,检查记录是否过期。 这种技术被称为lazy(惰性)expiration。因此,memcached不会在过期监视上耗费CPU时间。 LRU:从缓存中有效删除数据的原理 memcached会优先使用已超时的记录的空间,但即使如此,也会发生追加新记录时空间不足的情况, 此时就要使用名为 Least Recently Used(LRU)机制来分配空间。 顾名思义,这是删除

Is it okay to save lots of information in $_SESSION?

家住魔仙堡 提交于 2019-12-04 03:42:57
I need to store many arrays in $_SESSION to prevent retrieving information from MySQL. Is it okay? How much is "too much" information in $_SESSION or there isn't any "too much"? Thanks. P.S. Or it's better to use http://php.net/manual/en/book.memcache.php ? The limit of data you can store inside a session is limited by the session storage layer. The default sessions store is the file-system and one session is stored into one file. The name of the session variable/array-key is stored as well as it's data in a serialized form . A pipe symbol separates variable names and values from each other.

从RDBMS到NoSQL的架构演化

白昼怎懂夜的黑 提交于 2019-12-04 03:22:22
1. 从RDBMS到NoSQL的架构演化 互联网时代背景下大机遇,为什么用nosql 1 单机MySQL的美好年代 在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。 在那个时候,更多的都是静态网页,动态交互类型的网站不多。 上述架构下,我们来看看数据存储的瓶颈是什么? 1.数据量的总大小 一个机器放不下时 2.数据的索引(B+ Tree)一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 如果出现了上述1 or 3个上述瓶颈,架构开始演化到下一个阶段: 2 Memcached(缓存)+MySQL+垂直拆分 后来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展