Skip to main content

Home/ Arquitectura?/ Group items tagged cache

Rss Feed Group items tagged

Pablo Lalloni

Polipo - a caching web proxy - 1 views

  •  
    "Polipo is a small and fast caching web proxy (a web cache, an HTTP proxy, a proxy server). While Polipo was designed to be used by one person or a small group of people, there is nothing that prevents it from being used by a larger group. Polipo has some features that are, as far as I know, unique among currently available proxies: Polipo will use HTTP/1.1 pipelining if it believes that the remote server supports it, whether the incoming requests are pipelined or come in simultaneously on multiple connections (this is more than the simple usage of persistent connections, which is done by e.g. Squid); Polipo will cache the initial segment of an instance if the download has been interrupted, and, if necessary, complete it later using Range requests; Polipo will upgrade client requests to HTTP/1.1 even if they come in as HTTP/1.0, and up- or downgrade server replies to the client's capabilities (this may involve conversion to or from the HTTP/1.1 chunked encoding); Polipo has complete support for IPv6 (except for scoped (link-local) addresses). Polipo can optionally use a technique known as Poor Man's Multiplexing to reduce latency even further. In short, Polipo uses a plethora of techniques to make web browsing (seem) faster."
Pablo Lalloni

9 Docker Recipes for Java EE Applications | Voxxed - 0 views

  •  
    "A typical Java EE application consists of an application server, such as WildFly, and a database, such as MySQL. In addition, you might have a separate front-end tier, say Apache, for load balancing a number of application server. A caching layer, such as Infinispan, may be used to improve overall application performance. Messaging system, such as ActiveMQ, may be used for processing queues. Both the caching and messaging components could be setup as a cluster for further scalability. This Tech Tip will show some simple Docker recipes to configure your containers that use application server and database. Subsequent blog will cover more advanced recipes that will include front-end, caching, messaging, and clustering. "
Pablo Lalloni

ben-manes/caffeine: A high performance caching library for Java 8 - 0 views

  •  
    "Caffeine is a high performance, near optimal caching library based on Java 8."
Pablo Lalloni

InfoQ: Grails Best Practices - 0 views

  • Prefer dynamic scaffolding to static scaffolding until the former no longer satisfies your requirements. For example, if only “save” action needs to be modified, you can override just that “save” action and generate scaffolded code dynamically at runtime.
  • To install any plugin in your application, it's better to declare it in BuildConfig.groovy rather than using the install-plugin command. Read this thread for a detailed explanation.
  • Always ensure that you include an externalized config file (even if it's an empty file), so that any configuration that needs to be overridden on production can be done without even generating a new war file.
  • ...2 more annotations...
  • Keep personal settings (such as local database username or passwords, etc) in a <Local>Config.groovy file and add to version control ignore list, so that each team member can override configuration as per their specific needs.
  • In Grails 2.0 “grails.hibernate.cache.queries = true" by default, which caches queries automatically without a need to add cache:true. Set it to false, and cache only when it genuinely helps performance.
  •  
    This article is a basic list of best practices that our Grails projects follow, gathered from mailing lists, Stack Overflow, blogs, podcasts and internal discussions at IntelliGrape.
Pablo Lalloni

Rationale - Datomic - 0 views

  •  
    "Datomic is a distributed database designed to enable scalable, flexible and intelligent applications, running on next-generation cloud architectures. It does this by: Bringing declarative data manipulation into the application, and the data with it Getting time, process and perception right Process (writes) require coordination Perception (reads) require none The past doesn't change Leveraging immutability, and a sound model of state Datomic has: ACID Transactions Joins A sound data model A logical query language - Datalog Thus, Datomic avoids the compromises and losses of many NoSQL solutions. In addition, it offers flexibility and power over the traditional model in supporting: Hierarchy Multi-valued attributes Minimal schema Reliable operation on unreliable, ephemeral cloud instances Time Datomic avoids manual caching and replication, complex configuration, sharding (automatic or manual), logging, locking, latching and disk management of traditional servers."
Pablo Lalloni

Colossus - 0 views

  •  
    "Colossus is a lightweight framework for building high-performance applications in Scala that require non-blocking network I/O. In particular Colossus is focused on low-latency stateless microservices where often the service is little more than an abstraction over a database and/or cache. For this use case, Colossus aims to maximize performance while keeping the interface clean and concise."
munyeco

The Twelve-Factor App - 2 views

shared by munyeco on 20 Jul 14 - No Cached
  • The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
  •  
    "Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should
  •  
    Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.
1 - 8 of 8
Showing 20 items per page